Fake-IP 模式如何保留網域資訊：DNS 對映、適用情境與排除項目

一、Fake-IP 與實際位址解析的差異

啟用 Fake-IP 後，查詢某個網站的 A 記錄時，應用程式可能取得 198.18.0.2 這類位址，而不是網站伺服器的公開 IP。這通常是核心主動產生的虛擬位址，不應只憑這個結果判定 DNS 發生故障。它的用途是讓後續連線帶有可回查的標記，由核心還原這次連線對應的網域。

一般 DNS 解析回傳實際位址後，應用程式可能只向網路堆疊提交目標 IP。多個網域共用 CDN 位址時，光靠這個 IP 很難確認原始網域。Fake-IP 則會在 DNS 回應階段建立「網域與虛擬位址」的關聯；連線進入同一個核心後，即可透過對映找回網域，再進行規則比對與出站處理。

Fake-IP 不是代理節點：它是本機處理流程中的位址標記，不代表遠端伺服器的位置。
Fake-IP 不是 DNS 加密：上游使用 UDP、DoH 或 DoT，是另一層設定。
Fake-IP 不等於全域代理：在 mode: rule 下，連線仍會依規則進入直連或代理等目標。

198.18.0.0/16 位於保留作網路基準測試的 198.18.0.0/15 位址空間內，不是網站的實際公開位址，也不是一般家用區域網路的位址區段。如果裝置所在網路已使用這個範圍，應先處理路由衝突，而不是繼續疊加接管規則。

二、從 DNS 查詢到出站連線的五個步驟

理解 Fake-IP 的關鍵，是分開檢視兩條路徑：DNS 查詢進入哪裡，以及取得位址後的連線進入哪裡。只有兩者能對應到同一份有效對映，虛擬位址才有意義。

應用程式發起查詢。例如瀏覽器請求 example.com 的 A 記錄，查詢會經由系統解析器、DNS 轉發或 TUN 的 DNS 接管進入核心。
核心分配虛擬位址。若網域符合 Fake-IP 的處理條件，核心會回傳位址池中的一個位址並儲存對映。本文使用 198.18.0.2 說明流程，實際分配的位址並不固定。
應用程式建立連線。應用程式會對這個虛擬位址的目標連接埠發起連線，例如 HTTPS 使用的 443 連接埠。
核心回查網域並比對規則。核心收到連線後，利用對映識別 example.com，網域規則便取得可供比對的資訊。
依選定的出站方式處理。直連通常需要取得實際目標位址；代理出站可能將網域交由遠端解析，也可能在本機解析，取決於協定、節點選項與核心行為。

應用程式查詢 example.com
  → 核心 DNS 回傳虛擬位址
  → 應用程式連線至虛擬位址:443
  → 同一個核心回查得到 example.com
  → 比對規則
  → 直連或代理出站

因此，「DNS 已回傳 Fake-IP」只能證明查詢路徑的一部分成功，不能證明連線已被接管。若應用程式取得虛擬位址，卻繞過核心直接傳送資料，一般網路並不知道應將它送往哪個網站，通常就會表現為連線逾時。

為什麼已有網域對映，仍可能發生實際 DNS 查詢？

Fake-IP 可以讓應用程式先取得虛擬回應，但不保證整個連線過程完全不查詢實際 IP。直連出站、需要目標 IP 的規則判斷、代理伺服器本身的網域解析等，都可能觸發解析。規則是否帶有 no-resolve、核心是否支援對應的規則選項，也會影響處理流程，不能把「減少部分等待」理解成「取消所有 DNS 查詢」。

三、啟用前檢查 DNS 與連線接管範圍

Fake-IP 更適合需要透明接管，並希望保留網域規則比對資訊的環境，例如已正確設定路由與 DNS 接管的桌面 TUN。它不是所有應用程式連線問題的預設修復方式。

使用方式	網域資訊來源	優先檢查
HTTP 系統代理	代理請求通常已帶有目標主機名稱	應用程式是否遵循系統代理，不能據此推斷整台裝置的 DNS 已被接管
TUN 透明接管	可透過 Fake-IP 對映還原網域	DNS 查詢與虛擬位址連線是否進入同一個核心
區域網路閘道	由閘道 DNS 建立對映	終端裝置的 DNS、閘道路由與回程路徑是否一致
應用程式內建的加密 DNS	可能繞過核心 DNS，直接取得實際 IP	應用程式的安全 DNS、系統加密 DNS，以及現有 VPN 的設定

