Clash 显示连接成功但打不开网页 / 没网络全网最全排查指南

1. 测速数据流 vs 真实上网数据流的本质区别#

为了彻底理清其中的技术鸿沟，我们必须分别审视这两条链路在操作系统内部是如何流转的：

2. 全景数据流向与五大断裂点架构图#

以下 Mermaid 流程图直观展示了从浏览器发起请求到目标网站返回数据的完整路径，并标明了导致断网的五大核心故障断裂点：

3. 常见浏览器报错代码的底层技术语义#

遇到无法上网时，浏览器地址栏下方的那行不起眼的英文错误代码，实际上是操作系统与网络协议栈向你吐露的最宝贵线索。千万不要把它当成无意义的代码一关了之：

• ERR_PROXY_CONNECTION_FAILED（代理连接失败）：
  • 技术本质：浏览器尝试与配置的代理地址（通常是 127.0.0.1:7897 或 7890）建立 TCP 三次握手，但在本地环回接口上直接收到了操作系统的 RST（重置）拒绝报文。
  • 直接结论：问题 100% 发生在本机内部！说明 Clash 的内核根本没有在对应的端口上监听，或者系统代理填写的端口与 Clash 实际运行的端口不一致。
• DNS_PROBE_FINISHED_NO_INTERNET（DNS 探针完成但无网络）：
  • 技术本质：Chromium 内核在尝试加载页面前，会向系统底层注册的 DNS 服务器发起预检解析，由于 DNS 报文超时或者返回了不可路由的死地址，浏览器判定网络已彻底断绝。
  • 直接结论：这通常发生在启用了 TUN 模式 但系统 DNS 发生死锁，或者开启了某些第三方拦截工具破坏了 Windows 网络适配器的 DNS 自动分配。
• ERR_CONNECTION_TIMED_OUT（连接超时）：
  • 技术本质：浏览器成功发出了数据请求，但在设定的等待时间（如 20 秒）内，没有收到远端服务器的任何应答（SYN 丢包）。
  • 直接结论：这说明流量成功走出了本机，但被错误地路由到了直连通道（遭遇 GFW 丢弃），或者所选的代理节点在远端虽然有延迟响应，但在转发真实流量时被机房防火墙丢弃。
• ERR_CERT_AUTHORITY_INVALID 或 ERR_SSL_PROTOCOL_ERROR（证书无效/SSL协议错误）：
  • 技术本质：TLS 握手阶段，浏览器收到的数字证书无法被系统根证书颁发机构（CA）信任，或者握手数据包遭遇中间人劫持篡改。
  • 直接结论：多为安全软件（深信服、火绒、迈克菲）开启了 HTTPS 流量过滤审计，破坏了代理隧道的证书链。

1. 端口演进历史与版本冲突陷阱#

为什么会产生端口不一致？这涉及 Clash 生态的演进历史：

• 在 2023 年以前，全网最为流行的老版 Clash for Windows（CFW）默认将 HTTP 代理端口设为 7890，SOCKS5 端口设为 7891，混合端口（Mixed Port）同样习惯性配置为 7890；
• 随着 CFW 项目的原作者停更，新一代基于开源内核 Mihomo（Clash Meta）的现代化客户端迅速普及，以 Clash Verge Rev 为代表的新主力客户端，为了避免与老旧代理工具冲突，将默认的混合端口全面调整为了 7897。

这就埋下了一个巨大的隐患： 如果你曾经在同一台电脑上安装过多款代理工具（例如先用过 v2rayN，又装过老版 Clash，最近又换成了 Clash Verge Rev），或者你在更新客户端时未进行清理，系统代理设置很容易在多款软件的相互争夺中发生“神仙打架”。

2. Windows WinINet 注册表机制深度解密#

在 Windows 操作系统中，所谓开启【系统代理】，其实质动作是客户端调用了 Windows 底层的 WinINet API，向注册表的以下路径写入了配置键值：

1
注册表路径:
2
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings

其中包含三个至关重要的键：

1. ProxyEnable（REG_DWORD）：取值为 1 代表启用系统代理，取值为 0 代表关闭系统代理；
2. ProxyServer（REG_SZ）：保存具体的代理服务器地址与端口字符串，例如 127.0.0.1:7897 或 http=127.0.0.1:7890;https=127.0.0.1:7890；
3. ProxyOverride（REG_SZ）：不使用代理的绕过地址列表，通常包含 <local>、localhost、127.* 等。

