Clash 显示已连接却打不开网页：从系统代理到 DNS 的逐项排查清单

1. 区分连接状态与实际请求链路

客户端显示“运行中”“已连接”，通常只说明内核已启动，或系统 VPN 接口已经建立。节点延迟测试成功，也只代表测试地址在当时能够访问。浏览器请求还需要经过代理入口、规则匹配、代理组选择、节点连接与域名解析；其中任一环节失败，网页仍会打不开。

先保存当前配置，并记录客户端名称、客户端版本、内核名称及版本。Clash 是配置生态中常见的名称，Clash Meta 后续使用 mihomo 名称；不同客户端封装的内核与菜单不完全相同，不能把某个界面开关当成所有版本的固定功能。

先做三项基线检查

1. 临时关闭系统代理和 TUN，访问平时可直连的网站。如果仍无法访问，先检查 Wi-Fi、网关、认证页面和系统网络，不要直接修改代理规则。
2. 恢复原设置，用同一个网址分别测试浏览器与命令行。保持测试对象一致，避免把不同网站的可用性差异当成客户端故障。
3. 打开客户端的“日志”和“连接”页面，记录测试时间、目标域名、命中规则、使用的代理组与错误原文。分享日志前隐藏订阅地址、口令、令牌和节点凭据。

2. 检查系统代理与本地监听端口

系统代理影响的是愿意读取系统代理设置的应用，并不接管所有程序。浏览器扩展、Firefox 的独立代理设置、终端环境变量，都可能覆盖系统设置。下面使用 127.0.0.1:7890 作为示例 HTTP 或 mixed 入口；请先在当前运行配置中确认实际端口，不能直接假定所有客户端都是 7890。

按平台核对入口

• Windows 11：打开「设置」→「网络和 Internet」→「代理」→「手动设置代理」。使用手动代理时，检查地址和端口是否与客户端一致；如果使用自动配置脚本，则检查脚本地址，不要同时保留来源不明的旧脚本。
• macOS：打开「系统设置」→「网络」→ 当前网络服务 →「详细信息」→「代理」。检查网页代理、安全网页代理或自动代理配置；切换 Wi-Fi 与有线网络后，需要确认当前服务的设置。
• Android：多数 Clash 类客户端通过系统 VPN 服务接管流量。检查 VPN 授权、应用分流名单，以及其他 VPN 是否占用了唯一的活动 VPN 连接；桌面端的手动代理步骤不能直接套用。

显式指定代理进行对照

# Windows PowerShell 中使用 curl.exe；macOS/Linux 可使用 curl
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "" --proxy http://127.0.0.1:7890 https://example.com/
curl.exe -I --connect-timeout 10 --max-time 20 --noproxy "*" https://example.com/

第一条明确经过本地代理，第二条忽略环境代理、尝试直连。这里的域名仅用于演示，应替换成正在排查的网站。若第一条成功、浏览器失败，重点检查浏览器代理来源与扩展；若报 Failed to connect to 127.0.0.1，先查本地监听，而不是调整远端节点。

HTTPS 经过 HTTP 代理时，输出中的 200 Connection established 只表示 CONNECT 隧道已建立。还要继续看到目标站点的 HTTP 响应。目标返回 403 或 405 说明已收到服务器响应，但不代表页面内容可以正常访问；部分站点也不接受 HEAD 请求，可去掉 -I 复测。

3. 排除端口冲突与旧进程占用

界面进程打开，不代表内核成功绑定了端口。两个客户端同时启动时，常见错误是 address already in use 或 bind 失败。系统代理仍指向 7890，但实际占用该端口的可能是旧客户端，甚至已经失去有效配置的后台服务。

# Windows PowerShell：查看监听进程
Get-NetTCPConnection -State Listen -LocalPort 7890 |
  Select-Object LocalAddress, LocalPort, OwningProcess

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

# Linux：查看监听进程
ss -ltnp 'sport = :7890'

1. 查看监听进程对应的程序，确认是否属于当前客户端。Windows 可用任务管理器「详细信息」按 PID 查找。
2. 正常退出不再使用的客户端及其后台服务，再重启目标客户端。不要只按端口号盲目结束系统进程。
3. 如果改用 7892 等其他空闲端口，需要同步修改系统代理与测试命令。修改后重新检查实际监听结果。

port 通常提供 HTTP 代理入口，socks-port 提供 SOCKS 入口，mixed-port 可接受 HTTP 与 SOCKS 连接。把 HTTP 请求发到只支持 SOCKS 的端口可能失败。external-controller 是控制接口，不是网页代理入口；不要把它的端口填入系统代理。

4. 检查代理组选择与规则命中

订阅成功导入，只说明配置能够载入。规则引用的代理组可能仍选中 DIRECT、失效节点，或另一个嵌套代理组。打开连接详情，找到本次请求对应的目标域名，沿代理链确认最终出口，而不是只看首页显示的节点名称。

用模式切换缩小范围

