Linux 装 Clash 后网页打不开：systemd-resolved 与 DNS 模式分步核对

先分清：这是「解析坏了」还是「出口／规则不对」

经验上，若 同一浏览器里国内站点秒开、只有目标海外站「一直在转圈」或提示 DNS_PROBE 一类错误，而 Clash 日志里几乎看不到对应域名的连接尝试，优先怀疑解析链路；若日志里已有连接记录，但握手慢、频繁超时再换节点才有改善，则更偏节点质量、UDP／TLS／SNI与规则命中，而不是本机 stub 解析器。下文假设你已能正常更新订阅、策略组里也有可用节点，否则请先回到总览教程或订阅常见问题把基础闭环跑通。

另外，Fake-IP 模式会在内核里维护「域名 → 占位地址」的映射，与系统 /etc/hosts、浏览器 DoH 插件、以及是否启用 TUN共同作用；若你刚打开 TUN 或改过「仅代理」与「系统代理」组合，务必把变量一次只改一项，否则容易把DNS 问题误判成规则顺序问题。TUN 与 DNS 的耦合在TUN 模式深度解析里有更细的展开，本篇只收束到 Linux 上最常踩的 resolved 坑。

第一步：看清本机 DNS 问的到底是谁

在启用 systemd-resolved 的系统上，多数进程的「默认 DNS」并不是直接问 8.8.8.8，而是问本机 127.0.0.53 这个 stub：resolved 在前面接手、缓存、按度量转发。你可以在终端查看当前全局与链路作用域，例如 resolvectl status 或较老的 systemd-resolve --status，重点看 Current DNS Server、各网卡的 DNS Domain 以及 DNSSEC 是否开启。

再看 /etc/resolv.conf：若它是指向 127.0.0.53 的自动生成文件，说明普通应用的 getaddrinfo 会先把问题交给 resolved；若历史上有人手工改成直连公网 DNS、或指向路由器而路由器又往回转，就会形成弯路线。Clash 若同时配置「劫持本机 DNS」或「在 53 监听」，就可能与 stub 抢同一个语义空间——这就是许多「时而好时而坏」的根因。

第二步：检查 53 端口与「谁在听」

当 Clash／Mihomo 在配置里声明监听 0.0.0.0:53 或本机某个 DNS 入站端口时，若系统已有 avahi-daemon、dnsmasq、容器里的同名服务，或与 resolved 的独占绑定冲突，会出现服务起不来、或起来后间歇性不响应。用 ss -lunpt 或 sudo lsof -iUDP:53 -iTCP:53 看一眼当前到底是谁占着 53，把输出记在纸上：如果 53 已被系统服务稳定占用，而你的内核配置又要求「代理 DNS 必须用 53」，就要么改 Clash 的 DNS 监听端口并在防火墙／网桥规则里做显式转发，要么调整 resolved 的DNSStubListener（高级操作，改前建议备份并理解副作用）。

对桌面用户而言，更常见的稳妥路径是：让 Clash不要跟系统强抢 53，而是作为上层应用通过自身提供的本地 DNS（例如在高端口或使用「仅由内核处理」的模式）配合 TUN／系统代理；具体 YAML 键名随内核版本略有差异，以你当前 Mihomo／Meta 文档为准，但原则始终是：先消除端口与绑定冲突，再谈规则。

第三步：核对 DNS 增强模式：redir-host 与 Fake-IP

在 Mihomo／Clash Meta 系配置中，enhanced-mode 通常可选 redir-host 或 fake-ip。redir-host 更贴近「先把域名解析成真实 IP，再走规则」的传统路径；fake-ip 则先给应用一个私有网段地址，再由内核在真正建连时补全流程，对规则命中与延迟优化往往更友好，但对本机其它 resolver、某些硬编码 DoH 的客户端更挑剔。

如果你发现「浏览器能开、命令行 curl 却怪」「走了系统代理的应用正常、走 TUN 的却解析挂」，很像 Fake-IP 过滤／绕过列表与 sniffing、系统 DNS三者没有对齐。可先临时切到 redir-host 做对照实验：若症状明显缓解，再回到 fake-ip，并逐项补齐 fake-ip-filter、nameserver-policy 里对局域网、国内直连域、以及 mDNS／PTR 等记录的豁免。嗅觉相关（sniffing）与网页异常的组合，亦可对照Meta sniffing 与分流例外一文，但记得每次只动一层。