致命故障场景： 当你启动了 Clash Verge Rev（正在监听 7897 端口），但由于系统权限受限、杀毒软件拦截注册表写入、或者此前非正常关机导致的注册表锁定，Windows 注册表中的 ProxyServer 依然顽固地保留着旧软件写入的 127.0.0.1:7890。 此时：

• 浏览器读取注册表，欢天喜地地向 127.0.0.1:7890 发送流量；
• 但此时本机 7890 端口上空空如也，没有任何程序在监听；
• 浏览器遭到操作系统的即刻拒绝，瞬间暴毙报错：ERR_PROXY_CONNECTION_FAILED！

3. 僵尸内核进程霸占端口导致监听失败#

另一种常见的底层异常是**“僵尸内核（Zombie Process）霸占”**： 当你通过任务管理器强制结束客户端图形界面、或者软件意外崩溃闪退时，底层的 clash-meta.exe 或 mihomo.exe 核心进程可能并没有被操作系统完全杀死，而是作为一个不可见的无界面后台进程继续驻留，死死霸占着 7897 端口。

当你重新双击打开客户端时：

• 图形界面正常启动，UI 显示一片祥和；
• 但新启动的核心在尝试绑定 7897 端口时，系统返回底层错误：bind: address already in use（地址已被占用）；
• 新客户端未能成功建立任何本地代理监听！你在界面上看到的所有节点绿色测速，都是新进程在内存中测出来的，但它根本无法承接任何系统流量！

4. 端口错位与僵尸进程的根治操作#

1
# 1. 查找霸占 7890 和 7897 端口的进程 PID
2
Get-NetTCPConnection -LocalPort 7890, 7897 -ErrorAction SilentlyContinue | Select-Object LocalAddress, LocalPort, State, OwningProcess
3

4
# 2. 强制杀掉所有残留的 Clash / Mihomo / Verge 孤儿进程
5
Get-Process -Name *clash*, *mihomo*, *verge* -ErrorAction SilentlyContinue | Stop-Process -Force
6

7
# 3. 重新启动你的客户端，让端口重新纯净绑定

1. Chromium 扩展代理接管机制与优先级碾压#

要理解这种“唯独浏览器打不开网页”的奇葩现象，必须透视 Chromium 内核关于网络代理调度的底层特权机制：

1. chrome.proxy API 的绝对特权： Google Chrome、Microsoft Edge 以及 Brave 等主流 Chromium 浏览器，为扩展程序开放了一组名为 chrome.proxy.settings 的专用接口。 一旦某个扩展（例如 SwitchyOmega）声明接管了浏览器的代理控制权，浏览器的网络栈就会彻底切断与 Windows / macOS 操作系统的代理感知！
2. 操作系统的系统代理在浏览器内部彻底失效： 无论你在 Windows 桌面右下角如何点击开启或关闭 Clash 的【系统代理】，甚至无论 Windows 注册表里的 ProxyServer 写了什么，浏览器完全视而不见！ 浏览器发出的每一个 HTTP / HTTPS 网络请求，全部由 SwitchyOmega 内部配置的情景模式决定生死。

2. 扩展引发断网的三大典型故障场景#

• 场景一：情景模式依然指向早已遗忘的历史旧端口： 很多老用户之前用过基于 v2ray 核心的客户端（其本地 SOCKS5 端口通常为 10808，HTTP 端口通常为 10809），或者用过 Shadowsocks（端口通常为 1080）。 用户在 SwitchyOmega 中配置了一个名为“代理”的情景模式，写死了 127.0.0.1:10808。 后来换成了 Clash（端口为 7897 或 7890），但 SwitchyOmega 依然在忠实地把所有海外网页请求往已经关闭的 10808 端口上转发。结果可想而知：浏览器瞬间弹出连接失败！
• 场景二：插件误切换为“直接连接（Direct）”模式： 在调试某个国内网页时，用户在浏览器右上角不小心将 SwitchyOmega 点击切换为了深蓝色的【直接连接】。 此时即使系统开着全局代理，浏览器内访问 Google、YouTube 也是以绝对的“裸连”姿态直冲运营商骨干网，瞬间遭到 GFW 的单向丢包阻断，表现为网页无休止转圈直到连接超时。
• 场景三：自动切换规则列表源（如 gfwlist）下载失败： 许多用户在 SwitchyOmega 中启用了“自动切换”情景模式，依赖在线的 gfwlist.txt 规则进行分流。 如果由于某种原因该规则列表长期无法更新，或者规则库损坏，导致目标海外网站未被识别为受限域名，插件便会默认将其归入直连通道，导致网页无法打开。

3. 浏览器扩展冲突的一键排障与标准协同配置#

