托盘图标正常、日志里也有连接，但浏览器一打开就是「无法访问此网站」——这类 已连接却无法上网 的问题，在 Clash 用户里极其常见。真凶往往不在节点本身，而在 DNS 有没有真正交给 Clash、 fake-ip 与规则是否对齐，以及 规则优先级 是否把流量提前送到了错误的出口。本文按「先辨现象、再动配置」的顺序写，你可以从第一条开始逐项打勾。 同样一句「上不了网」，背后的网络路径可能完全不同。动手改 YAML 之前，先用半分钟把现象归类： 只有浏览器不行 ：微信、游戏或命令行反而正常，多见于浏览器开了独立 DoH 、扩展抢代理，或仅系统代理未覆盖浏览器沙箱场景。 国内外全挂，但 Clash 连接统计在涨 ：像是「连上了隧道，但解析或首包握手卡死」，优先怀疑 DNS 泄漏 、 nameserver 不可达，或规则把 DNS 查询送进了错误策略组。 国内站正常、国外站全超时 ：更像规则把海外流量判成 DIRECT 或节点组失效，但仍建议先排除 DNS，再换节点对照。 若实际是订阅过期、节点大面积超时，改 DNS 只会浪费一小时。先在同一网络下用手机热点试一次，或在 Clash 里临时切到可确认的节点组做对照。 第一步：30 秒分辨「解析坏了」还是「隧道坏了」 准备一个你确定需要代理的域名（例如常用外站首页），按下面顺序试： 在系统终端执行 ping 或 nslookup 看能否得到 IP。若这里就卡住，问题多半在 DNS 或本机网络，而不是网页渲染。 用 curl -v https://example.com （换成你的目标域）观察是卡在「Trying …」还是 TLS 握手后才有错误——前者多指向解析或路由，后者多指向证书、SNI 或节点质量。 在 Clash 日志或连接面板里，看该域名出现时匹配到的 策略 与 实际出站 是否一致；若显示 DIRECT 却访问的是海外站，属于 规则优先级 或 GEOIP 顺序问题。 很多 GUI 会缓存旧配置。改完 dns 或 rules 后，完整退出客户端再开，比单点「重载」更利于排除状态残留。 DNS 泄漏：系统解析绕开了 Clash DNS 泄漏 指：你以为 Clash 在接管查询，但操作系统、路由器或浏览器仍把请求发给运营商 DNS，导致解析结果与隧道策略不一致——Clash 按一套 IP 做分流，应用却按另一套 IP 建连，表现就是「图标绿灯、页面空白」。 常见触发条件包括：Windows「编辑网络适配器」里手动填了 DNS；路由器 DHCP 下发了强制 DNS；公司门户或校园网劫持 53 端口；以及浏览器「使用安全 DNS」与系统设置双轨并行。 系统 IPv4/IPv6 DNS 是否设为自动，或显式指向 127.0.0.1 （视客户端实现而定，以你所用分支文档为准）。 是否同时开着第三方「网络加速」「游戏加速器」类虚拟网卡，它们可能再次下发 DNS。 若使用 TUN 模式 ，确认路由与 DNS 劫持选项按文档开启；仅开系统代理时，某些应用根本不会问系统 DNS。 排障时可以先 临时关闭 浏览器安全 DNS，统一走系统解析，再观察 Clash 日志里 DNS 请求是否出现。若关闭后立刻正常，说明此前是 双解析器分裂 而非节点故障。 fake-ip 与 redir-host：假 IP 从哪来 Clash 的 enhanced-mode 常见两种： fake-ip 与 redir-host 。 fake-ip 会为域名分配一段本地虚拟地址，加快规则匹配、减少真实解析泄露；但若应用缓存了旧 fake-ip、或某些规则在 IP 层与域名层行为不一致，就会出现「偶发打不开、清缓存又好」的现象。 redir-host 则更接近传统思路：尽量使用真实解析结果再做策略。对兼容性挑剔的老应用、部分游戏协议，有时反而更稳。二者没有绝对优劣，只有与当前规则集、客户端实现是否匹配。 使用 fake-ip 时，留意 fake-ip-range 是否与局域网网段冲突。 订阅自带的 fake-ip-filter 列表会把指定域名改为真实解析；列表过长或与自定义规则冲突时，可能让你误以为「规则没生效」。 从一种模式切换到另一种后，务必 刷新系统 DNS 缓存 并重启浏览器，否则旧记录会继续捣乱。 NAS、打印机、内网管理地址若被错误地走代理，也会表现为「网页打不开」。确保 RFC1918 与相关域名在规则靠前位置 DIRECT ，再谈海外分流。 nameserver、fallback 与上游可用性 dns.nameserver 决定 Clash 向谁发起解析。 nameserver 填写的上游若在你当前网络下被墙、被劫持或 UDP 不通，全局都会表现为间歇性断网。实践中常见错误是：只写了海外 DoH，却在「无代理」环境下启动 Clash，导致首轮解析就失败。 很多配置会拆分 nameserver （国内快速）与 fallback （加密或海外），并配合 fallback-filter 防止污染。若你对这些字段还不熟，优先遵循订阅提供方的模板，再小步修改；一次改太多变量，日志很难读。 上例仅演示结构，具体关键字随内核版本可能略有差异，请以你所用 Clash / Meta 文档为准。核心原则是： 至少保证有一条在你当前网络下无需代理即可连通的解析路径 ，否则隧道尚未建立时就会「饿死在自己的 DNS 里」。