TUN 提供虛擬網路介面與接管路徑，Fake-IP 提供 DNS 對映，兩者屬於不同層級。開啟 TUN 不代表每個應用程式的 DoH 請求都會變成一般 DNS 查詢；啟用 DNS 的 enhanced-mode: fake-ip 也不會自動替系統設定完整路由。

記錄用戶端版本、核心名稱與核心版本，確認目前執行的不是另一個背景執行個體。
儲存目前生效的設定，以及用戶端另外維護的覆寫片段。只備份訂閱原文可能會遺漏 DNS 設定。
檢查其他 VPN、閘道軟體與安全軟體是否同時修改 DNS 或路由。
初次驗證時只變更 DNS 模式與必要的接管設定，不要同時修改節點、策略群組與規則順序。

四、Fake-IP 設定片段與欄位範圍

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter-mode: blacklist
  fake-ip-filter:
    - "localhost"
    - "*.lan"
    - "*.home.arpa"
  nameserver:
    - 1.1.1.1

兩個連接埠不能混用

7890 是範例中的 HTTP/SOCKS 混合代理連接埠；1053 是核心 DNS 監聽連接埠。瀏覽器的代理設定不能填入 DNS 連接埠。多數系統的 DNS 設定介面也不能直接指定非標準連接埠，因此這段設定適合明確指定連接埠的查詢工具，不會只靠載入 YAML 就自動接管系統 DNS。

listen: 127.0.0.1:1053 會將監聽範圍限制在本機。區域網路中的其他裝置不能將它用作 DNS 伺服器；若要服務區域網路，需另外規劃監聽位址、防火牆與流量路由。allow-lan: false 用於控制代理入口的區域網路存取，不能取代 DNS 監聽位址的安全設定。

過濾模式必須與核心能力相符

在支援 fake-ip-filter-mode 的 mihomo 中，範例明確選擇 blacklist：符合清單的網域不會回傳 Fake-IP，而是採用實際解析。若選擇 whitelist，清單語意會反轉為只有符合項目才使用 Fake-IP。舊版核心未必支援模式欄位，不能把未知欄位遭忽略當成設定成功。

範例 ipv6: false 用於縮小本次 DNS 驗證範圍，不等於關閉作業系統的 IPv6，也不代表其他解析路徑不會回傳 AAAA 記錄。正式環境需要配合 IPv6 路由與實際核心能力重新評估。更多欄位可對照設定大全逐項核對。

五、區域網路相容性問題與排除項目的選擇

部分應用程式需要實際位址，而不只是能建立連線的標記。例如 NAS 管理工具可能會檢查伺服器是否位於本地網段，列印工具可能將解析結果交給不經過代理的探索元件，某些程式還會把 IP 位址傳送給其他裝置使用。在這些情況下，為單一網域保留實際解析，通常比排除所有網域更容易控制影響。

排除 Fake-IP 不等於指定區域網路 DNS

將 "*.home.arpa" 加入過濾清單後，核心只是改為查詢實際位址。公用 DNS 通常不知道家庭網路中的主機記錄。若 NAS 名稱由路由器提供，仍需將對應網域交給路由器 DNS，例如透過核心支援的 nameserver-policy 設定指定解析，並確認路由器的 DNS 服務可連線。

.local 常用於 mDNS，本質上不同於向單播 DNS 伺服器發送一般查詢。將 "*.local" 加入清單不會自動恢復多播探索，也不會讓核心變成 mDNS 轉發器。投放或列印探索失敗時，還要檢查區域網路存取權限、多播流量與 TUN 路由範圍。

先限定網域：單一裝置發生問題時，優先針對該裝置名稱進行驗證，避免直接加入範圍過大的萬用字元。
再確認解析來源：排除後應取得可信任的本地 DNS 回傳的實際位址，而不是公用 DNS 回傳的不存在回應。
最後檢查連線規則：回傳實際位址，不代表流量會自動直連；規則仍可能將該網域送入代理群組。

不同用戶端對清單覆寫可能採用取代或合併策略，核心也可能有與版本相關的預設排除項目。修改後應查看最終生效的設定，而不是只看編輯器中新增的幾行。不要為了消除一個相容性問題就排除所有網域，否則很難再驗證 Fake-IP 是否參與處理。

六、依查詢、對映、規則與出站順序進行驗證

