Claude Code 连接超时怎么办？用 Clash 排查代理与网络配置

Claude Code 连接超时，先分清是登录失败还是模型请求失败 详解

运行 Claude Code 时，终端一直显示连接中、请求超时、无法完成登录，或者浏览器授权后命令行仍停在等待状态，确实很容易让人先去重装客户端、重建配置，甚至连续更换节点。但在启用了 Clash 的电脑上，这些现象不一定是 Claude Code 本身损坏；更常见的情况是终端进程没有经过代理、目标域名被规则分到了直连，或代理链路建立后又因 DNS、节点抖动而中断。

Claude Code 是终端工具，发起网络请求的是命令行进程，而不是你正在使用的浏览器。因此，浏览器可以打开 Claude 页面，并不能证明终端也走了同一条代理链路。反过来，终端连接超时也不一定意味着账号或 API 凭据错误：超时、TLS 握手失败和 HTTP 权限错误代表不同环节，排查时应先看错误发生在授权、请求还是响应阶段，再决定是否修改 Clash 配置。

本文按确认 Clash 状态、检查连接日志、修复规则、选择系统代理或 TUN、验证 DNS 与节点的顺序处理。重点是用一次可控测试找出流量实际走向，而不是同时切换全局模式、改 DNS、换订阅和重装工具，让故障原因变得更难判断。

先区分网络错误与账号错误：连接超时、连接被重置或 TLS 失败，优先检查代理与网络；若请求已经到达服务端并返回明确的认证、权限或地区提示，则应进一步检查登录状态、凭据和服务可用性。单纯更换 Clash 节点，无法修复无效凭据或账号权限问题。

第一步：确认 Clash 正在工作，终端请求确实进入代理 全面解析

先不要改 YAML。打开 Clash Verge、Clash Verge Rev、Mihomo Party 或其他当前使用的 Clash 客户端，确认配置已载入、内核正在运行，并且当前代理策略组中选中了一个可用节点。若使用规则模式，确认代理组不是空的，也不是误选了延迟很高或已经失效的节点。界面显示「运行中」只代表内核已启动，不代表 Claude Code 的连接一定被规则送进代理。

随后在 Clash 的连接或日志页面观察，并在终端重新执行一次会失败的 Claude Code 操作。查找与 api.anthropic.com、claude.ai 或其他 Anthropic 相关主机名对应的连接记录。域名可能随登录方式、客户端版本和功能变化，不必把某一份静态域名列表当成完整清单；以本机实际出现的目标域名为准。重点看三件事：是否出现连接记录、命中了哪条规则、最后选择了直连还是某个代理策略组。

  • 没有相关连接记录：终端流量可能绕过系统代理，或者请求尚未走到网络阶段。检查进程是否报本地配置错误，再考虑设置代理环境变量或启用 TUN。
  • 记录显示命中直连：优先检查规则顺序、目标域名和策略组。不要先把所有流量改成全局代理。
  • 命中代理但持续超时：观察连接失败节点和实际出口，换一个稳定节点作对照，并留意连接是否反复重试。
  • 连接成功后返回认证或权限错误：网络链路可能已建立，接下来应核对登录状态、凭据或账号权限，而不是继续盲目调整 DNS。

如果客户端提供连接详情，可记录目标主机、命中规则、策略组、连接结果和发生时间。只截取必要的错误信息即可；不要把订阅 URL、访问令牌、API Key 或完整环境变量发到公开论坛。日志中若出现用户名、路径或密钥，也应先遮盖再分享。

第二步：排查规则分流，避免 Anthropic 请求被直连 一次讲透

在 mode: rule 下，Clash 按规则从上往下匹配，先命中的规则决定连接去向。如果较宽泛的直连规则、地区规则或自定义规则排在前面，Anthropic 请求可能在到达代理规则之前就被送往直连。此时浏览器是否能访问其他网站、节点测速是否正常，都不能证明 Claude Code 目标域名已经使用代理。

可以先在规则列表中搜索日志记录的实际域名，检查它是否被 DOMAIN、DOMAIN-SUFFIX、规则集或更宽泛的规则提前匹配。确认原因后，再把范围尽量小的代理规则放到相关直连规则之前。下面的片段仅展示写法；AI-Proxy 必须替换为你配置中真实存在的策略组名称，且具体域名应以自己的连接记录和客户端文档为准。

rules:
  - DOMAIN,api.anthropic.com,AI-Proxy
  - DOMAIN-SUFFIX,anthropic.com,AI-Proxy
  - DOMAIN-SUFFIX,claude.ai,AI-Proxy
  - MATCH,其他策略组

