故障排查 预计阅读 12 分钟

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

从系统代理是否生效、端口冲突、DNS 解析、规则命中到节点可用性,按顺序逐项检查,帮助定位已连接却无法上网的具体原因。

1. 先区分客户端状态与真实请求

Clash 类客户端显示“已连接”，可能只表示 Mihomo 内核正在运行、系统代理开关已打开，或 Android 的 VPN 接口已经建立。这个状态不能证明浏览器请求进入了内核，也不能证明当前节点能连接目标网站。排查时需要沿着“应用 → 本地入口 → 规则与策略组 → 出站节点 → 目标服务”逐段确认。

先记录三个现象：所有网站都打不开，还是只有部分网站失败；只有浏览器失败，还是其他应用也失败；停用代理后，原本可以直连的网站是否恢复。使用同一个完整 URL 重复测试，避免把不同网站的访问条件混在一起。

观察到的现象优先检查下一步证据
访问网页时没有新连接记录系统代理、应用独立代理、TUN 接管显式指定本地代理测试
连接本地端口立即被拒绝内核启动状态、监听端口、端口占用端口监听进程
日志出现域名解析超时DNS 上游、节点域名解析、DNS 路由具体失败域名与解析器
请求命中了 DIRECT 或 REJECT规则顺序、规则集、策略组实际匹配规则
已选中代理节点但出站超时节点地址、认证、传输配置、网络限制换节点与换网络的对照结果

2. 系统代理是否真的指向 Mihomo

系统代理只是告诉遵循系统设置的应用使用哪个代理入口，不会自动接管所有程序。部分浏览器扩展、终端工具、游戏和其他 VPN 软件可能使用自己的网络设置。先暂时关闭浏览器代理扩展及其他代理客户端，只保留一个入口。

检查系统菜单与本地地址

  • Windows 11：打开「设置」→「网络和 Internet」→「代理」，检查“手动设置代理”中的地址与端口。若使用配置脚本，也要确认脚本是否仍然控制浏览器流量。
  • macOS：打开「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」，核对网页代理、安全网页代理或 SOCKS 代理。不同系统版本的菜单名称可能略有变化。
  • Android：系统 VPN 标志表示 VpnService 接口存在，还要检查客户端是否把浏览器排除在分应用代理之外。

下文以 127.0.0.1:7890 为本机混合代理入口。7890 只是示例，不是所有客户端的固定值。请从当前生效配置或客户端端口设置中读取实际数值；external-controller 是控制接口，不能当作网页代理端口使用。

用显式代理绕开系统设置

Windows 在 PowerShell 中使用 curl.exe，避免旧环境中同名命令别名带来的差异。macOS 与 Linux 可将下面的 curl.exe 改为 curl。示例目标是 https://example.com/；若它在当前网络不可用，换成自己已知可访问的 HTTPS 地址。

curl.exe -v --connect-timeout 10 --max-time 20 --noproxy "" -x http://127.0.0.1:7890 https://example.com/ -o NUL

macOS 与 Linux 将输出目标 NUL 换成 /dev/null。--noproxy "" 用于避免环境中的绕过列表影响这次显式代理测试。超时上限分别设为 10 秒和 20 秒，是排查参数，不是节点速度的实测结果。

  • 若命令成功、浏览器失败，优先检查系统代理、浏览器扩展、独立代理与缓存连接。
  • 若提示无法连接 127.0.0.1，先排查本地端口，不要立即更换 DNS。
  • 若显示 CONNECT 成功，随后出现 TLS 或远端连接错误，说明至少已经接触到代理入口，仍需继续检查出站链路。

3. 端口冲突与内核启动失败

客户端窗口能够打开，不代表内核加载配置成功。查看内核日志中是否出现 address already in use、配置解析失败、规则集加载错误或权限错误。若本地端口被旧进程占用，浏览器甚至可能连接到了另一套代理程序。

确认监听进程

Windows PowerShell 可以查询 TCP 监听端口，再用返回的进程编号核对程序。以下命令只查询，不会结束进程。

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

Get-Process -Id 1234

