运行 Claude Code 时频繁出现连接超时、长时间停在思考状态，或执行命令后返回 ETIMEDOUT、ECONNRESET、socket hang up，不一定是 Claude Code 本身故障。更常见的原因是：Clash 没有接管终端流量、Anthropic 相关域名被规则判定为 DIRECT、当前节点线路不稳定，或者终端使用了错误的代理端口。浏览器能正常打开网页，也不能证明 Claude Code 一定走了同一条网络路径。本文以 Clash Verge Rev 和 Mihomo 系客户端为例，从现象判断、连接面板、规则分流、终端环境变量到 TUN 模式，给出一套可以逐项验证的排查方法。

开始之前，建议先保留当前配置的备份，不要同时更换订阅、客户端和系统网络设置。一次只修改一个变量，才能判断究竟是哪一步解决了问题。以下方法适用于 macOS、Windows 和 Linux 终端；不同客户端的菜单名称可能略有差异，但核心思路都是让 Claude Code 的请求稳定进入 Clash，再由明确的代理策略转发出去。

先判断：连接超时属于哪一类问题

Claude Code 的错误信息看起来相似，实际对应的故障层并不相同。若错误发生在连接建立之前，常见表现是等待几十秒后出现 ETIMEDOUT、connect timeout 或 fetch failed。这通常与 DNS、TCP 连接、TLS 握手或代理路径有关。若已经收到 HTTP 状态码，则应优先按业务错误处理：401 往往指向 API 凭据或登录状态，403 可能与权限、区域或账户策略有关，429 则更接近速率限制，不能单靠更换 Clash 节点解决。

还要区分「首包慢」和「持续读取超时」。Claude Code 可能建立连接后保持较长时间的流式响应，某些终端库或企业网络设备会把长时间没有明显数据的连接误判为空闲并主动关闭。如果 Clash 连接面板显示请求已经命中代理、TLS 很快完成，但总是在固定等待时间后断开，就应同时检查客户端的读取超时、网络防火墙和节点对长连接的支持，而不是反复修改规则。

现象 优先检查位置 典型判断
连接面板没有任何请求 终端环境变量、进程代理支持 Claude Code 可能没有经过 Clash
请求显示 DIRECT 后超时 规则顺序、域名匹配 Anthropic 流量被错误直连
请求命中代理但握手失败 节点质量、DNS、TLS 代理链路或出口线路不稳定
返回 401、403 或 429 账户、权限、配额 不属于单纯的连接超时

检查 Clash：端口、代理状态与连接日志

第一步不要急着打开 TUN，也不要直接改成全局模式。先打开 Clash Verge Rev 的设置页面，确认内核正在运行，并记录当前的 mixed-port 或 HTTP 代理端口。常见端口可能是 7890、7897 或其他自定义值，但不能照抄示例；必须以客户端界面显示的实际端口为准。混合端口通常同时接受 HTTP 和 SOCKS 请求，适合给命令行工具使用。

接着打开连接面板或日志页面。在 Claude Code 发起一次最小请求时，观察是否出现 Anthropic 相关主机名。不要只看关键词是否包含 claude，还应留意 api.anthropic.com、身份验证服务域名以及客户端版本检查可能访问的其他主机。日志里的 Policy、Rule 或策略名称同样重要：如果请求显示为 DIRECT，说明当前代理开关并没有改变这条请求的最终去向。

如果连接面板完全没有记录，常见原因有三个。第一，Claude Code 启动在另一个用户会话或后台进程中，那个进程没有继承当前终端变量。第二，终端程序只支持 SOCKS，而你填入了 HTTP 端口，或者反过来。第三，系统启用了 TUN、VPN 或其他网络扩展，导致请求绕过了你正在观察的 Clash 实例。先关闭重复的代理软件，保留一个明确的网络入口，再重新测试，通常比同时调整多个工具更容易定位问题。

判断技巧：在终端执行测试命令的同时盯住 Clash 连接面板。只有当请求出现、主机名正确、策略命中预期代理组，并且节点有持续上下行数据时，才能确认「终端确实通过 Clash 出网」。单独看到系统代理开关处于开启状态，并不能替代这三项验证。