不要为了「保险」把所有流量都粗暴塞进同一个代理组。较宽的后缀规则可能覆盖 Anthropic 以外的服务，增加不必要的代理流量，也会让日后排查命中关系更复杂。若你的订阅使用规则集、覆写或远程配置，先确认本地修改能否在更新订阅后保留；有些客户端会重新生成配置，直接改临时文件可能很快被覆盖。

修改后重新触发一次请求，再看连接日志是否命中预期规则和代理组。若日志已经显示正确命中，但仍然超时，不要继续重复增加相同域名规则；转而测试节点、DNS 和连接模式。若日志中的主机名与预想不同，应以实际主机名为依据谨慎补充，而不是复制来路不明的全量规则列表。

小技巧：排障时一次只改一项。先固定一个节点，确认目标连接的规则命中；再测试 DNS 或 TUN。若同时改变节点、模式和规则，即使问题暂时消失，也很难知道真正起作用的是哪一步。

第三步：让终端进程使用代理，必要时再启用 TUN 深入理解

许多图形客户端可以通过「设置系统代理」影响遵循操作系统代理设置的应用，但命令行程序是否使用系统代理，取决于操作系统、运行时及程序本身。因而常见的误判是：浏览器已经走代理，Claude Code 仍直接连接网络。先检查客户端的系统代理开关和本机 HTTP 混合端口，再确认该工具或其运行环境是否支持代理环境变量；不同版本对环境变量的读取方式可能不同，设置了变量也不等于请求必然走代理。

如果客户端文档确认支持标准代理环境变量，可以在启动 Claude Code 的同一个终端会话中设置，并把端口换成本机 Clash 实际使用的 HTTP 或混合端口。例如，以下命令只适用于客户端确实在本机监听对应端口的情况：

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
export NO_PROXY=localhost,127.0.0.1

Windows PowerShell 的环境变量语法与 macOS、Linux shell 不同；而且有些应用只识别特定变量或有自己的代理设置。请对照当前终端和 Claude Code 版本的说明操作，并通过 Clash 连接日志验证结果。遇到登录流程时，也要避免把回环地址加入代理：本机的 localhost 或 127.0.0.1 通常应保留在 NO_PROXY 中，以免本地授权回调被错误转发。

若系统代理和程序支持的代理变量都不能稳定覆盖终端流量，可以将 TUN 模式作为下一步测试。TUN 从网络层接管符合配置条件的流量，适合不读取系统代理设置的应用，但它也会影响更多程序及路由行为。启用前确认客户端已获得所需权限、当前配置支持 TUN，并留意 VPN、虚拟机、容器或其他网络过滤软件是否与路由规则冲突。开启后仍要回到连接日志确认 Claude Code 的请求实际被接管；只看到 TUN 开关亮起，并不能单独证明目标连接可用。

不要把环境变量当作凭据：代理变量只负责指定网络出口，不会自动修复 API Key、账号授权或组织权限。排查完成后，若你不希望其他终端程序共用该代理，可以关闭当前终端窗口或清除变量；公开粘贴命令输出前，先检查其中是否包含敏感信息。

第四步：检查 DNS、节点稳定性与错误类型 详解

规则命中正确而请求仍然超时，接下来要判断问题是在域名解析、TCP/TLS 建连，还是服务端响应阶段。DNS 异常可能导致域名解析失败、解析到不可达地址，或在 Clash 与操作系统之间出现不一致结果。先查看 Clash DNS 相关日志，以及连接详情中解析后的目标地址；若客户端显示 DNS 错误或连接建立前就失败，再检查配置中的 DNS 模式、上游解析服务和 TUN 的 DNS 接管设置。一次只调整 DNS 的一个环节，然后重新测试同一个请求。

不要仅凭「换成某个 DNS 后网页能开」就断言问题已解决。网页访问可能走缓存、不同域名或不同网络路径，Claude Code 请求则可能需要重新解析多个主机名。修改 DNS 后清理本机缓存是否必要，取决于系统与客户端实现；更可靠的判断仍是查看新请求的解析结果和连接日志。若只有开启 TUN 后出现异常，也应检查 TUN 的 DNS 劫持、自动路由、网络接口选择和其他 VPN 的冲突，而不是叠加多套 DNS 规则。

