· 進階設定 · 約 12 分鐘

V2Ray DNS 分流設定：中國大陸網域直連解析與境外網域防污染

說明 DNS 模組的運作方式，示範中國大陸網域使用本地解析、境外網域使用遠端 DNS 的分流設定，並整理 FakeDNS、快取與路由搭配時的常見問題。

本文速覽

本文適合已具備可用代理出站、需要調整 DNS 策略的使用者。先釐清解析器選擇與查詢傳輸路徑，再整合中國大陸網域規則、遠端 DoH 與直連出站設定，最後透過獨立測試入口檢查解析鏈路。範例採用 V2Ray 風格的 JSON 片段，不會取代訂閱中的伺服器設定，也不假設所有用戶端都使用相同核心。

一、DNS 分流分為解析器選擇與查詢路由

DNS 分流不是把兩個伺服器位址放進清單就完成了。第一步是決定某個網域交由哪個解析器處理，第二步是決定連往解析器的連線採直連或代理。兩者都設定清楚，才能確認境外網域的查詢是否經過預期鏈路。加密 DNS 能保護查詢傳輸，但無法保證解析服務回傳的結果永遠正確。

網域進入核心 選擇解析器 比對查詢路由 取得解析結果 建立目標連線

核心 DNS 不等於作業系統 DNS。應用程式透過 SOCKS 傳入網域時，代理協定可能會把網域交由伺服器解析；若應用程式先呼叫系統解析器取得 IP，核心看到的可能只有 IP。只修改設定中的 dns 物件，不會自動接管電腦或手機上所有程式的查詢。

二、設定前確認核心、規則檔與出站標籤

v2rayN 是桌面端設定管理用戶端，實際行為取決於目前使用的核心。Android 版 v2rayNG 使用 Xray 核心，v2flyNG 則使用 V2Fly 核心。兩者許多欄位相近，但不代表所有 DNS 選項、FakeDNS 行為和預設值都完全相同。請先記下核心名稱與版本，再對照相關設定文件確認欄位是否支援。

  1. 在 v2rayN 的「設定」→「參數設定」中確認與目前核心相關的選項；DNS 設定入口會因用戶端版本而異，請以實際介面為準。
  2. 先備份目前的設定，查看產生的設定檔中 outbounds，記下代理與直連出站實際使用的 tag。
  3. 確認執行目錄中的 geosite.dat 可以讀取，且包含 cn 分類。只有使用 IP 分類時，才需要相應的 geoip.dat 規則。
  4. 先確認代理連線可用，再調整 DNS。若代理出站本身無法連線，遠端查詢失敗不一定是解析器造成的。
53
範例直連 DNS 的 UDP 連接埠
443
範例遠端 DoH 的 HTTPS 連接埠
1053
下文回環測試入口的連接埠

這些數字是設定所用的連接埠，不是效能測試結果。下文將現有代理出站稱為 proxy，直連出站稱為 direct；若實際標籤不同，引用處也要一併替換，不能只複製規則中的名稱。

三、中國大陸網域使用直連 DNS，其餘查詢使用遠端 DoH

將以下片段合併至現有設定頂層的 dns 欄位。中國大陸分類優先使用 223.5.5.5 查詢，未符合該分類的查詢則使用 https://1.1.1.1/dns-query。這兩個位址只是具體設定範例，不代表在所有網路環境中都能連線，也不表示一定要使用這組公共解析服務。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "port": 53,
        "domains": [
          "geosite:cn"
        ],
        "skipFallback": true
      },
      {
        "address": "https://1.1.1.1/dns-query"
      }
    ]
  }
}

遠端位址使用 IP 字面值，可減少「連線至 DoH 前還得先解析 DoH 網域」的前置依賴，但仍須通過 TLS 憑證驗證。請勿為了解決連線錯誤而關閉憑證驗證。若改用網域形式的解析服務，也要安排該服務網域的引導解析，避免再次依賴尚未建立的同一條 DNS 鏈路。

四、為 DNS 查詢指定出站，避免預設路由改變連線路徑

以下規則片段採用 AsIs，先處理兩個解析端點，再處理中國大陸網域，最後將其餘 TCP 與 UDP 連線交由代理處理。一般的 https:// DoH 與帶有本地直連語意的 https+local:// 不可混為一談：本例需要查詢連線經過核心路由，因此使用前者。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["223.5.5.5"],
        "port": "53",
        "network": "udp",
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["1.1.1.1"],
        "port": "443",
        "network": "tcp",
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

這是方便觀察連線路徑的基本策略，不包含區域網路、企業內網或廣告分類等規則。合併時應保留必要的既有規則並檢查順序：規則通常依序比對，放在末尾的兜底規則不能提前攔截解析端點規則。上述 IP 與連接埠規則也會比對連往同一端點的其他連線，不只辨識 DNS 模組產生的流量。

直連出站也要檢查 Freedom 的網域策略。以下是既有直連出站應具備的結構；請修改對應項目，不要新增另一個同名標籤。UseIP 會讓該出站透過內建 DNS 取得目標 IP，否則預設行為可能仍依賴系統解析。

{
  "tag": "direct",
  "protocol": "freedom",
  "settings": {
    "domainStrategy": "UseIP"
  }
}

結論：分別確認解析路徑與連線路徑

先確認中國大陸網域的直連出站確實會呼叫內建 DNS，再確認遠端 DoH 連線符合代理規則。只看到網頁能開啟，無法證明 DNS 分流已生效；代理請求若攜帶網域，目標解析仍可能在伺服器端進行。