在启动 Claude Code 的终端中设置代理

许多用户只打开了 Clash 的系统代理，却忘记命令行程序是否会读取系统代理。Claude Code 的具体网络行为会随版本、运行时和启动方式变化；从 Terminal、iTerm、PowerShell、VS Code 集成终端或脚本任务启动时，它们的环境并不一定相同。因此更稳妥的做法是在即将运行 Claude Code 的同一个终端会话中显式设置代理变量。

macOS 或 Linux 可以先查看 Clash 的 mixed-port，再执行下面的示例。请把端口替换为自己的实际值：

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

HTTPS 请求最关键的是 HTTPS_PROXY。补充 HTTP_PROXY 可以覆盖部分依赖 HTTP 请求的工具，而 ALL_PROXY 是否生效取决于具体运行时，不建议把它当作唯一配置。设置后，可以用 env | grep -i proxy 检查变量是否真的存在，再启动 Claude Code。若你修改了 ~/.zshrc 或 ~/.bashrc，需要重新打开终端，或手动执行 source 让当前会话加载新配置。

Windows PowerShell 的写法不同：

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="http://127.0.0.1:7890"

如果只在外部 Terminal 设置了变量，而实际任务由 VS Code 的任务运行器、后台脚本或另一个集成终端启动，变量仍可能缺失。此时应在对应的启动环境中核对，而不是继续增加更多代理变量。企业代理、内网 Git 和本地服务可能不适合经过 Clash，可以按需配置 NO_PROXY，例如将 localhost、127.0.0.1 和公司内网域名排除，避免本地开发服务出现回环或认证异常。

调整规则：让 Anthropic 请求命中正确策略

确认终端请求已经进入 Clash 后，再处理规则。订阅配置通常包含大量远程规则集，规则顺序可能因提供方不同而变化。某些「国内直连」「GEOIP」「漏网之鱼」规则放在过于靠前的位置时，可能把 Anthropic 的请求判定为直连；也有些配置只覆盖浏览器常见域名，没有覆盖 CLI 的鉴权或 API 主机。

建议在自定义规则或覆写区域靠前位置加入精确的域名规则，并将它们指向一个稳定的代理策略组。示例思路如下：

DOMAIN,api.anthropic.com,PROXY
DOMAIN-SUFFIX,anthropic.com,PROXY
DOMAIN-SUFFIX,claude.ai,PROXY

这里的 PROXY 只是示例策略组名称，实际配置中可能叫「节点选择」「Proxy」或其他名称。不要盲目复制不存在的策略组，否则配置会加载失败。DOMAIN 适合精确控制 API 主机，DOMAIN-SUFFIX 可以覆盖同一服务的多个子域，但范围更宽，可能把不需要代理的站点一并送入节点。若你所在网络或账户流程还涉及额外的身份验证域名，应以连接日志中实际出现的主机为依据逐条补充，不能仅凭猜测写一长串规则。

修改后重新载入配置，并清理或等待旧连接结束，再运行 Claude Code。重点观察三件事：请求是否不再显示 DIRECT，策略组是否选择了预期节点，以及同一主机连续请求时是否频繁切换节点。若策略组设置为自动测速，测速结果变化过快也可能导致长连接体验不稳定；排障阶段可以暂时固定一个延迟正常、丢包较少的节点，确认链路后再恢复自动选择。

用最小测试验证，再决定是否启用 TUN

不要把「能打开网页」当作 Claude Code 已经恢复。更可靠的验证方式是先用当前终端检查代理变量，再观察 Clash 连接记录，最后运行一个不会产生大量上下文的最小 Claude Code 操作。测试时记录开始时间、首个响应出现的时间以及最终错误内容。如果只是第一次连接慢、后续请求稳定，可能是 DNS 或 TLS 会话建立的冷启动；如果每次都在相同阶段失败，则应回到对应层继续检查。

