Claude Code终端连接不稳定？用Clash配置访问与分流指南
Claude Code 终端连接不稳定，先分清卡在哪一步 详解
运行 Claude Code 时，如果出现登录页面反复跳转、命令长时间没有响应、请求中途失败，或者浏览器能访问 Claude 而终端始终超时，问题未必出在账号或模型本身。桌面浏览器通常会跟随系统代理或浏览器扩展，终端里的 Claude Code 则由命令行进程发起网络连接；它是否使用代理，取决于启动时继承的环境变量、客户端的网络实现和当前系统网络路径。仅仅在 Clash Verge、Clash Verge Rev 或 Mihomo 中打开“系统代理”，不一定能让每个 shell、Node.js 进程或远程开发会话都自动走代理。
排查时先记录具体症状和发生阶段，而不是一遇到超时就更换节点。登录流程可能涉及浏览器授权、账号认证服务和本机回调；正常对话则会连接 Anthropic 的 API 服务；安装或更新工具还可能访问包管理器及其分发网络。这些请求的目标主机并不一定相同。若浏览器授权成功、终端对话失败，重点应放在 Claude Code 进程的代理继承和 API 域名分流；若安装阶段失败，则要另查 npm 或相应安装源的连接，不能仅凭一次失败就认定 Claude API 被规则拦截。
建议先打开 Clash 的连接记录，在复现问题的同时观察目标域名、命中的规则、策略组与实际节点。客户端界面名称因版本而异，但通常可以在“连接”“日志”或“Connections”页面找到这些信息。若完全没有对应连接记录，流量可能没有进入 Clash；若记录显示连接被 DIRECT 处理，说明规则顺序或终端代理设置值得优先检查；若已匹配代理策略但请求仍失败，再检查所选节点、TLS 连接和服务端返回内容。把“终端未走代理”“命中错误规则”和“代理已通但账号或服务端报错”分开，能显著减少无效试错。
先保护凭据：排障截图和日志可能包含账号信息、请求路径或环境变量。分享前请遮住 API Key、访问令牌、订阅链接和私人主机名；不要把认证信息粘贴到公开仓库或聊天记录中。
先让 Claude Code 进程明确使用 Clash 代理 全面解析
对于主要使用命令行的开发者，最容易验证的方式是在启动 Claude Code 的同一个终端会话中设置代理环境变量。先在客户端设置页面确认 HTTP 或混合端口的实际地址和端口号；不少配置使用本机回环地址以及类似 7890 的端口，但端口会因客户端、配置文件和用户修改而变化，不能照抄示例。确认端口已经启用后，再将代理变量指向该端口。HTTP 与 HTTPS 目标通常都可以通过本地 HTTP 代理转发，变量名称写作 HTTP_PROXY 和 HTTPS_PROXY，并建议同时设置小写形式，以兼容不同运行时和依赖库。
# macOS / Linux：请把 7890 替换为 Clash 的实际混合端口
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
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
export all_proxy="$ALL_PROXY"
# 设置后，在当前终端启动
claude如果终端提示找不到 claude，那是命令安装或 PATH 问题，不等于代理设置失败。若命令可以启动但仍连不上，可以先使用系统已有的 HTTP 客户端测试本机代理是否能连接目标，再观察 Clash 是否生成对应连接记录。测试时尽量使用你实际遇到问题的服务域名；单独测试一个公开网站，只能证明该网站的连接路径可用，不能证明 Claude Code 使用的每个域名都已经正确分流。
# 用 curl 验证代理路径；域名和端口可按实际情况替换
curl -I -x http://127.0.0.1:7890 https://api.anthropic.com/这个请求返回未授权、方法不支持或其他 HTTP 状态，并不必然代表代理故障：它只是检查 DNS、TCP、TLS 和 HTTP 请求是否能够到达服务端，并没有提供有效的 Claude Code 认证。真正要关注的是请求是否超时、TLS 是否握手失败，以及 Clash 连接日志里是否出现了目标域名和所选节点。可以把“代理连通性”和“账号权限、模型可用性”当成两项独立检查，避免把服务端拒绝误判为网络不通。
Windows PowerShell 用户可在启动命令前为当前窗口设置变量。新开的终端通常不会自动继承另一个已打开窗口的临时设置；通过图形界面启动的 IDE、远程开发容器或任务计划程序，也可能有各自不同的环境变量。修改后应在实际运行 Claude Code 的终端中重新启动进程，并确认变量值没有被旧窗口缓存。
# Windows PowerShell：使用 Clash 实际 HTTP / 混合端口
$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"
claude如果设置了代理变量却仍然直连，可按顺序核对：变量是否在启动命令之前设置；代理地址是否写成终端本机可访问的地址；Clash 的对应监听端口是否启用；终端是否运行在 WSL、容器、SSH 主机或虚拟机里。容器中的 127.0.0.1 指向容器自身，并不一定是宿主机上的 Clash；远程服务器里的回环地址也只代表远程服务器。此时需要针对运行位置确认可达的代理地址和网络拓扑，不能简单复制本机配置。
排查小技巧：在设置变量后先运行一个小型网络测试，再启动 Claude Code；一次只改一个条件，并记录变量、规则命中和节点名称。这样更容易确认问题究竟是终端没有使用代理，还是代理已经建立但目标服务仍不可用。
按连接记录设置 Clash 分流，不要盲目堆域名 一次讲透
Claude Code 所需的连接会随登录方式、功能和客户端版本变化，规则也可能因服务端调整而需要更新。配置时可以从已知的 Anthropic 服务域名开始检查，例如 api.anthropic.com；账号登录或网页授权过程中若观察到 claude.ai、console.anthropic.com 等目标，再根据连接记录判断是否需要一并纳入代理策略。不要把未经本机验证的域名清单当成永久完整的官方列表，也不要因为一个遥测或错误报告域名出现，就把所有相关网络流量都无差别送进代理。
对于 Mihomo 内核，规则应放在可能提前匹配的宽泛规则和兜底规则之前。下方只是展示规则组织方式，策略组名称必须替换为你现有配置中的真实名称；如果配置采用规则提供者或客户端覆写，应在相应位置添加，而不是无意中改写服务商下发的整份配置。
rules:
- DOMAIN,api.anthropic.com,PROXY
- DOMAIN-SUFFIX,anthropic.com,PROXY
- DOMAIN-SUFFIX,claude.ai,PROXY
- MATCH,DIRECT上面的例子表达的是优先匹配相关服务域名，再交给代理策略组；它不表示每个人都应该使用名为 PROXY 的组，也不意味着所有 Anthropic 子域都必须走同一条线路。若你希望让某个策略组自动选择节点，可以将规则的策略目标指向该组；若排障期间要固定出口，则可暂时选定一个稳定节点，减少自动测速切换带来的干扰。对长时间运行的命令行任务而言，连接过程中节点变化可能造成连接中断，所以应先确认节点稳定性，再考虑恢复自动选择。
规则顺序尤其重要。假如前面已经有把特定域名直连的规则，后面新增的代理规则就不会被匹配；假如一条较宽的规则先把所有流量交给其他策略组，精确规则也可能失去作用。添加规则后，重新连接并查看日志，确认目标域名命中了预期规则、策略组和节点。若日志显示规则命中正确而连接仍失败，可以临时在代理策略组中手动选择另一个可用节点进行对照；测试结束后再决定是否保留固定节点，避免把临时排障状态误当成长期最佳配置。
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| Clash 中找不到目标连接 | 终端代理变量、进程启动环境、TUN 接管范围 | 在同一终端测试代理端口，并确认运行环境是否为容器或远程主机 |
| 连接记录显示 DIRECT | 规则顺序、域名匹配范围、配置覆写是否生效 | 把精确规则放到兜底规则前，重新连接并检查命中结果 |
| 已走代理但连接超时 | 策略组选择、节点可用性、代理服务器延迟 | 暂时固定另一个节点，对同一请求做对照测试 |
| 网络可达但收到认证或权限错误 | 登录状态、账号权限、API 配置和服务端响应 | 保留网络测试结果，转向账号或服务配置排查 |
有些用户会考虑直接开启 Clash TUN 模式，让客户端从网络层接管更多应用流量。它适合终端程序不遵从代理变量、或者系统代理覆盖不到的应用，但也会改变路由和 DNS 处理路径，可能影响本地开发服务、VPN、虚拟机或公司内网。若环境变量已经能让 Claude Code 稳定连接，通常没有必要为了这一项命令行工具立刻开启 TUN；若确实需要 TUN，应先确认客户端权限、路由模式和内网排除规则，再逐项测试。不要同时更换代理变量、DNS、规则和 TUN 设置，否则出了问题很难找出真正原因。
稳定性验证与常见误区：把网络、登录和服务错误分开 深入理解
完成代理与规则配置后，建议用一次完整但可重复的检查来确认结果：在一个新的终端会话里设置代理变量；检查变量值与 Clash 监听端口一致；启动 Claude Code 并执行一个简单请求；同时观察 Clash 连接日志中的域名、规则、策略组和节点。若第一次请求成功、后续请求偶尔失败，可以继续记录失败发生的时间、目标域名和连接状态，判断是否是节点抖动、网络切换、代理进程休眠，或客户端进程没有继承最新环境。单凭“刚才好像通了”不足以说明整个链路已经稳定，尤其是切换 Wi-Fi、休眠唤醒或打开新终端之后，环境可能发生变化。
如果浏览器能登录、命令行却无法登录，先确认 Claude Code 是从哪个终端或 IDE 启动的，再检查该进程实际使用的代理环境。若浏览器授权后终端没有收到回调，检查本机安全软件、防火墙和回调端口是否被占用；不要把 localhost 或 127.0.0.1 的本地回调流量误加入远端代理规则。若请求已经到达服务端并返回明确的认证、权限或使用额度错误，换节点通常不会解决账号层问题，应保留错误信息并核对登录账号与产品权限。
常见误区之一，是只在操作系统设置里打开系统代理，就认为终端所有程序都会遵从。不同命令行工具、运行时、编辑器终端和远程开发环境的行为并不完全相同，最可靠的判断依据是同一进程的代理变量和 Clash 连接日志。第二个误区是把所有 Anthropic 相关请求一律写成代理规则，却忽略规则顺序和直连例外。第三个误区是一次超时后连续更换客户端、节点、DNS 与 TUN 设置；如果每次改动很多，短暂恢复也无法证明具体是哪项生效。采用“先观察、一次改一项、再复测”的方法，才更容易形成可复用的配置。
还要注意密钥与代理地址的安全边界。代理环境变量只是告诉进程如何连接网络，不应把 API Key 写进公开脚本、命令历史或共享配置文件；若使用第三方节点，也应了解该网络出口由谁提供，并避免在不可信环境中传递敏感开发凭据。将代理变量写入 shell 启动文件虽然方便，但会让之后启动的其他命令也使用同一代理；若只希望 Claude Code 使用代理，可以只在当前终端会话设置，任务结束后关闭窗口，或按团队安全规范管理变量。排障日志也应在分享前删去令牌、用户名、内网地址及项目路径。
相较于需要手动拼接环境变量、反复猜测规则顺序的零散代理方案，Clash 客户端能把终端流量的连接记录、规则命中与节点选择集中展示，便于开发者按实际请求逐项验证；不同客户端的界面和 TUN 能力各有差异，配置文件也需要结合自己的端口与策略组调整。Clash 提供面向常见 Clash 客户端的下载入口和配置说明，适合希望把终端代理问题拆成可检查步骤的用户；如果你正准备安装客户端或更换工具，可以先前往下载，再按本文的方法核对 Claude Code 的连接链路。