Clash 显示已连接却打不开网页：订阅、端口与系统代理逐项排查清单

先分清“已连接”代表哪一段链路

Clash 客户端显示运行中、节点显示延迟、系统显示 VPN 已连接，并不代表浏览器到目标网站的整条链路已经可用。运行中通常只表示内核进程启动；节点延迟测试通常只访问配置中的测试地址；Android 的 VPN 标识则主要说明本地 VPN 服务已经建立。网页还要经过应用代理设置、本地监听端口、分流规则、节点出站与目标站点，任意一段异常都可能让页面一直转圈。

下面以 Clash 兼容客户端为范围；使用 Clash Meta（现称 mihomo）内核时，也可按同样顺序排查。不同客户端的开关名称与默认端口不完全相同，示例中的 7890 只是待核对的本地混合端口，不应直接当作当前设备的实际值。

1. 记录当前配置名称、选中节点、代理模式、HTTP 或混合端口，以及系统代理和 TUN 开关状态。
2. 先暂停其他代理客户端和 VPN。桌面端先关闭 TUN，仅用系统代理排查，减少路由与 DNS 接管变量。
3. 分别打开一个原本可直连的网站和一个需要当前代理线路的网站，记下浏览器完整错误码。
4. 每次只改一项，再访问同一个地址。确认有效后保留，无效则恢复，避免同时修改端口、DNS 和规则。

第一步：检查订阅是否过期、配置是否真正加载

订阅更新成功，不等于节点可用

进入客户端的订阅或配置页面，核对当前启用的配置，而不只是列表里最近更新过的那一项。更新返回成功，说明订阅内容可以下载；它不能证明账户仍有可用流量，也不能证明节点服务器当前能够连接。反过来，订阅更新失败时，客户端可能继续使用缓存配置，因此列表里仍然会显示节点。

• 核对账户：到订阅提供方的账户页面查看到期时间、剩余流量及设备限制，不把客户端中的缓存数值当作唯一依据。
• 核对响应：日志出现 HTTP 401 或 403 时，检查授权、账户状态和服务方访问限制；出现 404 时，检查地址是否被撤销或复制不完整。状态码本身不能单独确定原因。
• 核对格式：若出现 YAML 解析错误，可能下载到了登录页、错误页，或内容并非当前客户端支持的 Clash 配置。
• 核对内核：配置包含当前内核不支持的协议或字段时，应选择提供方明确支持的订阅格式，或使用兼容内核，不能只靠反复导入解决。

用固定节点排除自动选择干扰

在当前策略组内手动选择一个节点，并确认请求实际经过该组。先测试节点 A，再测试节点 B，每次访问同一网站。延迟测试通过而网页失败，可能是测试站点可达、目标站点不可达，也可能是目标规则走了另一个策略组。需要同时查看连接记录中的出站链路，不能仅凭延迟数字判断。

如果所有节点均失败，但直连网站正常，优先检查订阅账户、节点地址解析和节点端口连通性。不要把订阅链接提交到陌生在线转换或检测页面；链接往往包含访问凭据，分享截图时也应遮住令牌和二维码。

第二步：确认混合端口监听，排除端口占用

系统代理指向 127.0.0.1:7890，但内核实际监听 7897，浏览器就无法通过该入口转发。另一个常见情况是旧客户端仍占用端口，新客户端界面已启动，内核却因绑定失败没有正常提供代理服务。先看当前运行配置中的 mixed-port 或 HTTP port，再看日志是否有 address already in use。

在 Windows PowerShell 中执行以下命令，检查示例端口 7890。如果你的端口不同，先替换命令中的数字。

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

没有监听结果时，检查内核是否启动、配置是否加载失败；查到进程 ID 后，用下面的命令确认进程归属。不要直接结束不认识的进程，也不要为了修复本地代理而把监听地址改成所有网卡。

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

绕过浏览器，直接测试代理入口

