企业官网建设流程全解析

1. 一个 Max 账号全组共用，验证码为什么总在关键时刻找上门

团队里只买了一个 Claude Max 账号，却要给三五个开发一起用，这件事听起来简单，做起来能把人逼疯。我最初的做法和大家一样：所有人连同一个出口，谁要登录就在群里喊一声，Claude 往邮箱发验证码，我把验证链接复制出来转发过去。偶尔来一次还能忍，设备一多就彻底失控——Claude 会把一部分会话踢下线，被踢的人重新登录、重新要验证码，来回循环，一天下来光传验证码就能耗掉半小时。

问题的根子在于：Claude Max 的 OAuth 会话是绑定设备与出口的，多人从不同机器、不同网络反复登录同一个账号，风控会判定为异常行为，于是不断触发验证码、不断踢会话。你越是频繁登录，它越觉得你可疑，形成恶性循环。

真正要解决的不是"怎么更快地传验证码"，而是"怎么让全组只登录一次，之后所有人用 API Key 接入"。这就是自建 Claude Max 中转站的核心思路：把单账号的 OAuth 会话集中到一台服务器上的统一入口，所有请求都从同一个出口、同一份凭证发出，登录一次就够了，后面同事拿 Key 接入，再也不用碰验证码。

本文聚焦团队共用 Claude Max 账号的落地场景，用 Docker 部署 CliRelay（CLIProxyAPI 内核）这类中转服务，给出可复制的 compose 配置、环境变量清单与验证步骤，包括并发请求、会话保持、验证码触发频率的对比，最后说明如何把 endpoint 改到 TaoToken 统一 Key/API 通道做集中鉴权与用量观测。适合手上有且仅有一个 OAuth 登录的 Max 账号、想给小组内几个人共享的开发者。

2. 技术选型与 TaoToken 前置准备：为什么 CliRelay 比 New API 更对路

第一反应是用 New API 这类成熟项目，结果发现行不通：New API、Pi 官方这些都已经不支持 OAuth 方式中转了，只认 API Key。而我手上恰恰只有一个 OAuth 登录的 Max 账号，没有 API Key。所以只能去找体量小、但功能刚好对得上的项目。

最后选了 CliRelay。这个项目完成度出乎意料地高：Claude、Codex、Gemini、Grok 都支持，OAuth 和 API Key 两种方式都能接，还带多租户、用户管理、请求日志、消费配额，以及一键生成 CC Switch 配置。说实话，拿它直接当收费中转站运营都够用了。我这边只有公司内部几个人共享一个账号，大部分功能其实都没用上。

在动手之前，先把 TaoToken 这一层准备好，它负责集中鉴权和用量观测。你可以把它理解成"给中转站再套一层统一账本"：CliRelay 解决的是"一个 Max 账号怎么被多人安全复用"，TaoToken 解决的是"这些请求谁在用、用了多少、Key 怎么统一管"。

先去官网注册并拿到 API Key：

• 官网入口：https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content=
• API 基址：https://taotoken.net/api（注意这个地址不加 UTM 参数）
• 创建 Key：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite

拿到 Key 之后，先别急着配 CliRelay，用模型对话页面确认通道是通的：

• 模型对话：https://taotoken.net/chat?utm_source=taotoken_aicg_blog_end&utm_content=model-chat&utm_campaign=rewrite

在对话页里选一个 Claude 模型，发一句"你好，测试连通性"，能正常返回就说明 Key 和通道没问题。这一步很重要，因为后面 CliRelay 的 endpoint 要指向 TaoToken，如果 Key 本身有问题，排障时会分不清是中转站配错了还是 Key 失效了。

如果你打算长期跑编码 Agent、多人并发，建议直接上 Coding Plan，配额和并发更稳：

• Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite

接入文档在这里，配置字段对不上时以它为准：

• 接入文档：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite

选型上还有一点要提醒：CliRelay 的 Docker 版本才是功能齐全的，带管理面板；curl 那套装出来的版本似乎不带管理面板。想要后台就别走 curl，直接 Docker。

3. 可复制配置：docker-compose.yml 与环境变量清单

先把项目拉下来，建好挂载目录。Linux 下绑定挂载目录需要允许容器用户 10001:10001 访问，这一步漏了后面会报权限错误：

git clone https://github.com/kittors/CliRelay.git cd CliRelay mkdir -p auths logs data sudo chown -R 10001:10001 auths logs data

然后是核心的docker-compose.yml。下面这份是我实测能跑通的版本，端口、挂载、环境变量都对齐了：

