V2Ray 進階設定手冊

先建立三層設定模型

快速上手頁面負責完成匯入訂閱、選擇伺服器、開啟系統代理與驗證連線這條主線。本手冊處理主線完成後的細部需求，包括多訂閱隔離、複雜分流、DNS 查詢路徑、TUN 接管範圍與自訂出站。開始修改前，先把目前設定拆成三層：最外層是 v2rayN、v2rayNG 或 v2flyNG 的介面設定；中間層是用戶端產生並交給 Xray 或 V2Fly 的執行設定；最底層是作業系統的代理、路由表、虛擬網卡與名稱解析行為。三個層級會互相影響，但意義不同。

例如，v2rayN 中的「設定系統代理」只負責將支援系統代理的應用程式指向本機監聽連接埠，並不等同於路由模式。「繞過中國大陸」屬於核心路由規則，決定請求進入核心後交給 direct 還是 proxy 出站。TUN 模式則從作業系統網路層接管更多連線，即使應用程式不讀取系統代理，也可能被虛擬網卡捕獲。把三者混成一個開關，最常見的結果是瀏覽器正常、命令列失敗，或關閉系統代理後仍有流量經過核心。

每次調整只修改一個層級。先儲存目前可用的設定，再記錄修改項目、重新啟動核心、查看記錄，然後執行固定測試。測試至少包含一個網域請求、一個直接使用 IP 的請求、一個明確應直連的目標，以及一個明確應走代理的目標。若一次修改同時涉及路由、DNS 與 TUN，記錄只能說明最終失敗點，無法反推出最先出現偏差的位置。

理解一次請求的實際路徑

在一般系統代理情境中，應用程式先連線到 v2rayN 提供的 HTTP 或 SOCKS 入站。核心讀取請求目標，必要時執行網域解析，再依路由規則比對出站標籤。命中 direct 時，核心從本機網路直接建立連線；命中 proxy 時，連線交給目前伺服器對應的代理出站；命中 block 時，請求在本機終止。TUN 情境會多一步：作業系統先將 IP 封包送入虛擬網卡，核心需要還原連線目標，接著才進入相同的路由與出站流程。

路由比對依賴可見資訊。SOCKS 入站通常能攜帶原始網域，核心可以直接比對 domain 或 geosite。某些程式會先自行解析網域，再只提交目標 IP，此時核心看到的是 IP，網域規則可能無法命中。流量嗅探可以從部分連線的握手資訊中還原網域，但並非對所有協定都有效，也不應視為錯誤 DNS 設定的替代方案。排查規則未命中時，必須先確認記錄中記載的目標究竟是網域還是 IP。

DNS 同樣不是獨立模組。路由規則可能要求解析目標 IP，DNS 查詢本身也需要選擇出站，TUN 下系統查詢還可能被核心攔截。如果將所有 DNS 請求都交給同一個遠端解析器，又讓該解析器的網域依賴代理出站，就可能形成啟動依賴：代理伺服器尚未連線，解析器也無法存取。解決方法不是反覆切換伺服器，而是為啟動流程保留可直接存取的引導解析方式，並明確哪些查詢走 direct、哪些查詢走 proxy。

用記錄定位層級，不憑介面狀態判斷

介面顯示「已連線」通常只代表核心程序已啟動，不能證明每個請求都找到正確出站。排查時先看監聽連接埠是否建立，再看請求是否進入對應入站，接著看路由命中結果，最後查看出站連線錯誤。若記錄完全沒有測試請求，問題在應用程式代理、系統代理或 TUN 接管層；若有入站記錄但規則與預期不同，問題在目標識別或路由順序；若已命中預期出站卻連線失敗，再檢查伺服器設定、網路可達性與時間設定。

• 確認目前操作的對象是訂閱原始項目、用戶端產生的設定，還是系統網路設定。
• 修改前匯出用戶端設定或記錄關鍵選項，確保可以回到已知狀態。
• 測試期間關閉會改寫代理設定的其他網路工具，避免連接埠與路由表互相覆蓋。
• 使用同一組目標重複測試，先比較路由命中變化，再比較最終存取結果。

桌面端進階設定優先使用 v2rayN，因為訂閱分組、路由規則、DNS 與 TUN 入口集中，記錄也便於對照。Android 端可使用 v2rayNG；需要 V2Fly 核心時再選擇 v2flyNG。三款用戶端的下載入口與平台範圍見用戶端下載頁。設定項目名稱可能因介面調整而變化，但「入站—路由—DNS—出站」的核心流程保持一致，後續各章均依這條流程說明。

依來源建立分組，不要把所有項目堆在一起

訂閱分組的第一個作用是標記來源。新增訂閱時，為每個位址設定穩定備註，例如「工作設定」、「行動備用」或「測試環境」，不要使用「訂閱一」、「新位址」這類無法追溯的名稱。更新完成後，伺服器項目應保留所屬分組關係。之後出現同名項目、路由表現差異或某個來源失效時，可以直接限定問題範圍，不必逐項猜測。

