Clash 已连接却打不开网页:从系统代理到 DNS 的逐项排查清单

1. 先确认“已连接”指的是哪一层

Clash 图形客户端显示内核运行、系统代理已开启，或者节点延迟有数值，并不代表浏览器已经通过该节点完成访问。一次网页请求至少经过应用代理设置、本地监听端口、规则与策略组、节点连接、域名解析和目标站点。任何一层出错，都可能出现“客户端正常，网页一直转圈”。

先记录正在使用的客户端名称、内核类型、当前配置、模式和本地代理端口。Clash、Clash Meta（现名 mihomo）及不同图形客户端的菜单名称并不完全一致，下面涉及的“代理”“连接”“日志”等名称应以当前界面为准；系统设置路径则按对应操作系统查找。

1. 保存当前配置副本，记下系统代理与 TUN 开关的原始状态。
2. 选择一个能稳定复现问题的网页，每次只改变一项设置后重试。
3. 如果同时运行了其他代理、VPN 或浏览器代理扩展，先退出其他工具，避免多个程序反复修改系统设置。
4. 临时关闭 Clash 的系统代理和 TUN，测试普通网站能否直连；测试后恢复原状态。

2. 检查系统代理是否指向正确端口

系统代理只是告诉遵循该设置的应用，把请求交给哪个本地地址。它不等同于全设备接管，也不保证所有命令行工具、游戏或独立应用都会使用代理。若浏览器有自己的代理扩展，扩展配置还可能覆盖系统设置。

Windows 与 macOS 的检查位置

• Windows 11：打开「设置」→「网络和 Internet」→「代理」，检查「手动设置代理」中的地址和端口，同时确认是否存在意外启用的设置脚本。
• macOS：打开「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」，检查网页代理、安全网页代理或自动代理配置。
• Android：代理客户端常通过 VPN 接口接管流量，不能照搬桌面的系统 HTTP 代理排查；需要检查 VPN 授权、按应用代理以及应用排除列表。

假设当前配置的混合代理端口为 7890，本机系统代理地址通常应为 127.0.0.1，端口为 7890。这里的端口只是示例，必须与客户端实际显示的监听值一致。HTTP 代理也能通过 CONNECT 转发 HTTPS，请勿仅因为网页是 HTTPS，就把系统代理地址改成远端节点地址。

# 本地代理字段示例，不是完整订阅配置
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port 同时接受 HTTP 与 SOCKS 代理连接。若配置使用独立的 port 和 socks-port，则要区分两者；不能把仅提供 SOCKS 的端口填入系统 HTTP 代理。修改后，在客户端重新加载配置，再确认界面中的实际端口，防止图形客户端的覆盖设置与文件内容不一致。

3. 用端口与显式代理测试缩小范围

系统代理看起来正确，但本地端口没有监听，浏览器仍然无法连接。打开客户端日志，先查找启动失败、配置解析失败、address already in use 或 bind 错误。端口被占用时，应确认占用进程，而不是直接结束不认识的系统进程。

检查 7890 是否正在监听

# Windows PowerShell
Get-NetTCPConnection -LocalPort 7890 -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

# macOS 或已安装 lsof 的 Linux
lsof -nP -iTCP:7890 -sTCP:LISTEN

Windows 可把查到的进程编号交给 Get-Process -Id 查看名称；macOS 与 Linux 的输出通常会直接显示进程。若没有监听结果，应检查内核是否真正启动、端口是否已改动，以及监听地址是否包含 127.0.0.1。若同一台设备启动了两份客户端，先退出不使用的那一份。

绕开系统设置，直接指定代理

在 Windows 使用 curl.exe，避免旧版 PowerShell 中 curl 别名的行为差异。macOS 与 Linux 可将下面命令中的 curl.exe 改为 curl。命令以 example.com 为基础连通性目标，随后应把网址改成实际失败的网站再比较。

# 显式经过本地 HTTP 混合代理端口
curl.exe --noproxy "" -I --connect-timeout 10 --max-time 20 --proxy http://127.0.0.1:7890 https://example.com/

# 不使用应用层代理，作为对照
curl.exe --noproxy "*" -I --connect-timeout 10 --max-time 20 https://example.com/

注意：--noproxy "*" 只绕过应用层代理。如果 TUN 仍开启，请求仍可能被虚拟网卡接管，不能把它当作真正的直连对照。部分站点不接受 HEAD 请求，遇到 405 时可去掉 -I，改为普通 GET 测试。

4. 核对策略组，别只看延迟数字

节点延迟测试通常只针对某个测试地址，测试成功不能代表所有网站都可访问。订阅更新成功也只说明配置下载与解析通过，不代表节点服务可用、账户流量充足或目标站点允许该出口访问。

1. 打开客户端的「代理」或「策略组」页面，找到目标流量实际使用的组。
2. 检查该组最终选择的是具体节点、另一个策略组，还是 DIRECT、REJECT。
3. 手动选择一个已知可用的节点，重新建立网页连接；不要只点击一次延迟测试就结束排查。
4. 如果存在多层策略组，逐层检查最终选择，避免外层显示“代理”，内层却落到直连。

可短暂切换到全局模式进行对照，并确认全局策略组中选择了实际节点。如果全局模式可用而规则模式失败，优先检查规则与分组；如果两种模式都失败，应继续看节点握手、网络阻断或 DNS。测试完成后恢复原模式，避免把全局模式长期当作修复结果。

5. 从连接记录确认规则命中了什么

规则模式通常按配置顺序匹配，首次命中后交给对应策略处理。一个放得过早的宽泛规则，可能让后面的域名规则始终没有机会生效。不要根据规则名称猜测结果，应在「连接」或「日志」里查看测试域名、命中规则、所用策略及最终节点。