使用 Windows 自带的 curl.exe，明确指定本地 HTTP 代理。macOS 或 Linux 可用 curl 执行同样的参数。下面的地址仅用于观察 HTTPS 请求是否能完成，不是节点速度基准。

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

HTTPS 请求中只看到 200 Connection established，不一定表示目标页面已成功返回；还要看后续 TLS 握手与目标响应。目标返回 403 或 429 也不等于代理断开，可能是站点访问策略或频率限制。

第三步：检查系统代理与浏览器设置是否一致

如果显式代理测试成功，浏览器却打不开，重点检查浏览器是否真的使用同一个入口。系统代理不是全设备透明接管，应用可以忽略它，也可以被扩展、PAC 脚本或自己的代理设置覆盖。

• Windows 11：打开「设置」→「网络和 Internet」→「代理」，查看手动代理地址、端口以及是否启用了设置脚本。使用客户端系统代理开关时，应核对这里的结果，而不是只看托盘状态。
• macOS：打开「系统设置」→「网络」→ 当前使用的网络服务 →「详细信息」→「代理」。确认 HTTP、HTTPS 或自动代理配置与当前方案一致，不要同时保留失效的 PAC 地址。
• Firefox：打开「设置」→「常规」→「网络设置」→「设置」，核对是否选择使用系统代理设置，或手动填写了其他代理。
• Android：通常通过客户端 VPN 服务接管流量，不能照搬桌面系统代理步骤。检查每应用代理列表，确认浏览器没有被排除，并留意其他 VPN 是否抢占连接。

暂时停用浏览器代理扩展后重试，并完全退出浏览器再启动，以减少旧连接复用的影响。Windows 中运行 netsh winhttp show proxy 查看的是 WinHTTP 代理，不代表所有浏览器使用的系统代理状态，不能把它作为唯一证据。

第四步：核对规则命中与实际出站策略

在客户端切换到规则模式后，打开“连接”或对应的请求列表，再访问一次失败的网站。重点记录目标域名、命中的规则、所选策略组和最终节点。Clash 的规则通常按顺序匹配，前面的宽泛规则可能抢先命中，使后面的域名规则没有机会生效。

1. 确认目标请求出现在连接列表。没有记录时，优先怀疑应用未走代理、连接被复用或被其他网络工具接管。
2. 如果最终出站是 DIRECT，核对该网站是否应直连，以及域名规则是否遗漏了登录、图片或接口域名。
3. 如果最终出站是 REJECT，检查拦截规则是否误伤，不要直接删除全部规则。
4. 如果走了代理组，展开组内选择，确认不是选中了不可用节点或 DIRECT。
5. 短暂切到全局模式，明确选定已测试的节点，访问同一地址；完成对照后恢复规则模式。

若全局模式能打开、规则模式不能打开，应继续查看两次请求的实际出站差异，而不是把“全局能用”当作永久解决方案。全局模式会改变大量连接的出口，可能影响本地服务、工作网络和账户登录。若两种模式均失败，则继续回查节点和解析，不必反复添加域名规则。

自定义规则应通过客户端支持的覆写或合并机制保存。直接修改订阅生成的文件，下一次更新可能覆盖修改。先保留最小的针对性规则，再验证页面所需的接口域名，避免用过宽的后缀规则改变无关流量。

第五步：区分 DNS 污染、解析失败与 Fake-IP 正常行为

浏览器显示解析失败，不一定就是 DNS 污染。上游 DNS 超时、加密 DNS 服务器不可达、节点域名无法解析、浏览器安全 DNS 与客户端解析路径不同，都可能产生相似现象。先查看日志中失败的域名是目标网站，还是代理节点自身的域名。

先明确当前查询走哪条路径

在 Windows 中可用下面的命令观察系统默认 DNS 的查询结果。它只反映该次系统查询，不自动代表浏览器、Clash 内置 DNS 或远端代理的解析结果。

nslookup example.com
ipconfig /flushdns

