为什么是「浏览器还行、CLI 却挂」的典型组合
Claude Code 的许多操作看起来只是「打一个命令」，背后却可能是：控制面会话、令牌交换、远端工具注册、SSE 流与多次短连接混在一起。Chrome 或其他浏览器往往已经跟随系统代理，但终端里的运行时并不天然继承同一出站：有的语言运行时读环境变量；有的二进制走系统解析器；还有一部分实现会在直连失败后才尝试走代理——这时你看到的就是莫名其妙的长尾超时或偶发 RST。
解决思路应该从「进程的默认出站是哪条？」倒推，而不是先试一圈节点。若在图形客户端只用 HTTP/SOCKS 监听端口而未让命令行读取 http_proxy／https_proxy／all_proxy，或未开启 TUN 级接管，则终端侧连接大量落在直连路径上——跨境链路一抖就会把 OAuth 与控制面拖到超时。请先把它当成「出站一致性问题」，再讨论节点质量。
Windows 场景的首次安装可参考 Windows 下 Clash Verge Rev 安装与首次代理；若你已熟悉 Cursor 链路里 GitHub 与 npm 的分流范式，可把本文当作同一套方法论在 Claude Code 上的外延：区别在于命中域名与控制面不完全重叠，仍以日志为准。Cursor／GitHub／npm 分流 这篇讲开发依赖，本篇讲 Anthropic 终端工具链本身的握手与超时。
与「网页与 API」通稿的关系：别重复踩坑
站内已有 Claude 网页与 API：Clash 分流与 DNS（2026）：它把通用的 anthropic.com、claude.ai 与网关类主机拆成可按日志维护的规则条目，并把 FakeIP／DoH／规则顺序讲得系统。本篇不再复述「整套 DNS 理论体系」，而把注意力放在两个差异点：① CLI 进程的默认出站与浏览器不同；② 你可能会把「看起来像 API 的失败」误判为 IDE 插件或本地防火墙，实际是命令行侧的 DNS／规则抢了先。
换句话说：两篇应该并列收藏——一篇解决「你从浏览器怎么用 Claude」，一篇解决「你在终端怎么用 Claude Code」；合在一起才覆盖会话、计费控制面与CLI 运行时两条出口。若你已按通稿配置了域名规则却仍只在命令行报错，几乎可以直接跳到下文 TUN／环境变量小节。
1先选对武器：监听端口、「系统代理」与 TUN 模式
仅靠「打开系统 HTTP 代理」并不能保证 Claude Code 的底层库走你想要的出口。监听端口方案的边界在于：必须由应用或其依赖显式或通过环境变量使用该代理——否则连接依旧直连。TUN 模式把未被排除的路由前缀交给内核侧的虚拟接口处理，从而在操作系统层实现「更广泛的一致性」，这也是为何社区里终端代理／命令行 AI 编程排障常与 TUN 绑定讨论。
在具体客户端里，堆栈选择与权限（尤其是 macOS／Windows）会影响稳定性；如果你尚未开启过 TUN，建议先按 Clash Verge Rev TUN 模式完整教程（Windows／macOS）逐项完成授权与兼容性确认，再回到本文继续做域名粒度规则。对已习惯「只开 Mixed Port」的读者，可把 TUN 理解成把默认路由里「本应直连却需要代理的流量」拉回 Clash——这在 CLI／Python／Go 二进制里格外明显。
若因环境受限暂时不能启用 TUN，可在启动 Claude Code 的同一 shell session 导出标准代理变量，并把 no_proxy／NO_PROXY 写明需要直连的内网与公司域名——避免把一切流量硬塞进节点导致本地 SCM、容器注册表或局域网调试全部变慢。即便如此，也请把「变量是否被 shell 与子进程继承」当作必须验证的一步，不要让 IDE 外层终端与独立 iTerm／Windows Terminal tab 自相矛盾。
2用日志找「真实 Host」，不要靠转载清单打天下
Anthropic 的前端域、CDN 与 API 主机名会随产品与区域策略调整；Claude Code 自己的更新与遥测也可能引入额外子域。最稳妥的做法是：在问题可复现的数分钟内打开 Clash 的连接或调试日志，抓三条信息——① 目标 Host／SNI；② 命中的 rules 序号与策略组；③ 最终选择的节点与失败原因（超时、证书、拒绝等）。把这三件事写在便签上，再决定是补一条 DOMAIN-SUFFIX，还是调整策略组选路。
当你看到 api.anthropic.com、anthropic.com、claude.ai 等字眼时，可以把它们作为起点写进本地覆写，但请始终保留「以日志为准」的习惯：任何第三方整理的静态列表都会过期。对频繁变更的集合，使用 Rule Provider 拆成小文件，配合 CI 或手工定期 diff，比直接改整份订阅安全得多。规则集维护节奏也可对照 ACL4SSR 与 Loyalsoldier 规则集对比，理解「上游集 + 本地补丁」的分工。
若你通过云厂商或兼容 OpenAI 协议的聚合网关间接访问 Anthropic，TLS 上的 SNI 可能并非 anthropic 后缀——此时必须按真实连接名写规则，而不是照抄「Claude」二字脑补域名。把这类连接单独放进一个策略组，便于与官方直连线路隔离观察。
3分流规则与策略组：把「长会话」喂给稳定出口
写规则时最容易犯的错，是把「海外 AI」随手丢进一个自动测速组，然后抱怨「怎么总断」。Claude Code 的长任务与工具回调对连接保持更敏感：策略组如果在 url-test 里频繁换边，会在用户侧放大为「偶发成功、偶发重试」。实用的做法是把 Anthropic 相关域名放进你可手动固定或至少低切换频率的组里，先验证「稳定单出口」能否消除超时，再决定是否恢复自动优选。
顺序上，请把这些域名规则放在过于宽泛的 GEOIP,CN,DIRECT 或粗糙的 MATCH 之前，避免被提前判定为直连或落入错误的默认组。若你使用「国内直连、海外代理」模板，重点检查：相关域名是否被大陆 IP 段规则误伤，或是否落在一个「看似 PROXY、实则 fallback 到 DIRECT」的嵌套组里。Clash Meta 规则顺序与 MATCH 一文可以帮助你自检「谁先匹配」这一基础但致命的问题。
对 QUIC／HTTP／3／UDP 敏感的网络路径，如发现页面或 API 在某个节点簇上异常抖动，可把观察重点暂时转向 UDP 兼容性（以及 Discord／游戏场景里常被提及的 UDP 通则）。这与 Discord 语音 UDP 与 TUN 排查 的技术栈同源：都是「别把 UDP 想当然地当好」这一类问题——只是症状落在 AI CLI 上就表现为工具注册或远端函数调用变慢。
4规则片段示意（请替换占位名与实际域名）
以下为说明书写顺序的结构示例——AI_PROXY、DIRECT 仅是占位符，请务必替换为你配置里真实存在的 proxy-groups／内置出站名；条目顺序需与你本地文件一致：
# Example only — substitute AI_PROXY/DIRECT with your real policy names from proxy-groups
rules:
- DOMAIN-SUFFIX,anthropic.com,AI_PROXY
- DOMAIN-SUFFIX,claude.ai,AI_PROXY
- DOMAIN-SUFFIX,api.anthropic.com,AI_PROXY
- GEOIP,CN,DIRECT
- MATCH,AI_PROXY
DOMAIN-KEYWORD 可能误杀无关域名，如无必要尽量不用；如果发现命中过于宽泛，可以拆分成多条前缀规则并观察一周调用分布。对与本地 Git／容器仓库共享同一策略组的写法要谨慎——必要时为「纯 Anthropic CLI」单独开组，别把科研下载与 IDE 大包流量绑在同一出口的瓶颈上。
5DNS、FakeIP 与「看起来像间歇性失灵」的根因
当你已经确认规则命中无误，但依旧出现「第一轮请求成功，第二轮卡住」这一类间歇症状，往往需要回头查 DNS：内核是否在用 FakeIP，相关域名是否正确落在 fake-ip-filter／等价绕过表里，nameserver-policy 是否对不同后缀走了不一致的递归路径。系统性排查请配合 Meta 内核 DNS 防泄漏终极指南（FakeIP、DoH、DoT）里的顺序执行；本文只强调CLI 场景下 DNS 与控制面令牌主机必须「与规则同一套语义」，否则会表现为偶发超时而不是稳定 403／401。
也请同步检查：操作系统自身的 DNS over HTTPS 是否与 Clash 的同时启用产生双栈劫持；企业与校园网是否还有透明代理在中间改写了 SNI。fake-ip-filter 与局域网直连域名 能帮你在 LAN 与云上内网场景中避免误解析；而 MCP 工具连远端模型 一文则从另一个开发者入口解释「编辑器外的工具链如何把 DNS／规则一起打乱」——思路可类比到 Claude Code。
如果你在 WSL2、容器或远程 SSH 里跑 CLI
大量 AI 程序员会在 WSL2 或远程机上跑 Claude Code。WSL2 的出站网络栈独立于 Windows GUI 的许多直觉设定：就算 Windows 侧的 Clash 已经打开系统代理，子系统里的二进制仍可能径直走虚拟交换机出口。遇到这种情况，要么在 Linux 视图里单独配置可用的 HTTP／SOCKS 出口，要么把宿主机的 TUN 策略扩展到子系统能看见的路由，具体打法见 WSL2 内 Git／npm 与 Windows Clash 打通。容器场景同理：Docker Desktop 的网路命名空间与公司 VPN 常会再次改写默认路由——此时「先确保 ping／curl 在容器里也走你期望的出口」优先级高于任何 Claude 专属的玄学参数。
常见问题：把现象对齐到可操作检查项
登录阶段浏览器弹窗卡住或回调打不开： 多为本地回送地址或 HTTPS 抓取被规则误送进代理；复核 localhost／127.0.0.1 是否应该直连（有时需要被列入 fake-ip-filter 或前缀直连规则），并保持命令行侧的 HTTP 客户端与 OAuth 打开的浏览器同属一个网络视图。
CLI 报错里出现 TLS／证书校验失败： 不一定是「你被中间人」，也可能是策略组在某个节点上对 ALPN／SNI 支持不完整；换一个出口族或短暂关闭 QUIC 试验可快速缩小范围——再不行才考虑安全软件解密。
仅在高峰时段变慢： 观察是不是 url-test 在与你抢节点；对相关域名用手动节点复现，再结合上游带宽与远端拥塞判断是否属于「服务端容量／区域」层面的硬限制——这类问题不是靠堆规则能解决，但能避免你在本地误判成配置错误。
合规提醒：请仅在适用法律、服务条款与公司网络政策的范围内使用加密代理与翻墙软件；企业生产环境请走正式备案线路或专用出口。
关于开源构建与本站下载：开源内核与 GUI 源代码可在上游仓库复核；需要从浏览器快速获取安装介质时建议使用 本站下载页，以减少误下无关二次打包版本的风险。
小结
把 Claude Code 放进日常开发链路后，Anthropic／Claude 的流量不再只属于浏览器：终端代理、分流规则与 DNS 是否一致决定了 CLI 侧的认证、API 超时与工具编排是否顺滑。优先级记住三句话：TUN（或等价的环境变量）让进程出站对齐；日志驱动的域名规则替代迷信静态清单；FakeIP 与规则顺序一起审，不要只改其中一端。
许多「单点工具」要你为每个二进制单独写代理钩子，长期在多个终端配置文件之间复制粘贴，既容易泄密也容易互相覆盖。Clash 在桌面端的优势在于把内核、订阅、可视化规则编辑与分流诊断收敛到一处：当你把本篇与站内的 Claude 通用分流、TUN／DNS 深度文串起来走完一遍，就能把「只对 Claude Code CLI 翻车」这一现象定位到可控的配置层；不少同类工具界面繁琐或缺少连接级日志对照，出问题只能盲换节点。Clash 则便于把每一条连接对应到域名、策略组与解析路径，排障更可预期。你可以免费下载 Clash，先按站内 TUN 教程启用虚拟网卡，再按上文顺序补齐 Anthropic／Claude 规则与 DNS，一般即可把最明显的长尾超时压回到正常区间。