先对齐现象：三种「假正常」
同样一句「上不了网」，背后的网络路径可能完全不同。动手改 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 防止污染。若你对这些字段还不熟，优先遵循订阅提供方的模板，再小步修改；一次改太多变量，日志很难读。
dns:
enable: true
enhanced-mode: fake-ip
nameserver:
- 223.5.5.5
- 119.29.29.29
fallback:
- https://dns.cloudflare.com/dns-query
fallback-filter:
geoip: true
geoip-code: CN
上例仅演示结构，具体关键字随内核版本可能略有差异，请以你所用 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 错误提示。
只有 Google 打不开？
多为规则或 DNS 污染组合问题。检查是否走了 DIRECT，以及 fake-ip-filter 是否异常；临时切 Global 仅作对照，确认后回到 Rule 细调。
怀疑 IPv6 作怪怎么办？
可在系统层暂时关闭 IPv6 试差。若症状消失，应在规则里系统性处理 IPv6，而不是长期关掉协议。
小结
Clash 已连接却无法上网多数是 DNS 与规则协作问题，而不是单纯「换个节点」。先对齐系统与 Clash 的解析路径，再检查 fake-ip 与 nameserver，最后用日志验证规则优先级——这三步能覆盖绝大多数搜索「已连接 无网络」的用户场景。
立即免费下载 Clash，开启流畅上网新体验：使用维护积极的客户端与清晰订阅，比手工拼 YAML 更省时间。