Clash 已连接却打不开网页：从端口到规则的逐项检查清单

先区分：内核运行、节点测速与网页连通

Clash 客户端显示“已连接”或服务正在运行，只能说明某个运行环节已启动。浏览器请求仍需经过应用代理设置、本地监听端口、规则选择、节点连接和目标网站。节点测速出现毫秒数，也只代表测速地址在当时可达，不代表所有网站和协议都能使用。

本文按桌面客户端与 mihomo 内核的常见组合说明。不同客户端的设置名称可能不同，应以界面实际显示的监听端口和有效配置为准。先记录客户端名称、版本、内核版本、当前配置名称，以及故障发生时间；不要一开始同时重装客户端、更换订阅和修改 DNS。

建立三个可复现的观察项

• 故障范围：是全部网站失败，还是只有某个域名失败；是浏览器失败，还是终端、其他应用也失败。
• 请求入口：当前使用系统代理、浏览器代理扩展，还是 TUN 模式；是否还开着另一款 VPN。
• 现场证据：刷新页面时，在客户端“连接”列表找目标域名，在“日志”里找同一时间的错误。

第一步：确认浏览器确实使用系统代理

以 Clash Verge Rev 常见界面为例，在「设置」→「系统代理」检查开关，再到操作系统核对实际代理地址。仅在客户端选中节点，不会自动让所有应用使用该节点；系统代理也不能接管所有不遵循系统设置的应用。

1. 在客户端查看实际“混合端口”。例如界面显示 7897，则本机代理地址应对应 127.0.0.1:7897。其他客户端可能使用 7890，不要照抄默认值。
2. Windows 11 打开「设置」→「网络和 Internet」→「代理」，查看“使用代理服务器”的地址和端口。注意同时存在的自动配置脚本可能影响最终路径。
3. macOS 打开「系统设置」→「网络」→ 当前连接的网络 →「详细信息」→「代理」，核对网页代理与安全网页代理是否指向预期地址。
4. Firefox 打开「设置」→「常规」→「网络设置」→「设置」，确认使用系统代理，或核对手动代理配置。其他浏览器的代理扩展也可能覆盖系统设置。

排查时先暂时停用浏览器代理扩展，只保留一套明确的代理入口。不要把 HTTP 混合端口填成 SOCKS 专用端口，也不要把控制器端口当成流量入口：external-controller 用于管理接口，不负责代理网页请求。

用显式代理请求绕过浏览器设置

假设当前混合端口确实是 7897，在 Windows PowerShell 执行下面的命令。这里使用 curl.exe，避免部分 PowerShell 环境中的同名别名影响参数解析；macOS 和 Linux 可将命令名改为 curl。

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

随后将测试网址换成实际打不开的站点。若显式代理请求成功而浏览器失败，优先处理浏览器扩展、系统代理、缓存连接或浏览器自身的安全 DNS 设置，不必马上更换节点。若返回 403 或 405，说明收到了 HTTP 响应，但网站可能限制访问或 HEAD 请求；可去掉 -I 再比较，不能直接判为代理未连接。

第二步：核对混合端口监听与端口冲突

显式代理请求如果立即提示无法连接 127.0.0.1，先查本地监听。此时请求还没到节点，切换远端服务器通常没有作用。Windows 可以在 PowerShell 中运行：

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

将结果中的进程编号代入 Get-Process -Id 1234，确认端口是否由当前使用的内核占用。这里的 1234 只是命令格式示例，应替换为查询结果。macOS 可运行下面的命令查看监听进程：

lsof -nP -iTCP:7897 -sTCP:LISTEN

如果需要改端口，可选择未占用的端口，例如从 7897 改为 17897，再让内核重新加载设置。随后同步检查系统代理、浏览器扩展及终端的 HTTP_PROXY、HTTPS_PROXY、ALL_PROXY。只修改客户端而保留旧入口，会继续连接错误端口。

第三步：比较规则模式与全局模式

确认本地入口正常后，检查客户端「代理」页面的模式选择。规则模式按规则决定走哪个策略；全局模式使用全局策略选择；直连模式不通过代理节点转发。这些是流量决策方式，与是否开启系统代理或 TUN 模式不是同一层设置。

1. 在规则模式下访问目标网站，记录连接详情中的规则、策略组、最终节点与错误信息。
2. 短暂切换到全局模式，并在全局策略中明确选择一个可用节点。全局策略若仍选着 DIRECT 或 REJECT，比较没有意义。
3. 再次访问同一网站。如果全局可用、规则模式不可用，重点检查规则及其指向的策略组。
4. 测试结束后切回原来的规则模式，避免把临时诊断设置长期保留。

如果两个模式均失败，观察日志是否出现节点连接超时、认证失败、TLS 握手失败或证书错误。可以换一个节点交叉测试，但应保持目标网址和测试入口不变。节点测速成功而实际网站失败，可能与出口限制、目标站点限制或节点协议参数有关，不能仅凭延迟值排除节点问题。

第四步：检查规则顺序、策略组与最终出口

