V2Ray 進階設定指南

為什麼需要設定基準

v2rayN 的實際連線結果由多層設定共同決定：訂閱提供伺服器資訊，用戶端負責選擇目前使用的伺服器，路由決定流量送往哪個出站，DNS 決定網域如何解析，系統代理或 TUN 則決定哪些應用程式流量能進入核心。任何一層發生變化，都可能表現為「網頁無法開啟」「只有部分程式生效」或「切換伺服器後結果不同」。如果同時修改路由、DNS 與接管方式，出問題後很難判斷究竟是哪一層造成。

建議先建立一份最小可用基準：只保留一個確認能連線的訂閱分組，選取一台設定完整的伺服器，路由使用用戶端內建的基本模式，DNS 維持預設值，接管方式先使用系統代理。接著造訪日常使用的一般網站，並觀察 v2rayN 記錄是否出現建立連線、網域解析與選擇出站的紀錄。這裡不必追求複雜效果，只要確認用戶端、核心、伺服器與本機網路能形成完整鏈路。

基準應記錄設定之間的關係，而不是某次測試得到的瞬時數值。可以記下目前使用的分組、伺服器別名、系統代理狀態、路由模式名稱、DNS 是否由用戶端處理、TUN 是否關閉，以及記錄中最後一次正常連線的大致時間。伺服器位址、驗證資訊等敏感內容不應抄入公開筆記；需要遷移時，使用用戶端提供的設定匯出功能，並將檔案儲存在受控位置。

採用單一變數修改法

從基準開始，每輪只變更一個設定主題。例如先完成訂閱分組與篩選，確認更新和選取都正常，再處理路由規則；路由穩定後再調整 DNS；最後才啟用 TUN 或 FakeDNS。每完成一輪，至少驗證三個方面：用戶端記錄沒有持續錯誤、預期應用程式能連線、不應被接管的流量仍依原路徑運作。如此一來，即使設定失敗，也能直接撤銷最近一次變更，不必將整套設定恢復原廠。

排錯期間可暫時將記錄等級提高至 info，需要觀察路由比對細節時再使用更詳細的等級。長期保留過於詳細的記錄會增加閱讀負擔，也可能讓真正有用的錯誤行被大量連線紀錄淹沒。檢查完成後恢復常用等級，並清理僅為測試建立的暫時規則。記錄中的第一個錯誤通常比後續重複錯誤更有價值，因為後面的失敗往往只是上游問題引發的連鎖結果。

建立可復原的工作副本

開始大幅修改前，可以在 v2rayN 中匯出目前設定或複製現有路由設定集，再為副本取一個能說明用途的名稱，例如「辦公室基本路由」或「測試-TUN-DNS」。名稱應反映使用情境，不要只寫「新設定」「設定二」。如果用戶端支援多個路由設定集，應保留一個未經實驗性修改的基礎設定集。更新訂閱不能取代這種備份，因為訂閱主要儲存伺服器項目，不一定包含本機路由、DNS、系統代理和自訂出站設定。

驗證設定時，要區分「用戶端沒有接管流量」與「流量進入用戶端後出站失敗」。前者通常檢查系統代理、TUN、應用程式本身的代理設定；後者則檢查伺服器、路由、DNS 與出站鏈路。最直接的方法是先查看記錄中是否出現目標網域或目標連線。如果完全沒有相關紀錄，應從接管層開始排查；如果已經出現但接著報解析或連線錯誤，再從 DNS 與出站層繼續。更多基礎錯誤現象可參考說明中心，避免把應用程式本身的問題誤判為核心問題。

依來源建立分組，不要依暫時狀態堆疊

v2rayN 可以同時儲存手動新增的伺服器和多個訂閱。較穩妥的組織方式是「一條訂閱對應一個分組」，手動設定則獨立放入「自建節點」之類的分組。如此更新某個來源時，不會誤刪另一個來源的項目，也能快速判斷伺服器欄位來自訂閱還是本機輸入。如果同一供應商提供不同用途的訂閱網址，也應分別命名，並在名稱中加入用途，而不是更新後再靠伺服器別名猜測來源。