1. 單獨驗證核心 DNS 回應

在已安裝 dig 的 macOS、Linux 或其他環境中，針對上述本機監聽位址執行：

dig @127.0.0.1 -p 1053 example.com A +short

若網域未被排除，預期會回傳所設定範圍內的虛擬 IPv4 位址；具體位址並不固定。若發生逾時，先檢查核心是否啟動、DNS 是否啟用，以及 1053 是否已被占用。若回傳實際位址，則核對過濾模式、預設排除項目，以及目前執行中的設定是否確實包含修改。這裡是預期行為說明，不是本站實測紀錄。

2. 使用實際應用程式驗證連線接管

確認系統或應用程式的 DNS 已依預定路徑接入後，用瀏覽器開啟測試網域，同時觀察用戶端的連線紀錄。應核對目標網域、命中規則、出站策略與連線錯誤，而不只是觀察「網頁是否開啟」。直接對核心執行一次 dig，不會自動讓瀏覽器採用相同的解析路徑。

明確指定 HTTP 代理的請求本身通常帶有網域，因此「透過代理連接埠存取成功」只能驗證該代理路徑，不能單獨證明 TUN 的 Fake-IP 回查正常。同樣地，對虛擬位址執行 ping 的結果不適合用來判斷 HTTPS 是否可用，ICMP 的處理方式與 TCP 連線並不相同。

3. 對照錯誤發生的位置

現象	優先檢查	下一步
查詢取得虛擬位址，但連線紀錄為空	應用程式是否繞過核心連線	檢查 TUN 路由、應用程式排除設定及其他 VPN
重新啟動核心後部分網站失敗	應用程式快取是否仍保留舊的虛擬位址	關閉舊連線、重新整理 DNS 快取並再次查詢
排除 NAS 網域後仍無法解析	該網域是否交由知道本地記錄的 DNS 處理	檢查指定解析及路由器 DNS 回應
網域與規則都正確，但出站逾時	節點、直連目標或出站解析是否可用	轉向檢查連線路徑，不要繼續擴大過濾清單

4. 清除快取後再進行單一變因複測

在 Windows 中可使用 ipconfig /flushdns 清除系統 DNS 快取；Linux 若使用 systemd-resolved，可執行 resolvectl flush-caches。瀏覽器、應用程式與核心可能各自擁有快取，系統指令不會清除所有層級。關閉測試應用程式的舊連線後重新發起請求，才能減少舊結果的干擾。

支援的核心可使用 profile.store-fake-ip 持久化對映，但這不能取代路由設定，也無法保證外部快取與對映始終同步。更換位址池或清除核心快取後，仍應讓應用程式重新解析。

七、常見問題與回退方式

Fake-IP 能保證所有網域規則都命中嗎？

不能。應用程式直接存取 IP、自帶 DNS 繞過核心、對映遺失，或規則被更前面的項目攔截，都可能影響比對。流量嗅探有時能從協定中補充主機名稱資訊，但這是獨立能力，不能保證對加密或非標準協定都有效。

啟用 Fake-IP 後，所有網域都會在代理伺服器上解析嗎？

不是。應用程式看到虛擬位址，只代表本地 DNS 回應採用了對映機制。實際解析發生在本機還是遠端，仍取決於規則、出站協定與節點設定。代理伺服器本身的網域也需要可用的解析路徑，應避免依賴尚未建立的代理連線而形成迴圈。

修改過濾清單後需要更新訂閱嗎？

通常需要重新載入應用程式設定或核心，並讓應用程式重新查詢，不必把更新訂閱列為固定步驟。若直接修改訂閱產生的檔案，下次更新可能會覆蓋變更。應在用戶端支援的持久覆寫入口儲存修改，之後查看最終設定，確認清單語意。

如果出現大範圍連線失敗，先恢復先前儲存的 DNS 與接管設定，再處理系統與應用程式快取。只將模式改回 redir-host 卻保留舊的虛擬位址快取，可能讓故障暫時持續；只退出用戶端，卻留下系統代理或 DNS 指向已停止的本機連接埠，也會造成新的斷網現象。

提交疑難排解資訊時，保留用戶端與核心版本、查詢指令及結果、命中規則與錯誤時間，並移除訂閱 URL、權杖與節點憑證。驗證目標應是「查詢與連線進入同一個核心、網域對映有效、規則與出站符合預期」，而不是單純追求 DNS 結果顯示為某個位址區段。