分組的第二個作用是隔離更新。訂閱更新通常會重新讀取遠端內容，並對該分組中的項目進行新增、修改或移除。更新前若曾手動修改伺服器位址、連接埠或傳輸參數，下次同步可能覆蓋本機修改。需要長期保留的自訂項目應複製為獨立本機設定，並在備註中寫明來源與用途；不要依賴「改完後不再更新」這類隱含約定。臨時修改則應記錄原值，測試結束後刪除副本。

分組的第三個作用是控制批次操作。測試伺服器、匯出選取項目、批次啟用或刪除時，先限定目前分組。尤其在多訂閱情境中，相同備註可能來自不同來源，單看顯示名稱無法判斷它們是否共用伺服器設定。建議讓分組名稱表達來源，讓項目備註表達區域、協定或用途，兩者承擔不同資訊，避免把所有屬性都塞進一個過長名稱。

篩選規則只負責縮小可見集合

伺服器篩選適合處理項目很多且命名穩定的訂閱。常見條件包括依備註包含詞、正規表示式、協定類型或分組篩選。先使用包含詞建立簡單規則，確認結果後再升級為正規表示式。正規表示式需要明確大小寫、空格、連字號與全形字元差異。例如要保留備註中含「備用」或「測試」的項目，可使用 備用|測試；若要排除這些項目，應使用用戶端提供的排除條件，不要用過度複雜的否定表示式模擬所有邏輯。

篩選與刪除的意義不同。篩選後的項目仍保存在訂閱分組中，只是不會出現在目前檢視或候選清單；刪除項目後，下次更新可能再次出現。若某類項目長期不需要，優先在分組的篩選條件中排除。若只是暫時聚焦某個協定或區域，使用檢視篩選，不要修改訂閱內容。篩選結果為空時，先清除規則恢復完整清單，再逐項新增條件。如此可以判斷是訂閱確實沒有項目，還是篩選表示式涵蓋範圍過大。

保留條件：
(備用|測試).*(VLESS|Trojan)

排除條件：
過期|維護|臨時

說明：
先比對用途詞，再比對協定詞；
排除條件獨立執行，不要與保留條件寫成一條複雜表示式。

範例用於說明篩選順序，實際比對對象是訂閱提供的伺服器備註。

更新訂閱時保留可回復狀態

執行更新前，先確認目前伺服器屬於哪個分組，並記下目前可用項目的備註。更新後不要立即批次刪除舊項目，先觀察新增、移除與參數變化。若用戶端支援更新時保留原項目，短期排錯時可以開啟；穩定後再清理重複項。長期同時保留舊、新兩套項目會造成選擇混亂，也可能讓自動選擇邏輯繼續使用已不再維護的設定。

訂閱位址讀取失敗時，依網路層次排查。第一步確認位址完整且前後沒有空格；第二步確認訂閱更新請求採用的代理方式，是直連、跟隨系統代理，還是透過目前核心；第三步查看回傳內容是否為用戶端可識別的訂閱格式。回傳登入頁面、錯誤提示文字或空內容時，用戶端可能只顯示「解析失敗」。此時切換伺服器通常沒有作用，應先處理訂閱請求本身。

訂閱更新成功但沒有新項目時，依序檢查目前分組、篩選條件、重複項目處理與協定支援。某些項目可能因備註相同而被視為重複，也可能因目前核心不識別對應欄位而未匯入。v2rayNG 預設面向 Xray 設定；v2flyNG 面向 V2Fly 核心。訂閱包含特定核心擴充時，應讓用戶端與核心能力相互對應，而不是手動刪除未知欄位後繼續使用。

建立穩定的伺服器選擇流程

伺服器測試只能說明測試時刻、測試方法與測試目標下的表現，不能取代協定參數檢查。先排除設定欄位不完整、位址無法解析或傳輸層不相容的項目，再進行連線測試。選擇後使用真實應用程式請求驗證路由與 DNS，不要只看用戶端測試結果。若多個項目共用相同網域，DNS 快取與連線重用還可能讓短時間測試結果互相影響，切換後應等待舊連線結束或重新啟動對應應用程式。

建議保留一個已驗證的基準項目。修改路由、DNS、TUN 或自訂出站後，始終先用基準項目測試。若基準項目也失敗，問題更可能出在本機設定；若只有新項目失敗，再檢查該項目的協定、連接埠、傳輸、安全層與伺服器名稱。透過這種對照，可以避免把本機規則問題誤判為訂閱問題，也能防止排查過程中連續切換多個變數。

訂閱匯入格式與桌面端、Android 端入口可繼續查看V2Ray 訂閱連結匯入教學。本章重點是匯入後的管理：來源可追溯、更新可回復、篩選可撤銷、選擇有基準。滿足這四項後，多訂閱與複雜路由才有穩定基礎。

先確定出站標籤，再撰寫比對條件