1234 是演示用进程编号，第二条命令执行前应改成第一条实际返回的 OwningProcess。macOS 可执行 lsof -nP -iTCP:7890 -sTCP:LISTEN；Linux 可执行 ss -lntp 'sport = :7890'。查看其他用户进程详情时可能需要相应权限。

让系统代理与有效配置保持一致

# 本地混合入口示例，仅用于说明相关字段
mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule

这段不是完整订阅配置，不要用它覆盖节点与规则。若把端口改为 7891，系统代理和测试命令也要同步修改。某些客户端会通过覆写或合并配置生成最终文件，因此应核对“实际生效配置”，不能只看订阅原文。保留回环地址便于限制本机入口，也不需要为了修复本机上网问题开启局域网访问。

4. DNS 排查：区分目标域名与节点域名

“DNS 出错”至少有两个方向：目标网站域名解析失败，或者代理服务器本身的域名无法解析。后者会让多个网站同时超时，即使这些网站的 DNS 回答完全正常。查看日志时要记录发生错误的具体域名，而不是只看见 timeout 就判断节点失效。

先看系统解析，再看内核日志

nslookup example.com

nslookup 通常查询系统选定的 DNS 服务器；在 TUN 劫持或网络重定向存在时，请求也可能被接管。它的结果不能直接代表 Mihomo 的所有 DNS 查询路径。浏览器安全 DNS、系统加密 DNS和内核内置 DNS，也可能各走不同路径。

  • 检查 DNS 是否启用：确认有效配置中 dns.enable 的状态，以及使用的 nameserver 是否能够从当前网络到达。
  • 检查加密 DNS 的依赖：DoH 或 DoT 上游使用域名时，需要可用的引导解析路径。default-nameserver 可用于解析 DNS 服务器域名，不能忽略它与上游地址的关系。
  • 检查代理节点的解析：proxy-server-nameserver 用于代理节点域名解析。若配置了它，应确认这些解析器可用，避免节点还没建立连接就依赖同一个节点完成解析。
  • 检查规则依赖：使用 respect-rules 等让 DNS 连接遵循路由规则的设置时，需要一起审查相关代理与直连解析器，避免形成解析与代理的循环依赖。

从 Fake-IP 切换到其他解析模式后，应用可能仍持有旧地址。Windows 可执行 ipconfig /flushdns 清理系统缓存，再完全退出并重新打开浏览器。清理系统缓存不会保证浏览器自己的缓存、DoH 缓存或已建立的连接同时消失，因此应重新发起请求并对照日志。

不要同时把 DNS 模式、全部上游和 TUN 开关一起改掉。先确认一个已知可用的解析路径，再逐项恢复原设置。关于字段含义，可结合DNS 配置说明核对。

5. 规则命中与策略组：看实际出口，不只看模式

Mihomo 的规则模式按顺序匹配规则。通常先匹配到的规则决定请求去向，末尾的 MATCH 用来接住未被前面规则处理的请求。如果目标域名被较靠前的规则送往 DIRECT，后面的代理规则不会再替它改道。

在连接详情里核对四项

  1. 目标域名和端口是否就是刚刚测试的网站，HTTPS 通常使用 TCP 443。
  2. 匹配的规则类型与规则内容，尤其是域名规则、规则集和兜底规则。
  3. 命中的策略组，以及该组最终选中的节点或 DIRECT。
  4. 失败发生在解析、拨号、代理握手还是 TLS 阶段。

先在客户端清空连接列表或记下测试时间，再打开一次目标网页。若旧连接复用导致结果难以判断，可关闭对应连接后重试。策略组名称只是一层选择入口，组内还可能嵌套其他组，因此需要追踪到最终出口。

全局模式只用于短时对照

临时切换全局模式，并明确选择一个节点。如果同一目标在全局模式可以打开、规则模式失败，重点回到规则顺序和策略组选择；如果两种模式都失败，继续检查节点和网络。全局模式不会修复失效节点，也不会自动接管没有进入内核的应用流量。

规则集下载失败也可能影响配置加载或分流结果，应查看 rule-providers 的更新日志与本地缓存状态。不要只为了让网页暂时打开就删除整套规则；先定位具体命中项，再调整必要的顺序或策略。排查结束后恢复原本的规则模式。

6. 节点可用性：延迟数字不等于网页可访问

