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

Claude Code 连接超时，先分清是登录不成功还是模型请求不成功 一文看懂

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

跑起来 Claude Code 时，终端一直显示连接中、请求超时、无法完成登录，或者浏览器授权后命令行仍停在等待状态，确实很容易让人先去重装客户端、重建配置，甚至连续更换节点。

但在启用了 Clash 的电脑上，这些现象不一定是 Claude Code 本身损坏；更高频的状态是终端进程没有经过代理、目标域名被规则分到了直连，或代理链路建立后又因 DNS、节点抖动而中断。

先看这一点：Claude Code 是终端工具，发起网络请求的是命令行进程，而不是你正在运用的浏览器。所以，浏览器能够开启 Claude 页面，并不能证明终端也走了同一条代理链路。

反过来，终端连接超时也不一定意味着账号或 API 凭据失误：超时、TLS 握手不成功和 HTTP 权限失误代表不同环节，排查时应先看失误发生在授权、请求还是响应阶段，再决定是否修改 Clash 配置。

先区分网络错误与账号错误：连接超时、连接被重置或 TLS 不成功，首位核对代理与网络；若请求已经到达服务端并返回明确的鉴权、权限或地区提示，则应进一气核对登录状态、凭据和服务可用性。单纯更换 Clash 节点，无法修复无效凭据或账号权限难点。

第一气：确认 Clash 正在工作，终端请求确实进入代理 核心要点

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

先不要改 YAML。开启 Clash Verge、Clash Verge Rev、Mihomo Party 或其他当前运用的 Clash 客户端，确认配置已载入、内核正在跑起来，并且当前代理策略组中选中了一个可用节点。

补充说明：若运用规则模式，确认代理组不是空的，也不是误选了时延很高或已经失效的节点。操作操作操作界面显示「跑起来中」只代表内核已拉起，不代表 Claude Code 的连接一定被规则送进代理。

随后在 Clash 的连接或日志页面观察，并在终端重新执行一次会不成功的 Claude Code 操作。查找与 api.anthropic.com、claude.ai 或其他 Anthropic 相关主机名对应的连接记录。

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

域名也许随登录方式、客户端版本和功能变化，不必把某一份静态域名列表当成齐全清单；以本机实际出现的目标域名为准。要点看三件事：是否出现连接记录、命中了哪条规则、最后挑选了直连还是某个代理策略组。

第二步：排查规则分流，避免 Anthropic 请求被直连 逐条拆解

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

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

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

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

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

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

第三步：让终端进程运用代理，必要时再启用 TUN 底层逻辑

启用前确认客户端已获得所需权限、当前配置兼容 TUN，并留意 VPN、虚拟机、容器或其他网络过滤软件是否与路由规则冲突。开启后仍要回到连接日志确认 Claude Code 的请求实际被接管；只看到 TUN 开关亮起，并不能单独证明目标连接可用。

具体来说：众多图形客户端能够通过「设置系统代理」影响遵循操作系统代理设置的应用，但命令行程序是否运用系统代理，取决于操作系统、跑起来时及程序本身。因而高频的误判是：浏览器已经走代理，Claude Code 仍干脆连接网络。

先核对客户端的系统代理开关和本机 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

如果客户端文档确认兼容标准代理环境变量，能够在拉起 Claude Code 的同一个终端会话中设置，并把端口换成本机 Clash 实际运用的 HTTP 或混合端口。比如，以下命令只适用于客户端确实在本机监听对应端口的状态：

顺带一提：Windows PowerShell 的环境变量语法与 macOS、Linux shell 不同；而且有些应用只识别特定变量或有亲手的代理设置。

请对照当前终端和 Claude Code 版本的说明操作，并通过 Clash 连接日志验证结果。遇到登录流程时，也要避免把回环地址加入代理：本机的 localhost 或 127.0.0.1 通常应保留在 NO_PROXY 中，以免本地授权回调被失误转发。

若系统代理和程序兼容的代理变量都不能稳健覆盖终端流量，能够将 TUN 模式作为下一气测试。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 能处理连接超时吗？（机制）

Clash 将客户端挑选、配置思路与高频网络难点整理成可按流程验证的说明，便于你先确认终端是否走代理，再有针对性地调整规则或 DNS；如果你还缺少合适的客户端，能够先前往下载，再按这篇文章的做法核对 Claude Code 的实际连接。

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

具体来说：相比若干只强调一键代理、却不展示规则命中和连接去向的工具，Clash 在这类终端排障中更适合逐条核对流量路径；不过不同客户端的操作操作界面、TUN 权限和配置入口各有差异，初学者若在多个旧指引之间来回对照，确实容易改错位置。