Clash 已连接却打不开网页:从订阅、模式到 DNS 的逐项排查清单

先区分“内核运行”与“请求成功”

Clash 客户端显示“已连接”，可能只代表图形界面已经连接本机内核，或者系统代理开关已经启用。它不能证明订阅中的节点可用，也不能证明浏览器请求经过了正确的策略组。完整链路是：应用发起请求 → 本地代理或 TUN 接管 → 规则匹配 → 策略组选择 → 节点连接 → 目标网站响应；任意一环出错，都可能表现为网页一直转圈。

Clash 是一类代理内核与配置生态的常用称呼，Clash Meta 后续以 mihomo 名称继续发展。不同图形客户端的菜单位置、覆写方式和内核能力存在差异。排查前在客户端的“关于”或“内核”页面记录实际版本，后续配置应以该内核支持的字段为准，不要把别人的整份 YAML 直接覆盖到当前订阅。

建立可重复的测试条件

1. 记录当前配置名称、代理模式、策略组所选节点、HTTP 或混合端口，以及 TUN 是否开启。
2. 暂时关闭其他 VPN、代理客户端和浏览器代理扩展，避免多个入口相互覆盖；保留组织要求的安全软件。
3. 准备一个日常可直连网站和一个需要当前代理线路访问的目标网站，每次测试都使用相同地址。
4. 打开客户端连接列表和日志，先用 Info 级别复现一次；信息不足时再短暂启用 Debug。

第一步：检查订阅有效性与配置是否被加载

“订阅更新成功”只说明客户端完成了一次更新操作，不等于套餐仍有流量，也不等于刚下载的配置就是当前活动配置。进入配置或订阅页面，确认所需配置处于选中状态，再到代理页面查看是否出现预期的节点和策略组。若仍显示旧节点，优先检查是否更新了另一份未启用的订阅。

• 套餐状态：在服务提供方的账户页面确认到期时间、剩余流量和设备限制。客户端显示的用量通常来自订阅响应头，可能缺失或滞后。
• 下载错误：HTTP 401、403 常见于鉴权失败或访问策略限制；404 可能是路径失效；429 表示请求受到频率限制。不要连续点击更新。
• 内容错误：日志出现 YAML 解析失败、未知字段或找不到策略组时，先处理配置兼容性。返回登录页或错误页的 HTML 内容不能当作 Clash 配置使用。
• 远程资源：主配置已加载，但 proxy-providers 或 rule-providers 更新失败，也可能造成节点缺失或规则与预期不符。

如果订阅只能通过代理更新，而当前节点又全部不可用，可以在服务提供方允许的范围内尝试可用网络或其官方提供的备用订阅入口。不要把完整订阅 URL 粘贴到陌生转换站或公开讨论区：其中的访问令牌通常相当于账户凭据。

第二步：验证节点，而不是只看延迟数字

延迟测试成功，只能说明该次探测在当时、对指定测试地址得到了结果。测试站可达，不代表目标网站可达；显示 80 ms 也不代表具备足够带宽。网页涉及 DNS、TLS、多个资源域名和可能的 UDP 请求，任意环节都比单次探测复杂。

手动选节点做交叉验证

1. 在实际承接目标流量的策略组中手动选择一个节点，避免自动选择组在排查时不断切换出口。
2. 访问目标网站，记录日志中的时间、节点名和错误。再切换第二条不同线路，重复同一请求。
3. 换到手机热点重试；若同一节点仅在某个 Wi-Fi 下失败，应继续检查该网络的出口限制、认证页面或 DNS。

日志中的 connection refused 通常说明某一连接目标主动拒绝；i/o timeout 表示相应操作未在时限内完成。必须结合错误中的目标地址判断发生在哪一跳。不要为了消除 TLS 报错直接启用跳过证书验证，应先校准系统时间并核对节点参数。

第三步：用代理模式缩小故障范围

规则模式按规则列表决定走哪个策略；全局模式把被内核接管的请求交给全局策略；直连模式则直接连接目标。这里的“全局”是出站策略含义，不代表所有应用都会自动进入 Clash。没有使用系统代理、没有显式配置代理且未被 TUN 接管的程序，仍可能绕过内核。