1. Fake-IP 的工作原理与革命性优势#

为了看透故障根源，必须首先理解 Fake-IP 究竟干了什么：

• 传统 Redir-Host 模式的痛点： 当你在浏览器输入 www.twitter.com 时，本地电脑必须先向 DNS 服务器发起查询，获取真实 IP。 在没有保护的情况下，这个查询请求会直接被运营商防火墙（GFW）抢答，返回一个虚假的、不可达的投毒 IP。电脑拿到假 IP 后再尝试连接，自然全部超时。
• Fake-IP 的降维打击： Clash 在本地虚拟了一个专属的内网保留网段——198.18.0.0/16（IP 地址范围为 198.18.0.1 到 198.18.255.254）。 当浏览器询问 www.twitter.com 的 IP 时，Clash 根本不需要在本地去向海外发起缓慢的真实查询，而是直接从虚拟池里捞出一个假的 IP（例如 198.18.0.25）秒级扔给浏览器！ 浏览器拿到 198.18.0.25 后立刻向其发起 TCP 连接，Clash 截获该请求，并在内部对照表中反查：“哦，198.18.0.25 对应的是 www.twitter.com！” 接着，Clash 把原始域名直接打包进加密隧道，让远端海外落地节点去直接连接真实的 Twitter 服务器。 优势：彻底杜绝本地 DNS 污染，同时实现 0 毫秒的本地 DNS 解析等待！

2. 为什么 Fake-IP 会发生死锁导致“没网络”？#

虽然 Fake-IP 极其先进，但在以下边界条件下，会产生致命的死锁：

1. 浏览器的“安全 DNS（Secure DNS / DoH）”强行夺权： 这是目前 Windows / Chrome 环境下引发断网的超级重灾区！ 现代版本的 Chrome 和 Edge 浏览器默认开启了一项名为【使用安全 DNS（DoH）】的功能，试图通过加密的 HTTPS 连接直接向 Google（8.8.8.8）或 Cloudflare（1.1.1.1）查询域名。 此时产生了灾难性的碰撞：
   • 浏览器尝试绕过操作系统的本地 DNS 栈直奔海外 DoH 服务器；
   • 但直连访问 8.8.8.8 的请求本身就被 GFW 封锁；
   • 浏览器的安全 DNS 查不到结果，又拒绝接受 Clash 返回的 Fake-IP；
   • 最终浏览器直接抛出惨绝人寰的报错：DNS_PROBE_FINISHED_NO_INTERNET！
2. 操作系统 DNS 缓存与 Fake-IP 映射表脱节： 如果电脑发生休眠唤醒、客户端重启、或者你手动清空过客户端配置，Clash 内存中的 Fake-IP 映射表已经被全部重置清空； 但是，Windows 操作系统的本地 DNS 缓存（dnscache 服务）以及 Chrome 浏览器的内部 DNS 缓存中，依然死死记录着上一次分配的旧 Fake-IP（例如 198.18.0.12）； 当浏览器向旧 IP 发送请求时，Clash 在自己的全新映射表里查无此人，不知道这个虚拟 IP 对应哪个域名，只能将数据包无情丢弃在本地黑洞中！

3. DNS 死锁的彻底根治实操#

1
# 1. 强制刷新并清空 Windows 系统的 DNS 解析缓存
2
ipconfig /flushdns
3

4
# 2. 重启 Windows 本地 DNS 缓存服务
5
Restart-Service -Name dnscache -Force -ErrorAction SilentlyContinue

1
chrome://net-internals/#dns

1. 规则匹配引擎的执行优先级与逻辑#

Clash 拥有业内极其强悍的智能规则分流系统，它默认按照配置文件中的 rules 列表自顶向下、严格顺序匹配：

1
rules:
2
  - DOMAIN-SUFFIX,google.com,🚀 节点选择   # 1. 优先匹配具体域名后缀
3
  - GEOSITE,github,🚀 节点选择              # 2. 匹配预编译的域名集合
4
  - GEOIP,CN,DIRECT                        # 3. 匹配国内 IP 走直连
5
  - MATCH,🐟 漏网之鱼                      # 4. 最终兜底规则

一旦一个数据请求从顶部开始逐行扫描，只要命中了其中任何一条规则，就会立即执行该规则指定的动作，并立即终止后续所有规则的匹配。

2. 规则失效导致断网的常见根源#