路由規則的結果不是「允許」或「拒絕」，而是將請求交給指定出站。常見標籤包括代理出站 proxy、直接連線 direct 與阻斷出站 block。用戶端產生的實際標籤可能不同，因此複製規則前必須先查看目前出站名稱。規則引用不存在的標籤時，核心可能拒絕啟動，也可能讓該規則無法得到預期結果。

一條規則可以依網域、IP、連接埠、入站標籤、網路類型或協定特徵進行比對。網域條件適合明確網站與 geosite 分類；IP 條件適合區域網路、私有位址與 geoip 分類；入站標籤適合將不同本機連接埠或 TUN 流量送往不同出站。不要在同一條規則中堆放彼此無關的條件，因為同一規則內的不同欄位通常會按同時滿足處理，範圍會比直覺更窄。

規則清單依序檢查，第一個命中項便結束比對。因此精確規則應放在分類規則之前，分類規則應放在最終兜底之前。例如某個屬於 geosite:cn 的網域必須走代理，應先為該網域單獨撰寫 proxy 規則，再寫 geosite:cn 到 direct。若順序相反，分類規則先命中，後面的例外永遠不會執行。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:internal.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:geolocation-!cn"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

這是一段核心路由結構範例。出站標籤需要與用戶端產生的設定保持一致。

理解 domainStrategy 的影響

AsIs 表示路由階段優先使用原始目標，不主動為了 IP 規則解析網域。請求攜帶網域時，網域規則可以比對；只有 IP 目標才能直接進入 IP 規則。其行為簡單，適合主要依網域分類的設定。缺點是網域未命中任何規則時，後續 geoip 條件無法接手，除非應用程式已將目標解析成 IP。

IPIfNonMatch 表示先嘗試網域規則，未命中時解析網域，再嘗試 IP 規則。它適合「網域分類優先，IP 地理分類兜底」的結構，也是常見的平衡選擇。需要注意，路由階段發生的解析會使用核心 DNS 設定；DNS 設定不完整時，表現會像路由規則失效。記錄中若出現解析錯誤，應先修復 DNS，不要繼續增加網域例外。

IPOnDemand 會在遇到可能需要 IP 的規則時更早觸發解析。複雜規則中它可能增加查詢次數，並讓原本只需依網域判斷的請求受到 DNS 結果影響。除非明確需要提前取得 IP，不建議將它作為解決「規則不命中」的通用開關。選擇策略時，應依規則結構決定，而不是依名稱判斷哪個更「完整」。

用可解釋的層級組織規則

建議將規則分為五層。第一層處理內網與本機資源，例如 geoip:private 和內部網域，通常走 direct。第二層是必須覆蓋分類結果的精確例外。第三層是協定或應用程式特定規則，例如依入站標籤區分瀏覽器連接埠與開發工具連接埠。第四層是 geosite、geoip 等大範圍分類。第五層是最終兜底，明確未匹配請求要走 proxy 還是 direct。

阻斷規則應保持可追溯。若直接加入範圍很大的分類清單，應用程式失敗時難以判斷是遠端問題還是本機命中 block。先從明確網域開始，並讓記錄保留路由結果。對於 UDP、區域網路探索、時間同步等系統流量，不要因為「看起來不需要」就全部阻斷；TUN 模式下這些請求可能影響網路狀態判斷與應用程式啟動。

連接埠規則需要同時考慮目標連接埠與傳輸協定。只依 53 比對可能同時涵蓋 TCP 與 UDP DNS；只依網路類型比對 UDP 又會包含其他即時通訊。若目標是單獨處理 DNS，應同時限定連接埠、網路與入站來源。若目標是讓某個應用程式固定走指定出站，優先為它設定獨立入站連接埠，或使用用戶端支援的程序比對能力，而不是用一組不斷擴大的目標網域猜測應用程式行為。

處理 geosite 與 geoip 更新後的變化

分類資料庫會影響同一規則的比對範圍。更新後若部分網域改變路徑，先確認資料檔案已被目前核心讀取，再確認分類名稱存在，最後查看精確網域是否被歸入新的集合。不要透過重複新增相同規則來掩蓋問題；第一個命中原則不會因規則重複而改變。相關檔案作用、替換入口與規則失效排查可查看geoip.dat 與 geosite.dat 更新方法。

完成路由設定後，將規則匯出為一份附有說明的清單。至少記錄規則順序、每層目的、依賴的出站標籤與資料庫分類。用戶端介面中的預設模式適合快速選擇，但自訂規則一旦增加，就應以實際產生的設定為準。如此在更新用戶端、切換核心或遷移裝置時，可以判斷差異來自介面預設，還是核心欄位變化。

區分系統 DNS、核心 DNS 與應用程式自行解析

系統 DNS 是作業系統提供給一般應用程式的名稱解析入口。核心 DNS 是 Xray 或 V2Fly 設定中的解析模組，主要為路由判斷、代理伺服器位址解析與被接管的 DNS 請求提供服務。部分瀏覽器或應用程式還會使用自己的加密 DNS，繞過系統設定。三條路徑可能同時存在，因此「修改了 DNS」必須說明修改的是哪一層。

