V2Ray 進階設定：訂閱、路由、DNS 與出站

設定基準：先固定可重現的工作狀態

建立最小可用鏈路

進階調整的起點不是「開啟所有選項」，而是建立一條可重複驗證的最小鏈路。先保留一個確認可用的訂閱、一台伺服器、預設路由與客戶端預設 DNS，關閉區域網路分享、TUN、FakeDNS 及額外出站。桌面端在 v2rayN 中選擇伺服器後啟用系統代理；Android 端則在 v2rayNG 或 v2flyNG 中選擇同類伺服器並建立連線。此時只驗證三項結果：客戶端核心能否啟動、瀏覽器請求能否經過預期出口，以及本地網路資源是否仍可存取。任何一項不成立，都應先回頭檢查訂閱參數或伺服器狀態，而不是繼續疊加路由規則。

基準狀態需要包含明確紀錄。記下目前使用的客戶端、核心家族、訂閱分組名稱、活動伺服器名稱、系統代理模式，以及是否啟用遠端 DNS。記錄的目的不是長期維護複雜帳冊，而是在修改後能準確回答「哪項設定發生了變化」。客戶端更新訂閱時可能覆蓋伺服器物件，但通常不會自動恢復手動修改的全域路由，因此訂閱狀態與全域設定要分開檢查。

區分四個設定層

一套可正常運作的 V2Ray 圖形客戶端設定通常包含四層。第一層是伺服器物件，儲存位址、連接埠、使用者識別、傳輸方式與安全參數；第二層是訂閱與分組，決定伺服器如何更新、顯示與篩選；第三層是本地接管方式，包括系統代理與 TUN；第四層是核心設定，包含 DNS、路由、入站與出站。伺服器能連線，只代表第一層基本正確，並不能證明 DNS 或分流符合預期。反過來，瀏覽器無法開啟頁面也不一定是伺服器故障；系統代理未接管該應用、DNS 回傳不適當結果，或規則把流量送往錯誤出口，都可能造成相似現象。

備份、命名與回復

修改前，使用客戶端提供的設定匯出或備份功能保存目前狀態，檔名只要清楚說明用途即可，例如「預設路由」「TUN 測試前」「雙訂閱合併前」。不要把多個實驗目標塞進同一個備份名稱。若客戶端支援路由設定檔，可複製現有檔案後再編輯；若只支援一套全域設定，請先複製核心設定文字。回復時也要檢查系統代理狀態，因為還原設定檔不一定會同步還原作業系統中的代理開關。

命名應描述用途，而不是情緒判斷。「工作直連優先」「全域代理測試」「保留本地域名」比「設定一」「最快設定」更容易維護。伺服器名稱可保留訂閱提供者原有的地區、協定與倍率資訊，篩選規則則應圍繞穩定欄位撰寫。不要依賴清單序號，因為更新訂閱後排序可能改變。對路由和出站使用固定標籤，例如 direct、proxy、block 與 dns-out，可降低規則引用錯誤。

用日誌確認設定生效

每次修改完成後重新載入核心，觀察日誌是否出現設定解析錯誤、連接埠佔用、權限不足或 DNS 請求失敗。日誌層級先使用資訊級別；只有定位特定問題時才短暫切換至除錯級別，完成後恢復，以免大量連線明細淹沒關鍵事件。閱讀時應從第一個錯誤開始，而不是從最後一行反向猜測。若出現 failed to parse config，先檢查 JSON 逗號、欄位層級與標籤引用；若核心成功啟動但請求逾時，再轉向伺服器、DNS 與路由。

完成基準驗證後，複製一份設定再進入下一章。後續每章都沿用相同原則：先定義目標，修改單一層，重新載入，再依日誌與實際存取結果驗證，失敗後回復。涉及具體錯誤文字時，可搭配V2Ray 執行日誌閱讀方法逐段定位，而不是反覆重新安裝客戶端。

訂閱分組與伺服器篩選：管理清單，而不是手動刪除節點

將訂閱來源與使用檢視分開

訂閱來源負責提供伺服器物件，分組則負責把物件整理成適合選擇的檢視，兩者不應混為一層。直接刪除暫時不用的伺服器看似簡單，但下次更新訂閱後通常會再次出現；更穩定的做法是保留完整訂閱來源，透過分組、備註與篩選條件控制顯示範圍。v2rayN 適合用訂閱分組管理桌面端的大量伺服器，v2rayNG 與 v2flyNG 則更適合保留較少的行動端候選，降低捲動清單與誤選的成本。