• 根源一：远程规则集（Rule Provider）拉取失败导致规则库全空： 现代的优质配置普遍采用动态引用的远程规则提供者（Rule Providers），例如从 GitHub 或 FastGit 实时拉取 Loyalsoldier 的规则集。 如果这些远程规则链接在首次拉取或更新时遭遇网络阻断、或者返回了 404 Not Found，本地生成的有效分流规则可能只有寥寥数条。 绝大多数海外网站无法匹配到前置规则，全部一溜烟滑落到了最底部的兜底规则；而如果你的兜底规则碰巧写的是 MATCH,DIRECT，所有海外流量全部被强迫走本地直连，直击 GFW 铁壁，当场超时断流！
• 根源二：策略组指向了失效的“空策略”： 在某些经过二次转换或者手工编辑的订阅中，规则指定的策略组名称（如 PROXY）在顶部的 proxy-groups 定义中由于大小写拼写错误、或者缺少对应分组，导致内核在路由时找不到目标出口，流量被静默丢弃。
• 根源三：分流规则误将海外 CDN 判定为中国大陆 IP： 许多大型海外跨国企业（如微软、苹果、Steam、甚至部分海外大学网站）在全球广泛部署了 Anycast 节点。某些老旧过期的 GeoIP.dat 数据库错误地将这些海外边缘 IP 识别为中国大陆（CN）网段，直接触发 GEOIP,CN,DIRECT 走直连，导致这些原本可用的海外网站彻底打不开。

3. 分流规则失效的交叉隔离排查法#

当怀疑是分流规则作祟时，绝对不要一上来就去修改数千行复杂的 YAML 规则，而是采用最经典的**“模式二分隔离法”**：

1. TUN 模式底层工作机制与三层接管#

与基于 WinINet 的纯应用层 HTTP 代理不同，TUN 模式直接深入到了操作系统的网络层（OSI 第三层）：

1. Clash 调用专用的虚拟网卡驱动（在 Windows 上通常为高吞吐的 Wintun 驱动，在 Linux 上为原生 tun 设备，在 macOS 上为 Network Extension）；
2. 操作系统在网络适配器列表中虚拟出一张专属网卡（例如名为 Mihomo 或 Clash 的虚拟网卡）；
3. 客户端自动修改操作系统的全局路由表，将默认网关（0.0.0.0/0）的路由指向该虚拟网卡，并将该虚拟网卡的优先级（跃点数 Metric）强行调整到比你的物理 WiFi 或有线以太网卡更高的水平；
4. 此时，操作系统内的所有网络流量，无论该软件是否遵循系统代理、也无论它使用的是 TCP、UDP 还是 ICMP 协议，全部被无条件吞入 TUN 虚拟网卡，交由 Clash 核心进行二次分流与加密封装。

2. TUN 模式诱发“没网”的三大死锁机制#

• 死锁机制一：路由回环死锁（Routing Loop）： 这是 TUN 配置最凶险的逻辑灾难。 当 Clash 将全局默认网关修改为虚拟网卡后，操作系统发出的所有流量都必须流经 TUN 网卡。 但是！Clash 自身向机场节点发起加密连接的数据包，也是由本机发出的网络流量！ 如果在配置文件中没有严格通过 auto-detect-interface: true 正确识别出真实的物理出站网卡，或者未将机场节点的公网 IP 排除在 TUN 路由之外，Clash 发往海外机房的底层握手包就会被 TUN 虚拟网卡再次截获，重新塞回 Clash 核心！ 数据包在虚拟网卡和 Clash 核心之间无限原地打转，形成可怕的“路由死循环”，瞬间挤爆本地缓冲区，导致整个电脑对外通信彻底陷入静默死亡！
• 死锁机制二：多重虚拟适配器与 VPN 冲突（TAP/Wintun 争抢）： 如果电脑中同时安装了向日葵远控、深信服 VPN、EasyConnect、VMware Workstation 虚拟网卡或蒲公英组网软件，这些软件各自创建的虚拟网卡可能在 Windows 路由表中争夺 0.0.0.0/0 的默认出口权。 一旦网关跃点数发生错乱，流量被送入了一个没有联网能力的死网卡中，浏览器自然提示断网。
• 死锁机制三：未安装服务模式导致的权限不足： 在 Windows 操作系统中，接管全局网络路由需要系统级的高危特权（Administrator / SYSTEM 权限）。如果客户端仅仅以普通受限用户身份运行，且未安装【服务模式（Service Mode）】，Wintun 驱动可能无法成功绑定底层 NDIS 过滤栈，导致虚拟网卡虽然表面上处于启用状态，但实际上根本无法转发任何数据包。

3. TUN 模式异常的重载与自愈实操#

