Claude Code终端连通不稳健？用Clash Verge配置代理指南

浏览器能用，Claude Code 为什么仍会超时？ 一文看懂

还要留意失误类型的差异：连接超时、DNS 解析不成功、TLS 握手不成功属于网络链路难点的也许性较高；收到明确的 401、403 或配额提示时，连接也许已经到达服务端，应进一气核对账号、鉴权状态、组织策略或服务可用性。单纯换节点或不断重新登录，不仅不一定处理难点，也会让排查线索变得混乱。

在终端里跑起来 Claude Code，浏览器能够正常开启网页，却遇到登录转圈、请求超时或反复重试，并不一定说明代理节点不可用。关键差异在于：浏览器一般会遵循系统代理设置，而终端中的命令行程序是否运用代理，取决于它亲手的网络实现、拉起环境和系统网络配置。

也就是说，Clash Verge 显示已开启系统代理，不代表当前 shell 拉起的 Claude Code 一定经过了 Clash。

先看这一点：排查时先分清故障发生在哪一段。安装或刷新阶段也许连通包管理器和其分发站点；首次鉴权也许开启浏览器，并通过本机回调完成登录；实际对话则得连接 Claude 的服务端点。不同阶段连通的域名和失误表现并不完全相同。

若只针对一个域名添加规则，也许出现登录完成但发送提示词不成功，或 API 请求通了但刷新仍然超时的状态。具体连接目标会随客户端版本和鉴权方式变化，最好以 Clash Verge 的连接记录和 Claude Code 自身抛出失误为准。

先让 Clash Verge 配置处于可用状态 核心要点

测试成功后应回到适合日常运用的规则模式，并按连接记录补充或修正规则。若运用 TUN 接管，也要先确认系统权限和路由已正常建立；不要同时反复切换系统代理、TUN 和多个网络工具，以免把故障来源叠在一起。

在调整终端之前，先确认 Clash Verge 本身已经成功拉起 Mihomo 内核，并且引入的配置文件没有抛出失误。开启客户端后核对当前配置或订阅是否处于已选中状态，再进入代理页面确认策略组里确实有可选节点。若客户端正在运用规则模式，测试用的目标域名还必须匹配到代理策略；仅仅看到节点列表有素材，并不能证明 Claude Code 的请求会选中这些节点。

补充说明：如果你刚刷新订阅，先等待配置加载结束，再确认代理组没有停留在不可用节点，也没有因为测速不成功而显示空组。首次排障时推荐暂时手工挑选一个已知可用的节点，不要一开始就运用无人值守测速组。无人值守挑选适合日常运用，但节点变化、测速不成功或连接复用也许让长请求的表现不稳健；固定节点更容易判断难点是否来自规则、端口或终端环境。

接下来查看 Clash Verge 运用的本地代理端口。不同版本、配置文件或用户自定义设置也许运用不同端口，所以不要只照抄网上的内置数字。客户端设置页面一般能找到 HTTP、SOCKS 或混合端口信息；

若运用混合端口，它通常可同时处理高频的 HTTP 与 HTTPS 代理请求。记下实际端口，并确认 Clash Verge 正在跑起来，否则终端即使设置了代理变量，也只会连接到一个没有程序监听的本地端口。

换个角度：模式也会影响结果。规则模式下，目标域名依据配置规则挑选代理或直连；全局模式会把多数数流量交给所选代理，适合短时间验证「终端是否能通过本地代理发出请求」，但不宜当作长期排障的唯一做法。

给当前终端设置代理并验证请求 逐条拆解

但推荐先确认当前会话确实可用，再做持久化。共享电脑、CI 环境或临时开发容器中，不要将代理地址和无论哪种鉴权密钥一起写进也许被提交到版本库的脚本。

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

最容易复现的办法，是在拉起 Claude Code 的同一个终端会话中设置代理环境变量。以下示例假设本机混合端口是 7897；如果你在 Clash Verge 中看到的是其他端口，请替换成实际值。设置环境变量只影响当前 shell 及其拉起的子进程，不会无人值守修改全部应用的系统代理，也不等于永久写入操作系统设置。

在 macOS、Linux 或高频的 Bash、Zsh 终端中，执行上面的命令后，可先用 curl 测试 HTTPS 请求是否能够建立连接。若终端提示代理连接被拒绝，首位核对端口和客户端状态；