建立分組時，先依來源劃分，再依用途建立篩選檢視。例如「主要訂閱」「備用訂閱」描述來源，「日常使用」「低倍率」「指定協定」描述用途。來源分組用於更新與故障隔離，用途篩選則用於實際選擇。不要把不同來源改成完全相同的名稱，否則訂閱更新失敗時難以判斷受影響範圍。手動新增的伺服器應放入獨立分組，避免更新訂閱時誤以為手動物件會隨來源同步。

設計易於維護的篩選運算式

伺服器篩選通常根據名稱中的地區、協定、倍率或用途標籤進行。先觀察訂閱名稱的穩定結構，再撰寫包含或排除規則。若名稱長期採用「地區｜協定｜倍率」格式，可以組合關鍵字；若分隔符號經常變動，則只依賴穩定詞段。正規表示式適合合併同義名稱，但應保持簡短。篩選「香港或新加坡」可使用 香港|HK|新加坡|SG，排除測試或到期物件可使用 測試|到期|剩餘流量。同時存在包含與排除規則時，先確認客戶端的執行順序；常見邏輯是先保留包含項目，再從結果中移除排除項目。

包含：
香港|HK|新加坡|SG

排除：
測試|到期|剩餘流量|官網

協定偏好：
VLESS|VMess|Trojan

倍率篩選：
(^|[^0-9])1(\.0)?x([^0-9]|$)

倍率篩選尤其容易誤匹配。只搜尋字元 1，可能同時匹配連接埠、編號或「1.5x」，因此應盡量限制邊界。訂閱命名不一致時，不要把倍率篩選當作計費依據；先核對訂閱提供的資訊，再把名稱篩選作為整理清單的工具。地區篩選也只代表名稱標籤，不等同於實際網路路徑。選擇伺服器時還要結合實際連線測試、協定相容性與實際存取表現，具體方法可參考依延遲、倍率與地區篩選伺服器。

排序、測試與選擇分工

清單排序用於縮小候選範圍，延遲測試用於排除無法連線的物件，最終選擇仍應以實際業務連線為準。基礎延遲只反映探測目標的回應速度，不能完整代表網頁載入、長連線或大型檔案傳輸。實際連線延遲更接近核心建立代理連線所需的時間，但也會受測試目標與當時網路狀態影響。正確流程是先用篩選取得少量候選，再進行實際連線測試，最後透過實際應用驗證；不要把單次測試結果永久寫入分組名稱。

自動排序後，保留一台已驗證且穩定的伺服器作為回復項目。它不必始終排在第一位，但應有清楚備註。經常更新訂閱的使用者，可以把排序範圍限制在目前分組，避免不同來源、不同用途的伺服器混排。若某個分組突然變空，先關閉篩選查看原始清單：原始清單存在，代表篩選條件已不再匹配；原始清單也為空，才需要檢查訂閱更新。

處理同名與重複物件

多個訂閱可能提供同名伺服器。不要只憑顯示名稱判斷它們相同；位址、連接埠、使用者識別、傳輸參數或來源只要有一項不同，都應視為不同物件。若客戶端的去重功能是依完整設定判斷，通常可以安全使用；若只依備註名稱判斷，則可能誤刪有效候選。更穩妥的做法是在分組層保留來源資訊，透過顯示前綴加以區分，而不是直接修改訂閱中的核心參數。

篩選規則需要定期反向檢查：查看被排除項目中是否混入正常伺服器，並查看未分類項目是否出現新的命名格式。每次訂閱更新後不必全面重做，只要抽查包含、排除與未匹配三個集合。這樣既能維持清爽清單，也不會因過度嚴格的運算式而失去可用伺服器。

多訂閱管理：更新隔離、優先順序與故障切換

確定主要訂閱與備用訂閱的職責

多訂閱不是把所有伺服器堆進同一份清單，而是為不同來源分配明確職責。主要訂閱負責日常選擇，備用訂閱只在主要來源更新失敗、協定不相容或特定地區無法使用時啟用；手動分組則保存長期固定或暫時測試的物件。職責明確後，更新問題就不會擴散至整份清單。v2rayN 可分別更新訂閱組並查看結果；行動端則應控制啟用數量，避免每次重新整理都重建過大的伺服器清單。

為每個訂閱保留獨立備註，並記錄所使用的篩選條件。不要在同一分組中混用「來源」與「用途」兩種命名邏輯。例如「主要訂閱」與「備用訂閱」屬於來源，「辦公」「串流測試」則屬於用途。需要交叉管理時，應從來源分組建立篩選檢視來產生候選，而不是移動原始物件。如此一來，訂閱更新後檢視可以重新計算，來源邊界仍能完整保留。

安排更新順序與失敗處理

