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

設定層級與回復基準

先釐清介面、核心與系統

連線是否成功，不只取決於伺服器參數。圖形化用戶端會儲存訂閱、目前使用的伺服器與介面選項，再產生核心可讀取的設定；核心負責入站監聽、路由比對、名稱解析與出站連線；作業系統則決定應用程式流量是否進入用戶端。排錯時，應先確認問題發生在哪個層級。例如，瀏覽器未遵循系統代理屬於流量入口問題；核心提示找不到出站標籤則是設定引用問題，兩者不應用同一個開關處理。

v2rayN 的「參數設定」、「路由設定」與主視窗中的系統代理選項，各自影響不同環節。「自動設定系統代理」通常只會變更提供給應用程式使用的系統代理入口，不等於啟用虛擬網卡；「啟用 Tun」則會新增另一條流量接管路徑。Android 端的 v2rayNG 透過系統 VPN 介面承接流量，「路由設定」負責進入核心後的分流。介面中的「繞過中國大陸」也可能使用不同規則範本，不能只看名稱相同，就認定產生的內容完全一致。

建立可重複驗證的基準

開始前先保留目前可用的設定：記下用戶端名稱、所選核心、目前伺服器、路由模式、系統代理狀態及 DNS 相關開關。使用用戶端提供的備份或匯出功能儲存設定時，請留意檔案可能包含訂閱網址、連線識別資訊與驗證資料，應存放在妥善控管的目錄。需要截圖求助時，先遮蔽這些資訊。不要將含有憑證的完整設定貼到公開討論區，也不要只截取最後一行錯誤訊息，卻省略問題發生前的操作情況。

驗證基準時，建議選擇三種具代表性的操作：使用明確設定為走代理的應用程式開啟一般網頁、連線至區域網路中的自有服務，以及測試日常使用的業務應用程式。記錄成功或失敗、錯誤類型與發生條件，而非只看單一延遲數值。瀏覽器能開啟網頁，不代表其他應用程式也已由用戶端接管；區域網路存取正常，也不代表 DNS 查詢走的是預期路徑。相同操作在修改前後都重新測試，才有比較意義。

一次只變更一個變數

建議依序調整訂閱整理方式、路由、DNS，最後才啟用 TUN 與 FakeDNS。每完成一項，重新連線並重做基準測試。如果用戶端要求重新啟動核心，請確認記錄中確實出現新的啟動流程，而非只關閉設定視窗。更換核心前先確認其支援的協定與安全參數，尤其是 REALITY 等設定；相關差異可參考Xray 與 V2Fly 核心差異，不要只憑名稱相近就推斷相容。

遇到故障時，依照變更順序反向還原：先關閉新加入的流量接管或解析功能，再還原路由範本，最後恢復原本的伺服器。還原後仍然失敗，才繼續檢查系統代理殘留、網路切換與其他 VPN。更新用戶端前，可前往安裝檔下載頁選擇對應平台；但排查同一問題時，請勿同時更換用戶端、核心與訂閱。否則會失去因果線索，也會讓原本可解釋的錯誤變成無法重現的偶發問題。

訂閱分組與伺服器篩選

分組先標示來源，再區分用途

訂閱分組的首要用途是區分不同來源。在 v2rayN 中，可從「訂閱分組」開啟分組管理，為每個訂閱網址建立獨立項目，並填寫容易辨識的備註。備註適合描述來源或用途，請勿填入密碼或完整連結。同一來源的訂閱若需要不同篩選條件，可拆分為不同分組，但應確認更新後不會產生難以辨識的重複項目。手動匯入的連線也建議放在獨立分組，避免與訂閱更新產生的伺服器混在一起。

v2rayNG 通常可在側邊欄的「訂閱分組設定」管理網址，再返回主畫面更新訂閱；v2flyNG 的操作入口與可用欄位，請以實際介面為準。儲存訂閱網址不代表伺服器清單已下載完成；更新成功也不代表已選取可用伺服器。操作後應確認目前分組、清單內容與作用中的項目。若更新後清單為空，先確認是遠端沒有回傳內容、格式無法解析，還是用戶端在篩選階段排除了所有項目。

篩選只處理清單，不等於存取控制

