V2Ray 進階設定
路由、DNS 與 TUN

01／設定來源

訂閱分組與伺服器篩選

分組的界線

訂閱分組主要用於管理來源，並不是流量分流規則。分組通常會儲存訂閱網址、更新選項，以及由該來源產生的伺服器記錄。將伺服器移入某個分組，不會自動指定特定網站使用該伺服器；網站要走哪個出站，仍由目前的連線設定與路由決定。先釐清這點，才不會把整理清單誤當成網路策略。

在 v2rayN 中，先開啟訂閱分組管理，建立名稱清楚的分組，再輸入來源提供的訂閱網址。名稱建議標示用途或來源，例如「日常使用」和「備用連線」，避免只用難以辨識的字母命名。儲存後更新目前分組，再返回伺服器清單確認匯入結果。各版本介面中的選單位置可能不同，請依功能名稱與說明找到入口。

訂閱網址通常包含存取憑證，應視同帳戶資訊妥善保管。分享截圖前請遮住網址與 QR Code，也不要將完整連結貼到公開記錄中。網址能在瀏覽器開啟，不代表回傳內容一定適用於目前的用戶端；登入頁、提示頁面和格式轉換結果都可能被當成一般文字下載，最後就會出現更新完成、卻沒有可用記錄的情況。

伺服器篩選

篩選可用來縮小清單，或控制更新後保留哪些記錄，但各用戶端的篩選範圍不盡相同。有些只會影響目前顯示，有些則會在解析訂閱時排除項目。初次設定時，先用簡單的名稱關鍵字確認效果：記下更新前顯示的內容，儲存條件後重新更新該分組，再清除篩選條件觀察結果。確認實際作用後，再組合較複雜的條件。

若輸入框明確支援正規表示式，可使用以下模式比對名稱中的兩種用途詞。直線符號代表「或」，括號用於分組。若輸入框只支援一般文字，貼上正規表示式不會產生相同效果。名稱由來源決定，可能隨更新改變；地區縮寫、倍率標示與協定名稱也不一定有統一格式，因此篩選條件宜保持寬鬆。

(日常|備用)

先確認輸入框的模式是「保留符合項目」還是「排除符合項目」。相同的表示式在不同模式下，結果可能完全相反。若清單變成空白，先別急著重新安裝用戶端：清除篩選條件、選取所有分組、取消搜尋，再更新單一來源。若記錄重新出現，問題就在顯示或篩選層，而不是伺服器連線參數。

更新與手動修改

訂閱記錄通常會由遠端資料重新產生。直接修改記錄中的位址、連接埠或傳輸欄位，下次更新時可能會恢復原值。若要長期保留調整，請複製成獨立的手動記錄並使用不同名稱，同時註明複製日期與用途。如此既能繼續接收來源更新，也能辨別哪些記錄已不再由訂閱管理，避免舊參數覆蓋新設定。

Android 上的 v2rayNG 與 v2flyNG 也應依來源分開管理訂閱。匯入 QR Code 適合單筆設定，匯入訂閱則適合日後批次更新；兩者代表不同的資料關係。若要從另一台裝置搬移設定，請先確認匯出的是單筆連線、訂閱網址還是完整應用程式設定，再選擇對應的匯入入口，不要反覆嘗試不相干的格式。

更新失敗時，先保留目前可用的記錄，再檢查系統時間、訂閱是否過期，以及更新要求是否需要透過現有代理連線。有些用戶端允許透過目前代理更新，有些更新流程則會直接連線。先用目前網路可行的方式更新一個分組，成功後再考慮自動更新；不要讓所有來源都依賴尚未驗證的連線。

整理完成後，選一筆記錄作為測試基準，暫時不要啟用自動切換或複雜篩選。先確認該連線在一般系統代理模式下可用，再開始設定路由與 DNS。來源管理要解決的是「設定從哪裡來」，連線測試要確認的是「設定能不能用」；兩項驗收分開記錄，才能縮小後續故障的範圍。

03／網域解析

DNS 設定最佳化

解析流程

最佳化 DNS 時，先確保解析路徑一致，再考慮回應速度。一次連線可能經過系統解析器、瀏覽器內建的加密解析、用戶端 DNS 與遠端伺服器解析。唯有確認由誰發出查詢、查詢經過哪個出站，以及結果交給誰使用，才能判斷修改是否有效。單純更換一個伺服器位址，通常無法掌控整條解析流程。

系統代理主要轉送遵循代理設定的應用程式要求，不一定會接管系統 DNS。瀏覽器可能直接將網域交給代理，也可能先自行解析；其他程式則可能直接連到固定的解析位址。因此，在用戶端填入 DNS，不代表裝置上的所有查詢都會使用它。請分別檢查瀏覽器設定、系統網路設定與用戶端的接管範圍。

遠端解析與直連解析的分工，應配合路由目標安排。直連資源通常適合使用目前網路可連線的解析器；代理資源則需確認解析要求能沿著預期路徑送達。若加密解析伺服器使用網域位址，就需要先解析該伺服器本身，這一步稱為引導解析；若引導路徑設定錯誤，就可能形成「解析器必須先解析自己」的相依問題。