第二条命令清除 Windows DNS 客户端缓存，不会同时清除浏览器缓存或内核 DNS 缓存。更改 DNS 配置后，应根据客户端能力重新加载配置或重启内核，并重新建立浏览器连接。不要仅因为两台 DNS 返回不同 IP 就认定发生污染，CDN 调度本来就可能返回不同结果。

Fake-IP 返回虚拟地址，不等于域名被解析错误

使用 Fake-IP 模式时，客户端可能返回 198.18.0.0/16 范围中的虚拟地址，具体范围取决于配置。它用于保存域名与连接的映射，不是目标网站的真实服务器地址。单独看到这个地址不能判为故障；应检查该连接是否被正确接管，以及内核是否保有对应映射。

• 若只有某个应用异常，先确认它是否使用独立 DNS、缓存了旧的 Fake-IP 地址，或绕过了代理。
• 若日志显示上游解析超时，检查 nameserver 中的服务器是否能从当前网络访问，不要一次加入大量来源不明的解析地址。
• 若节点使用域名，检查节点域名解析是否形成“先连节点才能访问 DNS、先解析才能连节点”的循环；mihomo 可按配置需要使用 proxy-server-nameserver 指定节点域名解析器，旧内核兼容性需单独确认。
• 若浏览器开启安全 DNS，可暂时关闭做一次对照；测试结束后按实际需求恢复，并记录是哪条解析路径导致差异。

更换 nameserver 或 fallback 前，先保留原配置。fallback 是否启用及结果如何参与选择，取决于内核与过滤配置；它不是简单的“第一个失败才调用第二个”。遇到解析故障，应依据日志与当前内核文档修改，而不是把整块 DNS 配置替换成不明示例。

第六步：仅在 TUN 开启时失败，检查路由与 DNS 接管

如果关闭 TUN、使用显式代理时正常，开启 TUN 后失败，问题范围已缩小到虚拟网卡、权限、路由、DNS 接管或与其他 VPN 的冲突。TUN 能接管哪些连接取决于路由、排除项及平台实现，不能将“开启 TUN”理解成所有应用必然全部走代理。

1. 确认客户端已获得当前平台要求的服务或网络权限，查看启动日志是否有创建设备、添加路由失败。
2. 暂停其他 VPN、加速器与重复运行的 Clash 客户端；工作设备上的安全软件和企业 VPN 应先按管理要求处理。
3. 检查是否有自定义路由排除或每应用绕过设置，确认失败应用和目标地址没有被排除。
4. 核对 dns-hijack 是否与当前内核配置一致。针对传统 DNS 端口的接管，并不能直接解密应用自身的 HTTPS DNS 请求。
5. 恢复单一、可解释的接管方案后重测，避免在故障状态下同时开启系统代理、多个 VPN 和复杂路由覆写。

如果小页面正常、较大的页面或下载才停住，在排除节点和站点因素后，再考虑 MTU 或路径问题。不要把修改 MTU 当作第一步；先保存现值，只调整一个参数，比较相同请求，并在没有改善时恢复。

整理排查结果：用最小证据定位问题

完成以上步骤后，应能区分是配置无效、本地入口未监听、应用绕过系统代理、规则误判，还是节点与解析链路异常。仍需求助时，提供下面这些信息，比只发送“已连接打不开”的截图更有判断价值。

• 操作系统、客户端名称及准确版本、内核名称及版本，可从客户端“关于”页面或启动日志读取。
• 实际监听端口、系统代理与 TUN 状态，以及失败是否只发生在某个浏览器。
• 同一网址在显式代理、规则模式、全局模式下的结果，以及测试的具体时间。
• 失败请求命中的规则、策略组和对应日志错误，遮住账号、订阅令牌及敏感地址。

最后恢复临时更改的代理模式、浏览器安全 DNS 与日志级别，只保留已经验证有效的修改。需要重新安装客户端时，先备份本地覆写和规则；重新安装本身不能修复订阅到期、节点失效或网站拒绝访问。