故障排查 预计阅读 12 分钟

Clash 已连接代理却打不开网页?逐项排查清单

从系统代理开关、端口占用、节点可用性到 DNS 污染与规则命中,按顺序逐项定位「连上了却上不了网」的真实原因,每一步给出验证方法与对应的修复动作。

客户端显示“已连接”、节点旁出现延迟数字，只能证明 Clash 核心已经启动，或者一次测试请求得到了响应。浏览器能否打开网页，还取决于应用流量是否进入监听端口、规则是否选择了正确出口、DNS 是否返回可用结果，以及所选节点能否完成真实的 TLS 连接。排查时不要连续切换多个开关，应从流量入口开始逐层验证。

第一步：区分网络故障与代理链路故障

先完全退出 Clash，而不是只关闭窗口。确认系统代理已经恢复为关闭状态，然后访问本地网络和普通网站。如果直连状态同样无法打开网页，问题通常位于 Wi-Fi、网线、路由器、认证门户或运营商连接，不应继续修改 Clash 配置。

执行三个基础测试

  1. 打开路由器管理地址，例如 192.168.1.1。能够打开说明设备到局域网网关的路径正常。
  2. 在终端执行 ping 1.1.1.1。部分网络会丢弃 ICMP，因此超时不能单独作为断网结论，但持续收到回复可以确认基础 IP 路径可用。
  3. 执行 nslookup example.com。若 IP 地址可达而域名解析超时，应先处理系统 DNS 或路由器 DNS。

酒店、机场与校园网经常要求在网页中完成认证。连接此类网络后，可暂时关闭代理并访问一个普通 HTTP 页面触发认证门户。完成认证再启动 Clash。认证尚未完成时，节点延迟偶尔也可能显示数值，但后续 HTTPS 请求会被网关拦截。

第二步：确认系统代理确实指向 Clash 端口

“系统代理”负责把遵循操作系统代理设置的浏览器和应用送入 Clash。核心运行而系统代理关闭时，日志里通常看不到浏览器的新连接，网页也会继续直连。以 Clash Verge Rev 2.x 为例，检查路径是「设置」→「系统设置」→「系统代理」；旧版 Clash for Windows 0.20.39 则在主界面检查 System Proxy。不同客户端的文字略有差异，但最终都应写入本机回环地址与实际监听端口。

核对监听地址与端口

常见配置使用 mixed-port: 7890，它同时接受 HTTP 与 SOCKS5 请求；也有配置分别使用 port: 7890 和 socks-port: 7891。这些只是常见值，必须以当前配置和客户端设置页显示的端口为准。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

macOS 15 可在「系统设置」→「网络」→ 当前网络接口 →「详细信息」→「代理」查看 Web 代理与安全 Web 代理。服务器通常应为 127.0.0.1，端口应与 Clash 的 HTTP 或混合端口一致。Windows 11 可在「设置」→「网络和 Internet」→「代理」查看手动代理；如果这里残留了已经退出的其他客户端端口，浏览器请求会直接失败。

绕过浏览器直接测试本地代理

假设混合端口为 7890，在 macOS 或 Linux 终端执行：

curl -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204
curl -I --socks5-hostname 127.0.0.1:7890 https://example.com

Windows PowerShell 应明确调用 curl.exe，避免命令别名产生不同参数行为：

curl.exe -I -x http://127.0.0.1:7890 https://cp.cloudflare.com/generate_204

若立即提示连接 127.0.0.1 被拒绝，说明端口未监听、端口填写错误或核心已经停止。若请求进入日志后才超时，则本地入口正常，应继续检查节点、DNS与规则。

第三步：排除端口占用和核心启动异常

多个代理客户端同时启动时，最常见的冲突是都尝试监听 7890。界面进程可能仍然正常显示，但核心日志会出现 address already in use、bind failed 或监听失败信息。此时系统代理即使指向 127.0.0.1:7890，该端口也可能属于另一个程序。

查看端口归属

macOS 与 Linux 可执行：