訂閱更新應逐一處理各個來源。先更新主要訂閱，確認回傳內容可解析、伺服器數量沒有異常變化，且原本穩定的物件仍然存在，再更新備用來源。一次更新所有來源雖然省事，但發生異常時很難判斷是哪個位址、哪種內容格式或哪條網路路徑失敗。若客戶端顯示更新成功但清單為空，請檢查訂閱內容是否被篩選規則全部排除；若顯示解析失敗，則保留舊清單，檢查訂閱位址與回傳格式，不要先清空本地資料。

更新失敗時，區分三種情況：請求未完成、內容已回傳但無法解析、解析成功但結果不符合預期。請求未完成通常從網路、系統代理或訂閱位址著手；解析失敗則重點檢查內容格式與客戶端相容性；結果異常則比較更新前後的名稱與分組。備用訂閱只用於維持連線能力，不應自動覆蓋主要訂閱。主要來源恢復後，再依正常順序切回，避免兩個來源同時頻繁變動。

控制自動更新的範圍

自動更新適合穩定來源，但不應與自動選擇伺服器綁定成無法觀察的黑箱。訂閱內容變更後，新物件可能因排序規則直接出現在前列；如果客戶端又自動選擇第一項，實際出口就會在未明確操作的情況下改變。較穩妥的設定是允許訂閱定時重新整理，但保留目前活動伺服器，只有目前物件失效時才手動切換。需要高度穩定的情境可以降低更新頻率，並在更新前匯出設定。

多台裝置使用相同訂閱時，不必強求清單完全一致。桌面端可保留更多地區與協定供測試，Android 端則只保留常用候選。設定同步的重點應是分組邏輯、路由目標與 DNS 策略，而不是清單順序。不同客戶端對訂閱欄位、路由介面與核心選項的呈現方式不同，強行複製整個資料目錄可能帶入平台相關設定。

避免訂閱內容污染全域設定

訂閱更新的理想界線是更新伺服器物件，不覆蓋全域 DNS、路由與本地入站。若客戶端支援「更新訂閱時匯入附加設定」，啟用前要先了解它會修改哪些層。來源不明的路由範本可能改變預設出口，遠端 DNS 設定也可能取代已驗證的解析鏈路。對於正式使用，建議把全域規則保存在本地設定檔中，訂閱只提供伺服器。

手動伺服器同樣需要隔離。將手動物件放入獨立分組並使用清楚備註，不要偽裝成訂閱物件。修改手動物件時先複製再編輯，原物件作為回復版本。若兩筆設定只有傳輸參數不同，請在名稱中寫明差異，例如「WS 測試」「gRPC 測試」，而不是只寫「備用一」「備用二」。這些細節會直接影響後續日誌定位。

執行可控的故障切換

切換前先確認問題確實出在目前伺服器，而不是 DNS 或本地接管。選擇備用伺服器後重新載入核心，檢查日誌中的活動出站，再對相同目標進行存取測試。切換成功後記錄觸發原因，不要立即刪除原物件；網路路徑恢復後仍需要它作為對照。若主要訂閱的所有物件都失敗而備用來源正常，優先檢查主要來源共同使用的協定或傳輸條件。若兩個來源同時失敗，則應回到系統代理、TUN、DNS 與本地網路層排查。

完成多訂閱整理後，應能在一分鐘內回答四個問題：目前伺服器來自哪個訂閱、更新失敗時使用哪個備用分組、哪些篩選規則會隱藏伺服器，以及全域路由是否獨立於訂閱。若答案仍需翻找大量清單，表示分組名稱或職責還不夠清楚，應先整理，再進入複雜的路由設定。

路由規則實戰：依匹配順序決定流量出口

理解從入站到出站的判定流程

路由規則處理的是已經進入核心的連線。應用程式先透過系統代理、TUN 或本地代理連接埠進入某個入站，核心再讀取網域、目標 IP、連接埠、網路類型、程序或入站標籤，並依規則順序選擇出站。路由無法接管尚未進入客戶端的流量，也無法修正錯誤的伺服器參數。設定前先確認應用程式請求已到達核心日誌，再討論它應走直連、代理或阻斷。

規則通常按照由上而下的順序匹配，命中後便不再繼續。具體條件應放在前面，寬泛條件放在後面，最後用預設出站接住未匹配的流量。常見基準是：私有位址直連，本地域名與 IP 集合直連，明確需要代理的網域走代理，其他流量依目前策略進入預設出口。若把「所有網域代理」放在第一條，後續直連規則就不會執行。

選擇網域策略

