Linux 裝 Clash 後網頁打不開：systemd-resolved 與 DNS 模式分步核對（2026）

症狀分類與本文邊界

開始改設定前，建議先把現象分桶。第一類是瀏覽器顯示 DNS_PROBE_FINISHED_NXDOMAIN、長時間「正在查詢主機名稱」、或只有特定網域永遠失敗——這通常與解析鏈路或 Clash 的 DNS 處理較相關。第二類是解析看似成功，但 TLS 憑證與網址不符、或連線被導向意外地區的 CDN——這可能牽涉 Fake-IP、規則順序與實際連線所見 IP 是否一致。第三類是「國內站走海外 DNS 答案、國外站卻拿到國內最佳化 IP」這類不一致，除了規則與節點，也常與系統 stub仍指向舊上游、或同時存在多個 DNS 客戶端有關。

若你的主訴是「開啟代理後大陸網站變慢、應直連卻進代理」，請優先搭配繞過大陸與 GEOIP CN 分步清單；若在 Windows 上跑 WSL2、要與宿主機 Clash 對齊，請改看WSL2 共用 Clash 專文。本篇假設你使用的是原生 Linux 桌面，且已能啟動核心或圖形客戶端，但網頁或部分應用程式在開啟客戶端後出現上述DNS 相關症狀。

步驟零：認識 systemd-resolved 與 127.0.0.53

在採用 systemd-resolved 的系統上，應用程式讀到的 /etc/resolv.conf 常指向 nameserver 127.0.0.53。這不代表「DNS 伺服器真的在 53 埠提供標準公開服務」這麼單純，而是本機 stub：glibc 等解析器把查詢送給這個位址，再由 systemd-resolved 依其設定轉發到實際上游（例如 DHCP 配到的 DNS、NetworkManager 設定的伺服器、或靜態設定）。因此，當你使用 resolvectl status、systemd-resolve --status（舊指令別名）或圖形網路設定時，你看到的是resolved 的完整決策，與直接讀 /etc/resolv.conf 的單行 nameserver 可能資訊量不同。

對 Clash 使用者而言，關鍵含意是：系統預設解析路徑已經被導向本機 stub。若你又在 Clash 設定裡啟用 DNS 伺服器並監聽 0.0.0.0:53 或 127.0.0.1:53，就可能與 systemd-resolved 或其他服務爭奪同一埠，或形成「查詢先經 stub、再被導向 Clash、Clash 又回頭問上游」的迴路，表面症狀便是間歇性解析失敗或逾時。接下來幾步會把這條鏈路拆開驗證。

步驟一：誰佔用了 53 埠

請在重現問題的當下，用具權限的指令檢查 53 埠（UDP／TCP）由誰監聽。常見工具如 ss -lunpt | grep ':53' 或發行版內建的 socket 列表。若你看到 systemd-resolved 或 libresolved 相關程序已佔用 127.0.0.53:53，而 Clash 設定又要求在本機 53 提供 DNS，就必須二選一或改監聽埠：要嘛讓 Clash 改監聽例如 1053 等非衝突埠並由防火牆／dnsmasq 轉發（進階），要嘛關閉或調整 resolved 的 DNSStubListener（風險與步驟因發行版而異，需自行評估），要嘛乾脆不要讓 Clash 在本機當「唯一 53 服務」，改採不與 stub 搶佔 53 埠的架構，沿用系統既有解析鏈。

實務上許多桌面使用者不必讓 Clash 綁定 53：若客戶端以 TUN 或透明 DNS 轉發方式工作，核心可能自行攔截 DNS 查詢而不需要你額外佔用系統 stub 的埠。若你啟用 TUN 後症狀改變，可對照Clash TUN 模式深度解析理解覆蓋範圍與路由互動。重點是：埠衝突不是「偶發小毛病」，而是會讓症狀看起來像節點或規則壞掉，因此請務必在調 Fake-IP 前先排除。

步驟二：Clash 設定中的 DNS 區塊與監聽位址

在 Mihomo／Clash Meta 系設定中，dns 區塊通常包含 enable、上游列表（nameserver、fallback）、listen、以及 enhanced-mode（或等同選項，依版本文件為準）。請逐一確認：

• listen 是否與步驟一的占用者衝突；若衝突，先改設定或關閉其中一方再測。
• 上游 DNS 是否能從你目前的網路環境連線（公司網路阻擋 DoH／外部 53 時特別常見）。
• ipv6 相關開關是否與你實際堆疊一致；雙堆疊環境下錯配可能造成「看似解析到卻連不上」。

圖形客戶端（如 Clash Verge 系列）通常會把上述對應到進階設定頁；若你尚未完成安裝與訂閱匯入，可先參考Ubuntu 24.04 的 Clash Verge 與 systemd 自啟或Arch Linux 與 AUR 安裝流程，再回到本文做 DNS 專項除錯。請記得：修改後需重載核心或重啟客戶端，否則舊的 DNS 監聽設定可能仍在。