五、透過獨立 DNS 入口驗證，別把瀏覽器快取當成結果

若要直接測試內建解析模組，可在現有 inbounds 與 outbounds 陣列中分別加入以下物件。入站只綁定 127.0.0.1，不要改成對外監聽位址。此入口供本機排查使用，不會自動修改系統 DNS，也不會自動接管瀏覽器查詢。

{
  "tag": "dns-in",
  "listen": "127.0.0.1",
  "port": 1053,
  "protocol": "dokodemo-door",
  "settings": {
    "address": "1.1.1.1",
    "port": 53,
    "network": "tcp,udp"
  }
}
{
  "tag": "dns-out",
  "protocol": "dns",
  "settings": {}
}

接著將以下規則放到前文 routing.rules 的最前面，讓測試請求進入 DNS 出站，而不是被末尾的代理兜底規則接走。DNS 出站會對 A、AAAA 查詢呼叫內建解析模組；其他記錄類型的處理與轉送行為應另行驗證，不要用一次 TXT 查詢取代本例的位址記錄測試。

{
  "type": "field",
  "inboundTag": ["dns-in"],
  "outboundTag": "dns-out"
}
  1. 重新啟動核心，先檢查設定載入記錄，排除連接埠遭占用、欄位不明及規則檔讀取失敗等問題。
  2. 在已安裝 dig 的環境中執行以下指令，分別測試中國大陸分類與遠端解析路徑。
  3. 搭配 DNS 除錯記錄與出站存取記錄，確認兩個解析端點實際使用的標籤。排查期間可暫時提高記錄層級，完成後再調回原設定。
  4. 每次只修改一項設定。重複查詢可能會命中快取；必要時重新啟動核心並清除應用程式或系統快取，再比對結果。
dig @127.0.0.1 -p 1053 www.baidu.com A
dig @127.0.0.1 -p 1053 www.example.com A

測試網域是否符合分類，仍須以目前使用的規則檔為準。解析結果不同不一定代表遭到污染；CDN 調度、解析服務位置與快取狀態都可能影響答案。應觀察查詢是否送往預期的解析器、是否逾時，以及最終目標連線是否成功，而非只比較兩次回傳的 IP。

六、FakeDNS、快取與路由解析策略的適用範圍

FakeDNS 回傳的是供核心映射使用的合成位址，不是目標網站的真實位址。它主要用來處理流量進入代理後保留或還原網域資訊的需求，不能取代真實解析服務，也無法修復無法連線的代理伺服器。啟用前應確認目前的核心、流量接管方式與網域還原鏈路都支援相應設定。

設定或機制實際作用常見誤判
DNS queryStrategy控制內建解析模組查詢或使用的位址類型。設為 IPv4 後，誤以為所有應用程式都不會再發出 IPv6 流量。
routing.domainStrategy控制路由比對時是否為網域取得 IP。把 AsIs 誤解為整個核心永遠不會解析網域。
Freedom domainStrategy控制直連出站建立連線時如何處理網域。只修改 DNS 清單，卻仍讓直連出站依賴系統解析。
FakeDNS維護網域與合成位址的映射，後續流量必須回到能還原映射的核心。只啟用合成回應，卻未確保對應連線也由核心接管。
DNS 快取重複使用先前取得的解析結果，減少重複查詢。修改設定後仍看到舊結果，就認定新設定未載入。

IPIfNonMatch 會在網域規則未符合時嘗試解析，再繼續比對 IP 規則；IPOnDemand 則會在比對需要 IP 的規則時觸發解析。兩者都可能增加本機查詢。若設定中已有必定符合的兜底規則，別想當然地認為每個網域都會進入 IP 解析階段。

七、DNS 分流常見問題與排查順序

設定了遠端 DNS，為什麼瀏覽器還是向本地解析器查詢？

先確認查詢是否進入核心。使用上文的 1053 連接埠測試入口單獨驗證，再檢查瀏覽器安全 DNS與系統代理行為。一般系統代理主要處理應用程式連線，不代表會接管作業系統的 UDP 53 查詢。

中國大陸網站可以開啟，境外網域卻一直解析逾時，該怎麼辦？

檢查 1.1.1.1:443 是否符合 proxy，並確認該標籤存在且代理連線正常。接著檢查 TLS 錯誤與系統時間。若代理伺服器位址本身是網域，也要排除其引導解析依賴遠端 DoH 而造成的循環。

更新訂閱後，剛設定的 DNS 怎麼不見了？

確認修改內容是否寫在用戶端暫時產生的執行設定檔中。切換節點或重新啟動時，產生的檔案可能會被覆寫。請使用目前版本提供的 DNS 設定或自訂設定入口儲存，再查看產生的結果，確認欄位與標籤都還在。

啟用 FakeDNS 後部分程式完全無法連線，該先檢查什麼？

先恢復一般解析並重新啟動核心，再清除相關應用程式快取。確認恢復正常後，檢查合成位址對應的連線是否回到同一個核心，以及入站網域還原設定是否符合目前核心的要求。請勿讓取得合成位址的程式繞過接管機制直接連線。

完成驗收後應保留三項記錄：目前使用的核心與設定來源、兩個解析端點對應的出站標籤，以及獨立測試入口的查詢記錄。這樣才能將問題定位在解析器選擇、查詢傳輸或目標連線階段，而不是一再更換公共 DNS 位址。

下載用戶端