路由中的網域策略決定核心何時將網域解析成 IP，再匹配 IP 規則。使用 AsIs 時，網域請求優先依網域規則判斷，不會為路由目的主動解析；使用 IPIfNonMatch 時，網域規則未命中後才解析，再嘗試匹配 IP 規則；使用 IPOnDemand 時，只要後續存在需要 IP 的判斷，就可能觸發解析。一般設定可從 IPIfNonMatch 開始，它兼顧網域規則與 IP 集合，但要確認 DNS 設定能提供穩定結果。

主動解析會讓路由與 DNS 產生耦合。若 DNS 回傳的位址不穩定，或因不同線路被分配到不同區域，IP 規則的結果也可能改變。因此，能以明確網域集合表達的目標，應優先使用網域規則；只有確實需要依目標位址判斷時，才依賴 IP 規則。日誌中出現規則結果不符預期時，要同時查看原始網域、解析後的 IP 與最終出站標籤。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

組合網域、IP、連接埠與入站條件

同一條規則中的不同欄位通常按「同時符合」處理，同一欄位中的多個值通常按「任一匹配」處理。例如一條規則同時寫入 network: tcp 與 port: 80,443，表示只處理 TCP 的這兩個連接埠；網域陣列中寫入多個集合，則任一集合命中即可。不要在一條規則中塞入彼此無關的目標，拆成多條並寫清楚用途會更容易排查。

入站標籤適合為不同本地入口設定不同策略。例如瀏覽器使用本地 SOCKS 入站，工作軟體使用另一個 HTTP 入站，兩者可以分別指向代理或直連。程序規則取決於客戶端、核心與系統權限支援，不同平台的表現不完全一致，應把它作為精細分流的補充，而不是唯一依據。連接埠規則適合明確服務，但現代應用程式可能改用其他連接埠或 QUIC，單靠連接埠推斷應用類型容易漏匹配。

建立三層規則結構

第一層處理不應送入遠端代理的本地目標，例如回環、區域網路與私有位址；第二層處理業務例外，例如指定網域直連、特定網域代理、廣告或已知風險目標阻斷；第三層定義預設出口。每一層內都應由具體到寬泛排列。修改規則後，用三個測試目標分別涵蓋直連、代理與預設路徑，避免只驗證目前關注的單一規則。

阻斷規則應保持可解釋。若某個應用程式啟動異常，先暫時停用阻斷規則驗證，而不是直接判定伺服器故障。UDP 規則也要謹慎，阻斷所有 UDP 可能影響 DNS、即時通訊或基於 QUIC 的連線；如果目的只是讓特定網域退回 TCP，應優先在對應應用程式或核心傳輸設定中處理。區域網路存取則應同時檢查私有位址直連與 TUN 繞過範圍。

用日誌驗證規則命中

驗證時先清空日誌或標記時間點，再發起單次請求。觀察請求進入哪個入站、識別到的網域或 IP、命中的規則，以及最終出站。若日誌只顯示 IP 而沒有網域，應用程式可能自行解析了目標，網域規則便無法直接命中；此時可考慮 TUN 的網域嗅探、FakeDNS，或補充可靠的 IP 規則。若規則命中正確但連線失敗，問題位於對應出站或伺服器層。

路由維護的核心不在規則數量，而在於每條規則都有可說明的目標、穩定的資料來源與明確的回復路徑。每季或訂閱結構變更後，檢查失效網域、重複集合與永遠無法命中的下層規則。遇到「有些應用正常、有些應用失敗」時，先比較它們是否進入同一入站、是否使用相同 DNS、是否命中相同出站，再前往說明中心查找對應故障分支。

DNS 設定最佳化：統一解析路徑與路由依據

先釐清一次查詢經過的路徑

DNS 問題經常被誤判為伺服器問題。一次網域存取可能經過應用程式自身解析、作業系統解析、客戶端內建 DNS 與遠端解析中的一層或多層。瀏覽器若啟用獨立的加密 DNS，查詢可能繞過系統設定；TUN 接管後，系統查詢可能被導入核心；FakeDNS 則會在本地回傳合成位址，並延後真實解析。最佳化前先確認是誰發起查詢、查詢進入哪台伺服器，以及結果在哪裡被路由使用。

基礎設定應盡量形成單一主要路徑：一般應用程式將查詢交給系統，系統查詢由客戶端接管，核心依網域集合選擇本地或遠端 DNS，回傳結果供連線與路由共同使用。若應用程式自行解析且只把 IP 交給客戶端，核心就會失去原始網域資訊，網域分流能力也會下降。此時應統一應用程式設定，或在 TUN 情境中使用嗅探與 FakeDNS 恢復網域關聯。

依網域集合選擇解析伺服器

