Claude 客户端可用、Claude Code 却返回 403 Request not allowed，是不少订阅用户会遇到的问题。文章从 CLI 代理继承、请求出口、IPv6/DNS、认证状态和账号合规几个层面给出排查顺序，并比较终端环境变量、settings.json、TUN 等做法的取舍，最后给出长期稳定运行的思路。
有开发者遇到这样的现象：Claude 的网页或桌面客户端可以正常使用，订阅也有效；但在本机运行 Claude Code 时，认证看似完成，请求却返回 API Error: 403 forbidden Request not allowed。同一账号换到另一台网络环境不同的机器上却能用。这个对比很关键：账号和认证未必是唯一问题，重点要查 Claude Code 的请求到底从哪个出口发出、有没有继承代理，以及服务端是否接受了这个来源。
403 不是“没登录”，而是服务端拒绝请求
401 通常和身份凭证有关，429 是限流，403 表示请求已经到达服务端，但服务端根据来源 IP、地区、账号状态、客户端行为或订阅权限拒绝。Request not allowed 是笼统提示，不能只靠它判断原因。
桌面客户端通常走系统代理，但终端里的 CLI 和 Node 进程不一定继承系统代理设置。很多“浏览器能用、命令行不能用”的场景，根源就在这里。
另外，通过修改 hasCompletedOnboarding 跳过引导，只是改变本地界面状态，不会改变服务端鉴权，也不建议作为长期方案。升级、缓存或重新登录后，状态可能不一致。
常见原因清单
- 终端没有设置
HTTPS_PROXY/HTTP_PROXY，或者设置了但启动 Claude Code 的终端不是同一个。 - 代理只接管了部分流量，IPv6、DNS 或某些分流规则让 API 请求走了直连。
- 代理出口被服务端判定为高风险，例如共享 IP、频繁切换、机房 IP 等。
- 账号、订阅、可用地区或使用条款不符合要求。
- 本地认证状态被跳过引导、旧缓存或多客户端登录弄乱。
- 使用自建中转、共享账号或公共 relay，导致 token 暴露、请求特征异常。
在合规前提下逐步排查
先确认账号、订阅和使用方式符合官方条款，并在官方支持的地区与环境使用。如果账号本身不符合可用地区或条款，改代理也不能解决问题，不建议尝试绕过。也不建议通过购买或共享账号、代充、公共中转、伪造信息等方式绕过限制；下面只讨论在合规网络环境里，排查客户端配置和请求路径。
1. 让终端进程真正继承代理
在启动 Claude Code 的同一个终端里设置环境变量，再启动命令。地址和端口换成你自己的本地代理：
export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890
检查是否生效：
env | grep -i proxy
新开终端后变量不会保留，需要写入 shell 配置，或在每次启动前设置。
2. 用 settings.json 固定 Claude Code 的代理
如果每次开终端都设置很麻烦，可以在 Claude Code 的用户配置文件里写环境变量。文件通常位于 ~/.claude/settings.json，修改前先备份：
{
"env": {
"HTTPS_PROXY": "http://127.0.0.1:7890",
"HTTP_PROXY": "http://127.0.0.1:7890",
"ALL_PROXY": "http://127.0.0.1:7890"
}
}
注意 JSON 不能有注释和尾逗号；改完完全退出 Claude Code 再重启。不同版本的配置字段可能变化，以官方文档为准。
3. 验证请求出口，而不是只看“能上网”
在终端里用同一代理请求 API 域名，观察是否能在代理下建立连接、返回头和直连是否不同：
curl -x http://127.0.0.1:7890 -I https://api.anthropic.com
这不等于验证权限成功；服务端仍可能返回 403。它的价值是判断请求有没有走代理、代理链路是否通。如果代理下仍然 403，而换一个合规网络环境正常，重点查出口；如果两边都 403，重点查账号、订阅和地区。
4. 检查 IPv6、DNS 和分流
有些全局代理只接管 IPv4。终端如果优先解析到 IPv6，可能绕过代理直连。检查代理是否处理 IPv6，或在系统层关闭 IPv6 优先。分流规则也要保证登录请求和 API 请求走同一出口，避免一个走代理、一个直连。
5. 重置认证状态
不要长期依赖跳过引导。先在客户端内退出登录，备份本地配置后重置，再走官方登录流程。多个终端、多个客户端同时登录时，尽量保持同一网络出口，减少状态冲突。
6. 对比不同网络环境，但不要频繁切换
同一账号在不同机器上表现不同，说明账号本身可能没有完全失效，差异在请求路径或出口。可以做一次对比测试：记录客户端版本、错误时间、请求域名、是否设置代理。不要为了试错频繁切换节点或反复重试，这可能让账号或 IP 更容易被风控。
几种做法的取舍
| 做法 | 优点 | 代价与风险 | 适用场景 |
|---|---|---|---|
| 终端环境变量 | 改动小，便于定位问题 | 只对当前终端生效 | 临时排查 |
| settings.json | Claude Code 启动时自动带上，较稳定 | 配置字段可能随版本变化 | 日常使用 |
| TUN/增强模式 | 能接管终端等不继承系统代理的流量 | 影响面大，权限和排障成本高 | 合规网络环境下、需要全局接管时 |
| 远程 Mac | 网络和在线时长稳定，适合长期任务 | 有延迟和成本，需注意数据安全 | 本地休眠、网络切换导致任务中断 |
| 自建中转/共享账号 | 看似方便 | 泄露凭证、违反条款、封号风险高 | 不建议 |
代理不是越全局越好。TUN 能解决“终端不走代理”的问题，但也可能把本地其他流量一起带走，增加排错难度。对多数人来说，先让 Claude Code 进程继承代理，比直接上全局 TUN 更可控。
不建议的做法
自建 relay、拼车、代充、买卖或共享账号，短期可能可用，但会把 token 暴露给第三方，也容易触发服务端风控。团队协作应走官方支持的组织或企业方案，让每个成员使用自己的合规账号。订阅渠道和价格会随平台、地区、税费变化，不要用旧截图判断，以官方结算页为准。
长期稳定运行的考虑
如果 Claude Code 需要长时间跑任务，本地机器休眠、网络切换、代理重连都会让会话中断。可以把运行环境放到网络稳定的远程 Mac 上，通过远程桌面连接，保持长期在线。例如新加坡独享远程 Mac：整台 Mac mini 放在机房，按月租用，适合长期在线运行 Claude Code 等 AI 工具。它解决的是链路稳定性和在线时长，不是绕过账号或地区限制；使用前仍需确认账号资格、服务条款和可用地区。
排查清单
- 确认账号、订阅、地区和使用方式符合官方要求。
- 用
env | grep -i proxy确认启动终端有代理变量。 - 检查
~/.claude/settings.json的env配置是否有效。 - 用
curl对比代理和直连下 API 域名的响应。 - 检查 IPv6、DNS 和分流规则是否让 API 请求绕过代理。
- 退出登录、备份并重置本地配置后重新认证。
- 记录客户端版本、错误时间和请求域名，必要时联系官方支持。
- 若工具链允许，评估其他兼容工具；迁移前测试权限、成本和稳定性。
小结
桌面客户端能用，不代表 Claude Code 能用。403 先查终端请求出口，再查账号、地区和订阅状态。合规前提下，终端环境变量和 settings.json 是最可控的两种做法；TUN 可以作为兜底，但副作用大；共享账号、自建中转和代充不建议。需要长时间在线时，再考虑远程 Mac 这类稳定运行环境。Claude Code 的套餐支持、可用地区和配置字段会随官方调整，操作前以官方最新文档为准。