Clash Fake-IP 區網與路由器打不開？繞過規則與嗅探

症狀：Fake-IP 開著，區網卻像斷線

典型情況是：Clash 訂閱與節點都正常，一開啟 Fake-IP（或搭配 Redir／TUN 的等效行為），瀏覽器就打不開 192.168.1.1、NAS 的網頁管理、印表機後台，或區網內某個以 .local、.lan 結尾的位址。有人會誤判成「路由器壞了」或「節點被牆」，其實多半是解析與路由決策在本地就先走偏：應用程式拿到的目標位址已經不是你在區網裡預期的那個，或規則把該連線送進了錯誤的策略組。

這與「手機連不上電腦代理埠」那類區網共享問題不同；若你同時在折騰 HTTP／SOCKS 分享，請先對照區網共享與防火牆專題，確認綁定位址與網段無誤，再回到 Fake-IP 與規則本身。若遠端 HTTPS 仍異常，可再搭配連線日誌與 TLS 排查，避免把兩層問題攪在一起。

ℹ 先釐清目標：區網裝置通常應直連（DIRECT），不要經過遠端代理節點。Fake-IP 只是 DNS 層的加速與相容手段，不能取代「私有位址必須直連」這條直覺。

原理：假位址、DNS 與規則如何一起誤導流量

在 Fake-IP 模式下，Clash 可能先給應用程式一個本機配置的虛擬位址池回應，真正的網域名解析與路由決策往往在核心內部完成。好處是相容舊式應用、也能降低部分 DNS 污染干擾；代價是：若某個區域網路存取目標被錯誤地納入假位址流程，或規則沒有優先把私有網段標成直連，連線就可能被送往代理，表現為「打不開路由器後台、NAS 管理頁一直轉圈」。

另一條常見分支是：你用網域名開啟路由器（例如 router.home），但嗅探與 SNI 還原尚未對齊，核心只能依假位址或寬泛規則做決策，結果命中了預設的 MATCH 規則而被送去代理。這就是為什麼實務上會同時處理繞過規則、DNS／fake-ip-filter，以及在需要時啟用網域嗅探（sniffing）——三者解決的是不同層次的資訊不足，而不是互相取代。整體規則結構仍建議遵循規則分流最佳實踐裡「細則在前、寬則在後」的順序思維。

繞過規則：私有網段請放在最前面

最穩健、也最該優先複製進設定檔的，是一組針對 RFC1918 私有位址與本機迴環的繞過規則：讓這些目標一律 DIRECT，並確保它們出現在訂閱帶入的寬泛規則（例如全盤 GEOIP 或過寬的 MATCH）之前。實務上常見寫法是以 IP-CIDR 覆蓋 127.0.0.0/8、10.0.0.0/8、172.16.0.0/12、192.168.0.0/16，並視環境補上鏈路本機位址 169.254.0.0/16（部分印表機或裝置發現會用到）。

若你的環境還使用 Carrier-grade NAT 或其他非公網區段，請依實際路由表增刪，不要盲抄教學。重點不在「背 CIDR」，而在規則順序：任何會把未知流量預設送去代理的規則，都不應該比私有網段直連更早命中。若你使用規則集（rule-providers），也要確認「區網／私有位址直連」是否被後載的集合意外覆蓋——那通常不是覆蓋，而是順序放錯。更多關於策略組與 RULE-SET 的維護方式，仍請以可讀性為優先，必要時把直連條目獨立成註解清楚的一段，方便日後 diff。

Illustrative rules fragment (order matters)

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,169.254.0.0/16,DIRECT
  - IP-CIDR,224.0.0.0/4,DIRECT
  # ... your subscription / GEOIP / MATCH rules below

路由器後台：IP 直連與本機網域名

若你在網址列直接輸入 192.168.x.x，理論上應走三層位址匹配：繞過規則中的 IP-CIDR 會讓它直連。若仍失敗，請先排除瀏覽器外掛、公司憑證攔截、或 HTTPS 強制升級造成的例外；再確認本機沒有另一層「系統代理」與 Clash 重疊導致流量繞圈。若你是用廠商提供的路由器後台網域名（例如 tplinkwifi.net、myrouter.local），則除了 IP 規則外，還需要讓該網域名在 DNS 與 fake-ip 行為上被視為「應拿到真實解析或至少直連」，否則仍可能出現「解析到了、但策略錯了」的組合問題。

實務上可以為已知的管理網域補 DOMAIN-SUFFIX 或 DOMAIN 直連規則，但長期仍建議搭配下文 fake-ip-filter 與嗅探，避免每換一台路由器就手動加後綴。若環境允許，用固定 IP 開管理頁是最利於除錯的路徑；域名則留給家人與手機 App 使用即可。

嗅探 sniffing：何時能還原真實網域

當連線已建立、但核心一開始只知道目標是一個假位址或 IP，嗅探（sniffing）可以從 TLS Client Hello 等資訊嘗試還原功能變數名稱，讓後續規則有機會依網域再做一次命中。對於「HTTPS 網站走代理／直連」這類依賴 SNI 的場景，嗅探能減少假位址與實際業務網域不一致的落差。對於純 IP 的區網管理頁，嗅探通常不是主角——此時仍應以 IP-CIDR 直連為主。