DNS 分流與流量分流應保持方向一致。計畫直連的本地域名，優先交給本地可達的 DNS；計畫走代理的網域，則可交給隨代理出站存取的遠端 DNS。這樣能減少解析結果與實際出口不匹配。不要簡單地把所有查詢送往多台伺服器並採用最快回應，因為最快回傳不等於最符合路由意圖，而且並行查詢會增加結果的不確定性。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"],
        "expectIPs": ["geoip:cn"]
      },
      {
        "address": "https://1.1.1.1/dns-query",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ]
  }
}

範例先為 geosite:cn 指定本地 DNS，並用 expectIPs 限制回傳位址範圍；其他明確的非本地域名則交給加密 DNS，最後一項作為未匹配查詢的回復。實際使用時應依所在網路選擇可穩定存取的 DNS，不要機械式保留範例位址。若遠端 DNS 需要透過代理存取，也要確保其網域或 IP 不會在解析自身時形成循環。

選擇查詢策略與位址族

UseIPv4 只請求 IPv4 位址，適合本地 IPv6 不可用或路由尚未完整設定的環境；UseIPv6 只請求 IPv6；UseIP 則允許兩種位址族。選擇策略應以本地鏈路、代理出站與目標服務三者共同支援為準。只要其中一層無法穩定承載 IPv6，強制回傳 IPv6 就可能出現「網域能解析但連線逾時」。相反地，網路與出站都支援時，長期停用 IPv6 也會失去可用路徑。

判斷方法不是查看系統是否取得 IPv6 位址，而是分別測試本地直連、代理出站與 DNS 回傳。若日誌顯示先嘗試無法連通的 IPv6，再回退到 IPv4，頁面就會出現首次開啟緩慢的情況；可先暫時使用 UseIPv4 驗證，再完善 IPv6 路由。不要同時修改位址族與網域分流，否則難以判斷改善來自哪一項。

避免 DNS 循環與洩漏路徑

DNS 循環通常發生在「解析 DNS 伺服器的網域本身」時，因而需要再次呼叫同一個 DNS。解決方式是為該伺服器提供可直接使用的 IP、透過 hosts 固定引導位址，或設定獨立的引導解析器。另一個循環來源是 DNS 出站被路由回一般代理入口，接著再次觸發 DNS。為 DNS 查詢建立明確的出站標籤，並在路由中優先處理，就能讓路徑保持單向。

{
  "dns": {
    "hosts": {
      "resolver.example": "192.0.2.53"
    },
    "servers": [
      {
        "address": "https://resolver.example/dns-query",
        "skipFallback": true
      }
    ]
  }
}

範例中的保留位址僅用於說明欄位關係，實際設定必須換成所使用解析服務明確提供的位址。所謂洩漏路徑，應從設定目標來理解：如果原本計畫讓某類網域透過遠端解析，卻被應用程式自身或系統的另一個介面直接查詢，就代表路徑發生偏離。檢查時應同時觀察客戶端 DNS 日誌與系統網路活動，不要只依賴網頁測試結果。

快取、重新整理與故障定位

修改 DNS 後，舊快取可能繼續影響結果。先重新載入客戶端核心，再關閉並重新開啟測試應用程式；必要時重新整理作業系統快取。Windows 可在終端機執行 ipconfig /flushdns，使用 systemd-resolved 的 Linux 可執行 resolvectl flush-caches。macOS 與 Android 的快取行為會隨系統網路狀態變化，切換網路介面或重新建立客戶端連線通常能觸發更新。執行指令只會清理系統快取，不一定會清除瀏覽器內部快取。

ipconfig /flushdns

resolvectl flush-caches

排查順序應固定：先用明確的 DNS 工具確認查詢是否有回應，再檢查回傳的位址族，接著查看路由如何處理該位址，最後檢查對應的出站連線。若只有一個網域失敗，檢查網域規則、快取與伺服器回應；若所有網域都失敗但直接存取 IP 正常，重點檢查 DNS 入站、伺服器位址與路由循環；若網域和 IP 都失敗，則回到接管與出站層。

TUN 模式：接管不讀取系統代理的應用程式

判斷是否真的需要 TUN

系統代理只會影響主動讀取代理設定的應用程式。命令列工具、部分桌面軟體、遊戲與使用自有網路堆疊的程式，可能直接建立連線，這時客戶端日誌看不到請求。TUN 模式透過虛擬網路介面接管更多系統流量，適合需要統一分流的情境，但也會引入路由表、DNS 劫持、權限與繞過規則等額外變數。瀏覽器與常用桌面軟體已能透過系統代理正常運作時，不必為了「設定更完整」而開啟 TUN。

啟用前先完成前幾章的基準：伺服器可用、路由規則可解釋、DNS 能穩定解析。關閉其他會建立虛擬介面或修改預設路由的軟體，記錄系統原有代理狀態，並保留復原方式。TUN 啟用失敗時，應先退出客戶端，讓虛擬介面與路由表恢復，再重新調整；不要在殘留介面上連續切換多種實作。

