2026-06-15 故障排查 预计阅读 8 分钟

Clash 已连接但网页打不开:从系统代理到 DNS 的逐项排查清单

代理显示已连接却无法上网,按顺序检查:系统代理是否生效、端口是否被占用、节点是否可用、DNS 是否被污染、规则是否误匹配,每一项给出验证命令与恢复手段。

客户端界面显示「已连接」,状态灯是绿色,节点延迟数字也正常,但浏览器打开任何网页都是转圈或报错——这是 Clash 使用过程中最常见的一类问题,原因往往不在节点本身,而在流量从系统到客户端再到出口这条链路上的某一环。下面按出现概率从高到低排列五个检查点,每个点给出可以直接执行的验证命令,不用瞎猜。

第一步:确认系统代理确实生效

客户端「已连接」只代表核心进程在运行、监听端口已打开,不代表系统流量真的走了这个端口。很多情况下用户开启了 Clash 自带的「设置为系统代理」开关,但系统层面的代理设置被其他软件覆盖,或者浏览器用了独立的代理配置,导致流量根本没进 Clash。

  • Windows:打开「设置 → 网络和 Internet → 代理」,确认「使用设置脚本」或「手动设置代理」里的地址与端口跟客户端里显示的一致。
  • macOS:打开「系统设置 → 网络 → 高级 → 代理」,检查「网页代理(HTTP)」与「安全网页代理(HTTPS)」是否指向 127.0.0.1 与客户端端口。
  • 浏览器单独设置了代理插件(如 SwitchyOmega)时,系统代理再怎么改都不会影响该浏览器,需要在插件里同步核对。

如果使用 TUN 模式,系统代理这一步可以忽略——TUN 是在网卡层接管全部流量,不依赖 HTTP/SOCKS 代理设置,但要确认 TUN 已经在客户端里真正打开,而不是配置文件写了却没启用。

第二步:排查端口占用与冲突

Clash 默认监听 7890(HTTP/SOCKS 混合端口)与 9090(外部控制端口)。如果本机同时跑着其他代理软件、虚拟机网络组件或者上一次没有正常退出的 Clash 进程,端口可能被占用,客户端表面上显示运行正常,实际监听失败。

Windows PowerShell
netstat -ano | findstr 7890
macOS / Linux
lsof -i :7890

如果查到端口被非 Clash 进程占用,先结束占用进程或把 Clash 的监听端口改成其他数值(如 7891),再重启客户端。同时留意任务管理器 / 活动监视器里是否残留了多个 clash / mihomo 后台进程,重复进程之间会互相干扰。

第三步:验证节点本身是否可用

节点延迟测出来是几十毫秒,不代表节点真的能连通目标网站——测速工具通常只测到落地服务器的 TCP 握手,不代表出口 IP 没被目标站点拉黑,或者该节点的出站带宽已经耗尽。逐一排除的方法:

  1. 在客户端节点列表里切换到另一个不同地区/不同协议的节点,重新访问同一个网址,判断问题是否只出现在当前节点上。
  2. 打开客户端的连接日志或流量面板,观察当前访问是否真的经过了选中的节点,还是被某条规则分流到了「DIRECT」直连。
  3. 用命令行直接测试出站连通性,排除浏览器缓存、DNS 缓存等干扰因素:
终端测试(经代理请求)
curl -x http://127.0.0.1:7890 -I https://www.google.com --max-time 8

如果这条命令返回 HTTP/2 200 或类似的正常状态码,说明代理链路本身没问题,浏览器打不开网页可能是浏览器自身的缓存、扩展或 HTTP/3 协议兼容问题,可以尝试无痕窗口或换一个浏览器验证。

第四步:检查 DNS 是否被污染或劫持

代理链路正常但特定网站打不开、或者能连上却加载出错误的内容,大概率是 DNS 环节出了问题。国内网络环境下,走系统默认 DNS 解析域名时经常拿到被污染的错误 IP,即使流量已经交给 Clash 处理,如果域名解析这一步没有走代理内置的 DNS 模块,后续请求依然会连到错误地址。

建议在配置文件里开启 dns 模块并启用 fake-ip 或 enhanced-mode: fake-ip,同时把 nameserver 指向可信的加密 DNS(如 DoH/DoT 地址),让域名解析也经过代理判断,而不是依赖本机系统 DNS。

config.yaml 片段
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://doh.example-provider.com/dns-query
  fallback:
    - tls://1.1.1.1:853

验证 DNS 是否解析正常,可以直接在命令行里对比走代理前后的解析结果:

终端测试(DNS 对比)
nslookup www.example.com
nslookup www.example.com 198.18.0.2

如果两次返回的 IP 明显不同,或者其中一个直接超时,说明本机默认 DNS 与代理内置 DNS 之间存在分歧,应以代理内置 DNS 的解析结果为准,并确认系统网络设置里没有强制指定了运营商 DNS 覆盖掉代理设置。

第五步:排查规则是否把流量分错了

Clash 的核心工作方式是按规则把每一条连接分流到不同策略组,如果规则集配置不当,完全可能出现「代理已连接、部分网站能开、部分网站打不开」的局面——问题网站被某条规则误判成了「应该走直连」,而本地网络恰好又无法直连到该地址。

  • 打开客户端的规则/日志面板,访问打不开的网址,查看该连接实际匹配到了哪一条规则、落到了哪个策略组。
  • 如果显示走的是 DIRECT 而不是代理节点,检查规则集(如 GeoSite、GeoIP 分类)是否把该域名或 IP 段错误地归到了「大陆节点」或「直连」分类下。
  • 规则集本身可能是过时版本,长期不更新会导致新增域名段没被正确收录,建议定期在配置里刷新规则集来源或更换维护活跃的规则仓库。

不要一遇到问题就把 mode 从 rule 改成 global 长期使用——全局模式能临时验证问题是否出在规则层,但会让所有流量(包括本地内网访问)都走代理出口,排查完成后应该改回规则模式。

五步走完还没解决怎么办

按以上顺序逐项排查后,绝大多数「已连接但无法上网」的情况都能定位到具体环节。如果全部检查都通过,流量、DNS、规则都显示正常,但网页依然打不开,可以进一步确认以下两点:本地防火墙或安全软件是否对 Clash 进程设置了单独的网络限制;订阅节点是否临时下线,可尝试重新导入订阅链接强制刷新一次节点列表。多数情况下,先重启客户端进程再按上述顺序复查一遍,问题会在某一步暴露出来。

下载Clash