Claude Code 与 API 在终端里连不上？代理配置与验证方法
浏览器里能用、终端里连不上，几乎都是同一个原因：命令行工具根本不看你在系统设置里点的那个开关。
浏览器里 Claude 用得好好的，终端里的命令行工具却一直连不上。原因几乎总是同一个：
命令行工具不读你在系统设置里点的那个代理开关。
图形界面的代理客户端通常通过修改系统代理设置生效，而系统代理设置主要被浏览器和部分图形应用读取。命令行工具、运行时、包管理器走的是另一套机制——环境变量。两套机制互不相通，所以会出现「一边能用一边不能」。
这篇按配置、验证、排错三步讲清楚。
先确认你的工具读哪一套配置
在动手之前花一分钟确认，能避免大部分无用功。命令行工具大致分三类：
| 类型 | 怎么获取代理配置 | 典型表现 |
|---|---|---|
| 只读环境变量 | http_proxy / https_proxy 等 | 最常见，本文主要针对这类 |
| 有自己的配置项 | 工具自带的 config 文件或参数 | 环境变量可能被它覆盖 |
| 两者都读，有优先级 | 通常自有配置优先 | 改了环境变量没反应，是被覆盖了 |
如果你改了环境变量完全没反应，优先怀疑第三类——去看这个工具自己的配置里有没有代理相关项，它可能设成了空值并因此屏蔽了环境变量。
三类环境变量，分别管什么
需要设置的是三组，每组都建议大小写两种写法各设一份：
第一组，管普通 HTTP 请求。 值是你本地代理客户端监听的地址和端口，不是订阅链接。这一点每次都有人搞错——写错了不会报错，只会静默失败。
第二组，管 HTTPS 请求。 大多数你要访问的地址都是 https，所以这一组比第一组更关键。只设了第一组却没设第二组，是「设了没用」的常见原因之一。
第三组，排除不该走代理的地址。 至少要包含本机回环地址、本机主机名和你在用的内网地址段，用逗号分隔且不加空格。漏掉这一组的后果很具体：本地开发服务器突然打不开，因为访问它的请求也被送去了代理。
关于大小写：这是历史遗留问题，没有统一标准。早期工具约定用小写，后来一些运行时改用大写，两派并存至今，同一个工具的不同版本都可能不一样。与其逐个查，不如两种都设——它们是独立的变量，同时存在不冲突。
还有一条容易忽略的：只在当前终端窗口里设置，关掉窗口就失效，新开的窗口和别的终端程序也读不到。要持久生效必须写进 shell 的配置文件里。
代理模式的选择比变量本身更容易出错
环境变量指向的是你本地的代理客户端，但客户端自己还有一层模式设置，两者要对得上。
- 规则模式下，只有匹配规则的域名才走节点。如果 Claude 相关域名不在规则里，即便环境变量配对了，请求也会被放行到直连然后失败。
- 全局模式下所有流量都走节点，配置最简单，但会把本地和内网流量一起带走——这时候第三组变量就更重要了。
排查时的标准做法是先切到全局模式复测一次：如果全局能用、规则不能用，问题就确定在规则上，回去补规则即可。三种模式的差别与适用场景见代理模式怎么选。
证书校验为什么在终端里更容易出问题
浏览器有一套自带的信任链管理，对常见情况容错较好；命令行工具和运行时各自维护信任链，出问题时直接报错退出，所以同样的链路在终端里更容易撞上证书问题。
常见原因有两类：
第一类，本地代理在做 TLS 解密。 部分客户端提供这个可选功能，开启后它会用自签证书重新加密流量。浏览器可能已经信任了这张证书，命令行工具没有，于是校验失败。解决办法是把这个功能关掉，而不是去让工具信任它。
第二类，设备上装了内网根证书。 公司设备常见，链路被合规地解密，浏览器因为系统信任而无感，运行时用自己的信任库所以报错。这种情况下需要把该根证书加入对应运行时的信任链。
不要关闭证书校验。 它确实能让报错消失，但同时让你失去了察觉连接是否被中途篡改的能力——在一条本来就要经过多个中间节点的链路上，这个代价不划算。TLS 相关报错的完整分型见 TLS 握手错误怎么排查。
配完之后，怎么确认真的生效了
这一步最常被跳过，结果是后面所有排查都建立在猜测上。
- 在终端里请求一个能回显出口地址的接口，看返回的地址是不是你节点的地址。如果返回的还是你本地的公网地址，说明代理根本没生效，先回去查变量。
- 在另一个新开的终端窗口重复一次。 这一步验证的是配置有没有持久化。两个窗口结果不同，说明你只设置了当前会话。
- 访问一次本地开发服务器。 验证第三组变量写对了，本地流量没有被错误地送去代理。
- 最后才跑真正的工具。 前三步都通过之后再测，出问题时你才知道范围缩小到了哪里。
和编辑器内 AI 补全的配置有什么不同
两者经常被混为一谈，但差别很实际：
| 终端里的命令行工具 | 编辑器内的 AI 补全 | |
|---|---|---|
| 代理来源 | 环境变量 | 编辑器自己的设置项，多数不读环境变量 |
| 失败表现 | 明确报错并退出 | 静默失败，补全就是不出来 |
| 证书问题 | 直接报错，好定位 | 常被吞掉，难定位 |
| 连接特征 | 可能是长任务 | 高频短请求，对延迟敏感 |
最关键的差别是：编辑器多数有自己的代理设置项，不读环境变量。 所以你把终端配好了，编辑器里的补全仍然连不上是正常的，需要单独配。编辑器侧与终端侧的完整配置见 Cursor 与 GitHub Copilot 网络配置。
另一个差别在连接特征上：补全是高频短请求，怕的是延迟高；命令行里的长任务是低频长连接，怕的是中途断。这两种需求对节点的要求不一样，如果你两样都用，可能需要分别给它们配不同的节点。
长任务还是会断的话
代理配好、验证通过之后，如果长任务仍然跑到一半中断，问题就不在配置上了，而在链路能不能维持长连接。
终端场景比网页端多一个优势：你可以自己控制超时和重试。给调用加上合理的超时设置和重试逻辑，一次中断就变成一次自动重试，从结果上能兜住大部分情况。
但这治的是表现不是原因。根本改善仍然要回到线路选择——抖动小、时段差异小的线路才扛得住长连接，具体的测试方法见 Claude 长回答中途断掉怎么办。Claude 对网络环境的整体要求见 Claude 访问指南。