伺服器篩選通常依備註文字、協定類型或用戶端提供的條件保留項目。它會改變匯入或顯示結果，不會限制應用程式能存取哪些目標，也不會自動建立分流策略。名稱中包含某個地區，不代表連線的實際出口或能力符合預期；篩選適合減少清單干擾，不適合作為安全界線。初次設定時先不要啟用篩選，確認完整訂閱可正常解析後，再加入一項容易驗證的條件並觀察結果。

不同用戶端的篩選欄位可能使用一般關鍵字、正規表示式，或分開設定包含與排除條件。先閱讀欄位旁的說明，不要把正規表示式填入只接受一般文字的輸入框。若欄位明確支援正規表示式，直線符號代表「或」，括號用於分組，句點預設可比對任意字元；若要比對句點本身，必須逸出。大小寫是否有區別、包含與排除條件的執行順序，請依目前用戶端的實際結果確認，不要直接套用其他軟體的使用習慣。

(?i)(測試|備用)

上例僅適用於支援相應正規表示式語法的欄位，表示不區分大小寫地比對「測試」或「備用」。它本身沒有保留或刪除的固定效果，實際用途取決於輸入位置是包含條件還是排除條件。請先在測試分組中驗證，不要直接套用到唯一可用的正式分組。伺服器備註由訂閱服務提供方設定，之後可能更名，依賴備註的篩選條件也會隨之改變。重要項目消失時，先暫時清除條件並重新更新，不要立刻重新購買或更換來源。

區分訂閱更新路徑與業務連線路徑

更新訂閱本身也是一項網路請求。如果用戶端提供「透過代理更新」與一般更新兩種方式，請依訂閱網址的可連線情況選擇。目前使用的代理已失效時，仍透過該代理取得修正後的清單，容易陷入依賴循環；反之，若訂閱網址只能透過目前連線存取，直接更新也可能失敗。排錯時應分別驗證更新請求與業務連線，不要把「網頁開得了」當成訂閱介面一定可用的證明。

更新完成後，請確認作用中的伺服器仍屬於原本的訂閱。有些更新流程會重新建立項目，舊的選取記錄未必還對應新清單。確認協定欄位、傳輸方式與安全選項仍然存在後，再將項目設為作用中。如果用戶端顯示不支援某種連線格式，不要只改副檔名或保留部分欄位來強行匯入；應先確認所選用戶端與核心是否支援該格式，再向訂閱服務提供方確認輸出類型。

清單為空、匯入時提示格式錯誤或更新時發生網路異常，可參考訂閱解析失敗檢查清單逐項排查。先停用篩選、確認來源與更新路徑，再檢查編碼及回應內容。分組管理有助追蹤設定來源；連線品質與協定相容性仍須在選取伺服器後另外驗證。

路由規則實作

規則順序比規則數量重要

路由會將核心已收到的連線資訊對應至所選出站。在 v2rayN 中，從「路由設定」查看目前方案，先確認主視窗選取的方案正是要編輯的方案。Xray 與 V2Fly 常見的路由行為是依序比對，採用第一條符合的規則；同一條規則內的不同欄位通常都必須符合，而同一個網域或 IP 清單中的項目則通常符合其中之一即可。在一條規則中同時設定網域與連接埠，代表兩者都要符合，而非任一符合即可。

實用的規則順序通常是：確有需求的區域網路直連規則、業務專用規則、一般分類規則，最後由預設出站處理未符合規則的流量。範圍過廣的規則不要放在最前面，否則後面的精細條件就不會生效。「繞過中國大陸」等預設方案可作為起點，但其包含哪些網域集合、IP 集合與解析策略，仍須查看目前方案或產生的設定。介面名稱只是方案入口，不是完整的規則說明。

網域規則與 IP 規則的涵蓋範圍

full: 用於完全比對網域，domain: 用於比對網域及其子網域，geosite: 用來引用網域分類資源，geoip: 用來引用 IP 分類資源。以下片段示範明確網域與私有位址直連的寫法，前提是完整設定中已存在名為 direct 的出站。使用用戶端的規則編輯器時，請將條件填入對應欄位，不要把整個路由物件貼進單一網域輸入框。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com", "domain:example.org"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

此處的範例網域僅用來說明比對語法，實際使用時應替換為要管理的業務網域。IP 規則無法自然涵蓋網域規則：網域可能解析出多個位址，在不同網路環境下也可能得到不同結果。相反地，只設定網域規則，也未必能辨識直接連線至 IP 的應用程式。處理區域網路服務時，還要考量存取方式、DNS 回傳位址與虛擬網卡路由；有些服務名稱仰賴本機探索協定，並非新增一條網域規則就能解決。