分組名稱宜簡短明確，例如「工作訂閱」「行動備用」「自建節點」。不要把到期時間、某次測速結果或目前使用的伺服器寫入分組名稱，這些資訊變動頻繁，會讓名稱很快失真。訂閱備註應說明來源和使用範圍；更新時間交由用戶端記錄即可。需要在多台裝置間維持相同伺服器來源時，可參考電腦與手機多裝置同步 V2Ray 設定的三種方案，其中訂閱同步與單一節點傳遞的界線不同。

理解更新、清理與合併的差異

更新訂閱時，用戶端會依訂閱回傳內容重新整理對應分組。是否保留舊項目取決於用戶端設定與更新方式，因此操作前應先確認目前選取的分組。如果訂閱來源刪除了某台伺服器，而本機仍保留舊紀錄，可能是更新時啟用了保留策略，也可能是同名項目來自另一個分組。此時不要直接全域刪除同名伺服器，應先顯示分組欄或切換分組檢視，確認項目的實際來源。

「清理舊伺服器」適合訂閱內容已有大幅變動的情況，但會影響該分組中曾手動修改的備註。若確實需要保留本機調整，可以先將必要項目複製到手動分組，再重新整理原訂閱。合併多個訂閱看似能減少分組數量，卻會失去來源界線：更新失敗時難以判斷是哪一條訂閱出了問題，同名伺服器也更容易互相覆蓋。除非上游已提供統一訂閱，否則更建議在用戶端層級維持多個獨立分組。

使用篩選運算式縮小清單

伺服器篩選主要用來處理「項目很多，但常用範圍很小」的情況。常見策略包括保留別名關鍵字、依協定名稱篩選、排除關鍵字，以及同時使用多個條件。篩選只會改變清單顯示或候選範圍，不會修復伺服器設定，也不會改變訂閱原始內容。設定篩選前，應先檢查伺服器命名是否穩定；如果訂閱每次更新都會更換別名格式，依賴名稱的規則也要隨之調整。

篩選運算式通常支援一般關鍵字或正規表示式。一般關鍵字較容易維護，適合名稱結構簡單的訂閱；正規表示式適合同時比對多個固定詞，但要注意跳脫字元和大小寫。以下運算式表示保留名稱含有「辦公」或「備用」的項目，並排除名稱含有「測試」的項目。具體輸入位置以用戶端的伺服器篩選設定為準。

保留運算式：
辦公|備用

排除運算式：
測試

如果使用正規表示式，建議先從簡單組合開始，不要一開始就撰寫過長的單行運算式。以名稱為「辦公-上海-VLESS」「備用-東京-Trojan」為例，可以使用 ^(辦公|備用)- 比對固定前綴。若名稱含有括號、加號或句點等正規表示式特殊字元，需要進行跳脫。篩選結果為空時，第一步應暫時清除排除條件，而不是重新匯入訂閱；確認項目恢復後，再逐段加入條件找出過度比對的位置。

先理解規則由上而下比對

一條連線進入 Xray 或 V2Fly 核心後，路由模組會根據網域、目標 IP、連接埠、網路類型、入站標籤和程序資訊等條件尋找符合的規則。通常第一條命中的規則會決定出站，後續規則不再參與。因此，越具體的例外規則越應放在前面，範圍較大的兜底規則則放在後面。例如某個網域必須經過代理，而它所屬的整個網域分類預設直連，那麼具體網域規則就應排在分類規則之前。

常見出站標籤包括 proxy、direct 與 block，實際名稱取決於用戶端產生的設定。自訂規則時必須使用目前設定中真實存在的出站標籤，標籤拼寫不一致會導致規則無法指向預期出站。圖形介面中的「代理」「直連」「阻擋」通常會轉換成這些標籤；如果匯入完整 JSON，則需要自行維持路由規則與 outbounds 陣列中的 tag 對應。

