通过中转站用 Claude Code:哪些功能和直连一样,哪些不一样,出了问题怎么判断是谁的
Claude Code 官方有一份写给网关的兼容性说明:哪些请求头和字段必须原样转发,漏了会坏什么。本站对照这份说明,在一家中转站上把十几项功能实测了一遍:大部分正常,遇到过三处不一样的地方,其中子代理换模型后主会话报 400 的一处,中转站已经修好。附判断问题出在哪一方的办法。
本站已实测,测试日期:2026-10-12。
本页目录(10 节)
这篇教程解决一个问题:通过中转站用 Claude Code,哪些功能和直连官方一样,哪些可能不一样;出了问题,怎么判断是中转站的问题、Claude Code 的问题,还是你自己配置的问题。
接入的步骤本站另有一篇:Claude Code 接入中转站。这一篇讲接上之后的事。
Claude Code 官方有一份专门写给网关运营方的兼容性说明,列出了它会发哪些请求、哪些头和字段必须原样转发、漏掉会坏什么。中转站在技术上就是这样一个网关。读懂这份说明,你就知道哪些功能依赖中转站的实现。
本站这个系列的实测都是通过酷站AI 做的。下面把这一路测到的,加上专门补测的几项,放在一起。
| 实测环境 | |
|---|---|
| 日期 | 2026-10-11,子代理换模型和 Haiku 5.5 两项在 10 月 12 日复测 |
| 版本 | Claude Code 2.1.296 |
| 系统 | Ubuntu 24.04 |
| 中转站 | 酷站AI,接口地址 https://api.koozhan.com,一把有额度上限的 key |
| 凭据放在 | ~/.claude/settings.json 的 env 里,变量是 ANTHROPIC_AUTH_TOKEN |
先说清楚范围:只测了这一家、这一把 key。 下面“不一样”的地方,换一家中转站、甚至同一家换一种 key,结果都可能不同。
1确认你真的连到了中转站
在会话里输入 /status:
Version: 2.1.296
Session kind: interactive
cwd: /home/ccdemo/demo/a2-express
Auth token: ANTHROPIC_AUTH_TOKEN
Anthropic base URL: https://api.koozhan.com
Model: Default (claude-opus-5-5)
Setting sources: User settings, Project local settings
Managed settings (remote): not fetched — not available with a custom ANTHROPIC_BASE_URL
Organization policy: not fetched with a custom ANTHROPIC_BASE_URL
Auto mode server: Enabled
按官方文档,看两行:
Anthropic base URL显示的是你的中转站地址,说明请求确实发到了那里。没有这一行,说明变量没有传进这个会话。Auth token(或者API key)后面是你设的那个变量名,说明用的是中转站的凭据,而不是以前保存的官方登录。
连不上的时候,官方给的办法是先绕开 Claude Code,直接向中转站发一个最小的请求:
curl -sS -w '\n%{http_code}\n' -X POST "$ANTHROPIC_BASE_URL/v1/messages" \
-H "Authorization: Bearer $ANTHROPIC_AUTH_TOKEN" \
-H "anthropic-version: 2023-06-01" \
-H "content-type: application/json" \
-d '{"model": "claude-sonnet-4-6", "max_tokens": 1, "messages": [{"role": "user", "content": "."}]}'
返回以 {"id":"msg_ 开头的 JSON,说明地址和凭据都对。即使返回的是“不认识这个模型”,也说明地址和凭据是通的。返回 401 是凭据被拒绝,先试试换另一个变量(ANTHROPIC_API_KEY)。这条命令我们没有单独跑,因为不想把 key 导出到 shell 里;我们用 /status 和实际的对话确认的连接。
官方要求网关做到什么
这一节是读懂后面的基础。官方的兼容性说明里,和使用者关系最大的几条:
| 官方的要求 | 做不到会怎样 |
|---|---|
anthropic-beta 和 anthropic-version 两个请求头原样转发 |
一些能力悄悄失效;或者头被去掉、对应的字段还在,直接报 400 |
| 流式响应边到边转,不要攒完再发 | Claude Code 卡住不动 |
保留流里的 ping 事件 |
模型长时间思考时,连接被判定为超时 |
cache_control 标记原样转发 |
不报错,但每一轮都按没有缓存的输入计费 |
| 上游返回的错误内容原样转发 | Claude Code 靠错误的原文来识别并自动恢复。改写之后它认不出来,就不会自动重试 |
提供 count_tokens 接口(可选) |
不报错,/context 里的数字变成估算值 |
提供 /v1/models 接口(可选) |
模型列表发现用不了 |
官方还说明了一点:Claude Code 把自定义地址的网关当作 Anthropic 格式的接口,会把发给官方的那一整套头和字段都发过去。网关后面如果接的是别的云厂商,中间的差异要由网关来抹平。
所以“这家中转站支不支持 Claude Code”不是一个是或否的问题。基本的对话能通,不代表上面每一条都做到了。
我们测到的:一张总表
| 功能 | 通过这家中转站的表现 | 在哪测的 |
|---|---|---|
| 对话、读代码、改文件、跑命令 | 正常 | 第一个小时 |
| 提示词缓存 | 正常。/cost 显示 92% 的输入来自缓存 |
同上 |
| 权限模式切换、plan 模式 | 正常 | 权限模式 |
| auto 模式 | 能用。会弹一次关于分类器计费的提示 | 见下文 |
claude -p 不带界面运行 |
正常。默认的权限模式是 auto | 权限模式那篇 |
| Hooks | 正常 | Hooks 实战 |
| MCP 服务器 | 正常 | MCP 实战 |
| 子代理,和主会话用同一个模型 | 正常 | 子代理实战 |
| 子代理,用另一个模型 | 现在正常。第一次测时主会话会报 400,中转站修复后复测三次都正常 | 见下文 |
| 换模型:Sonnet 5.5 | 正常 | 本篇 |
| 换模型:Haiku 5.5 | 这把 key 调不了 | 见下文 |
| 模型列表发现 | 正常。打开开关后 /model 里多出中转站提供的模型 |
本篇 |
| 联网搜索 | 能用,回答带了来源网址 | 本篇 |
/goal |
跑通 | 本篇 |
| 组织的托管设置、组织策略 | 不获取。/status 里写明了 |
本篇 |
Hooks 和 MCP 正常是意料之中的:它们在你自己的机器上运行,不经过中转站。
下面展开三处。第一处中转站已经修好,留在这里是因为它正好能说明这类问题长什么样、怎么缩小范围。
不一样的地方一:子代理换模型,主会话报 400(已修复)
这是我们遇到的影响最大的一处。我们给一个子代理指定了 model: sonnet,主会话用的是 Opus。派出子代理之后:
● test-reviewer(Review redirect deprecation tests)
⎿ Backgrounded agent (↓ to manage · ctrl+o to expand)
● API Error: 400 当前会话的 thinking 签名属于其他模型,请执行 /clear 新建空会话后重试
子代理自己跑完了,/cost 里能看到 claude-opus-5-5 和 claude-sonnet-5-5 都产生了用量,所以不是这把 key 调不了 Sonnet。但主会话从这一刻起,每发一次请求都是这条 400,子代理的结论拿不回来。
它不是每次都出。 修复之前,同样的配置我们跑了三次,两次报错,一次正常。对照会话的记录,区别在派出子代理之前,主会话有没有产生过思考块:
| 哪一次 | 派出子代理之前,主会话有没有思考块 | 结果 |
|---|---|---|
| 修复前,第一次 | 有 | 400,主会话卡住 |
| 修复前,第二次 | 没有 | 正常,之后主会话产生了思考块也没事 |
| 修复前,第三次 | 有 | 400,主会话卡住 |
| 修复后,三次 | 都有 | 都正常 |
修复前看起来的规律是:主会话的历史里已经带着思考块,这时同一个会话里出现了另一个模型的请求,主会话的下一次请求就被拒绝。主会话哪一轮会思考由模型自己决定,所以用的人看到的是有时行、有时不行。只测一次、又碰巧没有思考块,就会以为没问题。
中转站一方随后做了修复。10 月 12 日我们专挑之前会出错的情况复测:让主会话先读文件、先下判断,再派子代理。三次主会话在派出之前都有思考块,三次都拿到了子代理的结论,接着追问也正常。其中一次的 /cost:
Usage by model:
claude-opus-5-5: 1.3k input, 2.4k output, 174.6k cache read, 38.8k cache write ($0.2823)
claude-sonnet-5-5: 242 input, 4.8k output, 18.4k cache read, 9.7k cache write ($0.0750)
样本都很少:修复前三次,修复后三次。
如果你用的中转站出现这条报错:输入 /clear 清空对话,把子代理改成 model: inherit(和主会话同一个模型)。在别的地方指定了第二个模型的(skill、CLAUDE_CODE_SUBAGENT_MODEL),也是先把模型统一。代价是不能把简单的活交给便宜的模型来省钱。
当时为什么会一直卡住,这是我们的推断,没有证实。 官方的兼容性说明里有这样一段:上游因为思考签名而拒绝请求时,Claude Code 会去掉之前的思考块再重试,并在之后的请求里都不带它们。它是靠识别错误的原文来做这件事的,所以文档要求网关把错误内容原样转发。我们看到的这条 400 是中文的,不是上游的原文。不管它是网关自己判断后生成的,还是改写了上游的报错,Claude Code 都认不出这是一个可以自动恢复的错误,于是每次都原样重发、每次都失败。
不一样的地方二:auto 模式的分类器计费提示
第一次在 auto 模式下执行需要审查的动作时,会话里弹出一个提示,要按回车才继续:
We're changing auto mode to no longer charge for classifier requests in Claude Code.
However, this session isn't eligible because your requests go through api.koozhan.com,
which isn't compatible with this update.
Nothing breaks: auto mode keeps working, and its classifier requests are billed as before.
意思是:auto 模式里审查动作的分类器,官方正在改成由服务器在同一次请求里顺带完成,不另外收费。这要求网关把一个它可能不认识的请求字段(safeguards)原样传过去,再把响应里对应的字段(safeguard_results)原样传回来。做不到的话,Claude Code 就自己发分类器请求,这些请求计入你的 token 用量。
按官方文档:
- 什么都没坏,按回车继续就行。
- 订阅账号(Pro、Max、Team)不会看到这个提示。
- 已经知道网关做不到的话,启动前设
CLAUDE_CODE_AUTO_MODE_SERVER=0,提示不再出现,计费方式不变。官方注明这是临时的设置。
有一个细节值得一提:/status 里有一行 Auto mode server: Enabled。按我们的理解,它说的是 Claude Code 会去请求服务器端的检查,不代表这个检查真的到达了你的会话:我们的 /status 显示 Enabled,同时也弹出了上面那个提示。
不一样的地方三:有的模型调不了
指定 Sonnet 5.5 是正常的:
claude -p --model claude-sonnet-5-5 "只回复两个字:收到"
换成 Haiku 5.5:
There's an issue with the selected model (claude-haiku-5-5). It may not exist or you may not have access to it.
Run --model to pick a different model.
用别名 --model haiku 也一样,它解析成的就是 claude-haiku-5-5。
这多半和我们这把 key 开通的渠道有关,不一定是这家中转站不提供。但它提醒了一件事:Claude Code 不只在你选的那个模型上发请求。 官方文档提到它有一个“小而快的模型”,用来做后台的事,比如给对话生成摘要、判定 /goal 的条件有没有满足。这个位置默认用的是 Haiku 那一档。
我们测了 /goal,在这把 key 上是跑通的,所以没有观察到 Haiku 调不了造成的实际故障。如果你遇到后台功能异常,文档给了一个变量可以把这个位置指到你确定能用的模型上:
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-sonnet-5-5
我们设了它再跑 /goal,同样正常。
看看中转站到底提供哪些模型
Claude Code 可以去问中转站有哪些模型,把它们加进 /model 的列表。这个功能默认是关的,要自己打开:
CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1 claude
打开之后 /model 里多出了标着“From gateway”的条目:
❯ 1. Default (recommended) ✔ Use the default model (currently Opus 5.5) · $4/$20 per Mtok
2. Opus Opus 5.5 · Best for everyday, complex tasks · $4/$20 per Mtok
3. Fable 5 From gateway (claude-fable-5)
4. Fable 5.1 From gateway (claude-fable-5-1)
5. Sonnet Sonnet 5.5 · Efficient for routine tasks · $2/$10 per Mtok
6. Haiku Haiku 5.5 · Fastest for quick answers · $0.10/$0.50 per Mtok
7. Haiku 4.5 From gateway (claude-haiku-4-5-20251001)
8. Opus 4.5 From gateway (claude-opus-4-5-20251101)
9. Opus 4.6 From gateway (claude-opus-4-6)
… +6 models
两点说明:
- 列表里显示的价格是官方的价格,不是中转站的。
- 第 6 项 Haiku 是 Claude Code 内置的条目,不是中转站报上来的。出现在列表里不等于能用,我们上面就调不了它。
官方文档解释了为什么默认关着:很多网关背后是一把共用的 key,默认打开会把这把 key 能访问的所有模型都展示给每个用户。
常见报错,按官方文档对一下
下表摘自官方的排错表,挑了和中转站关系最大的几条:
| 你看到的 | 原因 | 怎么办 |
|---|---|---|
401,提示 token 无效 |
凭据不是这家发的,或者放在了它不读的请求头里 | 换另一个变量试试:ANTHROPIC_AUTH_TOKEN 和 ANTHROPIC_API_KEY 对应的请求头不一样 |
API returned an empty or malformed response (HTTP 200) |
网关或中间的代理返回了不是接口响应的东西,常见的是一个 HTML 报错页或登录页 | 用上面的 curl 命令直接测,看返回的到底是什么 |
400,提到 context_management、Extra inputs are not permitted 或其他不认识的字段 |
网关把请求转给了一个不接受这些字段的上游 | 设 CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1,会去掉大部分预发布的字段 |
400,提到 thinking 或 adaptive |
上游的模型版本不接受自适应思考 | 这要中转站升级上游 |
400,用中转站自己的话说超出了上下文或 token 上限 |
网关设了比模型原生窗口小的上限,并且改写了报错,Claude Code 认不出来,不会自动压缩重试 | 运行 /compact 恢复。预防的办法是把 CLAUDE_CODE_AUTO_COMPACT_WINDOW 设成网关的上限 |
| 卡住不动,很久没有输出 | 网关把流式响应攒完了才发,或者去掉了 ping 事件 |
这要中转站改 |
还有一种问题不报错,只是多花钱:缓存没有生效。 表现是每一轮的输入 token 都很高,几乎没有缓存读取。检查办法是看 /cost 里的这一行:
Prompt cache (main): 14 requests · 92% of input tokens from cache · no misses · warm
我们这里是 92%,是正常的。如果你看到的比例很低,而对话已经进行了好几轮,就值得去问中转站。
出了问题,怎么判断是谁的
按下面的顺序排查,大多数情况能分清:
- 看报错是谁的口吻。 Claude Code 自己的提示是英文的、格式固定。中文的报错,或者措辞明显不同的英文报错,是中转站那一层给的。
- 绕开 Claude Code 直接测。 用上面的 curl 命令。直接测也失败,问题在地址、凭据或者中转站,和 Claude Code 无关。
- 看
/status。 确认地址和凭据确实是你以为的那一套。 - 换一个模型再试。 换了就好,多半是那个模型在你的 key 上不可用。
- 缩小到一个功能。 只在用某个功能时出错(比如子代理、某个 MCP 服务器),先关掉它确认。
- 看调试日志。 用
claude --debug启动。
还要记得一类不属于任何一方的情况:订阅账号才有的功能,用中转站的 key 本来就没有。
选中转站时,可以多问几句
读完上面这些,“支持 Claude Code”这句话可以拆成几个更具体的问题去问:
- 流式响应是实时转发的吗?
- 请求头和不认识的字段是原样转发的吗?
- 上游的报错是原样返回的吗?
- 提示词缓存生效吗?
- 我这把 key 能用哪些模型,包括 Haiku 这一档吗?
至于中转站给的是不是它声称的那个模型,是另一个问题,这篇没有涉及。本站的中转站排行榜用的是 Veridrop 的检测数据,怎么挑见怎么选中转站。
这次实测没有覆盖到的
- 只测了一家中转站、一把 key。 这是这篇最大的局限。表里的“正常”和“不一样”都不能直接套到别家。
- 子代理那条 400 的根因我们不知道。 触发的规律是修复前三次运行对照出来的,为什么卡住写的是推断;修复之后也只跑了三次。
- 没有测 fast mode、VS Code 扩展和桌面应用。 桌面应用接中转站的方式和命令行不同,见Claude 桌面应用接入中转站。
- 没有测长时间的会话,所以上下文上限、自动压缩在这家中转站上的表现没有观察到。
- 没有和直连官方做对照。 我们没有官方账号可以在同一环境下对比,“和直连一样”指的是和官方文档描述的行为一致。