在一般系統代理模式下，應用程式若將網域交給 SOCKS 或 HTTP 代理，核心可以看到網域並依自身設定處理；應用程式若先使用系統 DNS 取得 IP，再連線代理，核心可能只看到 IP。TUN 模式下，系統 DNS 請求可以被虛擬網卡捕獲，但應用程式內建的加密 DNS 仍可能以一般 HTTPS 請求運作。排查解析差異時，先關閉應用程式內的自訂解析功能，以系統預設路徑建立基準，再逐層恢復。

DNS 設定的目標不是單純追求某個解析器回應更快，而是確保查詢可達、結果適用於目前網路，且路由能依結果作出一致判斷。若網域規則依 geosite 決定出站，而應用程式提前解析後只提交 IP，最終會改由 geoip 或兜底規則決定。兩種結果都可能正常，但必須符合設計預期。

為不同網域設定明確的解析伺服器

核心 DNS 可以設定多個伺服器，並依網域分類選擇。內部網域應交給能識別內部區域的解析器；一般直連網域可使用本地網路可達的解析器；需要透過代理存取的解析服務則必須指定對應出站，或確保路由規則不會形成迴圈。不要把所有伺服器簡單並列後期待核心自動選出「最佳」結果，不同核心與設定欄位對並行查詢、回退與預期 IP 的處理並不相同。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

範例展示分類查詢結構。實際位址與出站路徑應依目前網路條件設定。

hosts 適合固定少量內部名稱或覆蓋特定解析結果。它不是大型網域清單的替代品，也不應儲存頻繁變動的外部位址。domains 用於限定解析伺服器負責的網域集合，順序與比對優先級需要配合核心規則理解。expectIPs 用於檢查回傳位址是否符合預期分類；它能輔助回退，但分類資料庫過舊或目標使用跨區域分發時，過嚴條件可能拒絕原本可用的結果。

選擇 IPv4 與 IPv6 查詢策略

UseIP 通常允許回傳可用的 IP 類型，具體行為受系統與核心支援影響。UseIPv4 只請求或保留 IPv4 結果，適合目前網路沒有穩定 IPv6 路由的環境。UseIPv6 只使用 IPv6，前提是本機、代理伺服器與目標鏈路都具備對應連通性。不要因為某次 IPv6 連線失敗就永久關閉所有 IPv6；先判斷失敗發生在本機出口、代理出站還是目標網站。

雙協定環境中的典型問題是 DNS 回傳 IPv6 位址，但目前出站只能建立 IPv4 連線。應用程式可能先等待 IPv6 逾時，再回退 IPv4，表現為首次開啟速度緩慢。處理時可在核心 DNS 中暫時使用 UseIPv4 驗證。如果延遲消失，再檢查系統 IPv6 路由與出站支援；若沒有變化，瓶頸不在位址族選擇。反過來，強制 IPv4 後某些僅提供 IPv6 的內部資源會失效，因此內部網域最好使用獨立伺服器與規則。

避免 DNS 迴圈與啟動依賴

代理伺服器位址如果是網域，核心啟動時必須先解析它。若唯一 DNS 伺服器只能透過尚未建立的代理出站存取，就會形成迴圈依賴。為伺服器位址準備可直接存取的引導解析器，或在可靠前提下設定靜態對映。靜態對映需要自行維護位址變化，因此更適合受控環境，不適合將動態服務長期固定到單一 IP。

另一種迴圈發生在 DNS 路由規則：將所有 53 連接埠流量送入專用 DNS 出站，而專用出站本身又產生被相同規則捕獲的 53 連接埠請求。解決方法是用入站標籤、目標位址或專用出站標籤縮小規則範圍，確保核心自己的上游查詢能離開迴圈。TUN 下還需避免將虛擬網卡發出的查詢再次重新導向同一入站。

快取排查應採用先清理、後重現的順序。依序清理應用程式快取、系統 DNS 快取與核心快取，再只發起一次查詢。若不清理快取，修改解析伺服器後仍可能使用舊結果，導致誤判。確認設定穩定後再恢復正常快取，因為完全停用快取會增加查詢量，也會讓短暫網路波動更直接地影響每次連線。

最後使用「內部網域、明確直連網域、明確代理網域、代理伺服器網域」四類目標分別測試。查看每類查詢是否進入預期伺服器，並對照路由記錄確認最終出站。DNS 正常的標準不是所有網域都由同一個伺服器回答，而是每類名稱都沿可解釋的路徑取得可連線結果。

明確 TUN 解決的問題

系統代理依賴應用程式主動讀取作業系統代理設定。瀏覽器與部分桌面程式通常支援，某些命令列工具、遊戲啟動器或自帶網路堆疊的程式則可能忽略。TUN 模式建立虛擬網卡並調整路由，讓更多 IP 流量進入核心，再由路由規則選擇 direct、proxy 或 block。它擴大了接管範圍，但不會自動修正錯誤的伺服器、路由或 DNS 設定。

