Claude Code 切换中转站后 401 不断：先查环境变量覆盖顺序

本文摘要：切换中转站后 claude 反复 401，多因后加载的赋值覆盖了刚改的密钥。脚本自发现打印进程环境与各启动文件赋值行，再用 env -i 二分定位覆盖来源。

一、问题与结论

在 ~/.zshrc 里把 ANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN 换成新中转站的值，source 后新开终端跑 claude，仍然 401；换第二把、第三把密钥照样，偶尔还夹着 model not found。这两个键名属于常见写法，是待验证假设，下文脚本按自发现打印，不以断言为准。

结论：401 不是密钥错，而是你改的不是生效的那处变量。启动文件按顺序逐个执行，同名变量后赋值覆盖先赋值；你改的行在前面，后面某行会把旧值又 export 回去。先打印进程实际携带的环境，再倒推是谁写的，比继续换密钥快。

另有三处常被忽略的凭据来源：从 IDE / GUI 启动的终端继承登录会话时的旧环境；MCP 服务器配置里可能另存一份 API 凭据或请求头；登录态与环境变量并存时实际生效者未知。项目级 .claude/settings.json 与用户级 ~/.claude/settings.json 的相对优先级同属待本地实测项，本文不给定论。

二、排查与选择依据

先二分，把「密钥错」和「覆盖错」拆开，再动配置：

判定规则：第 2 步的值 ≠ 你刚改的那处 → 覆盖问题；env -i 下不再 401 → 继承的旧变量；干净环境仍 401 → 才把怀疑转向中转站侧。

替代方案与取舍

单点管理与本文不冲突：前者是长期收敛，后者是当下定位。只做单点管理而不打印继承链，出问题时你仍不知道是哪一行。

三、关键原理

终端进程的环境 = 启动文件按固定顺序逐个执行的结果，同名变量后赋值覆盖先赋值，这是 shell 通用行为，可自证。zsh、bash 各自的加载顺序因 shell 与发行版而异，本文不引用未给出的文档，一律以脚本第 2 步的实际输出为准。Windows 下 $env:ANTHROPIC_BASE_URL 只对当前 PowerShell 会话有效，新开进程继承的是 explorer.exe 那份用户/系统环境变量，两者并存时同样以实测为准。

claude 自述为「运行在终端里的 agentic 编码工具」，入口即终端——这正是覆盖顺序成为问题的结构性前提。其仓库自述未涉及中转站或 API 网关鉴权，切换后的 401 属于用户侧集成问题，官方侧没有对应说明，本文也不给中转站推荐。

多 harness 并存时更复杂：affaan-m/ECC 自述适配 Claude Code、Codex、Opencode、Cursor 等多个工具，同一台机器上可能有多个进程在读写 API 凭据，覆盖来源会多出一层。

四、可运行示例

环境：macOS / Linux 的 bash 或 zsh；Windows 用 $env: 与「环境变量」GUI 替代第 1、2 步的 env 与 grep。输入：你的 shell 启动文件（任意已存在者即可）。步骤：存为 claude-env-audit.sh，执行 bash claude-env-audit.sh。

#!/usr/bin/env bash
# claude-env-audit.sh
set -u

echo "== 1) 当前进程实际携带的变量（自发现） =="
hits=$(env | grep -Ei 'anthropic|claude' || true)
if [ -n "$hits" ]; then
echo "$hits" | sed -E 's/(TOKEN|KEY)=.{4}.*/\\1=****/'
else
echo "（未发现匹配项）"
fi

echo "== 2) 各启动文件里的赋值行 =="
for f in "$HOME/.zshenv" "$HOME/.zprofile" "$HOME/.zshrc" "$HOME/.zlogin" \\
"$HOME/.bash_profile" "$HOME/.bashrc" "$HOME/.profile"; do
[ -r "$f" ] || continue
hits=$(grep -niE 'anthropic|claude' "$f" 2>/dev/null \\
| sed -E 's/(TOKEN|KEY)=.{4}.*/\\1=****/')
[ -n "$hits" ] && { echo "— $f"; echo "$hits"; }
done

echo "== 3) 清空继承环境后复跑 =="
env -i PATH="$PATH" HOME="$HOME" TERM="$TERM" claude –version

预期输出：第 1 步列出进程内所有匹配 anthropic|claude 的变量（TOKEN、KEY 值已脱敏），第 2 步列出出现赋值的文件与行号，第 3 步打印 claude 版本号——以你本地 claude –version 的输出为准，本文所有结论附实测日期。实际输出：待实测。脚本设计成「输出键名」而非「断言键名」，键名随版本变化时仍能跑通、结论仍能自证。

常见失败：第 2 步出现多处赋值，且第 1 步的值与你刚改的那处不一致。原因：后加载的启动文件把旧值又 export 回去。修复：删掉后加载的那行，或把赋值收敛到唯一文件。

再用 curl 二分（路径按你中转站确认后的写法补全，本脚本不预设）：

curl -s -o /dev/null -w 'HTTP %{http_code}\\n' \\
-H "Authorization: Bearer $YOUR_TOKEN" "$YOUR_BASE_URL/<经确认的路径>"

五、验证结果与边界

以下按待复现假设列出，文中只呈现实际跑通的几条：

• A 继承来源不同：从 IDE / GUI 启动的终端，环境是登录会话时的旧值，与新开 shell 看到的不同。
• B 凭据不止一处：MCP 配置里另存一份凭据或请求头，换中转站后未同步。
• C 登录态与密钥并存：需用 env -i 二分确认实际生效者。
• D 密钥本身无效：干净环境仍 401，此时才查中转站侧，而不是继续调变量。

不适用本文方案的情况：你本就想改接入策略（账号体系、计费与网络路径都会变），或只想按仓库隔离凭据——后者应走项目级 settings.json，代价是每个仓库各维护一份，且相对用户级的实际优先级需本地实测。这与 cc-switch 一类工具处理的「工具↔工具」隔离是不同层面：本文解决的是「进程↔环境」，即单个 claude 启动时究竟读到哪一层。

思考

• 项目级 settings.json 与 shell 环境变量同时给出端点时，让谁赢才能兼顾团队共享与个人切换？
• wrapper 注入清单漏项，能否用启动后自打印环境代替手工维护？

参考资料

• anthropics/claude-code
• affaan-m/ECC