1
# 1. 检查当前活跃的默认网关路由表，观察是否有多个 0.0.0.0 的冲突项
2
Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric
3

4
# 2. 如果存在死锁，临时禁用并重新启用物理网络适配器（将 "Wi-Fi" 替换为你的真实网卡名称）
5
Restart-NetAdapter -Name "Wi-Fi"
6

7
# 3. 强制重置 IP 路由表至初始状态
8
netsh int ip reset

1. Windows AppContainer 沙箱与本地回环隔离机制#

这不是你的节点不行，而是你撞上了微软 Windows 操作系统极为严苛的安全沙箱防御机制（UWP Loopback Isolation）：

1. 沙箱隔离原则： 从 Windows 8 时代引入、并在 Windows 10/11 中全面强化的通用 Windows 平台（UWP / WinRT）应用程序，全部运行在一个被严格受限的沙箱容器（AppContainer）中；
2. 禁止访问 127.0.0.1： 微软为了防止恶意应用通过本地网络攻击本机上运行的后台服务（如本地数据库或核心系统组件），在内核层面硬性规定：所有处于沙箱内的应用，被绝对禁止向本地环回地址（127.0.0.1 或 localhost）发起任何网络连接！
3. 与系统代理模式的天然死锁： 当我们开启 Clash 的【系统代理】时，Windows 注册表里记录的代理服务器恰恰就是 127.0.0.1:7897！ 普通桌面软件（如传统的 Chrome.exe、WeChat.exe）不受沙箱限制，可以开心地把流量送给 127.0.0.1； 而所有 UWP 应用在尝试向 127.0.0.1 发送代理请求的瞬间，就被 Windows 内核的防火墙安全策略无情拍死在沙箱内部！这就造成了“浏览器能上网，微软商店却断网”的经典假象。

2. 彻底解决 UWP 回环隔离的两种生产级方案#

针对这一顽疾，业界存在两套完全不同的根治路线，均可永久消除此限制：

1
# 批量遍历注册表中的所有 UWP 包并逐一解除回环隔离
2
Get-ChildItem -Path "HKCU:\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Mappings" | ForEach-Object {
3
    $pkg = $_.PSChildName
4
    CheckNetIsolation.exe LoopbackExempt -a -p="$pkg"
5
}
6
Write-Host "所有 UWP 应用程序的回环网络隔离已成功解除！" -ForegroundColor Green

1. 工业级抗断网高可用 YAML 配置范本#

该配置针对 DNS 死锁、Fake-IP 缓存脱节、规则黑洞以及节点突发离线等高频痛点进行了深度防御加固，完美兼容基于 Mihomo 内核的各类现代化客户端：

1
# ===========================================================
2
# 青云宗高可用生产级配置范本 (深度防断网与自愈加固版)
3
# ===========================================================
4

5
# 基础端口定义 (推荐使用新一代标准 7897 端口)
6
port: 7890
7
socks-port: 7891
8
mixed-port: 7897
9
allow-lan: false
10
mode: rule
11
log-level: info
12
ipv6: false
13

14
# -----------------------------------------------------------
15
# 1. 现代化 DNS 模块 (彻底终结 Fake-IP 死锁与 DoH 抢权)
16
# -----------------------------------------------------------
17
dns:
18
  enable: true
19
  listen: 0.0.0.0:1053
20
  ipv6: false
21
  # 推荐使用 fake-ip 模式，搭配高可用过滤列表
22
  enhanced-mode: fake-ip
23
  fake-ip-range: 198.18.0.1/16
24
  fake-ip-filter:
25
    # 排除容易发生回环与特定局域网联机的域名
26
    - "*.lan"
27
    - "*.local"
28
    - "*.localhost"
29
    - "time.*.com"
30
    - "ntp.*.com"
31
    - "*.msftconnecttest.com"
32
    - "*.msftncsi.com"
33
    - "captive.apple.com"
34

35
  # 国内直连与节点域名解析 DNS (纯净无污染 DoH)
36
  default-nameserver:
37
    - 223.5.5.5
38
    - 119.29.29.29
39
  nameserver:
40
    - https://223.5.5.5/dns-query
41
    - https://doh.pub/dns-query
42
  # 海外受限域名的解析备用兜底
43
  fallback:
44
    - https://1.1.1.1/dns-query
45
    - https://8.8.8.8/dns-query
46
    - https://dns.google/dns-query
47

48
# -----------------------------------------------------------
49
# 2. 策略组架构 (自动优选 + 容灾兜底)
50
# -----------------------------------------------------------
51
proxy-groups:
52
  # 主力出口选择器