開啟 TUN 前，先在一般系統代理模式下確認基準伺服器可以連線、網域解析正常，且直連與代理規則符合預期。否則切換 TUN 後同時增加虛擬網卡、路由表、DNS 劫持與權限變數，排查範圍會顯著擴大。建議儲存一份一般代理設定，TUN 失敗時先關閉 TUN 並恢復系統網路，再驗證基礎流程是否仍然正常。

v2rayN 在 Windows、macOS 與 Linux 上提供桌面端，但不同系統建立虛擬網卡、修改路由與請求權限的方式不同。介面中的核心概念相同：選擇 TUN 入站、設定堆疊類型、決定自動路由與嚴格路由、設定 DNS 接管，並確保核心以足夠權限執行。平台安裝入口見Windows 下載、macOS 下載與Linux 下載。

選擇網路堆疊與自動路由

TUN 實作通常提供不同網路堆疊選項。系統堆疊更接近作業系統原生行為，相容性路徑清楚；使用者態堆疊在部分環境中更便於跨平台處理，但對特定協定、分片與本地網路的表現可能不同。沒有明確需求時，先使用用戶端預設推薦項。出現 UDP、區域網路或特定應用程式異常時，再切換堆疊進行單一變數對照，不要同時修改 MTU、DNS 與路由規則。

自動路由負責將符合範圍的系統流量送進虛擬網卡。啟用後應檢查預設路由、區域網路路由與代理伺服器位址的例外路徑。代理伺服器本身的連線不能再次進入同一個 TUN 入站，否則會產生迴圈。用戶端通常會為伺服器位址與必要的系統網路新增排除項，但伺服器使用網域且解析結果變化時，仍需查看記錄確認實際位址沒有被錯誤接管。

嚴格路由用於減少流量繞過 TUN 的路徑。開啟後，區域網路存取、虛擬機網路、容器網路與企業網路用戶端可能受到影響。先在關閉嚴格路由的狀態下完成基礎驗證，再依接管需求開啟。若開啟後只有區域網路資源失敗，應為私有位址與對應網段保留 direct 路由，並確認這些目標沒有被更前面的代理規則命中。

處理權限、防火牆與路由殘留

建立虛擬網卡與修改系統路由通常需要提升權限。若用戶端介面提示 TUN 已開啟，但系統中沒有對應介面，先檢查權限請求是否完成，再查看核心啟動記錄。不要反覆點擊開關；失敗的啟動可能留下程序或部分路由。先停止核心，退出用戶端，確認虛擬介面與相關程序狀態，再重新啟動。

防火牆可能依程式路徑、網路介面類型或網路設定檔控制存取。用戶端更新或切換桌面版與傳統 WPF 版後，程式路徑可能變化，舊規則不一定繼續匹配。出現「系統代理正常、TUN 完全沒有流量」時，檢查核心程序是否允許透過新的虛擬介面通訊。出現「部分應用程式正常、部分應用程式立即失敗」時，再檢查應用程式是否綁定特定實體介面，或使用目前堆疊不支援的網路方式。

異常退出後，系統可能暫時保留 DNS 或路由設定。處理順序是先正常關閉 TUN，再退出用戶端，然後恢復系統自動取得 DNS 與預設路由。只有確認用戶端程序已停止後，才進行系統網路重設。直接在核心執行時刪除虛擬網卡，會讓用戶端繼續持有失效介面，記錄中出現更多衍生錯誤。

依症狀縮小 TUN 故障範圍

若開啟後所有網路立即中斷，先檢查預設路由、核心是否成功監聽，以及代理伺服器是否被迴圈接管。若網域失敗但直接 IP 正常，重點檢查 DNS 接管與上游查詢出站。若網頁小資源正常、大資源卡住，保持其他設定不變，測試 MTU 是否過高。若只有 UDP 異常，查看目前伺服器協定、TUN 堆疊與路由規則是否允許 UDP，不要先修改 DNS。

若關閉 TUN 後網路仍異常，確認虛擬網卡是否消失、系統 DNS 是否恢復、預設路由是否指向實體網路。重新啟動用戶端核心不等於恢復作業系統設定；需要先執行用戶端的停止或恢復操作。完成恢復後，再用不經過用戶端的基礎網路請求確認系統狀態，最後重新開啟一般代理模式。

TUN 穩定後再設定程序規則、嚴格路由與 FakeDNS。每新增一項，都重複「網域請求、IP 請求、直連目標、代理目標、區域網路資源」五組測試。TUN 的價值是擴大接管覆蓋範圍，不是將所有流量強制交給單一出站。最終路徑仍由路由規則決定，因此直連網段、DNS 出站與伺服器迴圈例外必須明確。

理解「回傳假位址、保留真網域」的過程

