為什麼「換了節點」仍解決不了打不開？
在 Clash 生態裡，節點品質當然重要，但大量「網頁空白、TLS 握手卡住、只有某幾個域名怪怪的」現象，其實發生在DNS 與連線建立之前或同時。當 DNS 模式設為 fake-ip 時，本機應用程式往往先拿到一個虛擬位址，真正的域名解析延後到代理核心內部再做；這能減少重複查詢、讓規則更早介入，卻也可能讓必須依賴真實 IP的場景（例如區網 mDNS、某些企業內部 DNS、或只在內網有效的名字）出現解析失敗或連到錯誤目標。
相對地，redir-host（或語意相近、以真實主機名為主的模式）讓應用程式與核心在「誰先查 DNS、誰持有結果」這件事上更接近傳統行為，對內網存取通常較直覺，但有時會讓規則匹配與快取行為變得較依賴上游 DNS 與本機快取，進而出現「規則看起來對，實際卻走了意外路徑」的情況。理解這個取捨，比反覆重啟客戶端更能縮小問題範圍。
Fake-IP 與 Redir-Host：概念上差在哪？
以下用使用者可感知的語言說明，避免陷入實作細節差異：在常見配置下，Fake-IP的核心想法是「應用程式先連上一個本機配置的虛擬 IP，實際要連哪台機器、走哪條策略，由 Clash 在內部根據原始域名決定」。因此，應用程式 socket 層看到的目標位址，未必是你在 ping 或 nslookup 裡看到的那個。
Redir-Host則較偏向「盡量帶著真實主機名與（或）已由系統／核心解析出的位址往下游傳遞」，對需要與作業系統解析結果高度一致的工具、或某些只認真實區網段的情境，通常較友善。兩者沒有絕對優劣，只有與你的分流規則、是否使用 TUN、以及內網資源依賴程度是否合拍。
*.local、路由器主機名、公司內部網域、NAS」等關鍵字，先優先懷疑 fake-ip 與過濾名單是否涵蓋不足，而不是先換訂閱。
該選哪一種？用三個問題快速決策
第一，你是否頻繁需要區網名稱解析？ 若家裡或辦公室習慣用 nas.lan、printer.local 這類名字，且沒有把它們完整列入例外，fake-ip 下較容易遇到解析異常。可優先嘗試：補齊 fake-ip-filter（或你使用分支中等價設定）後仍保留 fake-ip；若仍怪，短期改 redir-host 做對照。
第二，你的客戶端是否以 TUN 為主接管流量？ TUN 會改變整機流量走向與 DNS 注入方式，與「僅系統代理」體感不同。建議一併閱讀我們在TUN 與系統代理對照教學中的平台注意事項，再把 DNS 模式變更與 TUN 開關做單因次實驗，否則很難判斷是哪一層造成網頁打不開。
第三，你是否依賴「國內直連＋海外代理」的細緻分流？ 在規則複雜、Rule Providers 很多的設定裡，fake-ip 常能讓域名層級規則較早生效；但若上游 nameserver 對特定網域回傳不理想，也可能放大「少數站點異常」。此時應同步檢查 fallback、nameserver-policy（或同等機制）是否針對該網域指定更合適的解析來源，而不是只來回切模式。
常見症狀：如何從現象反推 DNS 層問題
當Clash Fake-IP與規則搭配不當時，使用者看到的往往不是清楚的「DNS 錯誤」提示，而是瀏覽器轉圈、應用程式顯示無法連線、或只有 HTTPS 網站異常。若同一台裝置在關閉代理、或改為 redir-host 後立刻恢復，高度指向DNS 模式或過濾名單與該應用的假設不相容。
另一典型情況是：內網存取正常、外網也正常，但某幾個「理論上應直連」的國內站反而慢或打不開。此時請先確認規則是否真的讓該域名直連，再檢查直連路徑上是否仍由 Clash 做 DNS；若仍在核心內解析，就要看 nameserver 是否對該域名有污染、劫持或次優路由。不要先把責任推給「節點被封」，除非日誌已顯示流量確實進了代理卻握手失敗。
排查步驟：建議依序執行（單次只改一項）
步驟一：確認症狀是否僅發生在特定類型名字。 收集三個樣本：一個純內網主機名、一個常見公網域名、一個你覺得「應該直連」的國內站。分別在代理開啟／關閉下用瀏覽器與（若方便）命令列工具對照。若只有內網名出問題，優先處理 fake-ip-filter 與相關域名規則。
步驟二：檢視 fake-ip-filter（或等價設定）是否涵蓋內網與必要例外。 常見需納入的包含：*.local、路由器後台域名、公司內部網域後綴、以及你希望「完全不要走虛擬 IP」的監控或證書類服務。調整後請重啟核心或重新載入設定，並清除應用程式 DNS 快取（瀏覽器、部分系統需重啟網路介面）。
步驟三：暫時切換 redir-host 做 A／B 測試。 若切換後內網與問題域名立刻正常，代表原本 fake-ip 路徑與該應用不相容或過濾不完整；此時你可選擇長期使用 redir-host，或在維持 fake-ip 的前提下補規則與過濾，兩者皆可，重點是用對照實驗驗證假說。
步驟四：檢查上游 DNS 與 fallback 鏈。 將 nameserver 暫時簡化為少數可信來源做交叉驗證；若使用 DoH／DoT，確認系統時間正確、憑證鏈無攔截。若只有特定區域域名異常，為其單獨指定解析策略通常比全域改模式更有效。
步驟五：用日誌對照「域名 → 規則 → 實際策略」。 當你懷疑某站走了錯誤策略組，請在客戶端日誌中找該次連線對應的域名與命中規則；若日誌顯示域名被替換或延後解析，回到 DNS 段設定與 TUN 是否一致。需要更細的分流觀念時，可搭配YAML 規則與策略組教學理解優先順序，避免只改 DNS 卻被更上層規則覆蓋。
與行動端教學的關係：Android 仍請先看另一篇
若你主要在 Clash for Android 上遇到「節點全紅、全面逾時」這類連線層問題，請優先依序處理 VPN 權限、私人 DNS、分應用代理與測速網址等流程；本站已有專文從手機系統角度拆解，與本文進階 DNS 模式取捨互補而非重複。你可從Android 節點逾時與 DNS 排查入手，再回到本文補齊 fake-ip／redir-host 在桌面或通用 YAML 上的細節。
寫在最後：模式是工具，證據才是答案
Redir-Host與Clash Fake-IP之間的選擇，本質上是在「規則介入時機、解析一致性、內網相容性」之間找平衡。沒有一鍵適用全世界的預設值；真正可靠的做法，是為自己的網路環境建立一份可重複的對照實驗：每次只改一個參數，用日誌與三類域名樣本驗證，並把有效的例外寫回設定檔，而不是在論壇隨機抄一段 YAML。
相較於僅憑感覺切換節點，願意花時間釐清 DNS 模式與本地域名問題的使用者，通常能顯著減少「莫名其妙打不開」的挫折感，也更看得懂訂閱裡各種進階開關在做什麼。若你希望使用介面清楚、能搭配較新核心與一致說明的客戶端來落實這些設定，也可從本站整理好的安裝入口開始，少在版本與權限細節上繞路。
歡迎前往我們的下載頁面取得對應平台客戶端；先把 DNS 與內網路徑站穩，再搭配規則與 TUN 進階調校，整體體驗會更可控。
想延伸了解整機透明代理與 DNS 互動時，可一併閱讀技術專欄內與 TUN、YAML 規則相關的文章，依場景補齊知識版圖即可。