網域規則與 IP 規則的職責

網域規則在連線仍保留網域資訊時運作，適合依完整網域、子網域後綴或內建網域分類進行分流。IP 規則適合目標已解析為位址，或需要處理區域網路、保留位址範圍等情況。啟用網域嗅探後，部分最初只有 IP 的連線可能重新取得網域資訊，再參與網域路由；但嗅探不保證所有協定和應用程式都能恢復網域，因此重要規則不應只依賴單一路徑。

domain:example.com 通常會比對該網域及其子網域，full:api.example.com 只會比對完整名稱，regexp: 用於正規表示式條件。能以完整網域或後綴表示的規則，不必使用正規表示式。IP 規則可使用 CIDR，例如 192.168.0.0/16 表示一段區域網路位址。規則中的示例網域僅用於說明語法，實際使用時應替換成需要控制的業務網域。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:api.example.com",
          "domain:assets.example.com"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": [
          "bittorrent"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy 決定路由階段何時將網域解析為 IP。AsIs 優先保留網域，不主動為 IP 規則解析；IPIfNonMatch 在網域規則沒有比對成功時進行解析，再嘗試 IP 規則；IPOnDemand 則在遇到可能需要 IP 的規則時更早解析。一般先使用用戶端預設值，不要只為了「看起來更完整」就改用更積極的解析策略，因為這會改變 DNS 請求出現的時機，也可能讓排錯鏈路變得複雜。

用小規模規則集驗證順序

建立新的路由集時，可以先只撰寫三類規則：少量必須經過代理的網域、區域網路位址直連，以及最後的預設出站。儲存並套用後，用瀏覽器造訪符合條件的網域，再從記錄中確認命中的出站標籤。驗證完成後，再加入網域分類、連接埠或程序規則。如果一開始匯入數百條自訂規則，單一例外很容易被前面的寬泛條件攔截，也難以判斷內建資料是否與目前核心相容。

連接埠規則應結合網路類型理解。例如只寫 53 可能同時影響 TCP 與 UDP 的 DNS 流量；只需要控制 UDP 時，應同時指定網路條件。程序規則依賴用戶端、作業系統權限和接管方式，不同平台的能力可能不同。它適合處理少量應用程式例外，不宜取代網域與 IP 規則成為主要分流手段。應用程式升級後可執行檔名稱改變，也會使舊程序規則失效。

當某個網站包含多個資源網域時，只為主網域設定路由可能造成頁面主體能開啟，但圖片或 API 失敗。此時應在開發人員工具或用戶端記錄中找出失敗資源的網域，再把真正相關的後綴加入規則，而不是直接擴大為所有流量都經過代理。對 VMess、VLESS、Trojan 與 Shadowsocks 的選擇疑問，可閱讀代理協定比較；協定決定連線方式，路由則決定連線送往哪個出站，兩者不要混為同一項設定。

區分系統 DNS 與核心 DNS

系統 DNS 是作業系統和一般應用程式預設使用的解析路徑；核心 DNS 是 Xray 或 V2Fly 設定中的解析模組，主要服務於進入用戶端的連線、路由判斷和特定網域策略。啟用系統代理時，部分應用程式可能先在系統端解析，再把目標 IP 交給代理；另一些應用程式則會透過代理請求並保留網域。啟用 TUN 後，DNS 請求還可能被核心攔截。如果不先判斷查詢從哪裡發出，只修改核心 DNS，可能對實際問題沒有影響。

排查時可觀察記錄中是否出現目標網域的解析紀錄。如果瀏覽器已將網域解析成 IP，且沒有透過嗅探恢復，路由只能看到位址，網域規則可能無法命中。反過來，如果核心收到網域並負責解析，就要檢查 DNS 伺服器選擇、查詢類型、回傳位址和後續路由。不要把所有解析失敗都歸咎於伺服器；網域拼寫、系統快取、應用程式內建的安全 DNS、路由阻擋和 UDP 接管不完整，都可能造成相似現象。