当显式环境变量和规则分流都无效时，可以考虑在 Clash Verge Rev 中启用 TUN 模式。TUN 通过虚拟网卡和路由层接管流量，适合不读取 HTTP_PROXY 的二进制、IDE 子进程或多个工具混合运行的场景。启用前请先关闭其他 VPN、ZeroTier、WARP 或企业安全客户端，确认 Clash 已获得系统要求的网络权限。多个网络扩展同时接管路由，容易造成 DNS 泄漏、回环连接和间歇性断网。

TUN 并不是更强的「万能代理」。它可能改变 Docker、虚拟机、局域网服务和公司内网的访问路径，也可能让原本应该直连的资源经过节点。启用后重新检查 Claude Code 请求是否出现在连接面板，并确认本地开发站点、Git 私服和 SSH 连接没有受到影响。如果 TUN 一开就出现全局网络异常，先关闭它，回到「Rule 分流 + 终端环境变量」的组合，逐步排除冲突来源。对于只需要让 Claude Code 访问 API 的开发机，精确规则通常比全局接管更容易维护。

节点、DNS 与长连接问题的进一步排查

当请求明确命中代理但仍然超时，下一步是换节点做对照，而不是继续堆叠规则。选择两个地区和线路不同的节点，分别进行相同的最小测试；如果只有某一组节点失败，问题更可能出在出口线路、节点负载或服务商对长连接的处理。若所有节点都在相近时间失败，则要检查本地 DNS、Clash 内核状态、订阅是否过期以及账户侧返回的错误。

DNS 方面，重点观察域名解析是否反复变化、是否出现明显异常的国内地址，以及 Clash 的 DNS 模式是否与 TUN 设置相互匹配。混用系统 DNS、浏览器安全 DNS 和 Clash 内置 DNS，可能导致浏览器与终端得到不同结果。排障时尽量固定一种解析路径，并通过连接日志确认最终使用的主机名。不要为了追求某个公开 DNS 的名称而频繁切换配置；稳定、可复现比理论上的测速结果更重要。

如果 Claude Code 已经能够收到部分响应，却在长时间生成或工具调用阶段断开，应检查节点是否限制 WebSocket、HTTP/2 或长连接，也要确认本地安全软件没有设置过短的空闲连接超时。对于公司网络，代理服务器可能会主动关闭长时间无数据的 TLS 会话。此时可以分别用家庭网络、手机热点或公司网络做对照测试：只有一个网络失败，通常说明问题在网络出口策略，而不是 Clash 配置本身。

推荐的稳定排障顺序

为了避免反复试错，可以按以下顺序执行：先确认 Claude Code 的错误属于连接问题，而不是账户或配额错误；然后确认 Clash 内核运行、端口可用，并在连接面板中看到实际请求；接着在同一个终端显式设置 HTTPS_PROXY，检查端口类型与变量继承；之后把 Anthropic 相关域名放到自定义规则靠前位置，暂时固定一个节点；最后才考虑 TUN、DNS 模式和其他网络扩展。每完成一步都重新测试，并记录结果。

这套顺序的价值在于把问题拆成了「进程有没有代理」「规则有没有命中」「节点能不能稳定转发」「系统路由是否需要接管」四层。若第一层没有解决，调整节点没有意义；若第二层显示 DIRECT，升级 Claude Code 也很难改变结果；若前三层均正常而长连接仍断开，才值得深入检查 TUN、企业防火墙和客户端超时参数。排障记录最好包含时间、节点、策略、错误代码和是否出现首包，之后更换订阅或升级客户端时仍可作为对照。

相比只依赖浏览器代理插件的方案，Claude Code 这类终端工具更容易暴露环境变量未继承、规则误判和长连接不稳定等问题；一些简单代理工具虽然开关方便，却常常缺少可视化连接日志、精细域名分流和 TUN 兼容选项。Clash 的优势在于能同时查看请求、策略与节点状态，并按终端、IDE 和本地服务分别控制流量；如果你正在寻找一套便于验证和持续维护的 Claude Code 网络方案，可以从 Clash 的代理端口、规则分流与终端变量开始配置。

立即免费下载 Clash，开启流畅上网新体验 →