Claude 用 Clash 无法访问？超时与连接失败排查指南
使用 Clash 访问 Claude 时遇到页面打不开、响应超时或连接失败，通常与代理模式、分流规则、DNS 或节点质量有关。本文提供从基础检查到 TUN 模式和规则调整的完整排查步骤。
先区分症状:页面打不开不一定是同一个问题
使用 Clash 访问 Claude 时,常见提示包括页面长时间转圈、连接超时、连接被重置、TLS 握手失败,或者页面可以打开但消息发送后一直没有响应。它们看起来都像“代理不能用”,实际上可能分别对应入口连接、域名分流、DNS 解析、节点出口、长连接传输等不同环节。先记录具体表现,比一上来反复切换配置更容易定位。
排查前先关闭其他 VPN、浏览器代理插件、网络加速器和系统级流量转发工具。多个工具同时修改系统代理、DNS 或路由表时,Clash 面板里显示的状态未必等于实际生效状态。建议只保留一个客户端运行,并记下当前客户端名称、内核类型、代理端口、模式以及出现问题的时间。
| 现象 | 优先检查位置 | 常见原因 |
|---|---|---|
| 所有网页都无法访问 | 系统代理、端口、节点状态 | Clash 未接管流量,端口被占用,节点失效 |
| 普通网站正常,Claude 超时 | 规则命中、节点出口、目标域名 | 相关域名走了 DIRECT,节点地区或质量不合适 |
| 页面能开,发送消息失败 | 长连接、TLS、浏览器扩展 | WebSocket 或 SSE 被中途断开,浏览器扩展干扰 |
| 偶尔成功,很快又断开 | 节点稳定性、丢包、MTU | 出口拥塞、链路抖动、TUN 分片异常 |
| 只有某一台设备失败 | 本机 DNS、权限和客户端设置 | 系统代理未生效,VPN 权限被拒绝或缓存异常 |
先做最小化测试
不要同时修改模式、DNS、规则和节点。每次只改变一个变量,并在相同浏览器、相同网络下重新测试。这样才能知道究竟是哪一项设置改变了结果。
基础检查:确认 Clash 真的接管了请求
第一步不是修改 YAML,而是确认客户端自身已经正常工作。打开 Clash 的代理页或连接页,查看当前配置是否已选中,节点列表是否能够显示延迟,代理端口是否处于监听状态。节点测速成功只能说明测试请求完成,不代表 Claude 的所有域名都会自动走同一条代理链路。
- 在客户端的配置或 Profiles 页面确认当前配置处于启用状态,不要只下载了订阅却忘记选中配置。
- 在代理页面选择一个延迟较低、近期稳定的节点或策略组,不要在排查阶段使用自动负载均衡作为唯一变量。
- 暂时把模式切换为 Global,打开系统代理,关闭浏览器里的手动代理设置,再重新打开 Claude 页面。
- 如果 Global 模式可以访问,切回 Rule 模式测试。两种模式结果不同,基本可以把范围缩小到规则匹配或 DNS。
- 如果 Global 模式仍然失败,检查系统代理地址是否为
127.0.0.1,端口是否与 Clash 的 mixed-port 或 HTTP 端口一致。
常见的混合代理端口是 7890 或 7897,但不能把示例端口当成固定值。应以客户端设置页面显示的实际端口为准。命令行工具也可以用一个明确的假域名进行基础测试,例如在终端执行 curl -I -x http://127.0.0.1:7890 https://example.com;若端口不对,通常会出现 connection refused,这说明请求甚至没有进入 Clash。
浏览器还可能保存旧的连接状态。切换节点后,完全关闭相关标签页,退出浏览器后台进程,再重新启动;也可以使用无痕窗口测试。不要只按刷新键,因为页面脚本、Service Worker、HTTP/3 连接和旧的 DNS 缓存可能继续复用之前的失败状态。
Global 只用于定位
Global 模式会让更多流量经过节点,增加延迟和流量消耗。确认问题来自分流后,应恢复 Rule 模式并修正规则,不要长期依赖全局代理。
规则排查:Claude 相关请求是否误走直连
Rule 模式下,Clash 按规则从上到下匹配,第一条命中后就停止。Claude 这类服务通常不只使用一个网页域名,还可能涉及登录、静态资源、接口、文件上传和持续连接等不同主机。只给一个页面域名写代理规则,很容易出现首页能开、登录失败或消息发送超时的情况。
打开 Clash 的连接日志,在重新加载页面和发送一条测试消息时观察请求。重点查看目标域名、命中的规则类型以及最终策略组。若目标域名命中 DIRECT,而 Global 模式可以正常使用,说明规则范围不足或顺序有误。若命中了代理组却仍失败,继续检查策略组当前选中的节点和连接日志中的错误信息。
- 优先使用服务规则集。如果订阅或客户端提供了维护中的 Claude、AI 或相关服务规则集,优先把它指向稳定的代理策略组,不要手工猜测一长串域名。
- 自定义规则要放在兜底规则之前。目标域名的代理规则必须位于
MATCH,DIRECT或其他全局兜底规则之前,否则后面的规则不会再被读取。 - 策略组名称必须真实存在。规则写成
DOMAIN-SUFFIX,example.com,AI时,配置中必须确实有名为AI的策略组。名称拼错可能导致配置验证失败或规则无法按预期执行。 - 不要只按 IP 添加规则。服务端地址可能变化,CDN 也可能返回不同 IP。域名规则通常比固定 IP 段更适合这类服务。
- 观察连接而不是只看测速。测速测试的是节点延迟,不能证明目标服务的 TLS、长连接和上传链路都稳定。
在 mihomo 内核中,可以通过连接详情查看域名嗅探和规则匹配结果。若启用了 fake-ip,日志中可能看到本地连接目标是 198.18.x.x 网段,这本身不表示请求去了错误地址,关键是 Clash 是否能还原原始域名并按照域名规则分流。遇到嗅探不到域名的情况,可以暂时切换 redir-host 做对照,不要一开始就同时更换多项 DNS 参数。
动手修复:按顺序完成一次完整测试
下面这套流程适合 Windows、macOS 以及使用 mihomo 内核的常见客户端。菜单名称可能因 Clash Verge、Clash Verge Rev 或其他客户端而略有不同,但检查逻辑一致。每一步完成后都重新打开页面并发送一条简短测试消息,记录成功或失败。
- 固定测试节点。从策略组里手动选择一个延迟较低且近期没有频繁断线的节点,暂时不要使用 url-test 自动切换。自动测速可能在测试期间更换出口,使结果无法比较。
- 切换到 Global。打开系统代理,确认浏览器没有单独配置另一个 HTTP 或 SOCKS5 代理。页面能够打开但消息仍失败时,继续检查长连接和节点稳定性。
- 查看连接日志。重新加载页面,再发送测试消息,确认相关请求是否进入代理组。若完全没有日志,说明浏览器没有经过 Clash,应回到系统代理和端口检查。
- 清理 DNS 缓存。Windows 执行
ipconfig /flushdns;macOS 可执行sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder。随后重启 Clash 或重新加载配置。 - 切回 Rule。如果 Global 成功而 Rule 失败,根据连接日志补充或修正规则,并确保代理规则排在
MATCH兜底规则之前。 - 启用 TUN 做对照。在客户端开启 TUN 或增强模式,按系统提示安装服务并授权,再用 Rule 模式测试。若 TUN 成功而系统代理失败,说明原应用或浏览器没有遵守系统代理。
mixed-port: 7890
allow-lan: false
mode: rule
rules:
- DOMAIN-SUFFIX,example.com,AI
- MATCH,DIRECT上面的域名仅用于展示规则结构,不能直接当作 Claude 的完整域名清单。实际配置应使用服务商或规则维护者提供的目标域名集合,并把 AI 替换成配置中真实存在的策略组名称。若当前配置默认兜底是代理,可将目标服务规则指向专用策略组;若默认兜底是直连,则必须确保相关域名规则覆盖完整。
判断结果的方法
Global 成功、Rule 失败,优先修规则;系统代理失败、TUN 成功,优先修接管范围;所有模式都失败,优先换节点并检查 DNS、TLS 与网络质量。用这个分支判断,比盲目重装客户端更有效。
DNS、TUN 与 TLS:连接仍失败时继续深入
如果规则已经确认命中代理,但页面依旧超时,接下来重点看 DNS 和整机接管。系统代理主要覆盖遵守 HTTP 代理设置的应用,不能保证所有 UDP、QUIC、DNS 查询以及后台进程都进入 Clash。浏览器启用安全 DNS 后,也可能使用自己的 DoH 通道,结果是页面流量走了节点,域名解析却走了另一条链路。
在 mihomo 配置中,可以先使用相对保守的 DNS 设置进行对照。fake-ip 适合规则分流和 TUN 接管,但个别局域网服务或特殊应用兼容性较差;遇到异常时可暂时切换为 redir-host 判断是否由 fake-ip 引起。不要把局域网域名、路由器地址和本地设备全部强行送到远端代理。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter:
- "+.lan"
- "+.local"
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53ipv6: false适合先做排障对照。若本地 IPv6 路由质量差或 TUN 没有完整接管 IPv6,关闭后可以排除 AAAA 记录和 IPv6 直连造成的失败。dns-hijack用来把发往 53 端口的查询导入 Clash DNS。不同客户端对 TUN 字段支持程度不同,导入前先确认使用的是 mihomo 内核。- 浏览器的安全 DNS 可以暂时关闭,避免浏览器绕过 Clash DNS。测试完成后,再根据实际网络和客户端能力决定是否恢复。
- TUN 需要管理员权限、服务模式或 VPN 权限。开关显示开启但系统没有授权时,流量仍可能没有被虚拟网卡接管。
若日志出现 TLS handshake timeout、connection reset 或 EOF,不一定是证书问题。更常见的原因是节点出口不稳定、目标服务拒绝该出口、链路 MTU 不合适或中途设备主动重置长连接。先换同地区的另一个节点进行比较;如果只有某个节点失败,不要优先改证书验证开关。关闭证书校验会降低安全性,不能作为常规修复方式。
节点质量与网络环境:排除配置之外的故障
代理配置正确,仍然可能因为节点本身无法稳定访问目标服务。Claude 的网页加载、消息发送和文件传输对持续连接质量比较敏感,单次延迟很低的节点不代表长时间传输稳定。可以连续观察 3 到 5 分钟,分别测试页面加载、发送消息和保持页面空闲后的再次操作。
- 换出口地区。同一服务对不同地区、机房和 IP 段的可用性可能不同。优先选择服务商标注为稳定的节点,不要只按最低延迟排序。
- 比较协议。如果多个节点使用同一协议且都失败,再选择另一协议的节点对照。不要把协议名称当作质量保证,最终仍以丢包、握手和长连接表现为准。
- 检查时间。本机日期、时间和时区偏差过大,可能造成 TLS 证书尚未生效或已经过期。开启系统自动校时后重启客户端。
- 降低并发变量。测试期间暂时关闭节点自动切换、连接复用实验选项和不熟悉的脚本规则,保持配置简单。
- 检查 MTU。TUN 模式下若页面部分加载、发送大段内容时断开,可以尝试降低虚拟网卡 MTU,例如从默认值调整到 1400 或 1380,每次只改一个值并重启 TUN。
- 确认网络限制。公司、校园或公共 Wi-Fi 可能限制 UDP、长连接或未知端口。使用手机热点做一次对照,可以快速判断是本地网络还是客户端配置。
不要随意关闭安全选项
不建议通过关闭 TLS 证书验证、放宽所有规则、允许局域网公开代理或把订阅链接交给陌生在线转换服务来“修复”连接。它们可能暂时改变现象,却会扩大凭据泄露和流量暴露风险。
最后检查清单:把临时修复变成稳定配置
完成排查后,建议把配置恢复到可长期使用的状态,不要保留为了测试而打开的全局代理或过度权限。确认当前模式为 Rule,系统代理和 TUN 只保留实际需要的一种接管方式;如果同时开启两套接管机制,遇到应用异常时会增加判断难度。
- 当前配置已经选中,订阅可以正常更新,节点策略组中有可用节点。
- Claude 相关请求在连接日志中命中预期的代理策略组,没有被
DIRECT或错误的拒绝规则截走。 - DNS 查询由 Clash DNS 处理,浏览器安全 DNS 没有绕开既定的排查路径。
- Windows、macOS 或安卓系统已经授予系统代理、VPN、TUN 服务所需的权限。
- 更换两个以上节点后结果一致,并且在页面加载、发送消息、长时间保持连接三种场景下都能稳定工作。
- 没有为了绕过错误而长期关闭证书验证,也没有把订阅链接或外部控制器密钥暴露给第三方。
如果依次完成 Global、Rule、TUN、换节点和换网络测试仍然失败,保存客户端版本、mihomo 内核版本、连接日志中的错误类型、失败时间和测试节点信息,再向节点服务商或客户端维护者反馈。不要只提供“打不开”四个字;完整的测试路径能帮助对方判断是服务端拒绝、节点出口异常,还是本地流量没有进入 Clash。
相关操作入口
如果还没有完成客户端安装或订阅导入,可以先查看下载中心和快速开始教程,确认系统代理、配置文件和节点选择的基础步骤没有遗漏。排查过程中建议一次只修改一个参数,并保留能够复现问题的最小配置。