路由解析策略不等於 DNS 出站策略

AsIs 盡量使用現有的目標資訊進行比對；IPIfNonMatch 在網域規則未符合時，嘗試解析後再比對 IP 條件；IPOnDemand 則可能在比對需要 IP 的規則時觸發解析。這些策略決定路由階段何時需要位址資訊，不會直接指定 DNS 請求要經由哪個出站。若同時調整解析策略與 DNS 伺服器，問題來源會混在一起；建議先固定解析服務，再比較策略變更造成的比對差異。

在支援的流量中，嗅探可協助取得網域資訊，但不是所有協定都能可靠識別。加密封裝、應用程式直接使用 IP、連線重用或中繼資料不足，都可能影響判斷。啟用嗅探後，也要了解目標位址是否會被改寫；若只想補充路由資訊，應確認目前核心是否提供僅供路由使用的選項。不要把嗅探視為網域規則一定會符合的保證，更不要依賴它補足所有 DNS 設定缺漏。

透過記錄確認實際比對結果

儲存規則後重新載入核心，建立新連線，並在記錄中確認使用的出站標籤。既有長連線可能繼續沿用舊路徑，瀏覽器快取與背景連線也會影響觀察；必要時先關閉測試應用程式再重新開啟。規則未生效時，先檢查作用中的方案，再查看排在前面的規則，接著確認核心取得的是網域還是 IP，最後檢查分類資源是否存在。資源檔案缺失通常會在啟動階段回報錯誤，不要靠反覆重新連線掩蓋問題。

也必須明確確認預設行為。對這類核心而言，未符合規則的連線通常會交由完整設定中的第一個出站處理；圖形化用戶端可能據此安排預設代理或直連。不要只看規則清單就推斷未符合規則時的流量方向。若要固定行為，請使用用戶端提供的預設規則設定，或在自訂設定中明確安排最後的比對規則，同時確認沒有必須排除的管理流量。術語說明請參閱術語表，常見連線問題請見疑難排解。

DNS 設定最佳化

分別釐清業務連線與 DNS 查詢路徑

DNS 設定首先要釐清三件事：由誰發起查詢、由誰回傳結果，以及查詢透過哪條網路路徑抵達解析服務。應用程式可能直接使用系統解析，也可能內建加密 DNS；核心也可能為路由比對、連線目標或解析伺服器位址而發起查詢。因此，在用戶端填入遠端 DNS 位址，不代表系統中所有查詢都會經過該位址。請先確認應用程式流量是否進入用戶端，再判斷解析請求是否由核心處理。

v2rayN 可在「參數設定」中查看 DNS 相關設定；v2rayNG 可在「設定」中檢查「啟用本機 DNS」、遠端 DNS 與網域策略等選項。介面所稱的「本機」，通常是指用戶端端的 DNS 處理模組，不一定代表請求只會送往區域網路。各用戶端產生設定的方式不同，啟用開關後應查看記錄或產生的設定，確認實際使用的伺服器與策略，不要只看開關顏色就認定設定已完整生效。

先區分三種容易混淆的策略

以下是核心 DNS 物件的局部範例，示範限制查詢為 IPv4 位址並指定解析伺服器。此範例不包含 DNS 流量的路由設計，也不代表該請求自然會經過代理。設定加密 DNS 時，還需確認目前核心支援的位址語法、憑證驗證方式與網域解析入口。若解析伺服器位址本身是網域，請確認首次解析依賴哪個可用解析器，避免出現「必須先解析才能連線，但解析又依賴該連線」的循環。

{
  "dns": {
    "queryStrategy": "UseIPv4",
    "servers": [
      "1.1.1.1"
    ]
  }
}

依業務需求選擇解析方式

區域網路內的網域通常仰賴路由器、企業 DNS 或搜尋網域，應保留相應的本機解析路徑。若強制將所有查詢交給公共解析器，內部服務可能就無法解析。外部業務則應讓解析結果與所選出站保持合理一致：若目標使用地理位置導向的分流，而解析時所在的網路與實際出口不同，就可能取得不合適的位址。最佳化重點不是增加更多伺服器，而是為每類網域安排清楚且可說明的解析與連線路徑。

