Claude Code连接超时怎么办？用Clash排查代理与API请求失败

Claude Code 请求超时，先分清是登录、连接还是接口报错 详解

使用 Claude Code 时，终端可能停在「正在连接」或长时间没有输出，随后出现 ETIMEDOUT、ECONNRESET、TLS 错误，或者提示无法连接 Anthropic API。此时最容易做的事，是连续更换模型、重装 CLI 或反复切换节点；但这些操作会同时改变多个变量，反而让故障原因更难判断。更有效的方式是先确认失败发生在哪一段：Claude Code 是否完成登录、终端进程是否经过 Clash、目标域名是否命中正确策略、当前节点能否稳定建立 HTTPS 连接。

浏览器能打开 Claude 网页，并不代表 Claude Code 的请求也已经通过代理。浏览器可能遵循系统代理设置，而终端里的 Node.js 进程未必会读取相同设置；反过来，终端请求也可能已经发出，只是 Clash 把 api.anthropic.com 分到了直连或不合适的代理组。还有一种常见情况是认证已经成功，但首次模型请求连接 API 时超时，所以重新登录并不能解决问题。把「登录失败」「请求超时」和「服务端拒绝请求」分开看，能够避免把网络问题误判成帐号或权限问题。

先记录终端中完整的报错类型、发生时间和所处网络，再打开 Clash 客户端的连接或日志页面，观察报错前后是否出现 Claude Code 相关连接。日志里若完全没有对应请求，优先检查进程代理设置或 TUN 接管；若看到目标域名但连接失败，则继续核对规则、节点和 DNS；若连接已经建立并收到明确的 HTTP 状态码，问题可能在认证、帐号权限、模型访问资格或服务端响应，不宜只靠换节点处理。

先辨别错误类别：ETIMEDOUT 通常表示连接在规定时间内没有完成；ECONNRESET 表示连接被重置；HTTP 401、403 或 429 则说明请求已经到达某个服务端，但认证、权限或限流可能有问题。错误文本只是线索，仍要结合 Clash 连接日志判断流量实际走向。

理解 Claude Code 的请求链路：终端代理不等于系统代理 全面解析

排查时，可以把链路拆成四段：Claude Code 进程发起请求，系统或进程代理决定流量交给谁，Clash 按规则选择直连或代理策略组，最后由所选节点解析域名并连接 Anthropic 服务。任何一段不符合预期，都可能表现为命令卡住。尤其要注意，Clash 界面显示「系统代理已开启」，主要说明客户端设置了系统代理；它不能自动证明所有终端程序、后台进程、容器或远程开发环境都会遵循该代理。

Claude Code 的 API 请求通常需要关注 api.anthropic.com。登录、控制台跳转或产品相关流程还可能访问其他 Anthropic 域名，实际目标会随版本和使用方式变化。不要仅凭网上的一份静态域名清单就把大量域名全部加入代理规则；先从 Clash 的连接记录里确认本机真正访问的主机名，再按最小范围补充。若你使用的是 Amazon Bedrock、Google Vertex AI 等替代接入方式，请以对应云服务的认证和 API 域名为准，不能把直连 Anthropic API 的规则机械套用过去。

在 Clash 中，规则模式下常见的误区是「看起来有 Claude 规则，实际请求仍命中其他规则」。规则按配置中的顺序依次匹配；较早出现的宽泛规则、规则集或兜底规则，可能先于后面新增的域名规则生效。检查连接详情中的匹配规则和策略组名称，比只看 YAML 文件里是否出现某一行更可靠。节点策略组也要确认已经选中可用节点；如果使用自动测速组，排障时可暂时固定一个稳定节点，减少节点切换和连接重建带来的干扰。

终端代理变量与 Clash 的混合端口也必须对应。以常见配置为例，mixed-port 同时接受 HTTP 和 SOCKS 流量，但某些应用或环境变量对代理协议有具体要求；不要把 SOCKS 端口当成 HTTP 代理端口填写。端口号应以你当前配置文件和客户端设置页面为准，不能照抄其他电脑上的数值。系统代理、命令行代理变量和 TUN 可以并存，但初次定位故障时应先明确哪一种机制负责接管，避免同一请求经过不一致的出口路径。