核心 DNS 範例

以下是主設定中的局部 dns 物件。中國大陸網域優先交由指定伺服器解析，其他查詢則使用 DoH 位址。此範例用來說明依網域分配解析器的設定方式，不保證適用於所有網路。DoH 要求在特定核心與設定下如何選擇出站，仍須搭配路由及記錄驗證，不能只憑位址前綴推定一定會走代理。

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

domains 用來指定優先套用此伺服器的網域範圍，但查詢失敗後的處理方式也會受到回退選項與核心實作影響。這不應被視為嚴格的網路隔離策略。若要限制某類查詢絕不使用其他解析器，請進一步確認目前核心支援的回退欄位、失敗處理方式與實際網路路徑，再設計規則；不能只保留這段範例。

queryStrategy 在此限定核心 DNS 的查詢策略，不會關閉作業系統的 IPv6，也不會阻止所有應用程式自行查詢其他記錄。選用 IPv4 可用來排除雙協定堆疊問題，但不是通用的加速開關。若目前網路與伺服器都能正確處理 IPv6，應先個別測試，再決定是否保留，而不是長期掩蓋相關問題。

快取與分層驗證

更換解析設定後，舊結果可能仍留在系統、瀏覽器、應用程式與核心的快取中。先關閉目標應用程式並重新啟動用戶端，再依系統提供的方式清除快取。比較時使用相同網域，記錄解析結果與實際連線位址；不要只重新整理一次網頁，就認定新設定已生效，頁面資源可能來自本機快取，或仍沿用舊連線。

若「位址可以連線、網域無法開啟」，先檢查 DNS；若「網域解析成功、但連線失敗」，接著檢查路由與遠端連線。解析成功只代表取得了解析結果，不代表結果適合目前的網路路徑。有些服務會依解析器所在位置回傳不同的連線位址；若將直連解析結果交給遠端出站，可能造成不必要的繞路或連線失敗。

若只有瀏覽器異常，請暫時關閉瀏覽器自訂的安全 DNS，改回跟隨系統設定後再比較；若只有特定應用程式異常，請確認它是否使用獨立解析器或固定位址。測試完成後再決定最終策略。此處暫時關閉是為了縮小問題範圍，並非建議所有網路都採用相同的解析方式。

用戶端中的「遠端 DNS」、「直連 DNS」等表單欄位，可能會由設定產生器轉換成多個核心物件。優先使用同一組表單完成設定，不要又在自訂 JSON 中加入另一套相反設定。若需手動擴充，請查看最終產生的檔案，確認沒有重複物件或覆寫情形，再將有效修改記錄在獨立的變更說明中。

05／網域映射

FakeDNS

虛擬位址與原始網域

FakeDNS 會從位址池中回傳虛擬位址，並在內部保存位址與網域之間的映射。應用程式之後連線到這個虛擬位址時，配套入口會還原原始網域，再交由路由與出站處理。它不是公用解析器，也不會讓目標網站取得新位址。FakeDNS 的作用是保留網域資訊，減少本機實際解析結果對後續分流判斷的影響。

這套機制要求 DNS 查詢與連線都經過同一條受控路徑。如果只有 DNS 查詢進入 FakeDNS，後續連線卻繞過用戶端，應用程式就會嘗試直接連到一個並非真實伺服器的位址。反過來說，若連線進入了流量入口，但查詢由瀏覽器的獨立加密 DNS 完成，用戶端可能從未建立映射，網域也就無法如預期還原。

因此，不要將 FakeDNS 當成一般 DNS 位址填入系統。請先確認用戶端及流量入口元件明確支援相應模式，再依同一套實作設定 DNS 接管、位址池路由與映射還原。v2rayN 調度的 TUN 元件可能使用自己的虛擬位址機制，不能只因功能名稱相似，就同時啟用另一套核心 FakeDNS。

Xray 局部設定

以下展示 Xray 中的三個相關層級：頂層位址池、DNS 伺服器清單，以及需合併至目標入口的嗅探物件。位址池採用保留的基準測試位址範圍，並非公網目的位址。此範例沒有建立透明入口，也沒有新增系統路由；缺少這些配套條件時，複製範例不會讓整台裝置自動具備 FakeDNS 功能。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"],
    "routeOnly": false
  }
}

ipPool 定義虛擬位址範圍，poolSize 控制映射池容量。池中的位址只作為識別用途，不應當成真實遠端位址交給直連出口。設定前也請確認現有區域網路、其他通道與測試網路是否使用相同範圍。位址範圍衝突可能導致部分連線被錯誤送到實體介面或其他虛擬介面。

destOverride 中的 fakedns 用於依據映射還原目標。此處明確使用 routeOnly: false，因為若只將還原結果用於路由判斷，實際連線目標仍保留虛擬位址，無法達成此範例的目的。一般 HTTP 或 TLS 嗅探與 FakeDNS 映射並非同一種機制，不應只因欄位名稱相似就互換。

相容性與故障排查

