Claude Code连接超时怎么办？Clash排查与修复指南

Claude Code 为什么会连接超时

Claude Code 的一次完整请求，通常不只访问一个网址。启动时可能需要连接 Anthropic 账户、完成登录授权、读取配置或更新组件；进入对话后，还要持续访问 api.anthropic.com 等 API 主机，并通过流式连接接收模型输出。只要其中一个环节没有经过正确的 Clash 代理，终端就可能表现为登录失败、请求无响应、连接重试，或者等待很久后显示 ETIMEDOUT。

浏览器能够打开 Anthropic 网页，并不代表 Claude Code 一定能够联网。浏览器通常会读取系统代理设置，而 Node.js、独立 CLI 或由终端启动的子进程，可能完全不继承系统代理。反过来，即使终端已经设置了 HTTPS_PROXY，Clash 的规则模式仍可能把某些 API、认证或重定向请求判定为直连。因此，排查时不要只盯着节点延迟，而要确认「Claude Code 发出的每一条请求，是否都进入了预期的策略组」。

另一个常见原因是半代理连接。例如账户页面通过代理打开，但 API 请求直连；或者 API 走了代理，登录回调却被本地网络拦截。对于普通网页，这种分裂有时只表现为图片加载失败；对于 Claude Code 的长连接和流式响应，则可能直接导致会话中断。Clash 的连接日志、规则命中结果和当前模式，是定位这类问题的三个关键证据。

第一步：确认 Clash 模式、端口和节点状态

打开 Clash Verge、Clash Verge Rev、Mihomo 或你正在使用的其他客户端，先确认核心处于运行状态。很多「Claude Code 超时」其实发生在客户端没有启动、配置没有激活、节点已经失效，或者系统代理仍指向旧端口。不要只看托盘图标是否存在，还要进入连接面板或日志页面，确认最近确实有新的请求记录。

日常排障建议先使用规则模式，不要一开始就切换到全局模式。全局模式虽然可以快速验证「是否是分流规则导致的问题」，但它会把所有流量交给同一个代理，容易掩盖 DNS、国内站点直连和本地服务访问方面的其他问题。可以先在规则模式下测试，再临时切换全局模式做对照：如果全局模式可以连接，而规则模式超时，问题大概率位于规则匹配、规则集更新或 DNS 判断。

同时检查 Clash 的入站端口。终端代理通常使用 mixed-port，它可以同时接收 HTTP 和 SOCKS 请求；有些配置则分别提供 HTTP 端口与 SOCKS 端口。假设 Clash 实际监听的是 7890，但 Shell 变量仍指向已经关闭的 7897，Claude Code 就会立刻出现连接拒绝或超时。端口号必须以客户端当前配置为准，不能直接照抄其他教程。

节点选择也很重要。先选择一个能够稳定打开 Anthropic 相关页面、握手成功且延迟没有剧烈波动的节点。不要只根据测速结果选择节点，因为 ICMP 延迟低并不代表它适合 HTTPS 长连接。观察连接日志时，如果请求频繁出现连接建立后马上断开、TLS 重试或读取超时，应更换同一策略组中的其他节点进行对比。

• 确认 Clash 核心正在运行，并且当前配置已经激活。
• 确认系统代理和终端代理使用的是当前有效端口。
• 确认代理模式没有停留在直连模式。
• 确认策略组中至少有一个稳定节点，而不是全部节点都处于失败状态。
• 确认系统中没有 VPN、公司代理或其他 Clash 实例争用同一个端口。

第二步：检查 Claude Code 是否继承终端代理

这是最容易被忽略的一步。Claude Code 从终端启动时，是否使用代理取决于客户端本身的实现以及当前 Shell 环境。即使你已经在 Clash 中打开了「设置系统代理」，终端程序也不一定会自动读取它。尤其是在 macOS、Linux、WSL、Remote SSH、Dev Container 或通过脚本启动的环境中，显式设置代理变量通常更可靠。

你可以在当前终端查看代理变量是否存在。不同系统的变量名称略有差异，但一般会检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 以及对应的大写和小写形式。HTTPS 请求通常优先参考 HTTPS_PROXY，而部分 Node.js 工具或依赖库只识别其中一部分变量，所以排障时不要只设置一个变量后就断定代理已经生效。