1. 先在规则模式下复现故障，记录连接列表里显示的规则和出口。
2. 临时切到全局模式，并明确选中前一步验证过的节点，再打开相同网页。
3. 若全局成功、规则失败，重点转向规则、策略组和直连解析路径；若两者都失败，继续检查代理入口和 DNS。
4. 测试结束后恢复规则模式，避免把不需要代理的流量长期交给全局出口。

第四步：确认系统代理与本地监听端口一致

以下命令以客户端实际启用 mixed-port: 7890 为前提。7890 只是示例，必须用界面中的真实端口替换。混合端口可同时接收 HTTP 与 SOCKS 代理连接；独立 SOCKS 端口不能直接当作 HTTP 代理填写。一般桌面本机代理地址使用 127.0.0.1，不需要为了本机浏览器访问而启用局域网共享。

检查系统设置与显式代理请求

Windows 11 可从“设置”→“网络和 Internet”→“代理”检查手动代理与设置脚本；macOS 可从“系统设置”→“网络”→当前网络服务→“详细信息”→“代理”检查。客户端接管系统代理后，这些设置应与实际监听端口一致。部分浏览器使用独立设置，例如 Firefox 的“设置”→“常规”→“网络设置”→“设置”，需要确认选的是系统代理还是另一个手动端口。

在 Windows PowerShell 中先检查监听，再用显式 HTTP 代理请求测试。使用 curl.exe 可避免旧版 PowerShell 的同名别名干扰。

Get-NetTCPConnection -State Listen -LocalPort 7890
curl.exe -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

macOS 和 Linux 可以使用下面的请求对照。测试地址只是公共示例，随后应换成实际打不开的目标站点；-I 发送 HEAD 请求，某些站点不支持时可改用 -o /dev/null -v 发送普通 GET 请求。

curl -I --connect-timeout 10 --max-time 20 -x http://127.0.0.1:7890 https://example.com/
curl -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

• 立即提示无法连接 127.0.0.1：检查内核是否启动、端口是否改动，以及监听进程是否确实属于当前客户端。
• 显式代理成功、浏览器失败：优先排查浏览器代理扩展、PAC 脚本、独立代理设置和缓存的旧连接。
• 出现 HTTP 407：检查本地代理认证要求，不能直接归因于远端节点。
• 先显示连接隧道建立，随后 TLS 失败：隧道建立不是最终网页成功，继续查看 TLS 错误与内核日志。

--noproxy "*" 只绕过 curl 的应用层代理设置，不能绕过 TUN 或其他 VPN。需要比较真正的直连路径时，应在记录原状态后暂时关闭相关接管功能。终端也不一定读取桌面系统代理，检查 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY 和 NO_PROXY，防止旧环境变量把请求导向另一个端口。

第五步：分清 DNS 失败发生在哪一层

DNS 至少涉及三个不同目标：节点服务器域名、用户访问的网站域名，以及加密 DNS 服务本身的域名。节点服务器无法解析时，通常连代理隧道都建不起来；目标域名解析失败时，可能只有特定网站报错；DNS 上游依赖尚未建立的代理路径时，还可能形成循环依赖。

先观察，再决定是否改 DNS

1. 查看日志是否出现 lookup、no such host、DNS timeout 等信息，并记下具体域名。
2. Windows 用 Resolve-DnsName example.com，macOS 或 Linux 用 nslookup example.com 检查系统查询，再与客户端日志中的结果比较。
3. 检查浏览器的安全 DNS 设置。浏览器自带 DoH 可能改变解析路径；短暂关闭并复测后，按实际需要恢复。
4. 只有确认系统缓存陈旧时，再在 Windows 执行 ipconfig /flushdns，并重新建立浏览器连接。

系统查询成功并不能证明内核 DNS 正常：两者可能使用不同上游；反过来，系统查询失败也不必然导致通过代理的域名请求失败，因为解析可能由内核或远端完成。不要只凭一次 nslookup 就批量替换所有 DNS 字段。