动手排查：从 Clash 规则到 Claude Code 环境变量 一次讲透

下面按「先确认 Clash，再确认终端」的顺序操作。每完成一步就重新运行一次请求或简单连通性检查，并观察 Clash 日志是否有变化；一次只改一项，便于判断哪项调整真正有效。

  1. 确认 Clash 正在运行并选中节点：检查客户端核心状态、配置是否已加载、代理组是否选择了实际节点。排障期间暂时不要让自动测速频繁切换节点；先用一个已知可用的节点做对照。
  2. 确认代理端口：在客户端设置或配置文件中查找 HTTP、SOCKS 或混合代理端口。记录地址和端口，常见监听地址为本机回环地址，但具体值以你的配置为准；若端口没有监听，环境变量写得再正确也无法连接。
  3. 检查连接日志和规则命中：重新执行一次 Claude Code 请求，在 Clash 的连接页面查看是否出现 api.anthropic.com。确认连接使用的规则、策略组和节点符合预期；若日志显示直连，检查规则顺序和配置是否已重新加载。
  4. 为当前终端设置代理变量：如果终端程序没有使用系统代理，可在启动 Claude Code 前设置环境变量。以下示例中的端口须替换为本机的 HTTP 或混合端口： 
    export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
claude
    • macOS 或 Linux 的 Bash、Zsh 可在启动命令所在的终端会话中临时设置；确认有效后，再考虑写入 Shell 配置文件。
    • Windows PowerShell 可使用 $env:HTTP_PROXY="http://127.0.0.1:7890" 与 $env:HTTPS_PROXY="http://127.0.0.1:7890" 设置当前会话变量。
    • 如果你实际使用的是 SOCKS 端口，不要仅把协议文字改成 socks5 就认为所有客户端都支持；优先使用 Clash 提供的 HTTP 混合端口，或确认当前 Claude Code 运行环境明确支持所填代理协议。
  5. 重新启动并测试：保存变量后，在同一个终端窗口启动 Claude Code。若此前 CLI 已经运行，应彻底退出后重新启动，因为已存在的进程不会自动读取后来添加的环境变量。随后比较请求是否仍超时，并检查日志中是否出现新的连接。
  6. 检查排除列表：查看 NO_PROXY 或 no_proxy 是否意外包含 Anthropic 域名，或使用过于宽泛的匹配导致 API 请求绕过代理。内网地址通常需要排除，但不要把目标 API 域名误放进排除列表。

命令行代理变量只对相应进程及其子进程生效，不等于全系统代理。若你在 VS Code 集成终端、SSH 会话、容器、WSL 或自动化任务中运行 Claude Code，需在实际启动进程的环境里检查变量和网络路径。比如在本机终端设置了变量，却从另一个未继承该环境的 IDE 或服务启动 CLI，两个进程看到的配置可能完全不同。测试时先在同一终端查看变量是否存在，并确认端口对应本机正在运行的 Clash 实例。

更容易定位的做法：每次只切换一个变量，例如先固定节点，再检查规则命中，最后才设置终端代理或开启 TUN。每一步都记录结果；如果改动后 Clash 日志仍没有 Claude Code 的连接记录，问题更可能在代理变量没有传给进程、监听地址错误，或流量由其他网络环境发出。

规则正确仍然超时？继续检查 DNS、TUN 与节点稳定性 深入理解

连接日志已显示命中代理策略组，但请求仍无法完成时，下一步是核对 DNS 和节点。DNS 模式、缓存与规则可能影响域名最终解析到的地址；如果 DNS 查询走一条路径、实际 HTTPS 流量走另一条路径，就可能出现浏览器偶尔可用、CLI 却持续超时的情况。可以先在 Clash 中刷新配置或清理相关 DNS 缓存，再重新发起请求，并观察日志中的目标域名和连接结果。不要为了「试试看」同时更改 DNS 上游、fake-ip 模式和节点策略，否则难以知道是哪一项造成变化。