如果 Clash 的 mixed-port 是 7890，可以按终端工具支持情况选择 HTTP 代理或 SOCKS5 代理。HTTP 代理示例通常写成 http://127.0.0.1:7890；SOCKS5 代理则可能写成 socks5://127.0.0.1:7890。具体格式必须以 Claude Code 及其运行时支持的代理类型为准。若设置后出现「代理协议不支持」或连接立即失败，应换用 Clash 提供的 HTTP 端口，而不是反复更换节点。

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export ALL_PROXY=http://127.0.0.1:7890

Windows PowerShell 的环境变量写法与 macOS、Linux 不同。设置完成后，必须在同一个终端窗口中重新启动 Claude Code；已经运行的进程不会自动读取后来新增的环境变量。如果你通过 VS Code 任务、Shell 脚本或远程会话启动，还要确认这些启动方式没有清空环境变量。最简单的验证方法，是在同一窗口中先访问一个已知能够通过 Clash 打开的 HTTPS 地址，再启动 Claude Code 观察连接日志。

代理变量也可能带来反效果。某些企业网络、内网域名或本地回调地址不应经过远程代理；如果你把所有流量都设置为代理，登录回调或本地服务可能无法访问。可以根据环境补充 NO_PROXY，将 localhost、127.0.0.1、内网域名和公司内部地址排除。对于公共 API 请求，则要避免 NO_PROXY 规则过于宽泛，否则 Anthropic 相关域名可能被错误地绕过代理。

第三步：检查 Anthropic 域名分流与 DNS

在规则模式下，不能只给一个页面域名写规则。Claude Code 的登录、控制台、API、更新资源和错误处理页面，可能使用不同的主机名。最可靠的做法是先启动 Claude Code，再在 Clash 连接日志中过滤最近出现的请求，记录真实的 Host、端口、命中的规则和最终策略组。不要完全依赖网上流传的固定域名清单，因为客户端版本、登录方式和服务端架构都可能发生变化。

规则设计上，优先使用明确的 DOMAIN-SUFFIX 或订阅提供的官方规则集，不建议一开始使用过宽的 DOMAIN-KEYWORD。例如，一个关键词规则可能把无关站点、统计域名甚至本地测试域名一并送进代理，后续出现问题时很难判断是哪条规则造成的。更好的方法是先覆盖日志中确认过的 Anthropic 相关域名，再根据实际失败请求增量维护。

DNS 也会影响规则判断。如果 Clash 使用本地 DNS 解析，而本地网络无法正确解析目标域名，客户端可能在连接代理之前就失败；如果启用了 fake-ip 或增强模式，部分应用又可能因为不兼容 fake-ip 地址而表现异常。排查时可以先保持配置中已有的 DNS 方案，不要同时修改多个选项。先确认日志中的域名能够解析、请求能命中规则，再单独测试 redir-host、fake-ip、覆写 DNS 等变化。

如果你发现同一个域名在不同时间命中了不同规则，优先检查规则集更新状态和规则顺序。Clash 通常按照规则从上到下匹配，过于宽泛的直连规则放在前面，会截断后面的代理规则。自定义规则应放在能够覆盖它的位置，并在修改后重新加载配置。每次只改一个变量，才能知道究竟是域名、DNS 还是策略组解决了问题。

动手操作：用 TUN 模式处理终端不走代理

如果系统代理和 Shell 变量都无法让 Claude Code 稳定联网，可以考虑启用 TUN 模式。TUN 会在系统中创建虚拟网络接口，把没有主动配置代理的应用流量交给 Clash 内核处理，因此比单纯依赖浏览器代理或终端环境变量覆盖范围更大。它尤其适合 Remote 工具、子进程、某些不读取 HTTP 代理的 CLI，以及需要统一处理 DNS 的开发环境。

1. 先保存当前配置。在 Clash 客户端中备份正在使用的配置文件，记录现有模式、DNS、端口和节点选择，方便出现冲突时恢复。
2. 确认客户端支持 TUN。Clash Verge Rev、Mihomo Party 等客户端的菜单名称可能不同，常见入口位于设置、内核或网络增强选项中。不要把旧版客户端的菜单路径直接套用到新版本。
3. 按系统提示授予权限。TUN 通常需要管理员权限或系统网络扩展权限。只对可信客户端授予权限，并确认系统防火墙、企业安全软件和其他 VPN 没有阻止虚拟接口启动。
4. 开启严格路由或等价选项时保持谨慎。严格路由可能改变局域网、虚拟机、容器和公司内网的访问方式。先在个人网络中测试，不要在重要工作环境里直接覆盖原有 VPN 路由。
5. 重新启动 Claude Code 并观察日志。重点看 API 请求是否出现、是否进入预期策略组，以及流式连接是否能够持续数分钟。若普通网页正常而 API 仍失败，再回到节点与规则层排查。