選擇網路堆疊實作與基本參數

客戶端可能提供 system、gVisor 或 mixed 等網路堆疊選項。system 堆疊更依賴作業系統能力，通常效能路徑較直接；gVisor 使用使用者態網路堆疊，與 system 堆疊的相容性表現不同；mixed 則嘗試組合處理 TCP 與 UDP。不存在適用所有環境的最佳選擇。先使用客戶端預設值，只有在特定應用程式無法連線、UDP 異常或休眠恢復失敗時，才逐項切換並保留日誌作比較。

MTU 決定虛擬介面可承載的封包大小。設定過大可能在複雜鏈路中產生分片或丟包，表現為小頁面正常、大型請求卡住；設定過小則會增加封包數量與處理負擔。沒有明確證據時應維持預設值。若需要排查，可逐步降低 MTU 並測試相同目標，不要同時更換網路堆疊與 DNS。嚴格路由選項能減少流量繞過，但也可能影響本地網路存取，應搭配繞過位址使用。

設定區域網路與保留位址繞過

TUN 接管後，印表機、網路儲存裝置、路由器管理頁面或開發環境可能被錯誤送入代理。應優先讓回環位址、私有位址與鏈路本地位址直連，並確認區域網路探索所需的 UDP 流量沒有被寬泛規則阻斷。常見私有範圍包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16，但企業網路可能使用其他內部位址，應以實際路由表為準。

繞過私有位址不等於允許區域網路裝置存取客戶端代理連接埠。區域網路分享是另一項入站設定，需要單獨決定是否開啟，並限制監聽位址與防火牆範圍。只供本機使用時，代理入站應繼續繫結回環位址。若開啟分享，先確認本地網路可信，再設定存取範圍；TUN 的路由繞過不能取代入站存取控制。

處理 DNS 劫持與網域識別

TUN 模式若要實現可靠的網域分流，通常需要把系統 DNS 查詢導入核心。若只接管連線而不接管 DNS，應用程式可能先在系統外部取得 IP，核心只能依 IP 路由。啟用 DNS 劫持後，請確認查詢已進入客戶端內建 DNS，並避免客戶端自身的解析請求再次被劫持。連接埠 53 是傳統 DNS 的常見入口，但應用程式自帶加密 DNS 時仍可能繞過，因此需要在應用程式設定與路由層共同處理。

嗅探可以從部分連線中恢復目標網域，但不應視為所有協定都可靠。啟用後檢查是否誤寫目標位址，尤其是使用自訂憑證、內網網域或特殊服務探索的應用程式。出現建立連線後立即中斷時，可暫時關閉目標覆寫，只保留網域識別作比較。FakeDNS 是另一種維持網域映射的方法，適合 TUN 情境，但需要獨立位址池與正確的回收策略，下一章會單獨說明。

依現象定位 TUN 故障

若啟用後完全無法連網，先檢查核心是否成功啟動、虛擬介面是否建立、預設路由是否指向預期位置，以及 DNS 是否仍有可達路徑。若只有區域網路失效，檢查私有位址直連與嚴格路由；若只有 UDP 應用程式失效，比較網路堆疊、UDP 路由與伺服器協定支援；若休眠恢復後失效，重新建立 TUN 介面並查看是否殘留舊路由。不要先刪除所有客戶端設定，TUN 故障通常位於接管層。

完成驗證後，分別測試瀏覽器、原本不讀取系統代理的應用程式、區域網路資源、DNS 查詢與 UDP 業務。五類測試都能說明其路徑後，TUN 才算穩定。若需求只是讓單一命令列程式使用代理，優先為該程式設定明確的代理環境變數，比全系統接管更容易維護。

FakeDNS：保留網域資訊並延後真實解析

理解合成位址的作用

FakeDNS 收到網域查詢後，不會立即把真實目標位址交給應用程式，而是從預設位址池回傳一個合成 IP，並保存「合成 IP—原始網域」的映射。應用程式隨後連線至這個合成 IP，TUN 或透明接管層將連線送回核心，核心查表恢復網域，再依網域規則選擇 DNS 與出站。如此一來，即使應用程式只連線至 IP，核心仍能取得原始網域，網域分流也會更穩定。

合成位址不是遠端伺服器位址，也不應被一般路由視為公網目標。它只在本機接管鏈路中充當映射索引。如果請求繞過 TUN 直接送往網路，合成位址自然無法存取。因此 FakeDNS 必須搭配能截獲後續連線的接管方式使用，單獨開啟內建 DNS 中的 FakeDNS 選項並不能完成閉環。