啟用後，先檢查一般網域的解析結果是否落在設定的位址池內，再確認連線是否正確還原為網域。若結果仍是真實公網位址，請檢查查詢是否進入指定 DNS 路徑；若取得虛擬位址但連線失敗，應優先檢查位址池流量是否回到配套入口，以及入口是否使用同一份映射狀態。

有些程式會在本機檢查位址類型、拒絕保留位址，或將解析結果傳給另一台裝置使用。這些情況可能不適合使用 FakeDNS。區域網路裝置探索、依賴真實位址的服務及特定網路診斷工具，應依用戶端支援的方式設定真實解析例外。例外必須同時處理解析與路由，不能只將虛擬位址範圍設為直連。

重新啟動後，系統或應用程式可能仍快取舊的虛擬位址，但新程序中的映射表已經改變，因此會出現「剛啟用時正常，重啟後部分功能失敗」的情況。請先清除相關快取並重新啟動目標應用程式，再判斷設定是否有誤。不要將舊虛擬位址寫入長期 hosts 記錄，也不要把它當成服務的固定連線位址儲存。

若一般 DNS 與網域嗅探已能滿足分流需求，就不必為了增加設定項目而啟用 FakeDNS。它適合解決明確的網域保留需求，並非所有網路的預設最佳化方式。請先用單一應用程式驗證效果與相容性，保留可快速還原的設定副本，再逐步擴大使用範圍。

07／出口編排

自訂出站

標籤與協定物件

出站定義收到流量後如何建立下一段連線。路由中的 outboundTag 只是參照，必須對應實際出站物件的 tag。標籤有區分大小寫，建議使用簡短且用途明確的名稱。新增一條指向不存在標籤的規則，不會讓用戶端自動建立連線，並可能在啟動檢查或實際轉送時發生錯誤。

先區分用戶端產生的出站與手動擴充的出站。v2rayN 通常會依目前選取的伺服器產生遠端連線物件，切換伺服器後該物件可能會重建。若直接編輯暫存檔，修改可能在重新啟動時遺失。請使用用戶端明確提供的自訂設定入口，並確認其作用是合併、取代，還是完全接管主設定。

以下是獨立的局部範例：直連、封鎖，以及轉送至本機另一項 SOCKS 服務的出站。範例不包含遠端伺服器驗證資料，並假設本機服務確實在指定位址監聽，且不是目前的流量入口。複製前務必確認監聽連接埠，避免將流量再次送回同一處理流程而形成迴圈。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 10810
          }
        ]
      }
    }
  ]
}

freedom 表示依核心所在的網路直接建立連線，不代表繞過本機所有其他網路工具。若系統預設路由已指向另一個通道，直連出站仍可能經過該通道。判斷實際出口時，應同時查看作業系統路由與用戶端記錄，不能只憑標籤名稱是 direct，就認定流量走實體網路。

blackhole 用於丟棄符合條件的流量。封鎖出站適合明確不需要建立連線的目標，但不應拿來當作設定錯誤時的預設補救方式。若某項服務失敗，先確認是否誤命中封鎖規則，再調整比對範圍。要求遭到靜默丟棄可能會讓連線長時間等待，因此排錯時應將封鎖規則獨立列出檢查。

規則接入與預設出口

以下規則會將文件範例網域交給本機 SOCKS 出站處理，並應放在範圍較廣的兜底規則之前。範例網域僅用於展示語法，實際使用時請改成業務需要的目標。若要涵蓋更多服務，應依實際要求補上網域，而不是直接把所有連接埠交給本機服務，導致無關應用程式也改走其他出口。

{
  "type": "field",
  "domain": ["full:example.com"],
  "outboundTag": "local-socks"
}

未命中任何規則時，核心通常會使用預設出站；常見設定中，預設出站與出站陣列的第一個項目有關。上述範例的第一項是直連，因此不能整段取代原設定後，還假設未符合規則的流量會走代理。請保留原有遠端物件並明確設定兜底策略，或重新檢查陣列順序，確保最終行為符合預期。

鏈式連線的界線

轉送至本機服務與核心內部的鏈式連線不是同一種設定方式。前者會先連到另一個監聽連接埠，再由對方繼續處理；後者則依賴特定核心支援的出站組合欄位。不同核心的欄位與作用層級可能不同，不能將某種實作的傳輸設定直接複製到另一種實作。優先選擇用戶端明確支援、且容易觀察的方式。

新增一層轉送後，需分段驗證。先確認本機 SOCKS 服務能獨立運作，再確認核心能連上該連接埠，最後測試規則是否命中。若前一段正常、完整連線仍失敗，請檢查網域解析位置、UDP 支援與額外封裝需求。不要同時修改兩端設定，否則無法判斷是哪項變更造成結果差異。

自訂出站穩定後，請記錄用途、標籤對應與還原方式。敏感連線參數應留在受保護的用戶端設定中，不要複製到一般維護文件。日常只修改必要規則，避免每次切換訂閱都重寫所有出站；將設定來源與出口編排分開，更新與還原才容易控管。