Claude 单独走指定节点：域名分流不生效的原因与 sniffer 配置
想让 AI 流量走指定节点、其余流量保持本地线路，只加域名规则常常无效。本文拆解规则命不中的两类根因——域名清单不完整与纯 IP 连接拿不到域名，给出补全规则的写法、协议嗅探（sniffer）配置示例、逐条排查清单，并说明全局与分流两种做法的取舍和合规注意事项。
日常上网走香港节点延迟低，但访问 Claude 这类 AI 服务时需要换一个出口。一直开全局并不现实：所有流量绕远路，本地服务、内网面板、视频会议都会受影响。于是最自然的想法是按域名分流——只让 AI 相关请求走指定节点，其余保持原样。
真动手后会撞上一个典型问题：全局模式下一切正常，切回规则模式，AI 站点却一直转圈或直接报错；补了 claude.ai、anthropic.com 的域名规则仍然不解决。这类故障的根因往往不在节点质量，而在于「这条连接里根本没有可用的域名」。
先分清两类根因
规则匹配发生在连接建立的那一刻，判断依据是目标域名。下列情况会让域名规则失效：
| 现象 | 常见原因 |
|---|---|
| 规则写了却不生效 | 连接是纯 IP 直连，DOMAIN 类规则没有域名可匹配 |
| 主页面能开，图片、附件、上传失败 | 静态资源走了第三方 CDN，清单没覆盖 |
| 换个客户端就正常 | fake-ip 与 redir-host 对域名还原的处理方式不同 |
| 规则命中了但还是超时 | 命中的策略组指向香港节点，或节点本身不可用 |
| 时好时坏 | DNS 解析结果不稳定，或被本地 DNS 干扰 |
归纳起来是两条主线。
第一，域名清单不完整。一个 AI 站点通常由多个域组成：主站、API、用户内容与附件域、埋点统计域、CDN 域。只写主域名，静态资源和上传接口依旧走默认出口，表现就是页面骨架出来了但内容加载不出来。
第二，连接没有域名。客户端解析出 IP 后直接对 IP 建连，或者应用内部写死了地址、走 QUIC/UDP，规则引擎拿不到 TLS 的 SNI 或 HTTP 的 Host，再多的 DOMAIN 规则也无从匹配。协议嗅探（sniffer）就是为了把这类连接「还原」出域名。
方案一：补全域名规则
改动最小，先做这一步。核心是把同一服务的主域、API 域、内容域和 CDN 域一起纳入同一个策略组，并把这些规则放在 GEOSITE、GEOIP 和最后的 MATCH 之前——规则是自上而下匹配的，落到兜底规则就再也回不来了。
rules:
- DOMAIN-SUFFIX,claude.ai,AI-US
- DOMAIN-SUFFIX,anthropic.com,AI-US
- DOMAIN-SUFFIX,claudeusercontent.com,AI-US
- DOMAIN-SUFFIX,usefathom.com,AI-US
- DOMAIN-SUFFIX,cdn.usefathom.com,AI-US
- DOMAIN-SUFFIX,servd-anthropic-website.b-cdn.net,AI-US
# 其余规则……
- MATCH,DIRECT
几点提醒：
- 别直接照抄别人的完整配置文件。内核版本、策略组名、缩进层级差异很大，抄进去多半起不来。
- 域名清单会变。服务方新增静态资源域、切换 CDN 之后，旧清单就会漏，遇到「突然加载不出来」先怀疑这里。
- 部分内核提供现成的 AI 站点合集规则集，可以省掉手工维护，但规则集名称与引用方式随版本变化，以所用内核的官方文档为准。
方案二：开启协议嗅探，让 IP 连接也带域名
如果补完域名规则仍然不通，大概率是碰上了纯 IP 连接。此时开启 sniffer，让程序从 TLS 握手的 SNI 或 HTTP 的 Host 头里把域名「读」出来，再用这个域名去匹配规则。
sniffer:
enable: true
parse-pure-ip: true # 对纯 IP 连接也做嗅探
force-dns-mapping: true # 优先使用 DNS 映射结果还原域名
override-destination: false
sniff:
TLS:
ports: [443, 8443]
override-destination: true
HTTP:
ports: [80, 443]
override-destination: false
几个字段的实际影响：
parse-pure-ip：不打开的话，只嗅探原本就带域名的连接，最需要救的那部分恰恰漏掉。override-destination：决定是否把连接目标改写成嗅探到的域名。改写后规则匹配更准，但对个别依赖原始 IP 的应用可能造成握手异常，遇到问题优先把它调回false试。force-dns-mapping：让域名解析结果与嗅探结果对齐，减少「嗅探到了但映射不上」的尴尬。
不同内核（mihomo/Clash Meta、sing-box、Surge 等）的字段名和嵌套层级并不相同，有的把 sniffer 放在顶层，有的挂在入站配置里。上面只是结构示意，务必对照自己所用版本的官方文档调整。
验证与排查清单
配置改完不要靠感觉，逐条看：
- 打开客户端的连接日志面板，找到失败那条请求，看它命中的规则名、出口策略、链路耗时。命中
MATCH说明前面全漏了。 - 用
curl -v https://claude.ai观察实际连接的目标地址，确认是域名还是裸 IP。 - 用
dig或nslookup对比本地 DNS 与代理解析结果，检查是否存在解析不一致。 - 临时把该策略组切到全局同款节点，确认节点本身可用，排除「规则没问题、节点坏了」的误判。
- 改一处验一处。一次改五条规则，出错后无法定位是哪条引起的。
全局、域名分流、嗅探各自的取舍
- 全局代理：零配置、最省心，代价是所有流量绕路，延迟和带宽都受损，本地服务也可能被带偏。适合临时排障。
- 纯域名分流：精准、开销小，但要持续维护域名清单，遇到纯 IP 连接就束手无策。
- 域名 + 嗅探：覆盖面最广，代价是增加少量解析开销，个别应用可能出现兼容问题。
- 按进程分流：部分客户端支持按应用名走不同出口，粒度粗但维护成本最低，适合「只让某个客户端走指定线路」的场景。
几个容易忽略的点
- 分流不是越细越好。规则堆到几百条后，排障成本会反过来超过它省下的带宽。
- 频繁切换出口 IP 对账号稳定性和风控并不友好，建议把需要的线路固定下来。
- 使用代理应符合当地法律法规以及服务方的使用条款；账号的可用地区、计费方式以官方最新说明为准。共享账号、买卖账号这类做法风险很高，不建议碰。
- 如果目的是让 Claude Code 之类的工具长时间跑任务，本地机器休眠、合盖、网络抖动都会中断会话。把运行环境放到一台长期在线的远程 Mac 上（整机放在机房、按月租用、远程连接使用）是可选做法之一，网络环境相对稳定，具体是否满足服务方的地区要求，仍需以官方说明为准。
小结
规则模式单独失灵，先别怀疑节点，按「域名清单是否完整 → 连接是否带域名 → 规则顺序与策略组是否正确」三步走。补全域名规则能解决大部分问题，剩下的纯 IP 连接交给协议嗅探兜底；开启嗅探后再配合连接日志逐条验证，基本都能定位到具体是哪一环漏了。
