Clash 已连接却打不开网页:系统代理、DNS 与规则逐项排查清单

先区分客户端运行与网页连接

Clash 客户端的“已连接”可能表示内核正在运行、配置已经载入，或移动端的 VPN 接口已经建立，并不表示目标网站已成功响应。节点旁边有延迟数值，也只能说明当次测试地址可以通过相应路径访问，不能替代对故障网站的检查。

排查时保留一个确定能直连的网页和一个实际打不开的网页，每次只改一个设置，并记录浏览器报错、请求时间和连接日志。这样才能区分“改完碰巧恢复”与“某一层确实有问题”。

• 先保存配置：记录当前配置名称、运行模式、混合端口、策略组选择，以及系统代理和 TUN 的开关状态。
• 先排除基础网络：暂时关闭客户端接管的系统代理与 TUN，检查直连网页。酒店、校园或公共 Wi-Fi 可能要求先完成登录认证。
• 不要同时启用多个接管工具：其他 VPN、代理软件或浏览器代理扩展可能改变流量去向。逐个暂停，并在检查后恢复原设置。
• 确认实际内核：在客户端关于页或启动日志中查看是否使用 mihomo。不同客户端与内核的菜单、DNS 字段和 TUN 功能并不完全相同。

第一层：确认浏览器流量进入本地代理

检查系统代理地址与本地监听

系统代理依赖应用主动遵循代理设置，并不会自动接管全部程序。Windows 11 可在「设置」→「网络和 Internet」→「代理」查看手动代理；macOS 可在「系统设置」→「网络」→当前网络服务→「详细信息」→「代理」检查。界面名称可能随系统版本调整。

同一台电脑上，HTTP 代理通常填写 127.0.0.1 和实际混合端口。如果使用自动代理脚本，需要检查 PAC 地址是否仍由当前客户端提供。浏览器自己的代理扩展、Firefox 的独立连接设置，都可能覆盖系统配置。

先用命令行绕过系统代理发现机制，显式指定本地端口。以下命令只针对这一次请求，不会修改系统设置；Windows 请使用 curl.exe，避免部分 PowerShell 环境把 curl 当作其他命令的别名。

# macOS / Linux
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

# Windows PowerShell
curl.exe -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/

这里的 example.com 是用于说明命令的真实域名。实际排查还应对打不开的网站执行相同测试。-I 发送 HEAD 请求；即使返回 403 或 405，也说明已经收到 HTTP 响应，但不代表网页完整加载正常。

用连接列表验证，而不是只看开关

打开客户端的连接列表，刷新目标网页，查找相同域名或目标 IP。普通系统代理请求通常应出现在连接记录中。如果完全没有新记录，先检查浏览器入口，暂时不要改 DNS。若启用了 TUN，普通直连命令也可能被接管，因此“没有显式指定代理”不等于真正绕过了客户端。

第二层：区分本机 DNS、内核 DNS 与代理端解析

网页报 ERR_NAME_NOT_RESOLVED 时，应确认到底是谁在解析域名。浏览器可能使用安全 DNS，操作系统可能查询路由器，mihomo 可能使用独立上游，代理协议也可能把域名交给远端处理。这几条路径的结果不一定相同。

先看系统解析，再对比代理请求

# 将 example.com 换成实际故障域名
nslookup example.com

# SOCKS5：由本机解析目标域名
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5://127.0.0.1:7890 https://example.com/

# SOCKS5h：把目标域名交给 SOCKS 代理处理
curl -I -v --connect-timeout 10 --max-time 20 --noproxy "" --proxy socks5h://127.0.0.1:7890 https://example.com/

Windows 同样使用 curl.exe 执行后两条命令。混合端口可同时接收 HTTP 与 SOCKS 请求；如果当前仅配置了 HTTP 端口，应换成真实的 SOCKS 监听端口。socks5h 只是把目标域名交给本地 SOCKS 代理，之后在内核还是远端解析，仍取决于规则和出站协议。

• 本机解析失败，交给代理后成功：优先检查系统 DNS、浏览器安全 DNS，以及两者是否走了不同网络路径。
• 两种请求都失败：不能直接认定 DNS 故障，继续查看内核是否记录解析超时、规则命中或出站连接失败。
• 系统解析成功，浏览器仍报错：检查浏览器安全 DNS；它可能没有使用系统查询到的结果。

处理 fake-ip 与 DNS 劫持的边界

mihomo 使用 fake-ip 模式时，客户端 DNS 返回映射地址是正常机制，常见默认范围为 198.18.0.1/16。不能仅凭这个地址判定解析被污染。关键在于后续连接是否仍被同一个内核接管，内核是否保留域名映射。

若系统获得了 fake-ip，但 TUN 或相关路由已经关闭，应用可能无法访问该地址。先恢复一致的接管方式，再考虑清理缓存。修改 DNS 后，Windows 可运行 ipconfig /flushdns；macOS 可执行下面两条命令，然后关闭旧连接并重新测试：

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

第三层：核对规则命中与策略组实际选择

流量进入内核、域名可以解析之后，仍可能被规则送到错误出口。Clash 风格的规则通常按顺序检查，优先命中前面的规则；末尾的 MATCH 是未命中前序规则时的兜底。只看策略组名称，不能知道请求实际走了哪个节点。