規劃獨立且不衝突的位址池

位址池需要避開本地真實網路、企業內網、容器網路及既有虛擬介面使用的範圍。設定前查看系統路由表，確認候選網段沒有被真實路由佔用。位址池過小，會在大量網域並行時頻繁回收映射；過大則可能與其他網路規劃衝突。維持客戶端預設範圍通常最穩妥；只有確認發生衝突時才更換，並同步檢查 TUN 路由是否涵蓋新範圍。

{
  "dns": {
    "servers": [
      {
        "address": "fakedns",
        "domains": ["geosite:geolocation-!cn"]
      },
      "223.5.5.5"
    ],
    "queryStrategy": "UseIPv4"
  },
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ]
}

198.18.0.0/15 常用於基準測試網路，部分客戶端預設將其作為合成位址，但仍需檢查本地網路是否已有相同範圍的路由。poolSize 控制可用映射數量，不應超過位址池的實際容量。設定欄位會隨核心家族與客戶端產生方式不同而變化，使用圖形介面時應優先讓客戶端產生結構，再檢查最終核心設定，不要把整段範例覆蓋到不相容的層級。

決定哪些網域使用 FakeDNS

並非所有查詢都需要合成位址。本地域名、區域網路服務、印表機探索，以及需要將真實 IP 回傳給應用程式的工具，通常應繼續使用一般 DNS。計畫依網域進行代理的公網目標，更適合進入 FakeDNS。可以先只為明確的非本地域名集合啟用，確認穩定後再擴大範圍。若直接把所有查詢交給 FakeDNS，本地服務可能取得無法使用的合成結果。

排除清單應涵蓋區域網路後綴、開發環境網域，以及依賴真實位址的診斷工具。若應用程式會向使用者顯示 DNS 結果、將結果寫入設定，或交給另一台裝置使用，也不適合接收本機專用的合成 IP。FakeDNS 解決的是透明接管下的網域關聯，不是通用 DNS 加速器，也不應把合成結果傳播至區域網路中的其他裝置。

協調嗅探、路由與真實解析

FakeDNS 恢復原始網域後，路由會先依網域規則決定出口，接著真實 DNS 應沿著與該出口一致的路徑執行。若網域被判定為直連，就使用適合直連鏈路的解析器；若走代理，則使用為代理路徑設定的解析器。否則即使成功恢復網域，最終仍可能取得不適合該出口的位址。日誌應能連續看到合成映射、網域命中與真實目標連線。

嗅探與 FakeDNS 可以搭配使用，但職責不同。FakeDNS 依靠查詢映射恢復網域，嗅探則依靠連線內容識別網域。兩者同時啟用時，要明確是否允許覆寫目標位址。若同一連線出現網域判斷衝突，可先關閉嗅探覆寫，只保留 FakeDNS；若應用程式完全不發起可被接管的 DNS 查詢，FakeDNS 便無法建立映射，此時嗅探仍可能提供資訊。

識別快取與映射失效

應用程式、系統與客戶端都可能快取合成結果。修改位址池或關閉 FakeDNS 後，舊合成 IP 可能仍被應用程式使用，表現為部分網域持續失敗。處理順序是中斷 TUN、重新載入核心、重新整理系統 DNS 快取、重新啟動測試應用程式，再重新建立連線。不要在連線仍處於活動狀態時頻繁切換位址池，否則舊映射與新路由可能短暫並存。

若只有執行一段時間後才開始失敗，檢查位址池容量、映射回收與應用程式的 DNS 快取週期。若特定網域第一次正常、之後異常，比較真實 DNS 回傳是否變化，以及舊連線是否重用了過期映射。若所有合成位址都無法連線，重點檢查 TUN 是否接管該網段，而不是調整遠端伺服器。

最終驗證應包含一般公網網域、明確直連網域、區域網路網域與應用程式自帶解析四類目標。一般公網目標應建立映射並依網域路由；直連與區域網路目標應依排除策略取得真實位址；自帶解析的應用程式則需要確認是否進入接管鏈路。只有四類結果都符合設計，FakeDNS 才真正改善網域分流，而不是增加新的不透明層。

自訂出站：標籤、鏈式轉送與最終排錯

先定義出站職責與標籤

出站是路由規則的最終目的地。最小設定通常包含代理、直連與阻斷三種職責，分別使用穩定標籤 proxy、direct 與 block。自訂出站適合增加指定介面直連、獨立 DNS 出站或鏈式轉送，但每增加一個出站，就必須一併檢查標籤、路由引用與故障回復。標籤區分大小寫，重新命名後必須搜尋所有規則，避免路由仍指向舊名稱。