設定多個 DNS 伺服器時，不要假設它們一定會依清單順序逐一嘗試。核心可能依網域條件平行查詢或合併結果，回退欄位的支援方式也會因實作而異。先用單一穩定的解析路徑確認可用，再加入依網域選擇的伺服器，並檢查預設回退是否涵蓋其餘目標。若內部網域不應送往外部解析器，應明確排除公共回退，而非只在清單前面加入一個內網位址。

快取、雙堆疊與記錄的排查順序

變更 DNS 後，應用程式快取、系統快取與核心快取可能仍保留舊結果。關閉並重新啟動測試應用程式，再依系統提供的方式清除解析快取；必要時重新啟動用戶端核心。不要每次失敗就立刻更換解析器，否則快取會讓前後結果難以比較。若記錄出現逾時，先確認查詢路徑是否可連線；若已取得位址但連線仍失敗，接著檢查目標位址類型、路由與遠端連線，不要只反覆調整 DNS 開關。

處理 IPv6 問題時，應區分「查得到位址」與「連線成功」。網路可能回傳 IPv6 位址，卻沒有可靠的 IPv6 出口或正確的虛擬網卡路由。暫時限制位址類型有助於定位問題，但不應當成所有環境都適用的固定最佳化。反過來說，在依賴 IPv6 的網路中只查詢 IPv4，也可能導致無法連線。完成診斷後，應恢復符合目前網路能力的策略，並以新連線驗證，不要只憑單次網頁載入速度判斷整套解析設定。

TUN 模式

接管範圍改變，不代表規則失效

TUN 透過虛擬網卡與系統路由，將符合條件的 IP 流量送入用戶端，適合不遵循系統代理設定的應用程式。它改變的是流量進入用戶端的方式，不會自動決定所有目標都走遠端代理。流量進入用戶端後，仍須依路由規則選擇直連、代理或阻擋。因此，「啟用 Tun」與「全域代理」不是同一回事；即使接管範圍擴大，區域網路直連、內部 DNS 與業務例外仍應依實際需求保留。

在桌面端使用 v2rayN 時，先關閉其他可能接管系統路由的 VPN 或虛擬網卡工具，再依平台提示授予建立介面與修改路由所需的權限。權限不足時，介面可能顯示已切換，但網卡或路由實際上並未建立。不要為了解決啟動問題而長期關閉防火牆；應先查看用戶端與系統記錄，確認失敗的是權限要求、介面建立還是規則安裝，再以最小範圍調整系統設定。

從系統代理逐步切換至 TUN

啟用前先透過一般代理入口確認目前伺服器可用，並記下原本的路由模式。接著在 v2rayN 主視窗切換「啟用 Tun」，觀察核心啟動情況與虛擬網卡狀態。首次測試時，可讓系統代理維持明確且可還原的狀態，避免應用程式手動代理、系統代理與 TUN 同時疊加，造成判斷困難。若需要同時使用，應先了解各入口使用的監聽位址與流量方向，不要以為入口越多就越完整。

測試時從三個方向確認：明確不使用系統代理的應用程式能否連線至預期目標、區域網路裝置是否仍可連線，以及 DNS 是否依設計完成解析。瀏覽器遵循系統代理時，即使 TUN 接管失敗，畫面看起來也可能正常，因此不能只靠瀏覽器驗證。存取內部業務時，應同時測試網域與已知的內部位址；若前者失敗而後者成功，通常應回頭檢查 DNS 與搜尋網域，而不是繼續修改遠端伺服器。

路由循環與虛擬網卡衝突

TUN 必須避免將用戶端連往遠端伺服器的連線再次送回自身，否則就會形成循環。用戶端通常會透過繫結介面、排除路由或處理程序來避免這種情況，但自訂規則、同時執行多個 VPN 或網路介面變動，都可能破壞原本條件。啟用後若所有連線都逾時，或記錄反覆出現連往同一目標的連線，請先停用新啟用的接管功能，再確認目前預設網卡與伺服器出口路徑。不要直接新增範圍更廣的代理規則。

從有線網路切換到無線網路、裝置從休眠恢復或連上企業 VPN，都可能改變介面順序與路由優先順序。若 TUN 只在切換網路後失效，可先重新連線用戶端，讓它依新網路重建狀態；若每次都失敗，應檢查是否繫結到已失效的介面。Linux 與 macOS 的系統授權方式、網卡名稱及路由管理各不相同，不能直接照搬 Windows 的處理步驟。具體操作請依目前用戶端的權限提示與系統網路管理方式進行。