规则优先级：从上到下，细规则在前 Clash 按 从上到下 匹配第一条命中的规则。 GEOIP,CN,DIRECT 若放在过宽的全局代理规则之上，会让大量本该走隧道的流量提前直连失败；反过来，粗放的 MATCH 若缺少最后的兜底，也会让未知流量无处可去。 内网、局域网、认证类域名： 最前 。 明确要代理或明确要直连的域名 / 进程 / IP： 中间 ，越具体越靠前。 地区类规则（如 GEOIP）与总兜底 MATCH ： 靠后 。 改规则时不要凭印象，打开连接日志，把「失败时匹配到的规则名」记下来，再回到 YAML 搜索对应条目，看它的 物理顺序 是不是被后面更粗的规则盖住了。很多「我明明写了 DOMAIN 规则」的案例，其实是写在了 MATCH 之后，永远不会被执行。 浏览器 DoH 与「只代理一半」 Chrome、Edge、Firefox 均可单独启用 DNS-over-HTTPS。此时浏览器可能完全绕过系统解析，Clash 日志里甚至看不到对应查询——你从 Clash 视角一切正常，浏览器却按另一套路径建连，这就是典型的 双轨 DNS 。 排查时建议：用无痕窗口、禁用扩展、关闭浏览器安全 DNS，再试同一网址。若仅在某一浏览器复现，不要急着换节点，先把 浏览器网络栈 与 Clash 对齐。 TUN 与系统代理：谁负责 DNS 仅开启 系统代理 时，遵循系统代理栈的应用会把 HTTP(S) 流量交给 Clash，但部分程序仍自行解析域名或使用 QUIC，表现会「飘忽」。 TUN 模式 在网卡层接管，更容易做到全局一致，却也可能与企业 VPN、零信任客户端冲突。 若你在系统代理下长期遇到「只有浏览器偶发翻车」，可以按文档尝试 TUN，并观察 DNS 相关选项开启后的日志变化；若开启 TUN 后立刻稳定，说明此前确实存在 绕代理 或 解析分裂 。 可打印：已连接无法上网检查清单 确认订阅未过期、所选节点组在延迟测试中可用。 关闭或对齐浏览器 DoH，避免与 Clash DNS 双轨。 检查系统与路由器 DNS，排除运营商劫持与冲突网卡。 理解当前是 fake-ip 还是 redir-host ，切换后清缓存。 核对 nameserver / fallback 在无代理环境下是否可达。 在规则列表中按「具体 → 宽泛」排序，确认 MATCH 在末尾。 对照连接日志，验证目标域名命中策略与实际出站一致。 需要全局一致性时，评估 TUN 与绕过进程名单（split）配置。 ping 通 IP 但浏览器仍打不开？ 可能 ping 的是国内优化节点或假 IP，而 HTTPS 仍要走不同路径。以浏览器实际访问的主机名为准，看 Clash 对该主机名的策略与 TLS 错误提示。 多为规则或 DNS 污染组合问题。检查是否走了 DIRECT ，以及 fake-ip-filter 是否异常；临时切 Global 仅作对照，确认后回到 Rule 细调。 可在系统层暂时关闭 IPv6 试差。若症状消失，应在规则里系统性处理 IPv6，而不是长期关掉协议。 Clash 已连接却无法上网 多数是 DNS 与规则协作问题，而不是单纯「换个节点」。先对齐系统与 Clash 的解析路径，再检查 fake-ip 与 nameserver ，最后用日志验证 规则优先级 ——这三步能覆盖绝大多数搜索「已连接 无网络」的用户场景。 立即免费下载 Clash，开启流畅上网新体验 ：使用维护积极的客户端与清晰订阅，比手工拼 YAML 更省时间。 先把 DNS 对齐，再谈节点速度 下载整合优化的 Clash 客户端，减少订阅与默认模板上的坑，排障时日志更清晰。