lsof -nP -iTCP:7890 -sTCP:LISTEN
lsof -nP -iTCP:9090 -sTCP:LISTEN

Windows 可在 PowerShell 执行：

Get-NetTCPConnection -State Listen -LocalPort 7890
Get-Process -Id (Get-NetTCPConnection -State Listen -LocalPort 7890).OwningProcess

7890通常是代理入口，9090常用于外部控制接口，两者用途不同。不要把系统代理误填成控制端口。确认冲突后，退出旧进程，或把当前配置的混合端口改为例如 7897，随后同步更新系统代理。只改 YAML 而没有更新操作系统代理，会形成新的端口不一致。

第四步：验证节点能否承载真实网页请求

延迟测试不等于完整可用性。客户端可能只向测试 URL 发起一次较小的 HTTP 请求，而网页加载还涉及 DNS、TLS 1.3、HTTP/2、多个域名和持续数据传输。一个节点显示 82 ms，仍可能存在高丢包、出口拥塞、证书握手中断或目标网站限制。

按顺序切换出口

  1. 将代理模式临时设为「全局」，选择一个明确的节点，不要选择自动策略组。
  2. 访问 https://cp.cloudflare.com/generate_204，正常结果通常是 HTTP 204。
  3. 再打开两个不同网络运营方的网站，避免单个站点维护导致误判。
  4. 切换到另一个地区、另一条线路的节点重复测试。如果只有一个节点失败，优先判断为节点侧问题。

如果全部节点都在连接阶段超时，检查订阅是否过期、节点域名是否能解析、设备时间是否准确，以及当前网络是否限制对应协议。系统时间偏差数分钟就可能让 TLS 证书验证失败。macOS 可在「系统设置」→「通用」→「日期与时间」开启自动设置；Windows 11 可在「设置」→「时间和语言」→「日期和时间」执行立即同步。

日志中的 connection refused 通常表示远端端口拒绝连接；i/o timeout 更接近链路超时；TLS handshake timeout 表示 TCP 之后的加密握手没有按时完成。三类信息对应的故障层不同，不宜统一归因于客户端。

第五步：检查规则命中与代理组选择

规则模式下，请求进入 Clash 后仍可能被分配到 DIRECT、REJECT 或错误的策略组。典型现象是国内网页正常、特定外部网站失败，或者首页可以打开而图片、登录接口与验证码无法加载。网页往往依赖多个域名，仅观察地址栏域名不足以确认完整规则。

使用连接记录定位实际出口

打开客户端的「连接」或 Connections 页面，刷新目标网页，查看域名对应的规则、规则载荷与代理链。mihomo 内核通常会记录命中的规则类型和最终链路，例如：

example.com
Rule: DomainSuffix
Payload: example.com
Chains: Proxy Group → Singapore 01

如果目标请求命中 MATCH → DIRECT，说明前面的规则没有覆盖该域名；如果命中某个代理组但该组当前选择了失效节点，应进入代理组重新选择。若命中 REJECT，先确认它是否属于广告过滤或隐私规则集，避免直接删除整组规则。

临时切到全局模式后恢复正常，基本可以把范围收敛到规则或策略组。修复时应添加精确的 DOMAIN、DOMAIN-SUFFIX 或合适规则集，而不是长期保留全局模式。例如：

rules:
  - DOMAIN,api.example.com,PROXY
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

规则按从上到下的顺序匹配，第一条命中后通常不再继续。宽泛的 DOMAIN-SUFFIX 或 GEOIP 规则放置位置不当，可能提前截获后续精确规则。调整后应重新加载 Profile，并在连接记录中确认新规则确实生效。

第六步：定位 DNS 污染、Fake-IP 与 IPv6 问题

能够访问 IP 地址却打不开域名，或者浏览器长时间停留在“正在解析主机”，通常应检查 DNS。Clash Meta，也就是 mihomo，常用 fake-ip 或 redir-host 两种增强模式。Fake-IP 会从保留地址段返回映射地址，再由内核还原域名；如果应用流量没有经过 Clash，却使用了 Clash 的 Fake-IP 结果，请求就可能无法到达真实目标。