53
  - name: "🚀 节点选择"
54
    type: select
55
    proxies:
56
      - "⚡ 自动优选"
57
      - "🇭🇰 香港 IPLC 专线 01"
58
      - "🇯🇵 日本 软银 01"
59
      - "🇸🇬 新加坡 专线 01"
60
      - "🇺🇸 美国 CN2 GIA 01"
61
      - "DIRECT"
62

63
  # 高可用自动测速组 (防止单点失效与误判)
64
  - name: "⚡ 自动优选"
65
    type: url-test
66
    url: "https://cp.cloudflare.com"
67
    interval: 300
68
    tolerance: 50
69
    timeout: 5000
70
    lazy: true
71
    proxies:
72
      - "🇭🇰 香港 IPLC 专线 01"
73
      - "🇯🇵 日本 软银 01"
74
      - "🇸🇬 新加坡 专线 01"
75
      - "🇺🇸 美国 CN2 GIA 01"
76

77
  # 漏网之鱼兜底策略组 (避免规则未命中走直连导致断流)
78
  - name: "🐟 漏网之鱼"
79
    type: select
80
    proxies:
81
      - "🚀 节点选择"
82
      - "DIRECT"
83

84
# -----------------------------------------------------------
85
# 3. 智能分流规则 (严防规则黑洞)
86
# -----------------------------------------------------------
87
rules:
88
  # 本地局域网流量绝对直连
89
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
90
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
91
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
92
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
93

94
  # 关键系统测速与 NTP 授时直连
95
  - DOMAIN-SUFFIX,ntp.org,DIRECT
96
  - DOMAIN-SUFFIX,aliyun.com,DIRECT
97

98
  # 常见海外核心服务走代理
99
  - DOMAIN-SUFFIX,google.com,🚀 节点选择
100
  - DOMAIN-SUFFIX,github.com,🚀 节点选择
101
  - DOMAIN-SUFFIX,youtube.com,🚀 节点选择
102
  - DOMAIN-SUFFIX,twitter.com,🚀 节点选择
103
  - DOMAIN-SUFFIX,openai.com,🚀 节点选择
104

105
  # 国内主流 IP 与域名直连
106
  - GEOIP,CN,DIRECT
107

108
  # 最终兜底：未知流量走漏网之鱼策略组 (确保海外冷门站不被直连扼杀)
109
  - MATCH,🐟 漏网之鱼

2. Windows PowerShell 一键排障自愈脚本#

当电脑突然无法打开网页、而 Clash 界面显示已连接时，在 Windows 终端中以管理员身份直接运行以下自动化脚本。该脚本会自动扫描注册表端口、检测端口占用、重置 DNS 缓存并测试连通性：

1
# ===========================================================
2
# 青云宗 Clash 无法上网自动化排障体检工具 (PowerShell 脚本)
3
# ===========================================================
4
Write-Host "======================================================" -ForegroundColor Cyan
5
Write-Host "   Clash 显示连接成功但无法上网 一键自愈体检脚本" -ForegroundColor Cyan
6
Write-Host "======================================================" -ForegroundColor Cyan
7

8
# 1. 检查注册表 WinINet 系统代理状态
9
Write-Host "[1/5] 正在检查 Windows 系统代理注册表设置..." -NoNewline
10
$regPath = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
11
$proxyEnable = (Get-ItemProperty -Path $regPath).ProxyEnable
12
$proxyServer = (Get-ItemProperty -Path $regPath).ProxyServer
13

14
if ($proxyEnable -eq 1) {
15
    Write-Host " [系统代理已开启]" -ForegroundColor Green
16
    Write-Host "      当前指向地址: $proxyServer" -ForegroundColor Yellow
17
} else {
18
    Write-Host " [系统代理已关闭 WARN] -> 请确认是否使用 TUN 模式或手动开启系统代理！" -ForegroundColor Red
19
}
20

21
# 2. 检查本地 7890 与 7897 核心端口监听
22
Write-Host "[2/5] 正在排查本地代理端口监听状态..."
23
$ports = @(7890, 7897)
24
foreach ($p in $ports) {
25
    $conn = Get-NetTCPConnection -LocalPort $p -State Listen -ErrorAction SilentlyContinue
26
    if ($conn) {
27
        $pidNum = $conn[0].OwningProcess
28
        $pName = (Get-Process -Id $pidNum -ErrorAction SilentlyContinue).ProcessName
29
        Write-Host "  - 端口 $p: [正常监听] 占用进程: $pName (PID: $pidNum)" -ForegroundColor Green
30
    } else {
31
        Write-Host "  - 端口 $p: [未监听/空闲]" -ForegroundColor Gray
32
    }
33
}
34