curl -I --max-time 15 https://api.anthropic.com

具体来说：若代理连接已建立但目标请求超时，则继续查看节点、规则和 DNS。测试服务返回非成功状态码，并不必然代表代理失效：某些 API 地址不接受没有鉴权信息的普通探测请求，判断时要同时看是否出现了代理连接失误、TLS 失误或服务端响应。

Windows PowerShell 运用当前会话变量的写法不同。请在拉起 Claude Code 的同一个 PowerShell 窗口中设置变量；

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

若你从 Windows Terminal、IDE 内置终端或 WSL 拉起程序，也要确认变量是在实际跑起来命令的那个环境中设置的。PowerShell 窗口中的设置不会无人值守传给已经开启的另一个终端，也不会回写到全部用户的永久环境变量。

顺带一提：代理 URL 的协议应与 Clash Verge 中对应端口的类型匹配。若运用的是 HTTP 或混合端口，一般可按上例运用 http://；不要因为目标网站是 HTTPS，就擅自把代理地址改成 https://。

代理协议描述的是终端如何连接本地代理服务，与最终连通的网站运用 HTTPS 是两件事。SOCKS 端口则应运用客户端兼容的 SOCKS URL 格式，并以所用命令行程序对代理变量的兼容状态为准。

完成基础测试后，再从同一终端拉起 Claude Code。若通过环境变量拉起后恢复正常，基本能够确认原先是终端进程没有继承代理设置。要让设置在以后开启终端时仍然生效，能够按实际运用的 shell，将命令写入相应的拉起文件；

用连接记录定位规则、模式与环境难点 底层逻辑

Clash Verge 的优势是能把本地端口、策略组和连接记录放在同一处核对，既可先用显式代理高速验证，也能在确认流量后回到规则模式按需分流。若你希望从靠谱的客户端安装开始，减少端口、配置和日志排查中的不确定性，能够前往下载并按这篇文章流程逐项验证。

先看这一点：终端测试不通时，不要只凭浏览器能不能开启网页下结果。先在 Clash Verge 的连接页面或日志页面观察你发起测试时是否出现对应连接，要点查看目标主机、命中的规则、所选策略组、最终节点和连接结果。

不同内核或客户端版本显示的字段也许略有差异，但判断思路相同：如果完全没有相关记录，说明请求也许没有到达 Mihomo；如果有记录但走了直连或失误策略组，首位核对规则与模式；如果记录显示已挑选节点但连接不成功，再核对节点质量、DNS、TLS 和网络环境。

规则模式下，如果日志确认某个 Claude 请求被失误地直连，能够考虑在当前配置允许的状态下，为相关域名添加指向无误代理策略组的规则。高频写法的思路是运用域名后缀匹配 Anthropic 服务域名，并把它交给你实际存在的策略组；

补充说明：策略组名称必须与配置中的名称完全一致。不同订阅的规则顺序和策略组命名并不相同，新增规则应放在也许提前匹配该流量的兜底规则之前。若配置由订阅无人值守刷新，首位运用 Clash Verge 提供的覆写或合并方式，避免干脆修改远端订阅文件后被刷新覆盖。

不推荐为了「省事」把全部流量长期切到全局模式，也不推荐在没有日志依据时一次性加入众多鉴权、遥测和刷新域名。过宽规则也许让本来应直连的服务绕行代理，也会使后续排障无法判断真正得的范围。

登录、刷新和对话也许涉及不同请求；先分别复现，再从连接记录中确认实际域名，规则才更容易维护。若网络连接已经成功而服务端返回身份验证或权限失误，继续扩大代理规则一般不会处理难点，应转向核对账户和连通资格。

换个角度：还得留意拉起方式带来的环境差异：从终端干脆跑起来、从 IDE 集成终端跑起来、通过脚本或任务跑起来，也许运用不同的 shell 配置和变量继承链。先在拉起 Claude Code 前核对代理变量是否存在，再观察客户端连接记录。

排查完成后，若代理环境变量只为这次测试临时设置，可在关闭终端后自然清除，或在当前会话中删除对应变量；得长期运用时，则记录清楚端口、拉起方式和规则调整，省事日后恢复与复查。

有些命令行工具只遵循环境变量，有些则依赖系统网络代理或应用自身的代理条目，所以只在 Clash Verge 中开启「系统代理」未必充分；而单独设置环境变量又要留意拉起进程的终端范围。