UDP、MTU 與網路復原

TUN 能接收某類流量，不代表遠端協定、傳輸方式與伺服器都支援相同的轉送能力。遇到 UDP 業務失敗時，先確認目前完整連線路徑是否支援 UDP，再檢查規則是否將該業務送往正確的出站。只有在大型回應、檔案傳輸或特定應用程式卡住，但一般短請求正常時，才考慮 MTU、路徑探索或分片問題。不要毫無根據地不斷降低 MTU；請保留原值，每次調整後以相同業務驗證。

退出用戶端前，建議先在介面中關閉 TUN，再正常結束程式，讓程式撤銷路由與介面狀態。若程式異常終止後網路仍未恢復，先檢查系統代理是否仍指向已停止的本機連接埠，再確認其他 VPN 與殘留網卡狀態。必要時可透過系統網路設定恢復連線，但不了解用途時，請勿刪除正在使用的企業網路設定。恢復一般網路後，重新執行本章的基本測試，不要立刻重新疊加所有功能。

FakeDNS

合成位址會儲存網域對應關係

FakeDNS 並非會回傳目標真實位址的一般解析器。它會從專用位址池分配合成位址，並將網域與位址的對應關係儲存在核心中；應用程式連線至該位址時，核心再依對應關係還原目標網域，繼續進行路由與出站處理。這種方式可在部分流量接管情境中保留網域資訊，減少必須先解析出真實位址才能決定分流的需求。但它仰賴完整的 DNS、流量接管與網域還原路徑，單獨開啟開關並不是完整方案。

在 v2rayNG 中，可於「設定」查看「Fake DNS」相關選項，並一併確認「啟用本機 DNS」與目前路由設定。不同核心與用戶端自動產生所需設定的程度不一，請以實際產生的設定與啟動記錄為準。v2flyNG 不應只因介面相似，就沿用相同參數。建議先完成一般 DNS 與路由基準，再測試 FakeDNS；若目前連一般網路都無法正常使用，額外加入合成位址只會增加排錯難度。

位址池、查詢入口與還原能力

以下是常見核心語法的局部範例，包含合成位址池、DNS 服務入口與入站嗅探相關欄位。這些內容必須合併到相應位置，不是把整個物件任意貼進用戶端某個開關旁的輸入框。範例中的嗅探物件屬於入站設定；完整設定還需要能處理該流量的入站、路由與出站。位址池不得與實際使用的業務網段衝突，也不應設定為任意的公共位址範圍。

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

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

上例的位址範圍用於測試網路，放在此處是為了示範合成位址池，不是實際伺服器位址。位址池大小會影響可儲存對應關係的容量，但擴大容量並非通用的效能最佳化方式。更重要的是，應用程式取得的合成位址必須回到保存對應資訊的同一個核心。若一個用戶端負責回應查詢，連線卻被另一個 VPN 接管，或應用程式在核心重新啟動後仍使用快取位址，還原對應關係就可能失敗。

依應用程式行為判斷是否適用

適合測試的情況包括：應用程式主要透過網域存取服務、查詢與後續連線都由同一個用戶端接管，而且希望路由階段能更穩定地取得網域資訊。不適用的情況可能包括：應用程式依賴真實位址進行業務判斷、服務需要將解析結果提供給其他裝置，或內網業務與測試位址範圍衝突。有些應用程式會檢查解析位址屬性、快取結果或繞過系統 DNS，這些行為都可能使 FakeDNS 的效果與一般瀏覽器測試不同。

如果應用程式使用自己的加密 DNS，查詢可能不會進入 FakeDNS 處理模組。此時即使已啟用開關，目標仍取得真實位址，也不一定代表核心故障。反過來說，應用程式取得合成位址後若繞過用戶端直接連線，連線就會失敗。排錯時應分別確認查詢是否使用合成解析、連線是否由用戶端接管，以及核心是否成功還原網域；不要只看到「特殊位址」就認定整條路徑正常。

啟用與停用都要處理快取

啟用後，先重新啟動測試應用程式，讓它重新發出解析請求，再測試一般網頁、區域網路服務與一項日常業務。如果區域網路網域被錯誤地轉為合成位址，請依目前用戶端支援的功能，為內部網域保留真實解析，並確認相應連線會直連。請注意，DNS 規則中的排除、路由規則中的直連與系統路由中的繞過，分別作用於不同階段；只完成其中一項未必足夠。

