故障排查 预计阅读 10 分钟

Clash 显示已连接却打不开网页:八步排查顺序清单

从订阅是否过期、节点可用性、系统代理是否生效,到规则模式、DNS 与本地端口占用,按由浅入深的顺序逐项定位断网原因。

“已连接”通常只能说明客户端已开启某个开关，或内核已经启动，并不代表浏览器请求已成功经过节点。排查时需要分清三层：电脑本身能否联网、请求是否进入 Clash、进入后是否走向可用出口。不要同时更换节点、修改 DNS 和重装客户端，否则很难判断哪一步产生了作用。

先备份当前配置，记下客户端名称、内核版本、混合端口与原来的代理模式。下面示例使用 127.0.0.1:7890，实际操作必须以客户端显示的端口为准。每完成一步，用同一个网址重新测试。

第一步：关闭代理，确认基础网络正常

先关闭客户端里的“系统代理”和“TUN 模式”，保留客户端窗口便于随后恢复。如果电脑还运行着其他 VPN、代理扩展或加速工具，也先暂停，避免两套程序同时接管网络。此时访问平时能够直接访问的网站，确认不是 Wi-Fi、宽带或登录认证的问题。

  1. 检查电脑是否获取到有效的局域网地址与默认网关，而不只是显示 Wi-Fi 已连接。
  2. 若处于酒店、机场等公共网络，先完成网络要求的网页登录认证，不在异常证书页面输入账号。
  3. 让手机在同一 Wi-Fi 下关闭移动数据后测试；必要时再让电脑连接手机热点进行对照。

如果关闭代理仍无法打开普通网页，先处理基础网络。若换到手机热点后立即恢复，重点检查原网络的认证、DNS 或访问限制。不要把所有问题都归因于订阅节点，也不要用一个网站打不开就判定整条网络中断。

第二步：检查订阅有效期与当前启用配置

进入客户端的“订阅”或“配置”页面，查看当前选中的配置名称、最近更新时间和更新结果。不同客户端菜单名称会有差异，关键是确认“已下载的配置”确实被启用，而不是只存在于列表中。订阅更新成功也不代表套餐仍有流量。

  • 核对套餐：到订阅服务方的账户页面查看到期时间、剩余流量和设备限制；界面未显示流量时，不要推断为无限流量。
  • 手动更新一次：观察是否出现 HTTP 401、403、404 或超时。401、403 可能与授权或访问策略有关；404 可能是地址失效，需要结合服务方说明确认。
  • 确认加载结果：更新后检查节点数量与策略组是否存在；日志出现 YAML 解析错误时，先修复配置，不能继续把旧配置当成新配置测试。

订阅链接一般含有访问凭据，不应贴到公共讨论区或截图中。若订阅下载失败，但已有配置仍能正常加载，可以先用已有节点继续定位；下载订阅与实际代理连接并不一定使用同一条网络路径。

第三步：测试节点，而不是只看延迟数字

打开“代理”页面，找到当前策略组实际选中的节点。组名里写着“自动选择”，也应继续确认组内最终使用的是哪个出口。运行一次客户端提供的延迟测试，然后选择另一个节点重复访问同一网站。

延迟通过，不等于网页可用

延迟测试通常访问配置中的测试地址，只证明那个目标在当时可达。某个节点可能能够通过测试，却无法访问特定网站；反过来，测试地址受限也可能导致节点显示超时。不要把一个毫秒数字当作完整的可用性结论。

  1. 固定一个目标网址，先测试节点 A，再测试节点 B，其他设置不变。
  2. 查看日志是否出现连接超时、认证失败、TLS 握手失败或连接被重置。
  3. 若只有单个节点失败，优先更换该节点；若所有节点都失败，再继续检查本机代理入口与配置。

如果更换节点后恢复，先保留可用节点，不急着修改 DNS。认证错误通常需要核对订阅或节点参数；TLS 错误还可能与系统时间、服务端证书或链路有关，不能通过关闭证书验证来当作通用修复。

第四步：验证系统代理是否真的生效

浏览器请求必须先到达本机代理端口，节点才能发挥作用。Windows 11 可以进入“设置”→“网络和 Internet”→“代理”，检查手动代理地址和端口。macOS 可以进入“系统设置”→“网络”→当前网络的“详细信息”→“代理”，核对 HTTP 与 HTTPS 代理项。客户端开启系统代理后，应以系统实际显示的结果为准。

浏览器扩展可能覆盖系统设置，Firefox 也可单独选择代理方式。Firefox 的检查路径是“设置”→“常规”→“网络设置”→“设置”；排查时可选择“使用系统代理设置”，并暂时停用会改变代理的扩展。

用显式代理请求隔离问题

下面的命令绕过“系统代理有没有被浏览器采用”这一变量，明确要求 curl 连接本机 HTTP 代理。Windows 使用 curl.exe，macOS、Linux 可将命令名改为 curl。目标网站仅用于测试，不代表必须能够访问。

curl.exe --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
  • 返回目标站 HTTP 响应：说明这次显式代理请求已到达目标。即便返回 403，也要与本机连接失败区分。
  • 仅出现 200 Connection established：这可能只是代理隧道建立成功，还要看后续是否收到目标站响应。
  • 提示无法连接 127.0.0.1：优先检查端口与内核运行状态，直接转到第七步。

若命令成功而浏览器失败，优先检查浏览器代理设置、扩展与缓存连接，不必先重写整份配置。

第五步：用全局模式对照规则模式