也要区分「域名无法解析」和「解析完成但 TCP/TLS 连接失败」。前者应优先检查 DNS 上游、网络限制及本机解析结果；后者则更需要对照代理节点、端口、规则和网络稳定性。HTTP 代理端口未启动、系统安全软件拦截本地连接、企业网络限制长连接，或者当前节点到服务端的链路不稳定，都可能使请求停在连接阶段。不要把每一种连接失败都归结为 DNS 污染，也不要因为更换一个节点后偶尔成功，就断定其他设置无误。

TUN 模式适合系统代理无法覆盖的程序或复杂网络环境，但它不是所有超时问题的通用修复按钮。开启 TUN 前，先确认客户端具备所需权限、虚拟网卡已经正常启动，并检查路由与 DNS 接管选项是否符合当前系统。若启用后本机其他应用也断网，先恢复到原有状态，再检查 Clash 日志和系统路由；不要在不清楚网络变化的情况下同时叠加多个 VPN、代理客户端或虚拟网卡。对单纯的 Claude Code 终端请求，先用明确的代理变量验证链路，通常更容易复现和回滚。

现象 优先检查 下一步
Clash 没有相关连接记录 终端代理变量、进程启动环境、TUN 是否接管 在启动 Claude Code 的同一终端检查变量和本地代理端口
日志显示 API 域名走直连 规则顺序、规则集覆盖、配置是否已加载 确认目标域名实际命中的规则，再调整规则位置
规则命中代理但连接超时 当前节点、代理端口、DNS 与链路稳定性 固定一个可用节点，分开测试解析和 HTTPS 连接
返回 401、403 或 429 认证状态、帐号权限、使用限制或服务端响应 先检查 CLI 提示和帐号状态，不要只通过更换节点处理
开启 TUN 后全局网络异常 系统权限、虚拟网卡、路由和 DNS 接管 先关闭 TUN 恢复网络，再逐项核对配置与系统冲突

Claude Code 与 Clash 连接超时常见问题 详解

浏览器能用 Claude，为什么 Claude Code 仍然超时？（详解）

浏览器可能遵循系统代理或浏览器自身设置，而终端中的 Claude Code 进程未必使用同一代理。先在 Clash 连接日志中观察 CLI 发起请求时是否出现 API 域名，再检查启动该进程的终端是否设置了正确的 HTTP_PROXY、HTTPS_PROXY 和代理端口。网页可访问只证明浏览器这条链路可用，不能单独证明终端流量也已正确代理。

只打开 Clash 的系统代理够不够？（要点）

不一定。遵循系统代理的应用可能直接可用，但 CLI、后台进程、容器或远程开发环境可能忽略系统代理。可以先测试进程级代理变量；如果有多个程序都不支持代理设置，再评估 TUN 是否适合你的系统。选择哪种方式，应以连接日志能否确认请求确实经过 Clash 为依据。

应该把哪些域名加入 Clash 代理规则？（说明）

先关注日志中实际出现的 API 主机名，常见重点是 api.anthropic.com，再依据你的登录方式和接入服务检查其他请求。Claude Code 的请求目标可能随功能、版本或云端接入方式改变，因此规则应以本机连接记录和官方服务配置为准。规则添加后，重新加载配置并确认连接详情显示命中预期策略组。

HTTP 401 或 403 也能靠换节点解决吗？（实践）

不应默认如此。401、403 通常意味着请求已到达服务端，但认证凭据、帐号权限、组织策略或访问资格需要进一步核实；429 则可能与速率或使用限制有关。若日志已经显示连接成功，先根据 Claude Code 的提示检查登录状态与帐号配置，再判断是否需要处理网络问题。反复更换节点可能掩盖问题，却不一定能改变服务端对帐号的判断。

把排障过程变成可复现的检查顺序 全面解析

对 Claude Code 连接超时而言，关键不是把所有代理开关都打开，而是建立一条可验证的链路：先确认当前节点可用，再从 Clash 日志确认目标域名、规则和策略组，随后检查终端进程是否使用正确的本地代理端口，最后才调整 DNS 或 TUN。相比一些需要逐页翻找设置、且终端代理说明不够清楚的同类客户端与零散教程，Clash 将下载入口和 Clash 使用指引集中整理，便于按当前客户端核对设置、逐项验证并保留回滚空间；如果你还需要选择或安装适合自己的 Clash 客户端，可以前往下载，再按本文的顺序检查 Claude Code 请求链路。