應用程式發起網域查詢時，FakeDNS 不會立即回傳目標的真實 IP，而是從專用位址池分配一個臨時位址，並儲存「臨時位址—原始網域」的對映。應用程式隨後連線到這個臨時位址，TUN 入站捕獲連線後，核心依對映還原原始網域，再執行網域路由與真正的遠端連線。如此即使應用程式只提交 IP 封包，核心仍能依 geosite 或精確網域規則判斷出站。

臨時位址只在本機對映範圍內有意義，不應被送往區域網路或真實外部網路。若 TUN 沒有接管該連線，路由表將它送到實體網卡，應用程式會直接失敗。因此 FakeDNS 必須與 DNS 接管及 TUN 路由一起啟用。單獨在 DNS 設定中加入 FakeDNS 伺服器，卻沒有讓回傳位址對應的連線進入核心，會出現「解析有結果、連線全部失敗」的典型現象。

FakeDNS 主要解決網域資訊遺失問題，不會提升伺服器連線能力，也不會取代上游真實解析。核心還原網域後，仍需依出站方式解析真實目標，或將網域交給遠端。上游 DNS 無法連線、路由標籤錯誤或伺服器不支援目標連線時，FakeDNS 無法修復這些問題。

規劃位址池，避免與真實網路重疊

位址池應使用專門保留，且不與目前區域網路、企業網路、虛擬機網路或容器網路重疊的範圍。若臨時位址與真實內部網段重疊，存取內部資源時可能被誤認為 FakeDNS 對映，或外部網域的臨時連線被送往真實內網。啟用前檢查系統路由表，記錄實體網路、VPN、虛擬機與容器使用的網段，再選擇不衝突的範圍。

位址池大小決定同時可維護的對映數量。一般桌面使用不需要盲目擴大範圍；過大的範圍會增加與現有網路重疊的機會。對映具有生命週期，應用程式快取的臨時位址必須在對映有效期內持續可識別。若應用程式長期快取 DNS，而核心重新啟動後對映消失，舊連線可能短暫失敗。此時清除應用程式 DNS 快取並重新查詢即可，不應將舊臨時位址寫入 hosts。

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

範例位址段用於基準說明。啟用前仍需確認本機及所在網路沒有使用相同範圍。

決定哪些網域進入 FakeDNS

不建議將所有查詢一次切換到 FakeDNS。內部網域、區域網路裝置名稱與必須由本地 DNS 回答的區域應保留真實解析。先讓需要網域路由，且會被 TUN 接管的外部網域進入 FakeDNS；其他查詢繼續由對應解析器處理。分類範圍越清楚，出現問題時越容易判斷是對映、真實解析還是路由規則造成。

某些應用程式會比較 DNS 結果、建立直連 UDP 工作階段，或將位址傳給系統外的其他裝置。這類流程可能不適合臨時位址。若某個應用程式在一般 TUN 下正常，開啟 FakeDNS 後失敗，先為它涉及的網域設定真實解析例外，而不是立即關閉全部 FakeDNS。確認例外有效後，再判斷是否需要擴大該應用程式的網域集合。

FakeDNS 與流量嗅探可以搭配，但職責不同。FakeDNS 在查詢階段建立對映，適用於被接管的 DNS 請求；嗅探從連線內容中嘗試還原網域，適用於沒有對映但握手包含網域的流量。兩者同時啟用時，應查看記錄中的目標還原來源。若目標網域錯誤或規則異常，逐一關閉其中一項測試，避免無法判斷最終網域由哪條路徑取得。

依對映流程排查失敗

第一步確認應用程式查詢是否進入核心 DNS。若查詢沒有被接管，回傳的是一般真實 IP，後續不會產生 FakeDNS 對映。第二步確認回傳位址屬於設定的位址池。第三步發起連線並檢查 TUN 是否捕獲該臨時位址。第四步確認核心能從對映還原網域。第五步查看還原後的網域命中了哪條路由規則。依序驗證五個步驟，可以準確判斷斷點。

如果回傳臨時位址但連線沒有記錄，問題在系統路由或 TUN 接管。如果有連線記錄但無法還原網域，檢查對映是否因核心重新啟動而失效，以及應用程式是否使用了快取的舊位址。如果網域還原正確卻命中錯誤出站，回到路由規則順序處理。如果已命中正確出站但仍失敗，則檢查真實 DNS 與出站連線，不要繼續修改 FakeDNS。

完成設定後，分別測試首次查詢、重複查詢、核心重新啟動後的舊快取，以及區域網路名稱。首次與重複請求用於檢查對映重用，重新啟動測試用於確認應用程式快取恢復行為，區域網路測試用於驗證真實解析例外。FakeDNS 設定穩定的標準是網域分流可解釋、內部資源不受影響，重新啟動後透過重新查詢即可恢復，而不是所有 DNS 結果都變成臨時位址。

為每個訂閱定義職責