切换到“全局”模式，并在全局策略中明确选择一个已测试的节点，再打开同一网址。如果全局模式能访问，而规则模式失败，说明应检查规则匹配、策略组选择或直连路径，而不是直接判断节点失效。测试结束后恢复原来的规则模式。

在连接记录里查看实际去向

打开“连接”页面后刷新网页，查找目标域名对应的连接。重点看匹配规则、策略链和最终出口。某个规则命中 DIRECT 时，请求会直连；命中 REJECT 时，请求可能被直接拒绝。规则通常按从上到下的顺序匹配，前面的宽泛规则可能让后面的精细规则失去作用。

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

这段仅展示规则顺序：example.com 及其子域名直连，其他请求交给 PROXY。它不是完整配置，且只有已经定义名为 PROXY 的节点或策略组时才可使用。不要把这段直接覆盖到订阅配置中；订阅更新还可能覆盖手动改动，应优先使用客户端提供的覆写机制。

第六步：区分 DNS 解析失败与代理连接失败

浏览器显示“找不到服务器”、日志出现 no such host 或解析超时，才更值得沿 DNS 方向排查。日志明确显示连接节点服务器失败时，还要检查节点服务器域名是否能解析，不能只盯着目标网站的 DNS。

  • 先查本机解析：在终端执行 nslookup example.com，观察是否超时及使用了哪个解析服务器。这只能说明该查询路径的结果，不等于测到了 mihomo 内部 DNS。
  • 再查内核日志：确认是节点域名解析失败，还是目标域名解析失败，并查看 DNS 上游是否可达。
  • 检查浏览器安全 DNS：浏览器自带的 DoH 可能形成另一条解析路径。临时关闭后对照测试，记录结果，再决定是否保留。

使用 fake-ip 模式时，客户端可能向应用返回 198.18.0.0/16 范围内的映射地址；在采用该地址池的配置中，这不等于解析遭到破坏。需要继续确认对应流量是否进入内核，以及是否能恢复到正确的目标域名。

不要一次替换全部 DNS 上游，也不要把开启 fake-ip 当成必然修复。DoH 地址本身也需要可达；错误的引导解析或代理依赖可能形成循环。每次只改一项，并保留原配置以便回退。

Windows 在修正配置后可以执行 ipconfig /flushdns 清理系统 DNS 缓存，再重启浏览器测试。缓存清理只能移除旧记录，无法修复不可达的上游服务器。

第七步：检查 7890 端口与内核启动日志

mixed-port 可以在同一监听端口接受 HTTP 与 SOCKS5 代理请求。7890 是常见示例，不是所有客户端的固定值。如果内核没有启动，界面开关保持开启也无法代替真实的监听服务。

查看哪个进程占用了端口

# Windows：在命令提示符中执行
netstat -ano | findstr :7890

# macOS：查看 TCP 监听进程
lsof -nP -iTCP:7890 -sTCP:LISTEN

# Linux：查看 TCP 监听信息
ss -ltnp 'sport = :7890'

Windows 输出中需要找到本地端口为 7890 且状态为 LISTENING 的行，再将最后一列 PID 与任务管理器“详细信息”中的进程对应。仅看到远端端口或已经建立的连接，不代表本机代理正在监听。Linux 查看其他用户的进程信息时可能需要额外权限。

  • 端口没有监听：查看日志中的配置解析错误、启动失败或权限提示。
  • 被其他程序占用：确认进程身份后退出冲突程序，或把客户端混合端口改为未占用的端口，例如 7891。
  • 修改端口以后：重新启用系统代理，并更新浏览器手动设置及测试命令，避免仍然连接旧端口。

不要随意结束不认识的系统进程，也不要为了本机访问打开“允许局域网”。浏览器连接 127.0.0.1 不需要 allow-lan；开放局域网监听反而会扩大可访问范围。

第八步：隔离 TUN、其他 VPN 与安全软件

当显式代理测试成功，但开启 TUN 后访问失败，重点检查虚拟网卡、路由和 DNS 接管。TUN 用于接管更多应用流量，不是系统代理失败时必须开启的补丁。Clash 不同分支的能力也有差别，以下排查应以当前客户端使用的 mihomo 内核及其界面选项为准。

  1. 建立基线：关闭 TUN，仅开启系统代理，确认浏览器是否可用。
  2. 单独测试 TUN：关闭系统代理后再开启 TUN，按客户端提示安装服务或授予必要权限，观察内核日志中的网卡与路由错误。
  3. 暂停冲突接管：暂时断开其他 VPN、游戏加速器和会修改路由的工具；企业设备应先征询管理员。
  4. 检查安全软件记录：寻找具体的程序拦截或网络阻止事件，只针对可信客户端设置必要规则，不要直接长期关闭防火墙。

如果系统代理正常而 TUN 异常，可以先保留系统代理方式使用，再处理权限、路由冲突或 DNS 劫持设置。若只有某个应用失败，应检查该应用是否遵循系统代理、是否使用 UDP，以及所选节点是否支持对应流量，而不是认定全机断网。

仍未恢复：整理一份可复现记录

求助时提供系统版本、客户端与内核版本、故障出现时间、实际监听端口，以及“直连、显式代理、规则模式、全局模式、TUN”各自的测试结果。日志只截取一次失败前后的相关行，并隐藏订阅地址、访问令牌、节点凭据和个人网络信息。

八步排查的目标是找到最小故障范围：直连失败先修网络，显式代理失败查端口与节点，全局成功而规则失败查分流，只有 TUN 失败查接管链路。恢复后回到规则模式，撤销临时调试设置，再确认日常使用的网站与应用都能正常连接。

下载客户端