1. 在规则模式下访问目标，记录命中的规则与策略。规则一般按顺序匹配，靠前的宽泛规则可能提前接走请求。
2. 短时切换到全局模式，并确认 GLOBAL 组实际选中了要测试的节点。全局模式也可能选中 DIRECT，不能只看模式名称。
3. 重新加载网页并观察新连接。若全局模式成功、规则模式失败，重点检查规则顺序、规则集是否加载，以及相关策略组的选择。
4. 测试后恢复规则模式。全局模式是定位工具，不会自动修复 DNS、节点失效或本地端口问题。

# 规则顺序示例：仅用于说明，不要覆盖完整订阅
rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,PROXY

在这个片段中，example.com 及其子域名先匹配直连，最后一条才把其余请求交给 PROXY。其中 PROXY 必须是配置里已经存在的代理或代理组。若目标只能经代理访问，前面的直连规则就会造成“其他网站正常，某个网站打不开”。

切换节点后，应重新建立测试连接。浏览器的连接复用可能继续使用旧链路；必要时只关闭对应的活动连接再重试。节点延迟有数值不等于目标站点可达，也不等于该节点支持当前请求所需的 UDP 传输。

5. 从错误类型检查 DNS 与解析路径

DNS 故障的典型线索包括 no such host、lookup failed 和解析超时。但 i/o timeout 也可能发生在连接节点或访问目标的阶段，需要结合日志中的目标地址判断。先确认是节点服务器域名解析失败，还是网站域名解析失败，两者的处理位置不同。

区分系统 DNS 与内核 DNS

# 查询系统默认解析器
nslookup example.com

# 仅当内核确实监听 127.0.0.1:1053 时使用
# 需要系统已经安装 dig
dig @127.0.0.1 -p 1053 example.com A

nslookup 成功不能证明内核 DNS 一定正常，因为两者可能使用不同上游；失败也不能直接证明通过代理解析的请求必然失败。通过 HTTP CONNECT 访问域名与应用先在本地解析再连接，走的解析路径可能不同。

mihomo 的 DNS 配置中，nameserver、nameserver-policy、proxy-server-nameserver 等字段分别影响不同场景，需按内核版本核对支持情况。启用规则参与 DNS 上游连接选择时，还要检查是否形成“访问 DNS 需要节点、连接节点又需要 DNS”的循环依赖。不要直接粘贴另一份订阅的整个 DNS 块。

Fake-IP 与浏览器安全 DNS

Fake-IP 模式返回的虚拟地址用于后续映射，不是目标网站真实地址。常见配置使用 198.18.0.0/16 范围，看到这一范围本身不代表解析被污染；应检查后续连接是否仍进入负责映射的同一内核。只有明确遇到依赖真实 IP 的应用兼容问题时，再评估定向加入 fake-ip-filter。

浏览器启用安全 DNS 后，可能绕过预期的系统解析路径。可以短时关闭该选项进行对照，测试后恢复需要的设置。修改 DNS 后，Windows 可执行 ipconfig /flushdns 清理系统缓存；浏览器和内核仍可能保留自己的缓存，需要分别重试。不要把长期关闭安全功能当作通用修复。

6. 仅在 TUN 下失败时检查路由与权限

若关闭 TUN、改用显式 HTTP 代理后可以访问，而开启 TUN 后失败，优先检查虚拟网卡、系统路由、DNS 接管和其他 VPN。TUN 通过虚拟网络接口与路由接收流量，其接管范围仍取决于路由和排除配置，不代表每个应用、每种协议都会自动成功。

• 权限：桌面客户端通常需要管理员权限或辅助服务来创建接口和修改路由。检查服务是否运行，而不是反复点击开关。
• 路由：Windows 使用 route print，macOS 使用 netstat -rn，Linux 使用 ip route 查看路由。先保存输出，不要直接删除默认路由。
• 接口选择：同时连接有线、Wi-Fi、虚拟机网卡时，自动识别的出口可能不符合预期。将测试环境暂时收敛到一个实际联网接口。
• VPN 冲突：企业 VPN、其他代理和虚拟网络工具可能改写路由。经允许后逐一退出对照；企业设备应遵守管理策略。
• 协议与 MTU：若小请求成功、大页面或下载停滞，再检查 UDP、路径 MTU 与分片问题。不要在没有证据时随机修改 stack 或 MTU 数值。

7. 按结果收敛问题并恢复配置

完成以上检查后，把现象归到一个明确分支。有效的排查记录应能说明“哪个入口、哪个目标、哪个模式、出现什么错误”，而不只是“还是连不上”。下面的结果表可作为最后一轮复核。

修复后恢复规则模式、原有安全设置和必要的网络接口，再测试一次订阅更新与常用网站。若本地配置修改会被订阅更新覆盖，应使用客户端支持的覆写或合并机制保存差异；先确认合并后的运行配置，不要只检查编辑器里的原始文本。

需要进一步求助时，提供客户端与内核版本、操作系统版本、系统代理或 TUN 状态、实际监听端口、测试命令以及同一时间段的脱敏日志。一次只围绕能够复现的请求展开，通常比直接重装客户端更容易确定故障位置。