比较系统解析与代理解析

nslookup example.com
dig example.com
curl -v -x http://127.0.0.1:7890 https://example.com

若 nslookup 返回 198.18.0.0/16 范围内的地址，这通常是 Fake-IP 映射，并不代表真实公网地址。此时要确认系统代理或 TUN 仍在工作。关闭 Clash 前，应先关闭系统代理并清理受客户端管理的 DNS 设置，避免系统继续把查询发送到已经停止监听的本地 DNS 端口。

mihomo 配置可使用独立的默认解析器处理上游 DNS 域名，并通过加密 DNS 降低传统 UDP 查询受到干扰的概率。示例字段如下，具体服务器应结合所在网络测试：

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

如果问题只在部分支持 IPv6 的网站出现，可暂时关闭配置中的 IPv6 功能进行对照测试。设备获得了 IPv6 地址但网络出口不稳定时，应用可能优先尝试不可用的 AAAA 结果，等待超时后才回退 IPv4。确认原因后应修复路由器或上游 IPv6，而不是把每次超时都归入 DNS 污染。

第七步：TUN 模式开启后仍无法上网

TUN 模式会建立虚拟网络接口，覆盖不遵循系统代理的应用和部分 UDP 流量。它需要系统服务、管理员权限、路由表与 DNS 劫持协同工作。界面开关显示开启，不代表虚拟接口和路由已经成功创建。

先判断是否属于 TUN 独有故障

  1. 关闭 TUN，只开启系统代理。
  2. 用浏览器访问测试页面，并观察连接记录。
  3. 若系统代理可以上网、TUN 开启后全局断网，重点检查服务安装、虚拟网卡、路由冲突与防火墙。
  4. 若两种模式都失败，返回端口、节点和 DNS 步骤，不要反复重装 TUN 服务。

在 Clash Verge Rev 一类客户端中，可检查「设置」→「服务模式」或「设置」→「系统设置」中的服务状态。升级客户端后若服务版本与界面程序不一致，可先停止服务，再通过客户端提供的服务管理入口重新安装。Windows 还应在「设备管理器」→「网络适配器」确认虚拟适配器状态，并检查其他 VPN、虚拟机网络与安全软件是否同时修改路由。

macOS 上可用 route -n get default 查看默认路由，用 ifconfig 查看虚拟接口是否存在；Windows 可执行 route print 与 Get-NetAdapter。如果退出客户端后虚拟路由仍然保留，先重启相关服务或操作系统，再进行下一轮测试。不要在不清楚目标网段的情况下批量删除路由。

最后一步：按日志结果归类，不要直接重装

重装客户端只能替换程序文件，无法自动修复失效节点、错误订阅规则、系统残留代理或上游 DNS。完成前面的逐层测试后，应能把故障归入一个明确范围。下面的现象与处理方向可作为最终核对。

观察结果 主要范围 下一步动作
Clash 退出后仍不能直连 本地网络或系统网络设置 检查网关、认证门户、系统 DNS 与路由器
访问 127.0.0.1:7890 被拒绝 核心或监听端口 核对端口、核心日志和端口占用进程
代理请求进入日志后超时 节点或上游链路 更换协议、地区或线路不同的节点
全局模式正常，规则模式失败 规则与策略组 查看 Connections 的命中规则和最终链路
IP 可访问，域名解析失败 DNS 检查本地 DNS 监听、Fake-IP 与上游解析器
系统代理正常，TUN 模式断网 服务、虚拟接口或路由 检查服务权限、适配器状态和路由冲突

最有效的排查顺序是：先确认直连网络，再验证本地代理端口，然后检查节点、规则、DNS，最后处理 TUN。每一步都应同时观察终端结果和客户端连接日志。只要能确认请求在哪一层消失，就能避免无目的地切换节点、重置配置或反复安装客户端。

下载客户端