# 规则顺序示例；Proxy 必须是配置中已存在的策略名称
rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,LAN,DIRECT
  - MATCH,Proxy

上例只用于解释匹配顺序，不是适用于所有订阅的规则模板。MATCH 是兜底规则，应放在需要优先匹配的规则之后。若原配置使用规则集，还要检查相应规则集是否成功加载，以及规则集对应策略是否存在。

• 记录里没有请求：先检查应用是否真正进入代理；但 TUN 排除项、域名显示方式或日志级别也会影响观察，不能只凭一条空记录下结论。
• 命中 DIRECT 后失败：检查该网站是否应当经代理访问，以及更前面的直连规则是否过宽。
• 命中 REJECT：检查拦截规则是否误伤登录接口、静态资源或验证域名。
• 主页面正常，图片或登录失败：分别查看资源域名，不能只为地址栏中的主域名添加规则。

规则字段含义可对照配置字段说明。修改订阅生成的文件前，优先使用客户端支持的覆写或合并功能；直接修改缓存文件，可能在下一次更新订阅时被覆盖。

6. 分清本机 DNS、内核 DNS 与 Fake-IP

DNS 故障并不只有“换一个服务器”这一种处理方式。系统查询、浏览器安全 DNS、内核 DNS、代理服务器地址解析，可能使用不同路径。先在日志里区分 lookup 失败、DNS 请求超时、连接远端 IP 超时，以及 TLS 握手失败，再决定改哪一层。

系统解析正常，不代表内核解析正常

执行 nslookup example.com 可以观察系统默认 DNS 路径的结果，但浏览器启用安全 DNS，或代理内核自行解析时，不一定使用这条路径。若 mihomo 的 nameserver 填写了 DoH 地址，还需要确认该 DoH 服务可达、域名能够完成初始解析，以及 DNS 请求走向符合配置。

例如把上游写成 https://dns.example.com/dns-query 并不会自动解决网络不可达问题；该形式只是语法说明，不能把这个示例域名当作可用 DNS 服务。对于域名形式的节点地址，还应检查节点域名解析是否失败，避免节点尚未连上，就依赖该节点访问解析服务而形成循环依赖。

198.18 地址可能是正常的 Fake-IP 结果

在 Fake-IP 模式下，DNS 返回 198.18.0.0/16 范围内的地址是常见配置行为，这些地址用于内核映射，并非网站的真实公网地址。它本身不表示 DNS 被污染；关键是后续连接能否被同一个内核接管，并找到对应域名映射。

• 如果关闭客户端后系统或应用仍缓存 Fake-IP，访问可能失败。先恢复正常 DNS 路径，再清理缓存并重启受影响应用。
• 如果仅局域网域名、打印机或某个应用异常，可按实际域名检查 fake-ip-filter 与局域网解析安排，不必一开始就替换整个 DNS 区块。
• 如果浏览器启用了独立安全 DNS，可暂时切回系统解析进行对照；对照结束后，再决定保留哪套解析方式。

# Windows：清理系统 DNS 缓存
ipconfig /flushdns

# macOS：清理系统解析缓存，第二条命令需要管理员授权
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

清缓存不会修复错误的上游配置，也不一定清除浏览器自己的缓存。每次调整 DNS 后，重新加载内核配置，再新建测试连接。不要同时更改上游、Fake-IP 模式和全部分流规则，否则即便恢复访问，也难以确认真正原因。

7. 系统代理可用、TUN 不可用时查路由接管

TUN 通过虚拟网络接口接管符合条件的流量，与系统 HTTP 代理不是同一条入口。最有价值的对照是：关闭 TUN，仅使用系统代理测试浏览器；确认可用后，再开启 TUN 观察差异。Android 的 VPN 接口与桌面 TUN 机制有关联，但授权和路由管理由平台实现，菜单不能完全通用。

1. 检查权限与服务：查看客户端是否提示安装服务、授予 VPN 或网络扩展权限；没有权限时，开关亮起不代表路由已成功建立。
2. 排除其他 VPN：另一个 VPN、安全软件或虚拟网卡可能改变默认路由与 DNS，先在可控条件下逐一退出对照。
3. 核对 DNS 接管：检查配置中的 DNS 监听与 dns-hijack 是否符合当前内核和平台支持范围，不能假设所有 DNS 流量都会被接管。
4. 检查 IPv6：如果失败连接使用 IPv6，确认当前路由、节点与配置是否支持该路径。仅关闭内核的 IPv6 解析选项，不一定能阻止应用使用已有的 IPv6 地址。

不要把修改 MTU、关闭防火墙作为第一步。只有在小请求成功、较大传输持续卡住，并且路由与节点已确认正常时，才进一步检查 MTU、路径 MTU 发现或 UDP 转发。排查防火墙时优先核对客户端放行规则，而不是长期关闭系统防护。

8. 记录结果，按失败层级收尾

如果前面的检查仍没有定位问题，把一次失败请求的信息整理出来，比“已经重装几次”更有帮助。建议记录测试时间、目标域名、系统代理端口、模式、策略组、命中规则，以及日志中的第一条相关错误。若只有一个站点失败，也应考虑目标站点维护、账户限制或对出口地址的限制。

证书错误应沿着系统时间、配置与信任链处理，不要把跳过证书验证作为常规解决办法。需要临时提高日志级别时，只复现一次问题，再恢复常用级别；分享前移除订阅链接、访问令牌、节点密码及其他身份信息。

最终应能回答三个问题：浏览器是否把请求送进了内核，内核是否选中了预期规则与节点，DNS 与远端连接分别在哪一步成功或失败。按这个顺序逐项验证，通常能把“已连接却没网”收敛到一个可处理的具体问题，而不是在系统代理、节点和 DNS 之间反复盲改。