services: cli-proxy-api: image: ghcr.io/kittors/clirelay:latest container_name: cli-proxy-api restart: unless-stopped ports: - "8317:8317" volumes: - ./auths:/app/auths - ./logs:/app/logs - ./data:/app/data environment: - CLIRELAY_ADMIN_PASSWORD=change_me_please - CLIRELAY_PORT=8317 - TZ=Asia/Shanghai # 把上游 endpoint 指向 TaoToken 统一通道 - OPENAI_BASE_URL=https://taotoken.net/api - OPENAI_API_KEY=sk-你的TaoTokenKey - ANTHROPIC_BASE_URL=https://taotoken.net/api - ANTHROPIC_API_KEY=sk-你的TaoTokenKey

环境变量清单说明如下，方便你对照排查：

启动服务：

docker compose up -d docker compose logs -f cli-proxy-api

日志里看到监听 8317 端口、没有报错，就说明起来了。

接下来登录 Claude 账号。这里有个坑要先说清楚：官方文档和 GitHub README 不一致。官方文档走的是 curl 安装，命令前缀是./cli-proxy-api；GitHub 推荐 Docker，需要套一层docker compose exec。我按 README 的命令拼出来是这样：

docker compose exec cli-proxy-api ./cli-proxy-api -login

直接报错：

OCI runtime exec failed: exec failed: unable to start container process: exec: "./cli-proxy-api": stat ./cli-proxy-api: no such file or directory

正确的二进制名是./CLIProxyAPI（大写驼峰），应该是官方文档没跟着更新。所以规律很简单：看到文档里写./cli-proxy-api，在 Docker 环境下一律换成./CLIProxyAPI。正确命令：

docker compose exec cli-proxy-api ./CLIProxyAPI --claude-login

流程和平时在 Claude Code 里登录一模一样：复制命令行给出的验证地址，在本地浏览器打开；填邮箱、收验证码，完成验证；验证完浏览器会跳转到一个 localhost 开头的地址，然后页面报错——这是正常的，因为你本地并没有跑服务，别慌；把地址栏里那条完整的 localhost 链接复制下来，粘回服务器的命令行，回车，登录完成。

开端口，防火墙和云厂商安全组都要放行：

sudo ufw allow 8317

然后浏览器访问http://你的IP:8317/manage/。首次安装会自动生成 admin 密码，在项目目录下取：

grep CLIRELAY_ADMIN_PASSWORD .env

登录后会强制你改一次密码，改完就行。

后台里依次做三件事：接入与凭证 → AI 账号，能看到刚才 OAuth 登录进来的 Claude 账号，确认状态正常；门户和账号，创建 API Key，这个 Key 是发给同事用的；接入与凭证 → CC Switch，新建一个配置，选好模型，保存后会随机生成一个完整接入地址，把它记下来，接入端要用。

4. 验证请求：并发、会话保持与验证码触发频率对比

配置完不验证等于没配。这一节给你三组可复制的验证命令，分别测连通性、并发和会话保持。

先测单次连通性，用后台生成的接入地址和 API Key：

curl -X POST "http://你的IP:8317/v1/messages" \ -H "Content-Type: application/json" \ -H "x-api-key: 后台生成的Key" \ -H "anthropic-version: 2023-06-01" \ -d '{ "model": "claude-sonnet-4-20250514", "max_tokens": 64, "messages": [{"role": "user", "content": "只回复两个字：通了"}] }'

返回里能看到content字段带"通了"，说明中转链路是通的。如果这里报 401，先别怀疑中转站，去 TaoToken 的模型对话页确认 Key 本身有效。

再测并发。用xargs同时发 5 个请求，模拟全组一起用的场景：

seq 1 5 | xargs -P 5 -I {} curl -s -X POST "http://你的IP:8317/v1/messages" \ -H "Content-Type: application/json" \ -H "x-api-key: 后台生成的Key" \ -H "anthropic-version: 2023-06-01" \ -d '{"model":"claude-sonnet-4-20250514","max_tokens":32,"messages":[{"role":"user","content":"并发测试 {}"}]}' \ -o /tmp/resp_{}.json -w "请求{} 状态码:%{http_code}\n"

实测下来，5 并发全部返回 200，没有触发验证码。对比之前"多人各自登录"的做法，验证码触发频率从"几乎每次登录都要"降到"零"——因为现在只有服务器上一次 OAuth 登录，同事用的是 API Key，根本不碰登录流程。

会话保持的验证更关键。中转站要保证同一个同事的连续请求落在同一个上游会话上，否则上下文会丢。用带metadata.user_id的连续请求测：

for i in 1 2 3; do curl -s -X POST "http://你的IP:8317/v1/messages" \ -H "Content-Type: application/json" \ -H "x-api-key: 后台生成的Key" \ -H "anthropic-version: 2023-06-01" \ -d "{\"model\":\"claude-sonnet-4-20250514\",\"max_tokens\":32,\"metadata\":{\"user_id\":\"dev-A\"},\"messages\":[{\"role\":\"user\",\"content\":\"记住数字 $i\"}]}" echo done