节点质量也不应只看测速数值。短连接测速看起来很快，不代表它能稳定完成较长的 TLS 会话或连续 API 请求。建议暂时选定一个可用节点，连续尝试相同操作几次，观察是否每次都在同一阶段失败；再换一个节点作对照。若只有特定节点失败，问题更可能在该节点的出口或线路；若多个节点都在同一阶段失败，则应重新检查规则、代理接管方式、DNS 和本机网络。

报错内容可以帮助缩小范围，但不同客户端版本和底层运行时的错误文本不完全一致：

  • 连接超时或网络不可达：先查进程是否被 Clash 接管、规则是否直连，再测试节点和本机网络。
  • 连接重置或 TLS 握手失败：检查节点稳定性、代理链路、系统时间及是否存在其他网络过滤软件。不要通过关闭证书校验来规避。
  • DNS 解析失败：检查日志中的解析目标、Clash DNS 设置及系统网络配置，避免同时启用互相冲突的 DNS 接管方式。
  • 明确的认证或权限响应：网络请求可能已到达服务端，应检查 Claude Code 登录状态、所用凭据和账户权限。

第五步：用最小变更复测，避免把问题越修越复杂 全面解析

完成初步排查后，建议把测试条件固定下来：保留当前订阅，选择一个明确的节点，使用规则模式，并仅对日志中确认需要代理的目标域名设置规则。先在 Clash 连接页确认命中结果，再从同一终端发起 Claude Code 请求。记录时间、错误阶段、策略组和是否出现连接记录，这些信息足以让你比较每次调整的效果，不需要一上来就导出整份配置或重装所有软件。

如果使用环境变量，检查它们是否只在预期的终端会话中生效；如果使用系统代理，确认客户端退出或切换配置后系统代理状态没有残留；如果使用 TUN，则确认停用后网络路由恢复正常。调整配置前可备份原文件或使用客户端的覆写功能，避免订阅更新覆盖本地修改。任何测试都应先恢复一个能正常使用的状态，再进行下一项改动。

当 Clash 日志显示请求已经通过预期节点成功连接，但 Claude Code 仍返回账号、地区、配额或权限相关提示时，应停止反复修改网络规则，转向检查服务端返回内容和账号设置。相反，如果日志持续显示直连、没有记录，或在代理握手阶段失败，就继续针对本机代理接管和节点链路排查。把网络问题与账户问题分开处理，通常比一次性重置全部配置更快，也更容易复现和解决。

常见问题 一次讲透

浏览器能打开 Claude，为什么 Claude Code 还是超时？（详解）

浏览器可能遵循系统代理或自己的代理设置，而终端进程不一定会使用同一出口。先在 Claude Code 发起请求时查看 Clash 连接日志：没有记录时，检查系统代理、程序支持的代理环境变量或 TUN；出现记录但命中直连时，修正规则；已命中代理仍超时，再比较节点和 DNS。

要不要把 Clash 切成全局模式？（要点）

不建议把全局模式作为第一步。先确认目标域名、规则命中和策略组，针对实际需要代理的连接调整规则，范围更清楚，也不容易让无关流量一起改变。全局模式可以作为短暂对照测试，但测试后应恢复原模式，并结合日志判断结果，不能把「全局模式暂时可用」当成最终配置方案。

开启 TUN 后 Claude Code 仍然连接失败，怎么办？（说明）

TUN 开启只说明接管模式已启用，不代表该连接一定通过正确节点。检查 TUN 权限和路由状态，再查看连接日志中的目标主机、命中规则和代理结果。如果连接已到服务端并返回认证或权限错误，继续调整 TUN 通常无助于解决问题；如果日志没有连接记录，则需检查应用是否实际发起请求及本机网络环境。

重装 Clash 或 Claude Code 能解决连接超时吗？（实践）

只有在程序文件损坏、版本异常或配置无法恢复时，重装才可能有帮助。对于规则命中直连、终端没有使用代理、DNS 异常或节点不稳定，重装通常不会改变根因。先保存必要配置并用日志定位问题；涉及账号密钥或订阅链接时，切勿把它们作为排障截图公开分享。

相比一些只强调一键代理、却不展示规则命中和连接去向的工具，Clash 在这类终端排障中更适合逐条核对流量路径；不过不同客户端的界面、TUN 权限和配置入口各有差异，新手若在多个旧教程之间来回对照，确实容易改错位置。Clash 将客户端选择、配置思路与常见网络问题整理成可按步骤验证的说明，便于你先确认终端是否走代理，再有针对性地调整规则或 DNS；如果你还缺少合适的客户端，可以先前往下载，再按本文的方法检查 Claude Code 的实际连接。