35
# 3. 自动刷新系统 DNS 缓存
36
Write-Host "[3/5] 正在深度清空 Windows 本地 DNS 缓存..." -NoNewline
37
ipconfig /flushdns | Out-Null
38
Write-Host " [已清空 OK]" -ForegroundColor Green
39

40
# 4. 测试本地环回代理与目标网络连通性
41
Write-Host "[4/5] 正在测试本地代理通道传输能力..."
42
$testUrls = @("http://www.baidu.com", "https://cp.cloudflare.com")
43
foreach ($u in $testUrls) {
44
    try {
45
        $sw = [System.Diagnostics.Stopwatch]::StartNew()
46
        $req = [System.Net.HttpWebRequest]::Create($u)
47
        $req.Timeout = 4000
48
        $req.Proxy = New-Object System.Net.WebProxy("127.0.0.1", 7897)
49
        $res = $req.GetResponse()
50
        $sw.Stop()
51
        Write-Host "  - 经 7897 代理访问 $u: 响应成功 (耗时 $($sw.ElapsedMilliseconds) ms)" -ForegroundColor Green
52
        $res.Close()
53
    } catch {
54
        Write-Host "  - 经 7897 代理访问 $u: 失败 ($($_.Exception.Message))" -ForegroundColor Yellow
55
    }
56
}
57

58
# 5. 输出针对性修复建议
59
Write-Host "------------------------------------------------------" -ForegroundColor Gray
60
Write-Host "[5/5] 排查建议：" -ForegroundColor Cyan
61
Write-Host "  1. 若注册表端口为 7890 但监听的是 7897，请将 Windows 代理端口修改为 7897！"
62
Write-Host "  2. 若仅 Chrome 打不开，请检查是否安装了 SwitchyOmega 插件并切换为[系统代理]。"
63
Write-Host "  3. 若浏览器报错安全 DNS 异常，请在 Chrome 设置中关闭[使用安全 DNS]。"
64
Write-Host "======================================================" -ForegroundColor Cyan

案例一：外企工程师电脑装有 SwitchyOmega 导致“节点全绿但办公系统死活打不开”#

案例二：客户端异常崩溃导致 Windows 注册表残留“幽灵代理”死锁#

案例三：开启 TUN 模式后局域网共享断联与 DNS 探测失败事件#

Q1: 为什么彻底关掉 Clash 之后，电脑连国内网站也打不开了？#

这是最让新手恐惧的“关掉反而断网”惨剧。其根本原因在于系统代理处于悬挂状态： 当你以非正常方式关闭 Clash（例如直接在任务管理器中强制结束任务、软件意外闪退或电脑强制关机）时，Clash 未能来得及调用 Windows 的 API 把系统代理开关恢复原状。 此时，Windows 注册表依然坚信本地存在一个 127.0.0.1:7897 代理服务器，并把电脑的所有网络请求都定向送往这个端口。由于 Clash 已经被你关掉了，该端口根本没有程序在监听，操作系统直接把所有请求全部以 ERR_PROXY_CONNECTION_FAILED 重置丢弃！

• 秒级自救法：按 Win + I 打开 Windows 设置 -> 搜索【代理设置】-> 将【手动设置代理】里的开关手动关闭，国内网络瞬间秒级自愈！以后退出 Clash 时，请务必通过右下角任务栏托盘图标右键点击【Quit / 退出】，让软件安全自动复原系统配置。

Q2: 为什么手机开热点给电脑用能正常上网，换家里的 WiFi 就连不上？#

这种典型的网络环境切换差异，指向两个不同的底层病灶：

1. 家庭路由器或光猫开启了运营商 DNS 拦截：部分地区宽带运营商对家庭宽带开启了深度 DNS 抢答与 UDP 53 阻断，导致电脑在 WiFi 下解析节点域名遭遇投毒；而手机蜂窝 5G 网络由于走基站私网隧道，DNS 相对纯净；
2. 局域网 IP 网段与虚拟网卡产生冲突：如果你的家用路由器内网网段恰好也是 198.18.x.x 或者与 TUN 虚拟网卡分配的网段重叠，会导致电脑在 WiFi 下产生致命的路由冲突。将路由器 LAN 口 IP 改为常见的 192.168.1.1 或在客户端配置中更改 fake-ip-range 即可彻底根治。

Q3: 测速延迟显示绿色 45ms，但打开 YouTube 一直转圈圈，怎么看真实速度？#