mihomo 的规则通常自上而下匹配，命中后执行对应策略。一个域名可能被提前出现的规则送到直连或拒绝策略，后面的正确规则便不会生效。排查应以“连接”详情里的实际命中结果为准，而不是只搜索配置中有没有这个域名。

先看连接详情，再改配置

• 命中 DIRECT：核对是否属于预期直连范围，是否有过宽的域名后缀规则或 IP 规则提前命中。
• 命中 REJECT：检查拦截规则或外部规则集，确认网站依赖的资源域名是否也被拒绝。
• 命中代理组：继续展开组内选择。组名叫“代理”并不代表最终一定使用远端节点，它也可能选中直连或另一个组。
• 落到 MATCH：检查兜底策略；这通常说明前面的规则没有覆盖该请求。

下面仅展示规则顺序，不是可以替代订阅的完整配置。引用的 PROXY 必须在现有配置中有对应的节点或策略组名称：

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

真实网站经常同时请求登录、静态资源和接口域名。首页 HTML 返回成功，但页面持续转圈，可能是接口域名命中了另一条规则。打开浏览器开发者工具的「网络」面板，找到失败请求的域名，再到客户端连接列表查对应记录。

订阅更新可能覆盖直接编辑的订阅内容。需要长期修正规则时，优先使用客户端提供的覆写、合并或扩展配置功能，并确认修改进入有效配置。不要把订阅里已有的节点和策略组整段替换为网上的示例。

第五步：分开检查系统 DNS 与 mihomo DNS

DNS 错误通常表现为域名解析超时、解析失败，或解析结果无法用于连接。先确认是谁在解析：系统解析器、浏览器安全 DNS、内核 DNS，还是远端代理服务器。它们不一定走同一条链路，因此单独运行一次 nslookup 不能证明整个代理链路正常。

按入口比较解析结果

1. 运行 nslookup example.com，记录系统使用的 DNS 服务器与返回结果，再对实际故障域名重复测试。
2. 在客户端日志中查找目标域名，判断是否存在内核 DNS 查询失败，还是已经解析成功后节点连接失败。
3. 如果浏览器独有故障，记录原设置后，临时调整浏览器「安全 DNS」进行对照测试；测试后恢复或保留已确认有效的设置。
4. 如果配置使用加密 DNS，核对 DNS 服务器本身是否可达。把解析服务器换成一个当前网络无法连接的地址，只会增加新的超时。

使用 SOCKS 测试时，socks5:// 与 socks5h:// 也值得区分：在 curl 中，后者让代理端解析目标域名。若当前端口支持 SOCKS，可执行下面的对照请求：

curl.exe --noproxy "" --proxy socks5h://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com/

若远端解析方式可用、本地解析方式失败，应优先检查本地 DNS 路径。不过两种入口的成功与否仍需结合连接日志，不能仅凭一次请求认定唯一原因。

Windows 在修正相关设置后可执行 ipconfig /flushdns 清理系统 DNS 缓存，再关闭并重新打开浏览器。清缓存只是收尾动作，不能替代修正错误的 DNS 上游、路由或劫持配置。

第六步：单独验证 TUN、路由与其他 VPN

如果显式 HTTP 代理能访问，而启用 TUN 后失败，问题更可能位于虚拟网卡、路由或 DNS 接管路径。TUN 通过虚拟网络接口接管流量，不要求应用遵循系统 HTTP 代理；但服务权限不足、路由冲突或另一个 VPN 同时改写网络设置，都可能让流量走错路径。

• 在客户端「设置」中检查服务模式或相关服务是否正常，再检查「TUN 模式」开关。需要服务权限的客户端应按自身界面提示完成安装。
• 在网络策略允许的前提下，暂时关闭 TUN，仅开启系统代理，再用同一浏览器和同一网址测试。
• 如果只在 TUN 下失败，查看有效配置中的 tun.auto-route、tun.dns-hijack 等项目，并检查是否与其他 VPN 或虚拟网卡争用路由。
• 若只有部分 HTTPS 页面卡住，再结合日志与抓包检查 MTU、IPv6 路由等问题，不要把任意 MTU 数值作为通用修复方案。

公司设备或受管网络可能要求指定的 VPN、证书与 DNS 策略。此时应联系管理员确认兼容方式，不应通过停用安全组件绕过网络管理。对于普通个人设备，也应先停止重复的代理程序，再考虑清理遗留服务。

排查结果记录与恢复检查

完成一轮后，用下面的结果快速定位需要继续处理的层级。记录具体错误比只写“连不上”更有用，也便于在重启或订阅更新后验证问题是否复现。

提交问题时，提供客户端和内核版本、操作系统版本、实际混合端口、代理模式、TUN 状态、复现步骤，以及同一时间段的错误日志。分享截图或配置前，删除订阅地址、认证信息、控制接口密钥及个人浏览记录。

恢复使用前，将临时开启的全局模式切回预期模式，确认浏览器和终端没有残留旧端口，再检查原先失败的网站及其登录、图片和接口请求。基础设置可对照Clash 配置教程；需要继续按错误类型排查时，可进入故障排查页面。