各 Clash 衍生核心（含 Mihomo／Clash Meta）對 sniffing 的鍵名與細項可能略有差異，圖形客戶端也常把它包成「進階／實驗」選項。啟用後若你觀察到少數 HTTPS 網站異常，請回頭檢查覆寫範圍與排除清單，並在日誌中核對還原出的網域是否與預期一致。與透明接管相關的整體觀念，可一併參考 TUN 模式深度解析，避免與路由表、DNS 形成多重改写。

Illustrative sniffer block (Meta / Mihomo style — adjust keys for your core)

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]
    HTTP:
      ports: [80, 8080]
  skip-domain:
    - Mijia Cloud
    - '+.apple.com'

DNS 與 fake-ip-filter：別把區網域名塞進假池

若你把某些本應由區網 DNS 或 mDNS 回答的名稱，也丟進了 Fake-IP 流程，應用程式可能拿到一個「看起來像真的、其實不屬於你區網」的位址。為此，DNS 區塊中常見做法是設定 fake-ip-filter（或等效選項），把 *.lan、*.local、路由器廠商網域、以及你 NAS 的區網專用名稱列入「不要用假 IP 回應」的清單，讓解析回到你期望的路徑，再交給上層規則做直連。不同核心與版本在鍵名上可能叫 fake-ip-range、nameserver-policy 等，請以你正在使用的發行說明為準。

也請避免同時讓多個工具改写系統 DNS：例如 VPN、其他「加速」軟體與 Clash 一起改 /etc/resolv.conf 或 Windows 介面，會讓「偶發能開、偶發不能開」更難查。可先固定只留一個 DNS 決策者，再觀察區網設備是否恢復。更多概念層說明可見常見問題中與 DNS、模式相關的段落。

Illustrative DNS fake-ip-filter fragment

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '*.home.arpa'
    - 'router.lan'
    - 'nas.local'

TUN 與系統代理：行為差異與對照實驗

在系統代理模式下，只有尊重系統代理的應用會走 Clash；而 TUN 模式會在系統層接管更多流量，對「漏網之魚」更敏感，但也更容易與其他 VPN 或虛擬網卡搶路由優先順序。當你遇到「同一臺電腦上，瀏覽器能開路由器、某個 App 卻不行」時，優先懷疑是否只有部分流量進了 Clash。此時不必急著全局關閉 Fake-IP，可先對照：僅系統代理／僅 TUN／兩者皆開時的行為差異，並在日誌中確認該 App 的連線是否被記錄。

若你暫時需要最快恢復區網可用性，可在合規前提下將路由器、NAS 相關網域或 IP 規則提到最前，並避免讓預設策略把未知目標一律送往高延遲節點；長期仍應回到結構化規則與訂閱更新流程，避免「臨時直連清單」無限膨脹。

可複製的設定片段（示意）

下面將前述片段合併成一段較完整的示意（仍須依你的核心版本、策略組名稱與訂閱結構調整）。重點是：私有網段直連在前，DNS fake-ip-filter 覆蓋區網名稱，sniffer 作為 TLS／HTTP 場景的補強，而不是取代 IP 規則。

Combined illustrative YAML (customize before use)

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - '*.lan'
    - '*.local'
    - '+.router.home'

sniffer:
  enable: true
  sniff:
    TLS:
      ports: [443, 8443]

rules:
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-CIDR,10.0.0.0/8,DIRECT
  - IP-CIDR,172.16.0.0/12,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT
  - IP-CIDR,169.254.0.0/16,DIRECT
  - DOMAIN-SUFFIX,router.home,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

⚠ 合規與安全：請在合法、授權的網路環境中調整路由與 DNS。勿將本文用作規避組織資安政策或存取未授權系統；企業內網請依網管規範操作。

檢查清單與日誌對照

建議依序自查，將「區網／Fake-IP」與「節點品質」分開驗證：

確認 rules 最前段已包含私有 IP-CIDR 直連，且順序在寬泛代理規則之前。
以 IP 開啟路由器後台測試；若 IP 可而域名不行，優先檢查 DNS 與 fake-ip-filter。
在連線日誌搜尋目標位址或還原網域，核對命中規則是否為 DIRECT。
啟用嗅探後若僅少數 HTTPS 異常，為該網域新增排除或收窄嗅探埠。
比對系統代理與 TUN：若僅特定 App 異常，懷疑流量未進核心或被他程式攔截。
仍無法判讀時，將日誌對照 timeout 與 TLS 專題，區分 dial、握手與策略命中問題。

結語

Clash Fake-IP 能帶來更順的解析體驗，但在區域網路存取場景中，必須把私有位址與本機網域名從一開始就放回「直連」這條軌道：繞過規則處理 IP、fake-ip-filter 處理名稱、嗅探在需要時補上網域資訊。三者分工清楚，就不會再把「路由器後台打不開」誤認成節點故障。

相比一次性手改某幾行規則，把區網直連與 DNS 過濾寫成可維護的區塊，長期會更省力；圖形介面若能把模式、DNS 與規則命中講清楚，日常也會少很多猜測。若你正在挑客戶端，仍可參考全平臺客戶端對照，選擇日誌與設定結構較透明的一款。

→ 立即免費下載 Clash，開啟流暢上網新體驗，在釐清 Fake-IP、繞過規則與嗅探之後，讓區網設備與跨境流量各走其路、互不拖累。

Clash Fake-IP 模式下區域網路與路由器後台打不開？繞過規則與嗅探設定步驟