圖形客戶端通常會依目前伺服器產生主要代理出站。直接修改產生的物件，可能在切換伺服器或更新訂閱後被覆蓋，因此自訂部分應放在客戶端支援的附加設定、預設檔或自訂出站區域。先確認客戶端的合併順序：同名欄位是覆蓋、追加還是拒絕。無法確認時，匯出最終核心設定並檢查實際結果，而不是只查看介面中的輸入片段。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

為直連出口指定位址族或介面

多網卡裝置可能同時連接有線、無線、虛擬網路與企業網路。預設直連會由系統路由選擇介面；在核心支援的情況下，自訂直連出站可指定傳送位址或位址族，讓某類流量固定經由特定本地介面。設定前先確認該位址能長期存在；使用動態分配位址時，休眠、重新連線或切換網路後可能失效。若目標只是存取區域網路，優先依賴系統路由與私有位址直連，不必強制繫結介面。

指定位址族時，必須與 DNS 查詢策略一致。直連出站只允許 IPv4，而 DNS 回傳 IPv6，連線仍會失敗；代理出站支援雙協定堆疊，也不代表本地直連支援。排查時分別記錄 DNS 結果、路由標籤與出站實際撥號位址。多網卡環境還要檢查 TUN 建立的路由優先順序，避免自訂直連再次進入 TUN 形成迴圈。

理解鏈式轉送的適用範圍

鏈式轉送讓一個代理出站透過另一個出站建立連線，可用於明確的網路拓撲或入口限制。它會增加握手層次、延遲與故障點，不適合用來取代伺服器篩選。設定鏈路前，先分別驗證前置出站與最終出站能獨立運作，再將兩者串接。任何一層的 DNS、位址族、UDP 支援或傳輸失敗，都會表現為最終連線失敗。

鏈路必須避免迴圈。出站 A 透過 B，B 就不能再透過 A；DNS 出站也不能依賴一個最終仍需要該 DNS 才能解析的代理。為每一層使用清楚標籤，例如 proxy-entry 與 proxy-exit，才能在日誌中判斷失敗發生在哪個階段。預設路由只應指向最終業務出口；前置出站通常由轉送關係呼叫，不需要再被寬泛規則直接命中。

建立獨立 DNS 出站

當核心支援 DNS 出站時，可以將內部 DNS 查詢透過專用標籤送往指定路徑。如此一來，路由規則就能把 DNS 流量與一般連線分開，減少循環。典型結構是由內建 DNS 產生查詢，DNS 出站負責傳送，路由優先將對應入站或協定指向 dns-out。若遠端解析器需要透過代理存取，應讓 dns-out 經由明確代理路徑，而不是依賴預設規則猜測。

{
  "outbounds": [
    {
      "tag": "dns-out",
      "protocol": "dns",
      "settings": {
        "address": "1.1.1.1",
        "port": 53,
        "network": "tcp"
      }
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["dns-in"],
        "outboundTag": "dns-out"
      }
    ]
  }
}

範例用於說明標籤關係，不代表所有客戶端都使用相同欄位產生 DNS 出站。使用加密 DNS 時，位址、連接埠與傳輸方式仍需依核心支援方式設定。驗證重點是查詢只經過一次入站與一次出站，沒有重新回到一般 DNS 入口。若日誌持續重複相同網域，應優先懷疑解析循環。

依層執行最終排錯

複雜設定失敗時，從請求入口向外逐層檢查。第一步確認應用程式流量是否進入系統代理或 TUN；第二步確認 DNS 是否取得可用結果並保留網域；第三步確認路由命中預期標籤；第四步確認標籤對應的出站存在且參數有效；第五步才檢查遠端連線。每一步都需要日誌證據。跳過入口與路由直接更換伺服器，往往只會暫時改變現象。

錯誤可依影響範圍縮小：所有應用程式都失敗，多半位於核心啟動、接管或預設出站；單一應用程式失敗，比較其代理方式、協定與 DNS 行為；單一網域失敗，檢查網域規則、快取與真實解析；只有 UDP 失敗，檢查網路堆疊、路由與出站能力；只有區域網路失敗，檢查私有位址與 TUN 繞過。將現象對應到設定層，比記憶單一「修復指令」更可靠。

完成設定後，不要把最終結果視為永久不變。訂閱命名、網路介面、系統權限與業務網域都會變化，出現明顯行為變化時應重新執行基準測試。需要更換客戶端時，可先閱讀v2rayN、v2rayNG 與 v2flyNG 橫向評測；需要重新安裝時，請前往客戶端下載頁；遇到具體日誌錯誤，則搭配執行日誌定位步驟處理。維持設定分層、標籤穩定與修改可回復，比持續增加規則更重要。