第四步：systemd-resolved 与 Clash 的三条「和平共处」策略

实务上没有放之四海皆准的银弹，但可以把策略归纳成三条路径，按侵入性从低到高阅读（执行任何涉及 resolved.conf 的修改前请自行备份，并确认你有恢复手段）。

路径 A：让 Clash 只做应用层代理，不与 stub 抢 53。适合「只想稳定上网」：保持 resolved 为默认解析栈，Clash 侧关闭「强制接管本地 DNS」类选项，把重点放在系统代理或TUN带来的流量调度上；若规则依赖域名分支，交由内核在已有通道内完成，而不是再开一个 parallel DNS 入口。

路径 B：显式指定「问谁解析」，用 nameserver-policy 对齐场景。例如让国内常见域走运营商或公共 DNS，海外敏感域走 DoH／DoT，由 Mihomo 统一调度，避免应用各自选 DoH 与 Fake-IP 冲突。关键是策略一致：桌面浏览器若装了 DoH 插件，要意识到它已经绕开 stub，这时 Clash 日志里看到的域名可能不完整或时机错位。

路径 C：调整 resolved（仅限熟练用户）。某些进阶教程会讨论关闭 DNSStubListener、把 /etc/resolv.conf 改为静态并指向 Clash 提供的上游——这能把整台机器的解析收束到一处，但一旦 Clash 没起来，整机可能「全解析阵亡」。在家庭台式机可回退，在服务器或远程 SSH 场景风险更高，务必三思。

第五步：一条可打印出来的核对清单

建议把下面每一步从上到下做一遍，改一项、测一项，并在纸上记下「改之前／之后」的对比，而不是同时在图形界面里改五六处。

1. 看 resolved：resolvectl status 里的 DNS Server 与 接口是否合理；有无奇怪的第三方面向「公司自带 DNS」。
2. 看 resolv.conf：确认是符号链接还是静态文件；若曾被手工改坏，必要时按发行版文档恢复与 NetworkManager／systemd-networkd 的配合。
3. 看 53 端口：ss／lsof 输出里 Clash 与系统服务是否争用同一地址族。
4. 看 Clash DNS 段：enhanced-mode、fake-ip-filter、fallback、doq／doh 的可达性；用内核日志或 Mihomo API 看有没有反复超时重试。
5. 看规则与 no-resolve：是否存在大量依赖 GEOIP 的项却在假 IP 环境下没走到「正确解析时机」；必要时把相关行临时改成显式 DOMAIN／PROCESS 对照。
6. 看第二套 VPN：公司 GlobalProtect、WireGuard、zerotier 与 Clash 同时开时，默认路由与DNS 覆盖可能互相踩；先关掉其它隧道只留 Clash复现。

和站内其它 Linux 文怎么配合读

若你用的是我们写过的发行版专文，例如 Ubuntu 24.04、Debian 12、Arch 或 Fedora，那些文章侧重安装包、订阅、systemd 自启与 SELinux／防火墙；本篇则在他们「已经能启动客户端」之后，补上桌面解析栈这一层。若你主要痛点是国内站变慢，应先对照GEOIP CN 与绕过大陆核对清单；若跨 WSL／Docker，再看对应 Windows 专文，以免把命名空间里的 DNS与宿主机混谈。

合规说明

请在你有权使用的网络与设备上配置代理与 DNS，遵守当地法律法规及服务条款。本文仅做技术原理与排障顺序说明，不构成对任何机场或商用订阅源的建议。自行修改系统网络栈前应评估可恢复性，远程主机尤其要谨慎。

小结

Linux 桌面装 Clash 后出现「解析失败、网页打不开、国内外表现不一致」，与其盲目换节点，不如先把systemd-resolved、/etc/resolv.conf、53 端口与内核 DNS 模式（Fake-IP／redir-host）对齐成单一路径叙事。多数问题发生在「stub 还在、Clash 又想当唯一上游」或「Fake-IP 与系统／浏览器 DoH 各说各话」这两类场景；按本文分步缩小范围，通常能很快定位。

若你希望使用维护积极的核心与图形客户端，并从可信渠道获取安装包，可走本站下载页配合入门教程建立固定工作流。相比在论坛碎片帖里反复试错，先理顺 DNS 与 systemd-resolved，再调分流，长期成本更低。→ 立即免费下载 Clash，开启流畅上网新体验。