代理客户端显示 connected 但网页打不开：5 步排查法（2026）
代理客户端显示 connected 只代表内核或出口状态亮灯，网页请求可能卡在系统代理、TUN 路由、DNS 解析、规则命中、IPv6 或浏览器缓存。这篇用日志信号把问题切到具体层级，每一步给出可执行的验证命令。保留可见信号、工单材料和停止条件，问题扩大前就能决定该修哪里。
connected 不等于能上网。先看日志有没有请求记录 → 没有记录查入口（系统代理/TUN）→ 有记录查 DNS 和规则 → 再排除 IPv6 和浏览器缓存。这五步走完，90% 的 connected-but-no-internet 问题都能定位到具体层级，不用盲目换节点、换订阅、重装客户端。
这篇只处理代理客户端状态灯已亮、节点已连接，但浏览器打不开网页的场景。订阅导入失败、YAML 解析报错、客户端启动闪退不在这篇范围。
诊断决策表：看到什么现象，查哪一层
打开日志页面，刷新打不开的目标网页，看日志有没有新行，对照下表决定从哪步开始。
| 访问网页时日志里的信号 | 请求卡住的位置 | 跳到哪一步 |
|---|---|---|
| 没有任何新记录出现 | 请求没进客户端 | 第 1 步：查系统代理 / TUN 入口 |
出现域名但状态为 timeout 或 dial failed | DNS 解析失败或节点握手失败 | 第 2 步：查 DNS 解析 |
| 出现目标 IP 但连接超时 | 节点出口、TLS 或远程目标不可达 | 第 3 步：查规则命中 |
出现 DIRECT 或 REJECT | 规则匹配到了直连或拒绝策略 | 第 3 步：查规则顺序 |
出现 IPv6 地址（:: 开头）后超时 | IPv6 解析但出口不支持 | 第 4 步：IPv4-only 对照 |
| 日志有记录且状态正常，但浏览器不动 | 浏览器层（DoH、扩展、缓存） | 第 4 步：命令行对照 + 浏览器检查 |
这不是排错流程，这是分诊表。先确定你的信号落在哪一行，再读对应的步骤，比从头读到尾省一半时间。
第 1 步：日志无记录 → 查请求有没有进客户端
日志不出现目标域名，说明浏览器请求没经过客户端。先确认操作系统代理设置指向了正确的地址和端口。
系统代理模式下的检查路径：
- Windows：设置 → 网络和 Internet → 代理 → 手动设置代理。地址应为
127.0.0.1，端口通常是7890（Clash 系）或10809（v2rayN）。 - macOS：系统设置 → 网络 → 选择当前网络 → 高级 → 代理。确认「网页代理(HTTP)」和「安整体网络页代理(HTTPS)」已勾选，且地址指向
127.0.0.1。 - Linux：系统设置里的网络代理页面，或检查环境变量
echo $http_proxy和echo $https_proxy。
一个快速验证：浏览器地址栏输入 http://127.0.0.1:7890（换成你的客户端端口）。如果返回一段 YAML 或 JSON 文本，说明客户端端口在监听；如果显示「拒绝连接」，说明端口没起来或客户端未在监听。
TUN 模式下的检查路径：
- Windows：运行
ipconfig，看有没有名为Mihomo、sing-box或Clash的虚拟网卡。 - macOS / Linux：终端运行
ifconfig，同样找虚拟网卡（如utun接口）。 - 运行
route print（Windows）或netstat -rn（macOS/Linux），确认路由指向了虚拟网卡。
浏览器层面排查：
- 检查是否安装了 SwitchyOmega、Proxy SwitchyOmega 或其他代理管理扩展。这些扩展可能接管了浏览器的代理设置，覆盖了系统代理。
- 用无痕窗口打开目标网页。无痕模式默认不加载扩展，能快速判断是不是扩展干扰。
- Chrome/Edge 用户检查
chrome://net-internals/#proxy，看浏览器实际的代理状态。
以上都正常但日志仍无记录，退出安全软件测一次。部分防火墙会拦截本地环回地址的流量。
第 2 步：日志有域名但超时 → 查 DNS 解析
日志里出现了目标域名，但连接状态是 timeout、context deadline exceeded 或 lookup failed，问题卡在 DNS。
在命令行里做 DNS 对照：
# 用系统默认 DNS 查目标域名
nslookup google.com
# 如果 nslookup 返回的 IP 和客户端日志里的 IP 不一致，说明客户端 DNS 和系统 DNS 不在同一路径# 用 curl 带 -v 参数测试，能同时看到 DNS 解析和 TCP 连接过程
curl -v https://www.google.com如果 curl -v 停在 Trying <IP>... 没有进展，说明 TCP 连接都建不起来，先跳过 DNS 怀疑节点层。
Fake-IP 模式的特殊排查：
Mihomo 的 enhanced-mode: fake-ip 会给域名分配一个 198.18.x.x 的地址。日志里域名被解析成 fake-ip 不等于访问能通——还要看客户端是否维护了 fake-ip 到域名的正确映射。如果客户端重启或 DNS 缓存过期后映射丢失，浏览器的 fake-ip 请求就会全部失败。
浏览器 DoH 干扰：
Chrome、Edge、Firefox 的 DNS over HTTPS (DoH) 会绕过系统 DNS 和客户端的 DNS 劫持，基于域名的规则分流全数失效。检查方法：
- Chrome/Edge：设置 → 隐私和安全 → 安全 → 使用安全 DNS → 关闭。
- Firefox：设置 → 隐私与安全 → DNS over HTTPS → 关闭或设为默认保护。
Android 设备检查 Private DNS（设置 → 连接 → 更多连接设置 → 私有 DNS）。设为「自动」或指定了外部 DNS 时，客户端的 DNS 劫持会失效。
第 3 步：日志显示 DIRECT 或 REJECT → 查规则命中
日志里域名解析成功了，IP 也拿到了，但请求状态标记为 DIRECT（直连不走代理）或 REJECT（直接拒绝），说明规则匹配出了问题。
在 Clash Verge Rev 的 Connections 页面（或 Mihomo Dashboard），找到目标域名的请求，看它命中了哪个规则、进了哪个策略组。如果显示的是 DIRECT 或 MATCH → DIRECT：
- 打开规则列表或 Rule Provider，搜目标域名是否在直连规则里。
- 一个网页涉及主域名 + API + CDN + 认证域名，任何一个走了 DIRECT 都会异常。
- 看 final 或 MATCH 规则。很多配置把剩余流量设为 DIRECT——你的目标域名可能没在规则覆盖范围里。
- 查 Rule Provider 下载状态。Clash Verge Rev 规则集页面显示每个 provider 更新时间；显示「未更新」说明规则集没加载。
常见规则误判场景：
| 网页上的表现 | 日志里可能看到的 | 实际原因 |
|---|---|---|
| 首页能开，登录按钮点了没反应 | 主域名走代理，accounts.google.com 走了 DIRECT | OAuth/SSO 子域名没在代理规则里 |
| 页面打开但图片全是叉 | cdn. static. 域名走了 REJECT | 广告过滤规则误伤了 CDN |
| YouTube 首页能刷，视频一直转圈 | googlevideo.com 走了 DIRECT | 视频分发域名和页面域名不在同一策略组 |
| GitHub 页面能看，Release 下载失败 | objects.githubusercontent.com 走了 DIRECT | 对象存储域名未匹配代理规则 |
改完规则后必须重载配置（Reload Config），保存文件不等于生效。Mihomo 和 sing-box 的规则匹配是从上到下的，出现 DIRECT 就把目标域名相关的规则往前移。
第 4 步：排除 IPv6 和浏览器缓存
日志里 IPv4 的连接正常，但访问实际网页时浏览器优先尝试了 IPv6 地址且超时——这是系统 IPv6 优先级高于客户端出口能力产生的割裂。
用命令行做 IPv4-only 对照：
# 强制 curl 只用 IPv4
curl -v -4 https://www.google.com
# 对比 IPv6 的结果
curl -v -6 https://www.google.com如果 -4 成功、-6 超时，问题就定在 IPv6 出口。在两处处理比直接关系统 IPv6 更干净：
- 客户端 DNS 配置里设置
prefer-ipv4或disable-ipv6。 - 路由规则里把 IPv6 流量指向 REJECT 或 DIRECT，避免走不通的代理出口。
命令行通、浏览器不通 → 查浏览器层：
先用 curl -v https://www.google.com 确认网络层是通的。如果命令行能返回 HTTP 200 和完整 HTML，但同一个域名在浏览器里打不开，问题 100% 在浏览器。排查顺序：
- 无痕窗口打开目标网页（排除扩展、Service Worker、缓存）。
- 换一个从没装过代理扩展的浏览器（Edge 如果主力用 Chrome，反之亦然）。
- 清目标站点的站点数据（不要清全部历史，浪费时间）：浏览器地址栏左侧点锁图标 → Cookie 和网站数据 → 删除。
- Chrome 用户在
chrome://net-internals/#dns清 DNS 缓存，chrome://net-internals/#sockets清 socket 池。 - Firefox 用户在
about:networking#dns清 DNS 缓存。
HSTS 缓存也会干扰。浏览器记住「这个域名必须用 HTTPS」后，代理出口的 TLS 握手如果证书链和之前不同，浏览器可能直接拒绝连接。Chrome 在 chrome://net-internals/#hsts 底部输入域名删除缓存。
第 5 步：前面四步都正常 → 换节点做单变量对照
系统代理正确、TUN 网卡正常、DNS 解析成功、规则命中代理策略组、IPv6 已排除、命令行能通——但浏览器还是打不开。这时才是换节点的时机。
换节点的正确做法：同一策略组内换 2-3 个不同地区的节点，每次只改一个变量。不要同时换节点、改 DNS、切 TUN 模式，那样修好了也不知道是哪一步起的作用。
同一策略组内所有节点都超时 → 该策略组的节点整体有问题，换个策略组试试（比如从「自动选择」换成「手动选择」并指定一个确定能用的节点）。
换节点仍不通，且同一份配置在另一个客户端正常，可能是订阅格式兼容性问题。不同客户端对 YAML 和 JSON 的容忍度不同——用兼容 Clash / Singbox / V2Ray 的订阅做对照，一份订阅兼容多种格式，能隔离出是格式不兼容还是节点不可用。
修好后怎么确认
网页打开一次不算修好。验证四件事：
- 重启客户端后依然正常。
- 目标网页的登录、搜索、下载都正常——主域名能开不代表 API 和 CDN 域名也走对了。
- 换一个浏览器也正常。
- 断开 Wi-Fi 重连后代理状态自动恢复。macOS 切 Wi-Fi 后代理设置可能丢失。
这四件事都通过，connected 才算真正可用。
相关阅读
来源与时间
本文最后查看时间：2026-05-29。操作路径会随客户端版本变化，遇到按钮名称不一致时，优先按同义菜单和官方文档查看。