新增第二個訂閱前，先說明它要解決什麼問題。可以依工作環境、裝置用途、協定能力或備援關係劃分，但不要只因為「項目更多」就疊加來源。每個訂閱都應有唯一備註、明確更新方式與獨立篩選條件。若兩個來源提供大量同名項目，名稱前加上簡短分組標記，確保記錄與目前伺服器欄位能直接識別來源。

主要訂閱用於日常選擇，備用訂閱只在主要來源更新失敗或特定環境下啟用，測試訂閱則不參與自動選擇。將職責寫入分組備註後，批次更新與清理才有依據。若所有訂閱都長期啟用並混合顯示，誤選舊項目、重複項目或測試設定的機率會持續增加，也無法判斷某次參數變化來自哪個來源。

不同訂閱可能使用不同協定欄位與核心擴充。匯入成功不代表目前核心能完整運作。Xray 與 V2Fly 的能力差異可查看Xray 核心與 V2Fly 核心差異解讀。v2rayN 可在桌面端負責主要設定管理；Android 端依核心需求使用 v2rayNG 或 v2flyNG。跨用戶端遷移時，應遷移標準分享連結或受支援的訂閱格式，不要假設用戶端私有設定可以原樣互換。

安排更新順序與失敗回復

批次更新時依「備用—測試—主要」的順序執行。先更新非主要分組，可以提早發現訂閱格式變化、篩選規則失效或重複項目處理異常。確認匯入結構正常後，再更新主要分組。更新期間保持目前已連線項目不變，待新清單檢查完成後再切換，避免更新與連線切換同時發生。

訂閱更新失敗時不應立即刪除分組後重新新增。先記錄回傳錯誤，確認請求路徑與位址有效，再嘗試單獨更新。刪除並重建可能遺失分組篩選、更新策略與本機備註，也會讓舊項目與新項目之間的對應關係消失。如果確實需要重建，先匯出分組設定或截圖記錄關鍵項目，並為新分組使用臨時名稱，驗證後再取代舊分組。

對更新結果執行四項檢查：項目總類是否合理、目前項目是否仍存在、篩選後是否有可選項目、協定欄位是否能被目前核心識別。這裡不依賴固定數量，因為訂閱內容會變化。重點是比較結構，而不是追蹤容易過時的數字。若更新後清單突然為空，優先關閉篩選；若清單存在但全部無法啟動，檢查核心相容性與共用欄位變化。

處理重複項目與本機副本

判斷重複不能只看備註。相同名稱可能對應不同位址或協定，不同名稱也可能指向相同伺服器。清理前至少比較位址、連接埠、協定、傳輸、安全設定與伺服器名稱。用戶端的自動去重策略若只涵蓋部分欄位，仍可能留下功能上相同的項目。反過來，手動依名稱刪除可能誤刪不同用途的設定。

需要修改訂閱項目時，複製成本機副本，並在備註中加入「本機測試」與來源分組名稱。副本不參與訂閱更新，可用於比較傳輸參數、路由策略或核心差異。測試完成後，將有效修改回饋到可維護的設定來源，或保留一個說明清楚的本機項目。不要累積大量無法追溯的副本；它們在幾次更新後會與原始設定脫節。

本機路由、DNS 與 TUN 設定通常屬於用戶端層級設定，不應複製到每一個伺服器項目中。將伺服器連線參數與本機網路策略分開後，切換訂閱不會重設路由邏輯，也更容易判斷問題屬於伺服器還是本機策略。只有需要特定伺服器專用出站鏈時，才在自訂設定中建立明確引用。

遷移時只帶走可解釋的設定

遷移前列出訂閱位址、分組備註、篩選表示式、目前伺服器、路由規則、DNS 設定與 TUN 選項。先在新裝置匯入訂閱並驗證基礎連線，再遷移篩選與路由，最後遷移 DNS、TUN 與 FakeDNS。不要直接將整份產生的設定覆蓋到不同系統，因為入站監聽位址、虛擬網卡、檔案路徑與權限需求可能不同。

遷移後的第一輪測試使用同一個基準伺服器與同一組目標。若伺服器連線正常但規則不同，比較路由順序與分類資料庫；若網域行為不同，比較系統 DNS、核心 DNS 與應用程式設定；若只有 TUN 異常，檢查新系統的權限、路由與防火牆。分層遷移雖然步驟較多，但每一步都有明確的回退點。

多訂閱管理完成後，建議保留一份文字化設定說明，記錄各分組職責、篩選含義與遷移順序。說明不需要儲存伺服器敏感欄位，只需描述結構。如此在用戶端介面變化或重新安裝後，仍能依職責恢復，而不是依賴對舊介面位置的記憶。

從最小出站集合開始

一個可維護的設定至少包含主要代理出站、直接出站與阻斷出站。主要代理出站承載目前伺服器連線，direct 讓核心使用本機網路連線目標，block 終止明確不需要的請求。先確保三者運作，再增加備用代理、特定介面直連或鏈式出站。出站越多，路由標籤、DNS 路徑與記錄判斷就越複雜。