延迟测试反映的是指定测试 URL、指定时间和当前网络下的一次探测。显示延迟数值，不代表其他域名、视频服务或 UDP 流量都能通过。节点列表有记录，也不代表订阅中的地址、端口和凭据仍然有效。

  • 同网络换节点：保持浏览器、目标 URL 和代理模式不变，只替换节点。若另一个节点立即恢复，优先检查原节点或其服务端状态。
  • 同节点换网络：从 Wi-Fi 切到手机热点，重复访问相同目标。结果不同，说明接入网络的 DNS、防火墙或路由条件值得进一步检查。
  • 核对订阅更新时间：确认更新确实成功，而不是仍在使用旧缓存。更新后也要检查客户端覆写是否覆盖了节点相关设置。
  • 核对协议参数：手动配置应检查服务器地址、端口、认证信息、TLS 的服务器名称与传输参数。字段是否需要取决于具体协议，不能把其他协议的配置直接拼接过来。

connection refused 常见于目标端口未监听或被主动拒绝；i/o timeout 表示等待超时，不能单凭这一行判断是服务端故障还是中间网络丢包。证书错误则要检查系统时间、目标域名与 TLS 配置。不要通过长期跳过证书验证来掩盖握手错误。

若只有登录页或某个网站失败，还应检查网站返回的 HTTP 状态码。403、429 或账户限制与“本地代理端口没启动”不是同一类问题。此时先确认响应确实来自目标服务，再考虑出口地址策略或网站自身限制。

7. TUN、分应用代理与浏览器协议的补充检查

显式 HTTP 代理测试正常，而启用 TUN 后无法访问，是一条很有价值的分界线。TUN 依赖虚拟网卡、路由与权限；启用 tun.auto-route、接口检测或 DNS 劫持后，还要检查它们与其他 VPN、虚拟机网络及安全软件是否冲突。

桌面端先隔离 TUN 路径

  1. 记录当前 TUN 和系统代理状态，临时关闭 TUN。
  2. 只用前面的显式代理命令测试相同 URL，确认本地入口与节点链路。
  3. 若显式代理正常，再开启 TUN，检查启动日志中的权限、网卡创建及路由写入结果。
  4. 若关闭客户端后仍不能直连，检查遗留的系统代理、其他 VPN 和路由，不要盲目删除系统路由表。

Android 检查应用是否被接管

Android 通常只能有一个普通应用 VPN 服务处于活动状态。切换其他 VPN、广告过滤类 VPN 或工作配置中的网络工具时，原客户端可能被替换。分应用设置中，“仅代理所选应用”与“绕过所选应用”的语义相反，要确认浏览器处于预期列表。若锁屏后才失败，再检查后台限制与电池优化，而不是先重写规则。

只有浏览器失败时检查 HTTP/3

HTTP/3 使用 QUIC，通常涉及 UDP 443。显式 HTTP 代理命令成功，不能证明浏览器的 QUIC 路径也正常。若现象明确集中在浏览器，可临时禁用 HTTP/3 做对照；只有结果随之改变，才继续检查 UDP 出站、节点支持与 TUN 接管。不要把禁用协议当成所有网页故障的固定修复步骤。

8. 恢复配置与提交问题的最小清单

找到故障层后，把为测试临时改动的全局模式、DNS 上游、浏览器协议开关逐项恢复，只保留确实解决问题的修改。再次测试一个可直连网站、一个需要代理的网站，以及原本失败的目标。最后确认关闭客户端后，系统仍能按预期联网。

若仍需提交问题，提供下面的信息比只发一张“已连接”的截图更容易定位。日志只截取复现前后必要片段，避免公开订阅凭据、节点密码和控制接口令牌。

  • 操作系统版本、客户端版本、实际 Mihomo 内核版本，以及是否使用客户端覆写。
  • 系统代理或 TUN 的启用状态、本地监听地址与端口、分应用代理设置。
  • 发生问题的时间、目标域名、所用网络，以及是否所有目标都失败。
  • 显式代理命令的结果、实际匹配规则、最终策略组与节点。
  • 换节点、换网络、关闭 TUN 三项对照中，哪些步骤改变了结果。
下载Clash