為 DNS 伺服器定義清楚職責

一套容易維護的設定通常只包含少量 DNS 伺服器，並明確劃分各自的處理範圍。預設伺服器處理一般查詢，指定伺服器處理特定網域，必要時再設定回退。位址可以是傳統 UDP DNS，也可以是基於 HTTPS 的查詢網址，具體支援情況取決於目前核心與用戶端的設定方式。選擇時應優先考慮與現有路由相容且能穩定連線的服務，而不是堆疊多個職責相同的位址。

當 DNS 伺服器本身以網域表示時，會出現「先解析 DNS 伺服器網域」的啟動依賴。解決方式通常是提供 host 對映、使用可直接連線的位址，或指定用來解析該伺服器網域的引導 DNS。如果設定中還有自訂出站，應確認 DNS 查詢是直連還是經過代理。查詢路徑與目標網域的流量路徑可以不同，但這種差異應是明確設計的結果。

{
  "dns": {
    "hosts": {
      "router.local": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": [
          "domain:example.com"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

範例中的 hosts 用於固定本地域名對映；帶有 domains 的伺服器只處理符合範圍的查詢；最後一項則作為一般查詢路徑。skipFallback 表示符合該伺服器的查詢不再進入回退判斷，適合希望結果來源明確的網域。範例位址 dns.example 僅用於展示結構，實際設定必須替換成可用服務。如果不需要依網域分流解析，可以直接使用簡單的伺服器清單，設定越短越容易定位問題。

理解查詢類型與快取

queryStrategy 控制查詢 IPv4、IPv6 或兩者。網路環境沒有可用的 IPv6 路徑時，如果解析得到 IPv6 位址但無法建立連線，可能出現等待後才回退的現象。此時可以根據實際網路能力選擇只查詢 IPv4，而不是透過路由規則到處排除 IPv6。相反地，確認系統和出站都有穩定 IPv6 時，保留雙堆疊更符合正常網路行為。修改後應重新建立連線，並清除應用程式本身的快取，避免舊結果干擾判斷。

DNS 快取能減少重複查詢，但也表示修改設定後不會立即看到新結果。v2rayN 重新啟動核心通常會清除核心端狀態，但瀏覽器和作業系統仍可能保留快取。驗證時可以使用先前未造訪過的子網域，或等待快取到期。不要用同一個長時間開啟的頁面反覆重新整理來判斷，因為瀏覽器可能重用連線、重用解析結果，甚至由背景服務程序處理請求。

系統代理與 TUN 的接管範圍

系統代理適合遵循作業系統代理設定的瀏覽器和桌面應用程式。它設定簡單，停用後也容易直觀地恢復，但部分程式會忽略系統代理，UDP 流量的處理能力也取決於應用程式。TUN 模式透過虛擬網路介面接收更廣泛的 IP 流量，因此常用於命令列工具、獨立網路堆疊應用程式，或需要統一處理 TCP 與 UDP 的情境。接管範圍擴大後，區域網路存取、開發環境、虛擬機器和其他網路工具之間的關係也會變得更複雜。

啟用 TUN 前，應先確認同一台伺服器在系統代理模式下運作正常，並確保路由規則能正確區分代理、直連與阻擋。否則，TUN 只會讓原有設定錯誤影響更多程式。首次測試時，請關閉其他會建立虛擬網卡或修改預設路由的軟體，記錄本機區域網路網段與預設閘道，並在 v2rayN 中啟用基本 TUN 設定。成功後再逐一恢復其他網路元件，觀察是否產生路由競爭。

理解虛擬介面、路由與嚴格模式

TUN 啟動後，用戶端會建立虛擬介面，並透過系統路由將目標流量導入該介面。自動路由負責寫入所需路由項目，嚴格路由則盡量減少流量繞過虛擬介面的機會。嚴格模式有助於維持路徑一致，但也可能影響區域網路探索、容器網路或特殊虛擬網卡。如果啟用後無法存取印表機、路由器管理頁面或開發裝置，應先為區域網路位址保留直連規則，再判斷是否需要降低嚴格程度。

MTU 表示虛擬介面能承載的封包大小。設定過大時，某些路徑可能發生分片或封包遺失；設定過小則會增加封包數量和額外負擔。沒有明確證據時，應使用用戶端預設值。典型的 MTU 問題表現為連線能建立，但特定頁面載入停滯、上傳失敗或部分協定異常。排查時可以逐步降低數值並重複相同測試，但每次只改變一個級距，同時確認問題不是由伺服器或 DNS 引起。

依現象定位 TUN 啟動問題

如果 TUN 無法建立介面，先查看記錄中是否提示權限、介面名稱衝突或驅動元件問題。Windows 上可能需要以具備相應權限的方式啟動；macOS 與 Linux 則要確認系統是否允許用戶端建立虛擬介面。記錄已明確提示權限不足時，不要反覆切換伺服器，因為伺服器不會影響介面建立。重新安裝用戶端前，也應先確認目前使用的是下載頁提供的對應平台版本。

如果 TUN 能啟動但所有連線都失敗，應檢查預設路由是否指向虛擬介面、核心是否收到流量、DNS 是否可用，以及代理出站是否意外再次進入 TUN 而形成迴圈。用戶端通常會為自身連線設定排除或保護機制；自訂啟動方式、外部核心或複雜路由可能破壞這種關係。記錄出現大量重複連線、目標指向本機虛擬位址時，應優先考慮回環，而不是繼續增加路由規則。

如果只有區域網路連線失敗，請檢查 geoip:private 或明確的私有網段是否設為直連，並確認區域網路共用設定沒有改變監聽範圍。常見私有網段包括 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。企業或實驗室網路可能使用其他位址範圍，需要依實際網路補充。網域形式的本地服務還依賴本地 DNS，不能只設定 IP 直連。

停用 TUN 後若網路沒有立即恢復，可以先在用戶端中正常停止核心，再檢查虛擬介面和系統預設路由是否已撤銷，最後重新連線目前的網路。直接結束程序可能來不及執行清理步驟，因此不應作為日常關閉方式。如果問題持續，可在說明中心依「用戶端已退出但網路異常」的思路，逐層檢查系統代理、虛擬介面與 DNS，而不是只重新啟動瀏覽器。

FakeDNS 的運作方式

一般 DNS 查詢會直接回傳目標伺服器的真實位址，應用程式接著連線到該位址。如果連線進入核心時只剩 IP，網域路由可能需要依賴嗅探才能恢復原始名稱。FakeDNS 則從專用位址池回傳虛擬位址，並在核心內部保存「網域—虛擬位址」的對映。當應用程式連線到這個虛擬位址時，核心會依對映找回網域，再執行網域路由與實際解析。這種方式的核心價值是保留網域上下文，而不是提升伺服器效能。

FakeDNS 通常與 TUN 模式搭配使用，因為 TUN 能接收應用程式發往虛擬位址的連線，並將其交回核心。只啟用 FakeDNS 但沒有正確攔截 DNS 請求時，應用程式仍可能從其他解析路徑取得真實位址；只攔截 DNS 卻沒有讓虛擬位址流量進入核心，則會表現為解析成功但連線失敗。因此，DNS 查詢入口、FakeDNS 位址池、TUN 路由和核心對映必須形成閉環。

位址池與對映容量

FakeDNS 位址池應選擇不會與本機區域網路、企業網路、容器網路和其他虛擬介面衝突的保留範圍。用戶端預設值通常已考慮常見情況，除非出現明確衝突，否則不建議自行更換。衝突的典型表現是啟用後某段真實內網位址無法存取，或系統將虛擬位址送往錯誤介面。排查時應查看系統路由表，比較 FakeDNS 位址池與現有網路的路由範圍。

對映容量決定同時保留多少網域記錄。容量過小可能讓較早的對映頻繁被替換，複雜網頁載入大量網域時更容易出現不一致；容量過大則沒有明顯必要。維持用戶端預設值通常已足夠。應用程式長期重用舊 DNS 結果時，即使核心對映已清除，仍可能繼續連線到失效的虛擬位址。遇到這種情況，應同時重新建立應用程式連線並重新啟動核心，而不是只反覆重新整理網頁。

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

範例展示 FakeDNS 的常見結構：指定網域分類使用虛擬解析，其他查詢交給一般 DNS。198.18.0.0/15 是經常用於此類對映的位址範圍，但是否適合仍要以本機網路為準。不同核心的設定格式可能將 fakedns 放在不同層級，v2rayN 也可能透過介面自動產生相關欄位。不要直接用片段覆蓋整份設定，應先與用戶端匯出的目前結構進行比對。

哪些情況不適合優先啟用

依賴本地 DNS 回傳內網位址的辦公系統、區域網路裝置名稱和分流解析環境，需要謹慎使用 FakeDNS。這些網域通常應交給本地 DNS 並直連，不應回傳虛擬位址。可以透過指定網域規則、網域後綴或本地 hosts 對映讓它們繞過 FakeDNS。如果企業內部網域沒有穩定後綴，建議先收集實際查詢紀錄，再建立明確清單，不要使用過於寬泛的排除條件。

某些應用程式會驗證 DNS 回傳位址、直接使用內建 DNS、快取時間很長，或在連線過程中再次比對目標位址。這類應用程式與 FakeDNS 的配合可能不穩定。遇到單一應用程式異常時，優先為其相關網域使用一般解析，而不是關閉整個 TUN 設定。如果無法透過網域範圍定位異常，再退回不使用 FakeDNS 的基準，確認問題是否確實由虛擬對映引起。

FakeDNS 與網域嗅探可以互補，但不應盲目全部啟用。FakeDNS 已能為受控 DNS 查詢保留對映，嗅探則處理未經對映、但可從協定中恢復網域的連線。啟用嗅探時要留意目標覆寫設定：如果核心以嗅探到的網域取代原始目標，路由結果可能改變。建議先讓 FakeDNS 處理主要 TUN 流量，再根據記錄中仍只顯示 IP 的連線，決定是否啟用嗅探。

用記錄驗證對映鏈路

驗證時選擇一個先前沒有快取的網域，觀察 DNS 請求是否由 FakeDNS 回傳虛擬位址，再觀察緊接著的連線紀錄是否顯示原始網域。接著確認路由命中的出站標籤，並檢查實際連線是否成功。如果只看到 DNS 紀錄，沒有後續連線，通常是虛擬位址未被 TUN 接管，或應用程式尚未立即發起連線；如果有連線但無法恢復網域，則檢查對映是否已被清除，以及請求是否來自同一個核心實例。

為每條訂閱定義用途與優先順序

多訂閱不代表要把所有伺服器混在同一個候選池中。更可控的做法是先為每條訂閱定義用途，例如日常主用、工作備用、特定裝置或測試來源，再分別建立分組。日常選擇只在目前用途的分組內進行，需要切換來源時再切換分組。如此可以避免同名伺服器混淆，也能減少自動選擇功能跨來源跳轉造成的結果變化。

訂閱名稱應包含穩定資訊，不應依賴伺服器數量或更新時間。可以採用「用途—來源簡稱」的格式，並在備註中寫明適用裝置、是否允許自動更新、是否包含特殊路由參數。如果訂閱網址帶有存取權杖，應只保存在用戶端訂閱設定中，不要複製到截圖、公開記錄或共用文件。需要傳送到另一台自己的裝置時，應使用受控方式，並在不再使用的裝置上移除舊設定。

錯開更新並保留失敗現場

同時更新所有訂閱雖然省事，但某個來源失敗時，記錄中容易混雜多組請求。首次設定或正在排錯時，建議逐條更新：先選取分組、執行更新、確認回傳內容能夠解析，再處理下一組。穩定後可以使用定時更新，但更新間隔不宜過短。訂閱內容通常不會每分鐘變動，過於頻繁只會增加請求和清單重建次數。

更新失敗時先保留目前分組，不要立即刪除後重新新增。查看失敗是屬於網路連線、網址失效、回應格式錯誤，還是內容為空。如果網址能存取但解析失敗，可能是訂閱格式與用戶端預期不一致；如果只有目前使用的代理下更新失敗，可以暫時切換更新訂閱所使用的出站路徑。訂閱更新與一般網頁存取可能使用不同設定，應在記錄中確認請求實際是由直連還是代理發出。

當更新回傳空內容時，用戶端的保留策略非常重要。穩妥的做法是避免空回應直接覆蓋現有伺服器，待確認來源恢復後再更新。如果用戶端已清空分組，可從設定備份還原，而不是憑記憶重建每台伺服器。更新成功後，也應抽查協定、位址、連接埠、傳輸方式和安全層欄位是否完整；只看到伺服器名稱出現，不代表每個欄位都能建立連線。

處理重複項目與名稱衝突

不同訂閱可能包含相同伺服器，別名也可能完全一致。只按名稱去重可能誤刪設定不同的項目，只按位址和連接埠去重又可能忽略協定或使用者識別差異。因此，除非明確知道上游內容的關係，不建議跨分組自動合併。清單中重複項目過多時，可以透過分組檢視隱藏，而不必破壞原始訂閱結構。

如果確實需要建立統一的候選集合，可以先保留原始分組，再建立一個手動精選分組，將少量常用項目複製進去。精選分組不會自動繼承訂閱更新，因此每次上游調整後都要重新檢查。它適合長期穩定的少量伺服器，不適合作為所有訂閱的鏡像。伺服器欄位發生變化時，舊的複製項目不會自動修正，這是手動分組最容易忽略的維護成本。

自動選擇與手動選擇的界線

自動選擇功能應限定在設定一致、用途相同的候選集內。如果把協定、用途和來源完全不同的伺服器放入同一個自動集合，某次選擇變化可能同時改變連線能力與路由表現。進階設定階段更建議先手動固定伺服器，完成 DNS、路由和 TUN 驗證後，再開啟自動選擇。如此發生故障時，可以排除「目前使用的伺服器剛好變更」這個變數。

不要把一次延遲測試當作長期排序依據。網路路徑會隨時間和連線狀態變化，能快速回應測試請求的伺服器也不一定適合所有業務。選擇時應同時關注連線是否穩定、協定欄位是否完整、目標應用程式是否正常，以及切換後是否需要重新建立舊連線。需要了解用戶端介面中的分組、伺服器清單與記錄位置，可閱讀v2rayN 主介面功能分區速覽。

出站物件由協定、設定與標籤組成

核心中的每個出站至少包含協定類型、協定設定，以及供路由引用的標籤。v2rayN 會根據選取的伺服器產生主要代理出站，同時通常也會產生直連與阻擋出站。自訂出站可以連線到本機既有的 SOCKS 服務、指定特殊直連行為，或作為鏈式連線的一環。無論用途為何，標籤都必須唯一且穩定，因為路由規則、DNS 伺服器和其他出站可能透過標籤引用它。

新增自訂出站前，先畫出流量路徑：哪個入站接收流量、哪條路由命中、自訂出站連線到哪裡，以及該出站本身是否還需要經過另一個代理。如果無法用一兩句話說明路徑，設定通常已經過於複雜。鏈式出站會增加故障點，任何一段的 DNS、驗證、監聽位址或網路不可用，都會表現為最終連線失敗。應逐段驗證，而不是只看鏈路末端。

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

這個範例將本機 127.0.0.1:1081 的 SOCKS 服務定義為 local-socks，並保留直連和阻擋出站。使用前必須確認該連接埠確實有服務監聽，且不會反向將連線送回 v2rayN 目前的入站，否則可能形成迴圈。範例沒有驗證欄位；如果本機服務要求驗證，應依核心支援的 SOCKS 伺服器結構新增，並避免在公開文件或截圖中展示真實憑證。

用路由將有限目標送入自訂出站

建立新出站後，不要立刻將其設為全域預設。先建立一條只比對測試網域的路由規則，並將 outboundTag 指向新的標籤。確認記錄顯示規則命中後，再檢查本機 SOCKS 服務是否收到連線。測試通過後逐步擴大範圍。如果規則沒有命中，問題在路由條件或順序；如果命中但本機服務沒有連線，請檢查出站位址、連接埠和迴圈；如果本機服務收到連線但最終失敗，再排查下一段鏈路。

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

出站標籤重新命名後，所有引用位置都必須同步更新。常見遺漏包括路由規則、DNS 伺服器的 outboundTag、代理鏈中的 proxySettings，以及用戶端介面儲存的自訂範本。核心啟動時顯示「找不到標籤」，應搜尋整份產生的設定，而不只是檢查 outbounds 陣列。如果用戶端每次啟動時都會重新產生設定，直接修改暫存 JSON 可能在下次套用設定時遺失，應優先使用用戶端提供的自訂設定入口。

設定檔的驗證方法

儲存前先檢查 JSON 語法：物件和陣列括號是否成對、最後一個成員後是否多出逗號、字串是否使用雙引號。語法正確只代表檔案可解析，還要確認欄位受目前核心支援。啟動後從記錄開頭檢查設定載入結果；如果核心直接退出，第一個錯誤通常會提供欄位路徑或標籤名稱。修正一個錯誤後重新載入，後續錯誤可能只是被前一個錯誤遮蔽。

設定成功啟動後，再依「入站—路由—出站—目標」的順序驗證。先確認測試連線進入預期入站，再確認路由命中目標標籤，接著檢查出站建立，最後驗證應用程式行為。對 DNS 相關出站，還要單獨確認解析請求是否使用該標籤。不要只以瀏覽器頁面是否開啟作為唯一判斷，因為快取、連線重用和應用程式回退可能掩蓋設定問題。

控制長期維護成本

一套可長期使用的進階設定，應能回答三個問題：每條自訂規則為何存在、它依賴哪個分組或出站，以及失效時如何回退。建議在規則名稱或本機說明中記錄用途，不要記錄敏感連線資訊。每隔一段時間檢查不再使用的訂閱、重複伺服器、失效篩選詞、過期的網域例外和無人引用的出站標籤。刪除前先停用並觀察，確認沒有隱含依賴後再徹底清理。

用戶端和核心更新後，不要立即重新調整所有舊設定。先使用原有設定驗證基本連線，再閱讀介面中新增或變更的選項，重點檢查 TUN、DNS、路由資料和設定產生方式。如果出現問題，使用本章開頭建立的基準逐層恢復。v2rayN 是桌面平台的首選用戶端；Android 可依核心需求選擇 v2rayNG 或 v2flyNG，三款用戶端的具體入口和平台說明集中在用戶端下載頁。

當某個問題只在一台裝置上出現時，應比較接管方式、系統 DNS、區域網路網段和應用程式代理行為，不要先假定訂閱內容不同。在多台裝置匯入同一訂閱，只能確保伺服器來源接近，並不能同步本機路由、TUN 權限、系統代理和 DNS 快取。列出這些裝置端變數逐項比較，通常比重複匯入訂閱更有效。

進階設定的目標不是讓設定檔不斷變長，而是讓流量路徑更符合實際需求。能由用戶端預設值解決的問題，優先使用預設值；只有當記錄和測試明確指出範圍不足時，再增加一條針對性規則。維持變更範圍小、標籤含義清楚、驗證步驟固定，即使訂閱、網路環境或使用情境發生變化，也能較快找到需要調整的那一層。