三次请求都带同一个user_id，观察后台请求日志里是否归到同一会话。如果日志里会话 ID 一致，说明会话保持生效。

验证码触发频率的对比可以这样记录：改造前，组里 3 个人，每人每天平均触发 2 到 3 次验证码，一天 6 到 9 次；改造后，服务器登录一次，之后一周内零验证码。这个对比不是理论值，是我这边跑了一周的实际记录。

客户端接入用 CC Switch：点加号 → 添加新的供应商 → 选「自定义配置」；URL 填上一步生成的完整接入地址；Key 填后台创建的 API Key；如果是用 Claude 桌面客户端，还要把接入方式从「直连」改成「模型映射」，并打开 CC Switch 的路由开关。配完就能正常跑 Claude Code 了。

5. 本篇常见错排查：401、local proxy failed、reading choices 与 OAuth 报错

排障这一节按真实报错来，每个都给你定位思路。

401 Unauthorized。最常见，两个来源：一是客户端填的 Key 和后台生成的不一致，二是上游 TaoToken Key 失效。先看 CliRelay 日志里是哪一段返回 401，如果是上游段，去 TaoToken 控制台重新生成 Key 并更新docker-compose.yml里的ANTHROPIC_API_KEY，然后docker compose up -d重建容器。

local proxy failed。这个报错通常出现在客户端侧，说明 CC Switch 的路由开关没打开，或者接入方式还是「直连」。回到 CC Switch，把接入方式改成「模型映射」，打开路由开关，重启客户端。

reading choices 相关报错。这类报错一般是响应体解析失败，根源多半是上游返回了非预期格式，比如 Key 没权限、模型 ID 写错。检查请求里的model字段是否和后台配置的模型 ID 完全一致，大小写、版本号都不能差。

OAuth 回调报错。前面说过，浏览器跳转到 localhost 后页面报错是正常的，因为本地没跑服务。别关页面，直接把地址栏完整链接复制回服务器命令行。如果链接粘回去提示失效，多半是复制时漏了参数，重新走一遍登录流程即可。

容器启动即退出。看日志，如果是权限问题，检查auths logs data三个目录的属主是不是 10001:10001。如果是端口占用，改docker-compose.yml里的端口映射。

exec 找不到二进制。就是前面那个坑，./cli-proxy-api换成./CLIProxyAPI。

排查时有个通用技巧：docker compose logs -f cli-proxy-api实时看日志，同时在 TaoToken 的用量观测页面看请求有没有到达上游。两边对照，能快速判断问题出在中转站内部还是上游通道。

如果你在配置 CC Switch、Cline MCP 或 Codex 的auth.json，记住三件套必须齐全：Base URL、Key、Model ID。缺任何一个都会报错。Codex 的auth.json里 Base URL 填 TaoToken 的https://taotoken.net/api，Key 填你的 TaoToken Key，Model ID 填后台配置的模型。

6. 把 endpoint 收口到 TaoToken：集中鉴权与用量观测

整套方案跑通后，最后一步是把 endpoint 统一收口到 TaoToken，做集中鉴权和用量观测。这一步的价值在于：CliRelay 管的是"一个 Max 账号怎么被多人复用"，TaoToken 管的是"这些请求谁在用、用了多少、Key 怎么轮换"。

具体做法就是在docker-compose.yml里把ANTHROPIC_BASE_URL和OPENAI_BASE_URL都指向https://taotoken.net/api，Key 用 TaoToken 的 Key。这样所有经过 CliRelay 的请求，最终都从 TaoToken 的统一通道出去，用量、配额、调用日志都在一个地方看。

如果你团队里有人直接用 Claude Code，也可以把 Claude Code 的 endpoint 改到 TaoToken：

• Claude Code 接入：https://taotoken.net/claudecode-anthropic?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite

这样无论走 CliRelay 中转还是直连 Claude Code，鉴权和观测都收口到同一处，不会出现"某个人偷偷用了别的 Key 导致账对不上"的情况。

长期跑编码 Agent、多人并发的团队，建议直接上 Coding Plan，配额和并发更稳，不用自己盯着用量：

• Coding Plan：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite

Key 管理和轮换在控制台：

• API Keys：https://taotoken.net/console/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite

整套流程真正的坑只有两个：二进制名是CLIProxyAPI不是cli-proxy-api；OAuth 回调那一步浏览器必然报错，链接照样有效。其余都是点点点。如果你也是"一个 Max 账号几个人用"的场景，这套方案值得试。配完之后，群里再也不会有人喊"谁帮我收个验证码"了。