界面上的绿色 45ms 仅仅代表一次极轻微的 HTTP 204 头信息往返时延（RTT），它只证明“通道是通的”，绝对不代表通道的带宽（吞吐量）有多大！

• 如果节点遭遇了晚高峰国际出口拥塞，丢包率高达 30%，一个几百字节的探测包可能侥幸通过（显示 45ms），但 YouTube 传输 4K 视频所需的海量 TCP 数据流会发生巨量丢包重传，导致视频无限转圈；
• 真实测速方法：在客户端界面右键点击节点选择【真实测速】；或者打开浏览器无痕窗口，直接访问国际公认的测速网站 https://fast.com 或 https://speedtest.net，观察实时跑出来的带宽下行速率（Mbps）。

Q4: 什么是系统代理和 TUN 模式？平时上网应该开哪一个？#

两者的底层技术机制与适用范围有着天壤之别：

• 系统代理（System Proxy）： 工作在操作系统应用层（OSI 第七层）。它仅仅向 Windows / macOS 注册表写入一个 HTTP 代理地址。只有主动遵循系统代理设置的软件（如 Chrome 浏览器、Edge、常规社交软件）才会走代理。特点是轻量、省电、不改变底层路由，日常办公、网页浏览首选推荐开【系统代理】。
• TUN 模式（TUN Mode）： 工作在网络层（OSI 第三层）。它在系统中虚拟出一张物理网卡，把电脑的所有网络流量（包括游戏联机、Git 命令行、终端 SSH、微软商店 UWP 应用等）强行捕获并分流。玩外服游戏、使用命令行开发工具、或应用商店无法联网时，强烈推荐开启【TUN 模式】，详见 Clash TUN 模式与系统代理深度对比。

Q5: 为什么只有 Telegram 或 Discord 连不上，其他海外网页都正常？#

某些特定海外即时通讯软件打不开，通常是由于以下两点引起的针对性阻断：

1. UDP 流量被丢弃：Telegram 的语音/视频通话以及 Discord 的底层通信重度依赖 UDP 协议。如果你的节点服务商不支持 UDP 转发，或者客户端中关闭了 UDP 开关（配置中 udp: false），这些软件就会卡在“正在连接（Connecting）”状态；
2. 软件自身代理设置覆盖：检查 Telegram 客户端的【设置】->【数据与存储】->【连接类型】。如果此前手动在 Telegram 内部配置了无效的 MTProto 代理或错误的 SOCKS5 端口，请将其改回“使用系统代理”或直接禁用软件内部代理。

Q6: 打开 Clash 之后微信视频通话断断续续或局域网投屏断开了，怎么解决？#

这属于典型的“分流规则漏判与局域网误杀”：

• 微信视频通话与电视局域网投屏依赖内网私有广播协议与国内直连通道。如果在【规则模式】中未对国内常用应用配置分流保护，或者开启了全局模式（Global），微信的通话流量会被强行打包绕道海外节点再折返回国，造成极高的延迟与卡顿；
• 根治方法：确保客户端处于【规则模式（Rule）】，并在配置文件中确认包含国内直连规则：GEOIP,CN,DIRECT，同时确保局域网私网段（192.168.0.0/16）严格设为 DIRECT，详见 Clash 规则模式与智能分流最佳实践。

Q7: 为什么 Edge 浏览器频繁报错 ERR_PROXY_CONNECTION_FAILED？#

Edge 浏览器作为 Windows 深度集成的核心组件，对系统的网络栈状态最为敏感：

1. 核对 Windows 设置中的【代理】端口是否与正在运行的 Clash 客户端端口完全对齐（详见诱因一）；
2. 检查 Edge 内部是否开启了【启动增强（Startup boost）】导致后台常驻了死锁的旧网络配置。可在 Edge 设置中搜索“启动增强”并将其关闭，彻底重启 Edge 即可恢复。

Q8: 杀毒软件（火绒/360/Windows Defender）拦截代理流量时会有什么底层特征？#

当杀毒软件介入拦截时，通常表现出以下极具欺骗性的特征：

• 客户端本身没有任何报错，日志面板也显示一切就绪，但在发起网络连接时，日志中会瞬间刷屏 operation not permitted、access is denied 或 read: connection reset by peer；
• 在浏览网页时，可能会弹出杀毒软件拦截恶意发包的气泡提示；
• 根治方案：打开杀毒软件的【防护中心】->【信任区 / 排除项】，将 Clash 的安装主目录、clash-meta.exe、mihomo.exe 以及数据缓存目录完整添加到排除扫描白名单中。