使用 fake-ip 模式时，看到来自配置中 fake-ip-range 的合成地址可能是正常现象，例如常见的 198.18.0.0/16。这些地址用于让内核关联域名与连接，并非真实网站地址。若应用拿到了合成地址，而连接没有回到接管它的内核，就会失败，应检查路由、DNS 接管及其他 VPN 的冲突，而不是把合成地址写入 hosts。

第六步：检查规则命中与策略组最终出口

若全局模式可用而规则模式失败，打开连接列表，按目标域名寻找对应请求，查看命中的规则和策略链。规则通常按从上到下的顺序匹配，前面的宽泛规则可能提前截走请求；MATCH 是末尾兜底，不应被放在仍希望生效的其他规则之前。

下面只展示规则顺序，不是可直接替换订阅的完整配置。它把 example.com 及其子域名交给名为“网页代理”的策略组，其余连接直连；使用前必须确保该组真实存在且已选择可用节点。

rules:
  - DOMAIN-SUFFIX,example.com,网页代理
  - MATCH,DIRECT

• 命中 DIRECT：检查直连是否符合预期，以及该网站在当前网络能否直连。
• 命中 REJECT：查看拦截规则或规则集是否误收录目标域名，不要一次关闭全部防护规则。
• 命中代理组但仍失败：展开策略链，检查嵌套组的最终节点；组名相同不代表出口相同。
• 主页面成功、图片或登录失败：检查 CDN、认证和接口域名，这些请求可能命中了不同策略。

规则集下载失败、客户端本地覆写、进程规则和订阅更新，都可能改变最终配置。应查看运行中的有效配置与连接记录，而不只查看订阅原始文件。修改后重新发起连接，已有长连接可能继续使用原来的路径。

第七步：仅在需要时排查 TUN、IPv6 与 UDP

当浏览器显式代理正常，但游戏、终端或其他应用失败时，先确认应用是否支持代理。系统代理并不保证所有程序遵循设置；需要更广的流量接管时，才考虑 TUN。启用 TUN 后仍需正确的路由、权限和 DNS，并不是开启开关就能覆盖所有异常。

• TUN 与权限：确认服务模式或所需权限已就绪，并检查日志是否报告虚拟接口或路由创建失败。
• 网络冲突：临时停用另一个非必需 VPN 后复测，关注路由优先级、虚拟网卡与 DNS 接管冲突。
• IPv6：检查目标是否存在 AAAA 记录，以及实际连接是否走 IPv6。若 IPv4 可用而 IPv6 失败，应修复对应路由或出口，不要直接把全系统禁用 IPv6 当作默认方案。
• UDP 与 QUIC：部分浏览器使用 UDP 443 的 HTTP/3。若 TCP 网页请求成功而 UDP 应用失败，检查节点协议、服务端和本地接管是否支持该 UDP 路径。

必要时短暂关闭浏览器 QUIC 做对照，但不要把这一项当作通用加速设置。出现大页面卡住、小请求正常时，还应考虑路径 MTU、丢包和线路拥塞；先保留重现记录，不要连续试填多个 MTU 数字。

收尾：恢复最小配置并整理故障记录

定位后恢复规则模式、常用 DNS 和需要的接管方式，撤销仅用于对照的临时改动。不要在客户端退出后遗留指向无人监听端口的系统代理。如果关闭客户端后所有网页都打不开，先检查系统代理是否仍指向 127.0.0.1:7890，而不是立即重装浏览器。

提交问题时保留这些信息

• 操作系统版本、客户端版本和实际内核版本；是否开启 TUN、系统代理和浏览器安全 DNS。
• 故障时间、目标域名、可重复步骤，以及问题影响全部网站还是个别网站。
• 同一目标在规则模式、全局模式、另一节点和另一网络下的对照结果。
• 已脱敏的错误日志、规则命中与最终出口；不提供订阅令牌、节点密码或完整配置凭据。

最有价值的结论不是“已重启多次”，而是“显式代理成功、浏览器失败”或“全局成功、规则命中 DIRECT 后失败”。这种按链路分层的证据能把问题收敛到应用入口、节点、DNS 或规则，减少反复改配置带来的新故障。