1. 确认当前处于规则模式，而不是直连模式。全局模式通常使用全局策略选择，适合做短时对照，不适合直接当作故障结论。
2. 在连接详情里查找故障域名，记录命中的规则类型、规则内容和策略链。
3. 检查规则目标是 DIRECT、REJECT，还是某个策略组；继续展开策略组，确认最终选择的真实节点。
4. 清理该网站的旧连接，再刷新页面。已有连接通常不会因为切换策略立刻迁移到新出口。

下面是规则顺序的最小示意，不是一份可直接运行的完整配置。含义是拒绝一个指定主机，其余请求直连；实际配置应使用真实域名、现有策略组，并遵循自己的分流需求。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - MATCH,DIRECT

如果把 MATCH,DIRECT 提到第一行，后面的域名规则就不会处理这些请求。规则集同样需要检查顺序和加载状态；订阅更新成功只说明配置获取完成，不代表所有远程规则集都已下载成功。

用短时全局对照缩小范围

可以临时切换到全局模式，并明确选中一个节点，再访问同一网页。若规则模式失败、全局模式成功，应回到连接详情检查命中差异；若两种模式都失败，继续检查出站。测试后恢复原模式，避免把局部故障扩大到其他应用。全局成功也可能伴随解析路径变化，因此还需结合日志确认。

第四层：验证出站节点与目标站点

节点延迟测试通常针对配置中的一个测试 URL。它成功不等于所有站点、所有端口和 UDP 都可用。浏览器访问还可能包含主站、登录域名、图片域名等多个请求，单个资源失败会表现为白屏或一直加载。

• 对比两个节点：固定同一个故障域名、同一种代理入口与模式，只切换最终节点。切换后关闭该域名旧连接，再重试。
• 检查订阅状态：核对服务提供方显示的有效期、流量和节点状态。更新订阅后确认正在运行的配置确实切换到了新内容。
• 检查系统时间：时间偏差会影响 TLS 证书验证，也可能影响依赖时间的认证。先开启系统自动时间，再看错误是否消失。
• 检查协议兼容：出现不支持的代理类型、加密方式或配置字段时，核对当前内核能力。客户端能导入订阅，不等于内核已经成功启动全部节点。

日志中的 connection refused 通常指向某个连接目标主动拒绝或端口未监听；i/o timeout 只能说明操作超时，不能单独定位 DNS、线路还是远端；x509 相关错误应结合证书域名、有效期和系统时间判断。不要通过关闭 TLS 证书验证来掩盖问题。

如果只有某个网站返回 403、地区限制或验证码，而其他网页正常，说明已经走到了 HTTP 响应阶段，应继续检查站点策略与出口条件。此时反复改本地混合端口通常没有帮助。

TUN 模式与浏览器单独故障的补充检查

系统代理可用，TUN 开启后失败

TUN 通过虚拟网络接口接管流量，涉及权限、路由和 DNS。若显式代理测试正常、开启 TUN 后才断网，应优先检查这些环节，而不是重新导入订阅。查看日志是否有创建接口失败、权限不足、路由设置失败或 DNS 请求超时。

在 mihomo 配置中，tun.auto-route、tun.auto-detect-interface 与 tun.dns-hijack 分别涉及自动路由、出口接口识别和 DNS 劫持；具体效果受平台与客户端实现影响。切换 Wi-Fi、插拔网线或连接另一套 VPN 后，旧出口接口与路由可能已经不适用。保存日志后重新启动 TUN，再比较同一请求。

命令行可用，只有浏览器打不开

1. 临时停用浏览器代理扩展，在 Firefox「设置」→「常规」→「网络设置」检查是否使用独立代理。
2. 检查浏览器安全 DNS。可短时关闭做对照，确认后恢复原设置，不要同时修改内核 DNS。
3. 打开开发者工具的「网络」面板，查看失败的是主文档还是某个脚本、图片、登录接口。
4. 若日志指向 UDP 或 QUIC 路径，先用普通 HTTPS 命令行请求对照。HTTP 请求成功并不能证明节点支持 UDP。

Android 上还要检查客户端是否启用了按应用代理，以及目标浏览器是否在排除列表；系统“私人 DNS”也可能使解析路径与预期不同。移动端 VPN 图标只说明接口存在，仍应以实际请求和客户端日志判断。

恢复设置并保留可复现的排查记录

完成检查后，恢复临时调整的全局模式、浏览器设置与日志级别。需要向客户端维护者或服务提供方反馈时，提供可重复的步骤比“已连接但没网”的截图更有效。

• 记录操作系统、客户端与内核的实际版本，以及系统代理和 TUN 是否开启。
• 说明故障范围：全部网站、单个网站、单个浏览器，还是只有 TUN 模式。
• 附上显式 HTTP 代理测试结果、DNS 对照结果、规则命中与最终出站节点类型。
• 截取同一次请求前后的相关日志，分享前遮盖订阅地址、认证信息、控制接口密钥和个人访问记录。

需要核对配置字段时，可查阅本站的配置进阶；常见安装与使用问题可从帮助中心继续查找。