TUN 并不是万能修复方案。它可能与系统 VPN、Docker 网桥、虚拟机网络、公司安全代理或其他代理客户端发生路由冲突。如果开启 TUN 后所有网络都变慢、局域网设备不可访问，或出现 DNS 循环，应先关闭它并恢复原配置。正确的目标不是「尽可能让所有流量进代理」，而是让 Claude Code 的目标请求稳定、可解释地进入正确出站。

节点、TLS 与流式连接的进一步排查

当规则命中正确、终端也确实通过 Clash 连接，但 Claude Code 仍然超时时，问题可能在节点本身。AI 编码工具通常会发起持续时间较长的请求，期间还可能传输大量上下文。某些节点虽然适合打开短页面，却无法稳定维持长连接；节点运营商的出口限速、连接数限制、TLS 转发质量和地区策略，都可能在对话过程中暴露出来。

更换节点时建议遵循单变量原则：保持 Clash 模式、规则和终端代理不变，只切换策略组中的一个节点，然后重新执行相同的测试请求。记录连接建立时间、首字节时间、是否出现中途断流，以及重试后是否恢复。不要在节点、DNS、TUN 和 Claude Code 配置之间同时来回切换，否则最后即使恢复，也无法知道真正原因。

如果日志显示 TLS 握手失败，可以先检查系统时间、证书链、杀毒软件的 HTTPS 扫描和公司网络的中间人证书。系统时间错误会导致证书尚未生效或已经过期；安全软件拦截加密流量时，浏览器可能因为安装了企业证书而正常，但终端运行时并不信任同一证书。此时继续更换 Clash 规则通常没有意义，应先处理信任链问题。

对于流式输出中断，还要注意连接复用和超时设置。某些网络设备会在一段时间没有明显数据时主动回收连接，或者对长时间保持的 HTTP/2、SSE 会话进行限制。可以通过更换节点、关闭冲突的网络加速器、暂时停用额外的 HTTPS 检查来做对照。不要为了「解决超时」而随意关闭 TLS 校验或接受未知证书，这会降低账户和代码传输的安全性。

常见问题

浏览器能打开 Claude，为什么 Claude Code 仍然超时？

浏览器可能使用系统代理，而 Claude Code 使用独立的终端网络栈；两者还可能访问不同的认证、API 和流式端点。请在启动 Claude Code 的同一个终端中检查代理变量，并在 Clash 连接日志中确认真实请求是否命中代理策略组。

切换到全局模式就能用，是否说明节点一定没问题？

这通常说明节点至少具备基本连通性，但不能证明节点长期稳定。全局模式能用、规则模式不能用，往往意味着规则顺序、DNS 判断或域名覆盖不完整。应根据日志补齐准确规则，而不是长期依赖全局模式。

开启 TUN 后 Claude Code 还是连接不上怎么办？

先确认 TUN 虚拟接口已经启动，并且没有被其他 VPN 或安全软件拦截；然后查看 API 请求是否出现在 Clash 日志中。如果日志完全没有请求，可能是路由或进程环境问题；如果请求出现但节点返回超时，则应继续检查策略组、节点和 TLS。

需要重新安装 Claude Code 或 Clash 吗？

大多数连接超时并不是安装损坏造成的。重新安装之前，应先保留日志，核对代理端口、规则命中、DNS、节点和环境变量。只有在核心无法启动、配置文件损坏、权限异常或版本组件明确缺失时，才建议备份后重新安装。

与只会切换系统代理的轻量工具相比，Clash V.CORE 更适合排查 Claude Code 这类同时涉及认证、API 和长连接的开发工具：你可以查看连接日志、区分规则模式与 TUN 模式、单独切换节点，并把问题定位到域名分流或终端环境，而不是反复重装软件。部分旧版客户端的内核更新缓慢，图形界面也缺少清晰的请求诊断；如果你希望用一套更完整的能力处理 Claude Code 超时、规则匹配和节点切换，可以前往下载 Clash V.CORE，按照本文的顺序逐项验证。