停用 FakeDNS 後，應用程式或系統可能仍快取合成位址，但核心已不再保存對應關係，因此可能暫時出現「停用後反而無法連線」的情況。先停止測試應用程式、清除相關快取並重新建立連線，再判斷是否已成功還原。重新啟動用戶端也可能改變對應狀態，因此應將長時間執行的應用程式納入測試。詳細原理與適用範圍可參閱FakeDNS 運作原理與適用情境。

多訂閱管理

建立來源、用途與更新方式的對應關係

管理多個訂閱時，先為每個來源建立獨立分組，再決定哪些項目用於日常連線，哪些只用於相容性測試。不要先把所有連線合併成大型清單，再靠備註猜測來源。分組名稱可用「日常」、「測試」、「手動設定」等用途命名，同時透過本機紀錄保留來源對應關係。訂閱網址可能因帳號重設而變更；名稱沒有變，不代表它仍指向原本的設定集合。

在 v2rayN 的「訂閱分組」中檢查各組的網址、篩選條件與更新方式，並依用戶端提供的選項設定更新週期。Android 端可在「訂閱分組設定」管理來源，再分別執行更新。先逐組驗證，確認每個來源都能獨立解析，最後再使用「更新所有訂閱」等批次操作。如此一來，部分更新失敗時就能直接定位來源，而不會把所有網路異常都歸咎於用戶端故障。

更新頻率與作用中的項目應分開管理

頻繁更新不代表連線更穩定。更新請求需要網路與伺服器處理，也可能觸發來源的存取限制。依服務提供方的使用說明與實際變更頻率安排即可，不必用極短間隔反覆更新。行動裝置還需考量背景執行限制：系統省電策略可能延後工作，介面設定的間隔不代表每次都會準時執行。需要使用前，可手動更新指定分組並確認結果，不要只依賴背景狀態。

更新後應重新確認目前作用中的伺服器。訂閱可能刪除舊項目、修改備註或調整安全參數，用戶端也可能重新產生內部識別碼。舊的收藏、排序與路由繫結是否仍有效，應以目前介面為準。不要只看作用中的名稱相同，就認定參數沒有改變；若使用自訂出站或依標籤引用的設定，還應進一步確認引用仍指向預期項目。建議為日常使用的項目保留清楚的本機用途說明，方便更新後核對。

重複項目與跨裝置移轉

重複項目可能是多個訂閱包含相同連線，也可能是手動匯入與訂閱更新同時存在。判斷是否重複不能只比較備註，還應一併比對位址、連接埠、協定、安全參數與傳輸設定。只因顯示名稱相同就刪除其中一項，可能會誤刪用途不同的設定。若用戶端提供去重功能，請先了解比對標準，並在備份後對測試分組執行。來源不同的項目即使連線參數相同，也可能有不同的更新與撤銷範圍。

跨裝置移轉時，應將「訂閱來源」與「本機環境」分開處理。訂閱網址可在獲得授權的裝置間依需要重新輸入，但本機監聽連接埠、TUN 權限、系統代理、依應用程式設定的代理與內網 DNS，通常不能直接照搬。v2rayN 的完整設定檔也不應直接當成 v2rayNG 或 v2flyNG 的設定備份。請先在目標裝置完成基本匯入，再逐項重建路由與 DNS 設定意圖，避免複製只有原裝置才有的路徑與介面名稱。

失效訂閱與撤銷憑證

某個來源更新失敗時，先保留其他可用分組，不要為了重試而清空所有伺服器。確認問題僅與該訂閱有關後，再檢查網址是否過期、是否需要登入重新取得，以及更新是否錯誤地經過已失效的連線。若網址外洩，應透過來源提供的重設機制撤銷舊連結，再更新本機分組；只修改分組備註不會讓舊網址失效。也請檢查其他裝置，避免背景程序繼續使用舊網址。

長期不使用的來源應主動移除，並檢查相關收藏、快速操作與自訂出站引用。匯出的備份也可能保留已撤銷的網址，還原備份後需再次檢查。多訂閱管理的目標，是讓每項設定都能追溯來源、說明用途並單獨還原，而不是讓清單不斷變長。若清單維護已影響日常操作，應先減少重複來源與失去用途的項目，再考慮增加更複雜的自動選擇規則。