步驟三：Fake-IP 與 redir-host 何時像「解析壞了」

Fake-IP（或舊稱 fake-ip 模式）的核心思想，是對部分查詢快速回傳虛擬位址，讓規則引擎能盡早決定連線策略，再由核心在後續階段還原真實目標。當應用程式或除錯工具看到的是這些虛擬 IP，使用者容易誤以為「DNS 解析錯了」。若你同時在瀏覽器裝了獨立 DNS外掛、或某程式繞過系統解析器直連指定 DoH，則 Clash 可能看不到該次查詢，規則與 Fake-IP 也就無法如預期介入，症狀會像「只有某個瀏覽器異常」。

相對地，redir-host（或文件中的 redir-host／映射模式）較偏向讓解析結果與傳統意義上的主機名對齊，對某些依賴「解析結果必須可稽核」的工具較友善，但可能增加規則判斷的複雜度。實務排查建議：在隔離變因的前提下，暫時關閉瀏覽器 DNS 外掛、固定用同一瀏覽器設定檔測試，並在客戶端連線日誌中確認查詢是否進入核心。若完全沒有 DNS 日誌，優先回到步驟零與步驟一檢查鏈路，而不是先改規則。

步驟四：讓「系統要問的 DNS」與 Clash 預期一致

當 stub resolver 指向 127.0.0.53 時，你的「系統 DNS」實際上是 systemd-resolved 的政策。若你希望所有應用程式的查詢都進 Clash，常見做法包括：由 TUN 模式攔截、由客戶端設定「接管系統代理／虛擬網卡 DNS」、或調整 resolved 的上游與轉發（進階且因發行版而異）。反之，若你只希望瀏覽器走代理，而終端機與部分工具仍用 stub，則要接受不同程式看到不同解析路徑的事實，並在除錯時註明「哪一個程式」異常。

與「國內外解析不一致」相關時，請同時檢查：地理分流規則是否讓某類網域固定走特定出口，導致你看到的 DNS 答案偏向該出口所在網路的最佳化結果；以及 systemd-resolved 是否快取了舊答案。可嘗試在測試前清除快取（指令與權限依版本而異，請參考發行版文件），並以單一測試網域重複驗證。若你需要從頭建立安裝與基礎觀念，可搭配本站Clash 使用教學；取得客戶端安裝檔則建議以本站下載頁為主，與上游原始碼頁面分開看待。

可列印核對清單（精簡版）

將下列項目依序勾選，可覆蓋多數 Linux＋Clash 的 DNS 類症狀：

1. /etc/resolv.conf 是否指向 127.0.0.53？若是，記住「實際決策在 systemd-resolved」。
2. 53 埠是否只有一個監聽者符合你的設計？Clash 與 resolved 是否衝突？
3. Clash dns.listen 與防火牆／SELinux 是否允許（Fedora 等可對照本站 firewalld 教學思路）。
4. 上游 DNS（含 DoH）在目前網路是否可達；公司網是否攔截。
5. Fake-IP 是否開啟？應用程式是否繞過系統解析？
6. 變更後是否已重載核心／重啟客戶端，並用連線日誌確認查詢進入點？

常見問題

我把 nameserver 改成 127.0.0.1 指向 Clash，為什麼反而全機斷網？

若 Clash 的 DNS 服務未成功監聽、或與 53 埠占用衝突，系統解析器會把查詢送到一個無法回應的位址，表現就像全機解析失敗。請先確認服務狀態與埠占用，並優先採用發行版支援的方式調整，而非長期手改 resolv.conf。

Fake-IP 開著時，dig／nslookup 看到的 IP 很怪，是中毒了嗎？

不一定是安全問題；許多情況是 Fake-IP 機制下的預期行為。請以客戶端日誌與實際連線是否成功為準，並閱讀你所用核心的 DNS 模式說明。

只有瀏覽器異常，curl 卻正常，還要查 systemd-resolved 嗎？

要。這代表解析路徑可能分裂：瀏覽器可能使用安全 DNS、外掛或獨立快取。請分別測試無痕模式、停用外掛，並比對系統 Proxy／TUN 是否只影響部分流量。

總結來說，Linux 上 Clash 的「網頁打不開」若集中在解析逾時、NXDOMAIN、或國內外答案不一致，請先把 systemd-resolved、stub、53 埠與核心 DNS 區塊當成同一條鏈路來排查，再處理 Fake-IP 與規則。相比只反覆更換節點，這套順序更能對症下手，也與本站其他「分流規則」專文互補。若你希望找一款能清楚呈現連線與 DNS 行為、並承載現代 Mihomo 功能的客戶端，不妨先從本站取得適合的版本實測——相較於僅依賴整機 VPN，規則型工具在可觀測性上往往更利於長期維護。→ 立即免費下載 Clash，開啟流暢上網新體驗。