每個出站都必須使用唯一且穩定的 tag。標籤是路由規則、DNS 查詢與其他出站引用的連接點，不只是介面名稱。建議使用小寫英文與連字號，例如 proxy-main、proxy-backup、direct-work。修改標籤後，必須搜尋所有設定引用；遺漏一處就可能導致核心啟動失敗或流量落入兜底。

用戶端依目前伺服器自動產生的代理出站，可能在切換伺服器後變化。若自訂規則引用用戶端固定保留的邏輯標籤，應確認切換後標籤仍然存在；若直接引用某個手動出站，則該出站必須獨立儲存。不要透過複製整段產生的設定來鎖定目前伺服器，這會讓訂閱切換與更新失去作用。

{
  "outbounds": [
    {
      "tag": "proxy-main",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "server.example",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-4000-8000-000000000000",
                "encryption": "none"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "server.example"
        }
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

範例中的位址與識別碼僅用於展示結構，實際連線參數應來自有效設定。

為 direct 出站指定清楚邊界

direct 並不表示流量繞過核心，而是請求進入核心後由 freedom 出站從本機網路建立連線。它仍會受到核心 DNS、位址族策略與出站繫結設定影響。區域網路、內部網域與明確直連分類通常指向 direct，但必須確保路由規則順序正確。若 TUN 已接管 direct 流量，還要防止該出站連線再次被系統路由送回 TUN。

在多網卡環境中，可以為特定 direct 出站設定傳送介面或來源位址，讓工作網路與一般網路分開。設定前先確認介面名稱穩定，並驗證目標網段可從該介面到達。系統休眠、網路切換或介面重建後，繫結名稱可能失效。出現「預設 direct 正常、自訂 direct 失敗」時，先移除繫結恢復基準，再檢查介面與來源位址，不要修改目標路由規則。

阻斷出站只應接收明確匹配的流量。命中 block 通常表現為本機立即失敗，與遠端逾時不同。記錄中若能看到請求進入 block，就不應繼續檢查伺服器。為便於排查，阻斷規則應集中放置並寫明目的，避免分散在多個預設與自訂清單中。

謹慎使用代理鏈

鏈式出站讓一個代理出站透過另一個出站建立連線。它適用於具有明確網路拓撲的情境，但會增加一層或多層連線。每一層都涉及伺服器解析、路由、傳輸與錯誤處理。設定前先分別驗證每個出站可單獨使用，再建立引用；鏈路失敗時從最外層連線開始查看，確認請求實際到達哪一層。

出站引用必須避免迴圈。若 proxy-a 透過 proxy-b，而 proxy-b 又透過 proxy-a，兩者都無法建立基礎連線。更隱蔽的迴圈來自路由：proxy-b 的伺服器位址被規則重新送回 proxy-a，而 proxy-a 又依賴 proxy-b。解決方法是為鏈路中的伺服器位址設定高優先級規則，並明確它們應經由 direct 或某個前置出站。

鏈式設定還需要考慮 DNS。每個伺服器網域由哪一層解析、查詢走哪個出站、解析結果是否被 TUN 接管，都應事先確定。最穩妥的方法是先使用可直接解析的入口伺服器建立第一層，再讓後續連線經過已建立的出站。不要讓最底層連線依賴最上層的 DNS 路徑。

用標籤閉環驗證整份設定

完成自訂出站後，列出所有標籤及其引用方。每條路由規則引用的出站都必須存在；每個鏈式引用都必須指向可獨立建立的前置出站；DNS 專用出站不能依賴自身；TUN 排除路徑必須涵蓋代理伺服器連線。然後檢查是否有從未被引用的出站。未引用項不一定錯誤，但通常代表舊設定殘留或預期規則尚未建立。

• 使用主要代理出站測試明確代理網域，並在記錄中確認標籤。
• 使用 direct 測試區域網路與明確直連目標，確認沒有返回 TUN 入站。
• 使用一條臨時精確規則測試備用出站，完成後刪除臨時規則。
• 觸發一個明確阻斷目標，確認記錄顯示本機命中 block。
• 重新啟動核心後再次測試，排除僅由舊連線或快取維持的假正常狀態。

設定無法啟動時，先驗證 JSON 結構，再檢查重複標籤、未知出站引用與協定必要欄位。能夠啟動但路徑錯誤時，查看路由第一個命中項。路徑正確但連線失敗時，再檢查目標出站本身。不要在同一輪修改中同時處理啟動錯誤、路由錯誤與連線錯誤。

至此，訂閱、篩選、路由、DNS、TUN、FakeDNS 與出站形成完整閉環。後續新增規則時，從請求入口沿流程逐層判斷，不要從最終錯誤反向猜測全部設定。若需要重新建立基礎環境，可回到使用指南依快速主線操作；若需要更換用戶端或桌面版本，可進入V2Ray 用戶端下載頁。設定完成後保留一份結構說明與可正常工作的基線，下次調整只改變一個變數。