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

Claude Code 连接超时，先分清是登录无法完成还是模型请求无法完成 要点速览

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

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

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

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

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

第一口气：确认 Clash 正在工作，终端请求确实进入代理 关键信息

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

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

这里要多说一句：若采用规则模式，确认代理组不是空的，也不是误选了响应时间很高或已经失效的节点。UI UI UI 界面显示「持续持续持续运行中」只代表内核已开启，不代表 Claude Code 的连接一定被规则送进代理。

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

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

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

第二步：排查规则分流，避免 Anthropic 请求被直连 关键点梳理

修改后重新触发一次请求，再看连接日志是否命中预期规则和代理组。若日志已经显示对路命中，但仍然超时，不要继续重复增加相同域名规则；

在 mode: rule 下，Clash 按规则从上往下匹配，先命中的规则决定连接去向。如果较宽泛的直连规则、地区规则或自定义规则排在前面，Anthropic 请求或许在到达代理规则之前就被送往直连。

此时浏览器是否能访问到到其他网站、节点测速是否正常，都不能证明 Claude Code 目标域名已经采用代理。

落到实处：得以先在规则列表中搜索日志记录的实际域名，排查它是否被 DOMAIN、DOMAIN-SUFFIX、规则集或更宽泛的规则提前匹配。确认根源后，再把范围尽量小的代理规则放到相关直连规则之前。

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

下面的片段仅展示写法；AI-Proxy 必须替换为你配置中真实存在的策略组名称，且具体域名应以自行的连接记录和客户端文档为准。

不要为了「保险」把各个流量都粗暴塞进同一个代理组。较宽的后缀规则或许覆盖 Anthropic 以外的服务，增加不必要的代理流量，也会让日后排查命中关系更复杂。

别忽略了：若你的订阅采用规则集、覆写或远程配置，先确认本地修改能否在升级订阅后保留；有些客户端会重新生成配置，径直改临时文件或许很快被覆盖。

转而测试节点、DNS 和连接模式。若日志中的主机名与预想不同，应以实际主机名为依据谨慎补充，而不是复制来路不明的全量规则列表。

第三步：让终端进程采用代理，必要时再启用 TUN 完备说明

若系统代理和程序适配的代理变量都不能平稳覆盖终端流量，得以将 TUN 模式作为下一口气测试。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，并留意 VPN、虚拟机、容器或其他网络过滤软件是否与路由规则冲突。开启后仍要回到连接日志确认 Claude Code 的请求实际被接管；只看到 TUN 开关亮起，并不能单独证明目标连接可用。

第四步：排查 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 仍返回账号、地区、配额或权限相关提示时，应停止反复修改网络规则，转向排查服务端返回正文和账号设置。

别忽略了：完成初步排查后，不妨把测试条件固定下来：保留当前订阅，选定一个明确的节点，采用规则模式，并仅对日志中确认要代理的目标域名设置规则。

先在 Clash 连接页确认命中结果，再从同一终端发起 Claude Code 请求。记录时间、疏漏阶段、策略组和是否出现连接记录，这些信息足以让你颇为每次调整的成效，不要一上来就导出整份配置或重装各个软件。

如果采用环境变量，排查这几个是否只在预期的终端会话中生效；如果采用系统代理，确认客户端退出或切换配置后系统代理状态没有残留；如果采用 TUN，则确认停用后网络路由恢复正常。

关键点是：调整配置前可备份原文件或采用客户端的覆写功能，避免订阅升级覆盖本地修改。不管哪一套测试都应先恢复一个能正常采用的状态，再进行下一项改动。

相反，如果日志持续显示直连、没有记录，或在代理握手阶段无法完成，就继续针对本机代理接管和节点链路排查。把网络困扰与账户困扰分开处理，多数现状下比一次性重置全部配置更快，也更容易复现和处置。

普遍困扰 关键点梳理

浏览器能启用 Claude，为什么 Claude Code 还是超时？（速览）

浏览器或许遵循系统代理或自行的代理设置，而终端进程不一定会采用同一出口。

先在 Claude Code 发起请求时查看 Clash 连接日志：没有记录时，排查系统代理、程序适配的代理环境变量或 TUN；出现记录但命中直连时，修正规则；已命中代理仍超时，再颇为节点和 DNS。

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

不不妨把全局模式作为第一口气。先确认目标域名、规则命中和策略组，针对实际要代理的连接调整规则，范围更清楚，也不容易让无关流量一起改变。

这里要多说一句：全局模式得以作为短暂对照测试，但测试后应恢复原模式，并结合日志判断结果，不能把「全局模式暂时可用」当成最终配置方案。

开启 TUN 后 Claude Code 仍然连接无法完成，怎么办？（清单）

TUN 开启只说明接管模式已启用，不代表该连接一定通过对路节点。排查 TUN 权限和路由状态，再查看连接日志中的目标主机、命中规则和代理结果。

如果连接已到服务端并返回身份校验或权限疏漏，继续调整 TUN 多数现状下无助于处置困扰；如果日志没有连接记录，则需排查应用是否实际发起请求及本机网络环境。

重装 Clash 或 Claude Code 能处置连接超时吗？（说明）

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

只有在程序文件损坏、版本异常或配置无法恢复时，重装才或许有帮助。对于规则命中直连、终端没有采用代理、DNS 异常或节点不平稳，重装多数现状下不会改变根因。

换个说法：先保存必要配置并用日志定位困扰；涉及账号密钥或订阅链接时，切勿把这几个作为排障截图公开分享。

Clash 将客户端选定、配置思路与普遍网络困扰整理成可按环节验证的说明，便于你先确认终端是否走代理，再有针对性地调整规则或 DNS；如果你还缺少合适的客户端，得以先前往下载，再按本篇正文的思路排查 Claude Code 的实际连接。