自訂出站

標籤代表引用關係，不是連線名稱

出站定義核心如何建立目標連線，路由則透過標籤選取出站。outboundTag 必須引用完整設定中已存在的 tag，大小寫與拼寫都必須一致。用戶端清單中的伺服器備註不一定就是核心標籤，訂閱分組名稱也不會自動成為可引用的出站。撰寫規則前，先確認產生設定中的標籤結構；尤其不要直接把介面上容易辨識的名稱填入路由，就以為核心會自動找到對應伺服器。

以下是直連與阻擋出站的局部範例，適用於支援這些協定物件的 Xray 或 V2Fly 設定環境。範例只定義兩個出站，不包含代理伺服器、入站或完整路由。若直接用它取代現有的出站清單，原本的代理連線就會消失。圖形化用戶端可能已產生相同標籤，合併前應確認沒有重複；同名定義會讓引用關係不明確，不能靠調整顯示順序補救。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

明確設定阻擋規則與預設出站

阻擋適用於已確認不需要存取的目標，不應用來處理所有未知連線。請先使用確定不會影響日常業務的測試網域，確認規則確實符合，再考慮擴大範圍。業務應用程式可能仰賴多個網域完成驗證、載入內容與更新，只阻擋其中一個也可能造成部分頁面異常。遇到問題時，應從記錄確認具體目標，不要反覆以更大範圍的網域分類試錯。

{
  "type": "field",
  "domain": ["full:example.invalid"],
  "outboundTag": "block"
}

上例是放入 routing.rules 陣列的規則物件，使用專門保留的無效網域示範語法。只有在前述 block 出站存在時，這項規則才有作用。設定正式業務規則前，應先確認目標，再依需求使用完整網域或子網域比對。同時也要檢查未符合規則的流量預設會前往何處；若自訂設定把 direct 放在首位且沒有兜底規則，預設行為可能與原本的用戶端方案不同，不能只驗證明確規則就結束。

鏈式連線與選擇器是不同概念

多個出站並列存在，代表路由可選擇不同路徑，不會自動組成鏈式連線。鏈式連線還需要核心支援的出站轉接機制、正確的引用方向與可連線性設計；不同核心的欄位與限制並不完全相同。需要這項功能時，應先確認用戶端是否提供受支援的前置代理或鏈式入口，再依目前核心的文件設定。不要以為將多台伺服器依序放入陣列，連線就會依陣列順序逐一經過。

負載選擇、故障轉移與手動切換也應分開理解。選擇器只會在特定條件下挑選候選出站，不代表既有連線會自動轉移；探測目標可連線，也不表示所有業務都能正常使用。新增自動化機制前，先確認每個出站都能獨立運作，並驗證協定、安全參數與 DNS 路徑正確，再設計選擇條件。若訂閱更新重新產生出站標籤，也要同步更新選擇器引用，否則設定可能無法啟動，或候選清單變成空的。

使用受支援的設定入口，保留回復備份

在 v2rayN 中使用自訂設定功能時，應先確認目前設定是由介面產生，還是由外部檔案提供。兩種模式的管理範圍不同：介面模式可能在重新啟動時覆蓋手動修改的內容；自訂檔案模式則可能無法繼續使用部分自動產生的設定。Android 端也應透過用戶端提供的設定入口匯入，不要在不清楚檔案生命週期時修改內部目錄。儲存後先查看啟動記錄，確認沒有欄位不受支援、標籤缺失或資源路徑錯誤。

驗證完整設定時，依序檢查入站監聽、DNS 查詢、規則比對與出站連線。核心無法啟動時，先處理語法與引用問題；核心可啟動但無法存取時，再檢查流量入口與網路路徑。可暫時提高記錄詳細程度以觀察問題，定位後再恢復日常等級，並妥善處理可能包含目標位址的記錄。不要將記錄寫入無法控管的共用目錄，也不要為了取得更多輸出而長期保留含敏感連線資訊的記錄。

若新增出站未能解決明確需求，應回到用戶端內建的路由方案，減少需要自行維護的設定。協定與核心相容性問題可繼續參考核心差異文章；基本連線的恢復方式請依入門指南重新驗證。進階設定的完成標準，是每條流量路徑都能清楚說明、每項變更都能單獨還原，而非啟用越多開關越好。