v2rayN 進階設定指南：訂閱、路由、DNS 與 TUN

設定模型與可回復的變更方法

先區分四個設定層級

v2rayN 的介面設定最終會組合成核心執行設定。排查問題前，應先區分伺服器、訂閱、客戶端行為與核心設定四個層級。伺服器記錄包含位址、連接埠、使用者識別、傳輸方式與安全參數；訂閱負責批次提供與更新伺服器記錄；客戶端行為包括系統代理、系統匣操作、自動更新與介面篩選；核心設定則處理入站監聽、DNS、路由與出站。一個節點可以通過延遲測試，並不代表系統代理、DNS 或路由一定正確，因為這些環節位於節點連線之外。

圖形介面中的「目前伺服器」通常只是預設代理出站的來源。路由規則可能將部分請求交給直連或阻斷出站，TUN 也可能接管原本不讀取系統代理的程式。因此，判斷某項設定是否生效時，不能只觀察節點是否變色或系統匣圖示是否變化。應同時確認客戶端執行狀態、代理模式、目標程式的連線方式與規則命中結果。

建立最小可用基準

進行進階調整前，先建立一套可重複驗證的基準：保留一台已知能連線的伺服器，將路由恢復為簡單規則，暫時關閉 TUN 與 FakeDNS，只啟用系統代理，然後用瀏覽器開啟一般 HTTPS 頁面。確認此狀態可正常運作後，再依照「訂閱篩選、路由、DNS、TUN、FakeDNS」的順序逐層增加設定。一次只變更一個層級，變更後立即重新測試，能大幅縮小定位範圍。

建議為每次測試記錄四項資訊：修改內容、修改前的值、預期結果與實際結果。不需要複雜工具，使用一段本機文字即可。遇到無法連線時，先撤銷最後一次變更，不要同時切換節點、修改 DNS、重裝客戶端及清理系統網路。一次執行多項操作會破壞可重現性，也無法確認真正原因。

理解產生式設定與手寫設定的界線

v2rayN 適合透過介面維護常見參數，介面產生的設定也較容易在切換伺服器時自動更新。手寫 JSON 適用於需要額外出站、特殊 DNS 策略或細緻路由的情境，但必須考慮客戶端重新產生設定時是否會覆蓋修改。若某項功能可透過路由設定、DNS 設定或自訂設定入口完成，應優先使用對應入口，不要直接修改暫存執行檔案。

設定片段必須保持完整的 JSON 語法：屬性名稱與字串使用半形雙引號，陣列項目之間需要逗號，最後一項不能多寫逗號。網域、路徑與正規表示式也可能涉及反斜線跳脫。儲存後若核心立即結束，優先查看日誌中最早出現的解析錯誤；後續連線失敗通常只是前一項解析錯誤引發的連鎖結果。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

依現象決定檢查入口

瀏覽器可用但其他程式不可用，先檢查程式是否讀取系統代理，再考慮 TUN；網域無法開啟但直接連線目標位址有回應，先檢查 DNS；只有部分網站異常，檢查路由順序與網域規則；訂閱更新後節點消失，檢查篩選運算式與分組；啟用 FakeDNS 後區域網路名稱異常，檢查排除範圍與 DNS 接管界線。依現象選擇入口，比從頭重設所有設定更可靠。

完成一組穩定設定後，應保留設定匯出檔或介面截圖，並記錄使用的模式。設定備份只保存本機設定，不等同於訂閱服務本身；訂閱位址失效時，備份無法產生新的伺服器記錄。訂閱位址、伺服器憑證與自訂設定檔應按敏感資訊處理，不要放入公開文件，也不要將執行日誌原樣傳送到公開區域。

訂閱分組與伺服器篩選

分組解決的是管理問題

訂閱分組用於區分伺服器來源、用途與更新節奏，而不是改變協定本身。匯入多筆訂閱後，若所有伺服器混在同一個清單中，節點名稱重複、地區標記不一致與倍率說明會使篩選結果難以判斷。較穩妥的做法是依來源建立分組，為每筆訂閱設定明確備註，再透過篩選條件建立暫時檢視。分組名稱應描述來源或用途，不要依賴容易變動的節點數量。

訂閱位址應透過客戶端的訂閱分組設定保存。新增後先手動執行一次更新，確認伺服器記錄能夠解析，再設定自動更新間隔。若首次更新失敗，應先檢查位址是否完整、複製時是否帶入空格，以及網路是否能存取訂閱端點。不要在首次失敗後連續建立多個相同分組，否則後續更新會產生重複伺服器，增加清理成本。

備註、分組名稱與伺服器名稱各有用途

分組備註由使用者維護，適合標記來源；分組名稱用於清單歸類；伺服器名稱通常由訂閱提供者產生，更新時可能改變。需要長期穩定篩選時，不應只依賴完整伺服器名稱，而應選擇相對穩定的關鍵字組合，例如地區縮寫、協定名稱或用途標籤。若訂閱方改變命名規則，篩選結果也會改變，因此每次大規模更新後都應確認篩選檢視仍包含預期伺服器。

伺服器篩選通常分為包含與排除兩類。包含條件可縮小顯示範圍，例如只顯示名稱中帶有某個地區標記的記錄；排除條件則用於移除維護、剩餘流量、到期提示等非伺服器項目。篩選只影響檢視時，不會刪除原始記錄；刪除操作則會直接移除本機伺服器。執行批次刪除前，務必確認目前操作對象是篩選結果還是整個分組。

從簡單條件開始設定篩選運算式

如果客戶端入口支援正規表示式，應先使用一般關鍵字確認範圍，再逐步增加組合條件。正規表示式中的圓括號、方括號、句點與加號都有特殊意義，直接複製伺服器名稱可能改變比對結果。需要比對多個一般關鍵字時，可以使用直線符號表示「任一個」，例如 HK|SG|JP。需要排除「剩餘流量」「方案到期」等提示項目時，先個別測試每個關鍵字，再合併條件。

包含範例：
HK|SG|JP

排除範例：
剩餘流量|方案到期|官方網站|維護

協定篩選範例：
VMess|VLESS|Trojan

篩選條件不應負責自動選路。它適合縮小可見清單，但不會持續判斷節點品質，也不能取代真實連線延遲測試。篩選後應在目標集合內執行真實連線延遲測試，排除握手失敗的記錄，再結合實際下載或網頁瀏覽選擇伺服器。ICMP Ping、真實連線延遲與下載測速的差異，可參考延遲測試說明。

更新、覆寫與移除策略

訂閱更新通常會依分組重新整理記錄。若更新後出現大量重複項目，先確認是否匯入了相同位址的多個分組，再檢查客戶端的更新行為是覆寫舊記錄還是保留手動修改。直接修改訂閱產生的伺服器名稱或參數，可能在下次更新時被覆寫。需要長期保留的手動伺服器應放在獨立分組，不要與自動更新訂閱混在一起。

移除訂閱時，需要區分「刪除訂閱設定」與「刪除該訂閱已產生的伺服器」。只刪除訂閱位址可能留下舊伺服器，這些記錄不會繼續取得參數更新；只刪除伺服器而保留訂閱，下次更新又會重新產生。停用某個來源時，先停止自動更新，再刪除對應伺服器，最後移除訂閱分組。完成後檢查目前活動伺服器，避免它仍指向已刪除的記錄。

在 v2rayNG 或 v2flyNG 中，訂閱管理入口與桌面版配置不同，但處理順序相同：為來源設定備註，單獨更新，確認解析結果，再選擇活動設定。行動網路切換頻繁時，不宜設定過短的自動更新週期；更新失敗時保留現有伺服器，先判斷是網路暫時無法連線，還是訂閱位址本身已變更。

路由規則實戰：比對條件、順序與出站

規則依順序決定出站

路由的核心任務是將連線交給指定出站。常見出站包括代理、直連與阻斷，自訂設定還可以增加其他代理鏈路。規則由比對條件與目標出站組成：當網域、位址、連接埠、網路類型或入站標籤符合條件時，便將連線交給對應的 outboundTag。多數實作會依規則由上至下比對，較具體的規則應放在較通用的規則之前，否則前面的寬泛條件會提前接管請求。

一套容易維護的基本順序是：先處理明確需要阻斷的目標，再處理區域網路與私人位址直連，接著放置業務上明確的網域或位址規則，最後設定備援行為。備援可以由預設出站承擔，不一定要寫成涵蓋所有目標的規則。若在規則頂端使用過於寬泛的網域比對，後續分流項目將沒有機會生效。

網域比對與位址比對不是同一個步驟

網域規則在連線仍保留網域資訊時最清楚，例如 domain:example.com 可比對該網域及其子網域範圍，full:example.com 用於精確主機名稱，regexp: 則適合確實需要模式比對的情境。正規表示式的解析與維護成本較高，能以一般網域表達時，不應優先使用正規表示式。網站依賴多個靜態資源網域時，應逐一確認，不要根據首頁網域推斷所有請求都會命中同一規則。

位址規則會在目標已解析為 IP 時使用，可比對單一位址、CIDR 網段或內建分類。geoip:private 常用於私人位址直連，避免區域網路印表機、儲存裝置與路由器管理頁面被送入代理。網域解析結果可能隨時間與地區變化，把動態網站目前的位址寫成永久規則通常不穩定；能以網域表達的業務條件，應優先使用網域規則。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["full:telemetry.example.com"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:docs.example.com",
          "full:api.example.net"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 如何改變比對流程

AsIs 表示優先依請求中的原始網域處理，不主動為路由比對解析位址；IPIfNonMatch 表示網域規則未命中時，再解析位址並嘗試比對位址規則；IPOnDemand 會在規則判斷需要位址時更早觸發解析。選擇策略時要結合 DNS 設定。若路由依賴位址分類，而策略始終不解析位址，對應規則可能不會命中；若過早解析，也可能增加 DNS 查詢或改變網域分流鏈路。

一般情境可以從 AsIs 開始，只有明確需要依解析位址繼續判斷時，才使用 IPIfNonMatch。修改後應重點觀察同一網域是否產生不同 DNS 請求，以及是否命中預期出站。不要把策略名稱理解成「速度檔位」；它改變的是比對階段與解析時機，不保證某個值在所有網路環境中都更快。

驗證規則時應觀察完整請求

驗證路由不能只測試首頁是否能開啟。一個頁面可能同時請求主網站、圖片、介面與身分驗證網域，不同請求可能經由不同出站。先用一個具體目標建立單一規則，重新啟動核心後查看日誌中的目標、命中結果與出站標籤。確認單一規則有效後，再擴大網域範圍。若日誌中只有位址而沒有網域，應回到 DNS 與嗅探設定，檢查是否仍能取得網域資訊。

規則未生效時依序檢查四項：規則是否位於正確順序、比對語法是否符合核心格式、目標出站標籤是否存在，以及實際連線是否由目前核心接管。瀏覽器內建的安全 DNS、應用程式內建代理或已建立的長連線，都可能繞過剛修改的鏈路。測試前關閉並重新開啟目標程式，必要時清除其連線快取，不要只重新整理頁面。

路由規則應保持可讀。數十條零散網域比少量按業務分類的規則更難審查，也更容易發生前後覆寫。完成設定後，從頂端逐條回答「比對什麼、交給哪個出站、為什麼必須放在這裡」。無法明確回答的項目通常需要拆分、重新命名或移除。

DNS 設定最佳化與解析鏈路排查

先釐清是誰發起查詢

DNS 異常經常被誤判為節點失效。實際鏈路可能包含系統解析器、瀏覽器安全 DNS、v2rayN 核心 DNS、TUN DNS 接管以及遠端解析。不同程式若使用不同解析入口，同一網域可能取得不同結果。最佳化前先確認目標程式是否使用系統解析、查詢是否進入核心、核心向哪台伺服器發送請求，以及解析結果如何參與路由。

只啟用系統代理時，瀏覽器可能自行解析網域，也可能將網域交給代理入口，具體取決於代理類型與程式實作。啟用 TUN 後，系統 DNS 請求通常更容易被統一接管，但仍需正確設定 DNS 位址、路由與排除項目。瀏覽器單獨啟用安全 DNS 時，其查詢可能以一般 HTTPS 流量傳送，表面上看不到傳統的 53 連接埠請求。

核心 DNS 的伺服器與查詢規則

核心 DNS 設定可以定義多個伺服器，並依網域範圍選擇。一般 UDP DNS 設定簡單，但請求路徑取決於網路與路由；基於 HTTPS 的 DNS 透過 HTTPS 連線查詢，需要先解決伺服器網域的初始解析問題；使用固定位址可以減少啟動依賴，但位址變更時需要維護。選擇方式時應考慮可達性與依賴鏈，不應只依名稱判斷優劣。

DNS 伺服器也可以帶有網域篩選條件。這樣做通常是讓特定網域使用指定解析器，而不是把所有查詢隨機分配給多個伺服器。若多個伺服器的網域範圍互相重疊，應明確設定優先關係。預設伺服器負責處理沒有特殊要求的網域，專用伺服器只涵蓋必要範圍，設定會更容易驗證。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "https://dns.example/dns-query",
        "domains": ["domain:service.example"]
      },
      "1.1.1.1",
      "localhost"
    ],
    "queryStrategy": "UseIP"
  }
}

範例中的網域僅用於展示結構，實際設定必須換成可存取的解析服務。hosts 用於少量固定對映，適合本機裝置或測試環境，不適合維護大量公網網域。錯誤的固定對映會繞過正常更新，因此設定後要記錄用途。localhost 會回到系統解析器；若系統解析器又把請求交回核心，可能形成迴圈，使用前必須確認鏈路方向。

查詢策略與位址族

queryStrategy 控制回傳的位址類型。UseIP 允許依環境取得可用位址，UseIPv4 只請求 IPv4，UseIPv6 只請求 IPv6。只有在網路確實具備對應連線能力時，回傳的位址才有意義。系統取得 IPv6 位址並不代表出站鏈路能穩定存取所有 IPv6 目標；若表現為部分網站等待後回退，可以暫時限制為 IPv4，以確認是否與位址族有關。

位址族問題應透過對照測試確認，而不是永久關閉某一類位址作為通用做法。分別記錄解析結果、連線目標與失敗階段。如果 DNS 能回傳位址但 TCP 或 UDP 建立連線失敗，問題位於解析之後；如果只有某個解析器逾時，則檢查該解析器的存取路徑。日誌中的「解析失敗」與「連線遭拒」代表不同階段，應分開處理。

清理快取僅用於驗證

修改 DNS 後，系統、瀏覽器與核心都可能保留舊結果。Windows 可在終端機執行 ipconfig /flushdns 清理系統快取，但該命令不會清除瀏覽器自身快取，也不會終止既有連線。較可靠的測試流程是儲存設定、重新啟動核心、關閉目標程式、清理必要快取，再重新發起請求。頻繁清理快取無法修復錯誤設定，只適合確認舊結果是否仍影響測試。

ipconfig /flushdns

nslookup example.com

nslookup example.com 1.1.1.1

nslookup 適合比較系統預設解析器與指定解析器的回傳結果，但不一定會經過應用程式實際使用的核心 DNS 鏈路。因此命令結果正常而瀏覽器仍失敗時，應繼續檢查瀏覽器與代理入口。若啟用了 TUN 或 FakeDNS，一般查詢工具看到的結果也可能是接管後的對映位址，需要結合對應章節理解，不能單憑傳統 DNS 結果判斷。

v2rayN TUN 模式：接管範圍與系統差異

TUN 解決哪些程式不讀取代理的問題

系統代理依賴應用程式主動讀取代理設定。瀏覽器與部分桌面程式通常支援這種方式，但一些遊戲啟動器、命令列工具、背景服務或使用自訂網路堆疊的程式可能直接連線。TUN 模式透過虛擬網路介面接管系統流量，讓這些程式的連線也能進入核心。它改變的是流量入口，不是伺服器協定，也不會讓原本失效的節點恢復連線。

是否啟用 TUN 應由應用程式需求決定。只使用能正確讀取系統代理的程式時，系統代理設定較簡單，排錯範圍也較小。只有明確發現某個程式不經過代理入口，或需要統一處理 TCP、UDP 與 DNS 時，才啟用 TUN。將 TUN 作為預設排錯動作，容易同時引入路由、權限、虛擬介面與 DNS 問題。

啟用前確認權限與衝突項目

TUN 需要建立或控制虛擬網路介面，並調整路由。Windows 環境中可能需要提升權限；macOS 與 Linux 也需要系統允許相應網路操作。若客戶端提示介面建立失敗，先查看權限與驅動程式狀態，不要反覆切換節點。企業網路管理軟體、其他虛擬網路工具與已執行的同類代理程式可能同時修改路由，測試時應只保留一個接管者。

啟用前記錄系統預設閘道與 DNS，關閉其他網路接管工具，然後啟動 v2rayN 的 TUN 模式。成功後先測試一般網頁，再測試原先不讀取系統代理的程式。若所有網路立即中斷，應先關閉 TUN 恢復基礎連線，再檢查虛擬介面是否建立、預設路由是否變更，以及 DNS 是否指向預期入口。不要在斷網狀態下繼續疊加 FakeDNS 與複雜路由。

嚴格路由、自動路由與 MTU

自動路由用於將需要接管的流量導向 TUN 介面；嚴格路由通常會進一步限制可能繞過該介面的路徑。具體選項名稱可能隨版本變化，但判斷原則相同：先使用預設自動路由驗證基本接管，再依據洩漏路徑或區域網路需求調整嚴格程度。啟用嚴格路由後，若區域網路資源無法存取，應檢查私人網段是否保留直連，而不是直接增加全域代理規則。

MTU 決定虛擬介面可承載的資料封包大小。數值過大時，某些鏈路可能出現網頁載入不完整、上傳卡住或特定連線逾時；數值過小則會增加分片與額外負擔。遇到「可以連線但大型請求失敗」時，可以記錄原值後分段降低 MTU 進行對照。不要只憑單次測速判斷，至少測試小型網頁、較大檔案傳輸與需要持續連線的應用程式。

排除區域網路與客戶端自身流量

TUN 路由通常需要讓私人網段保持直連，否則印表機、閘道管理頁面與區域網路服務可能被錯誤送入代理。常見私人位址範圍可透過 geoip:private 規則統一處理。若本地網路使用非典型位址範圍，還需依實際網段補充。區域網路服務若使用網域名稱，也同時依賴本地 DNS；只有位址直連而 DNS 由遠端解析時，名稱仍可能無法使用。

客戶端自身連往代理伺服器的連線也必須避免再次進入同一代理出站，否則會產生流量迴圈。成熟的預設設定通常會處理這點，但使用自訂路由或自訂出站時，仍要確認伺服器位址採用直連路徑。若核心啟動後不斷重新連線，日誌反覆出現同一伺服器目標，應檢查是否發生代理自身迴圈。

關閉 TUN 後的恢復檢查

正常關閉客戶端時，虛擬介面與暫時路由應一併撤銷。若異常結束後網路仍無法使用，先重新開啟客戶端並正常關閉 TUN，再檢查系統預設路由與 DNS 是否恢復。重新啟動系統可以清理部分暫時狀態，但不應取代原因定位。若反覆出現殘留，應檢查是否有多個網路工具同時管理介面，並從日誌確認結束階段是否報錯。

行動版的 v2rayNG 與 v2flyNG 透過系統提供的網路接管介面運作，應用程式排除、背景限制與省電策略會直接影響持續連線。桌面版的 TUN 設定不能原樣套用到 Android，但路由與 DNS 的分析方法一致：先確認流量是否進入客戶端，再確認規則命中與出站，最後檢查系統是否在背景終止連線。

FakeDNS 的運作方式、適用情境與界線

FakeDNS 保存網域與連線的對應關係

FakeDNS 接管 DNS 查詢後，會為網域回傳保留位址池中的暫時位址，並記錄該位址與原始網域的對映。當應用程式連線到這個暫時位址時，核心會依據對映還原網域，再執行網域路由與遠端連線。它的主要價值是為那些先在本地解析、之後只攜帶位址發起連線的程式保留網域資訊，讓網域規則仍有機會生效。

FakeDNS 回傳的位址不是目標伺服器的真實公網位址，因此不能脫離核心單獨使用。查詢與後續連線必須進入同一條接管鏈路，對映才會成立。如果 DNS 查詢經過 FakeDNS，但連線繞過 TUN，應用程式會嘗試直接存取暫時位址並失敗；反過來，連線進入 TUN 但查詢由其他解析器完成，也無法利用對映還原網域。

適合啟用的情境

當 TUN 已穩定運作，但日誌中大量連線只顯示位址、網域路由難以命中時，可以考慮 FakeDNS。它也適用於希望減少本地真實解析，讓網域在代理鏈路中繼續處理的情境。啟用前必須先確認一般 TUN、DNS 接管與基礎路由可用，否則新增的位址池與對映機制會讓故障現象更難解釋。

一般系統代理情境通常不必為了「更快」而單獨啟用 FakeDNS。許多代理入口本身可以接收網域，網域資訊並未遺失。FakeDNS 也不是快取加速器，其核心作用是對映與還原。是否改善連線取決於原本的網域處理問題，不能將它視為所有環境都應啟用的效能選項。

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

範例展示常見結構，實際支援方式取決於客戶端使用的核心與設定入口。198.18.0.0/15 是常用於基準測試的保留網段，可作為對映池，但仍應確認本地網路、其他虛擬網路或企業路由沒有使用相同範圍。位址池發生衝突時，可能表現為特定內部網路服務無法連線，或路由將真實目標誤判為 FakeDNS 位址。

區域網路、分流與排除

區域網路名稱、印表機探索與路由器內部網域通常依賴本地 DNS，不適合統一交給 FakeDNS。應讓私人網域與本地域名後綴使用本地解析，並讓私人位址直連。若區域網路使用自訂後綴，需要明確加入排除範圍。只排除私人位址不一定足夠，因為名稱解析發生在取得位址之前。

FakeDNS 與網域分流搭配時，規則應在網域還原後進行判斷。若連線日誌始終只顯示對映位址，表示還原鏈路尚未完成，應檢查 DNS 查詢與連線是否由同一個實例處理、位址池是否一致，以及 TUN 是否接管目標應用程式。不要透過新增對映位址段的代理規則掩蓋問題，這會讓所有暫時位址進入代理，卻仍失去原始網域的規則價值。

快取生命週期與測試方法

FakeDNS 對映有容量與生命週期。應用程式長時間保留舊對映位址，而核心已重新啟動或對映記錄已被替換時，舊連線可能失敗。測試設定變更時應重新啟動目標程式，必要時清除其 DNS 快取，讓查詢與連線在同一輪執行中重新建立。只重新啟動核心而保留應用程式的舊連線，容易得到不一致的結果。

驗證時可以選擇一個具有明確網域規則的測試目標。先在未啟用 FakeDNS 時記錄日誌中的目標形式，再啟用後重新建立全新連線，確認 DNS 回傳對映位址、核心還原網域，以及規則命中預期出站三個階段都出現。任何一個階段缺失，都應修復該階段的問題，而不是繼續增加規則。

關閉 FakeDNS 後，應同時恢復對應的 DNS 伺服器設定，並讓應用程式重新解析網域。只移除位址池而保留 fakedns 解析入口，會導致設定不完整。若需要長期在啟用與關閉之間切換，建議保存兩套完整設定，而不是每次手動修改多個分散選項。

多訂閱管理、更新節奏與衝突處理

讓每個來源維持獨立生命週期

多訂閱管理的目標不是把更多伺服器堆進同一份清單，而是讓不同來源能夠獨立更新、停用與審查。每筆訂閱應使用唯一備註與分組，不要把兩個位址設定成相同名稱。如此一來，某個來源更新失敗、節點命名變更或需要暫停時，就能只處理對應分組，不影響其他已驗證的伺服器。

建議將手動伺服器單獨放在「本機維護」分組。訂閱更新通常以遠端內容為準，直接修改訂閱產生的伺服器可能在下一次重新整理時被覆寫。需要暫時調整某個參數時，先將伺服器複製到手動分組，再進行修改，並在名稱中標記用途。保留原始訂閱記錄不變，方便與遠端參數對照。

錯開更新，而不是頻繁輪詢

自動更新間隔應依訂閱的變化頻率設定。間隔過短會增加無效請求，也可能在網路切換時連續產生失敗記錄。多筆訂閱不必在同一時間更新；先手動確認每個來源都能獨立更新，再啟用合理週期。筆記型電腦從睡眠恢復、網路剛切換或代理核心尚未連線時，首次自動更新可能失敗，應等待網路穩定後再手動重試。

更新訂閱時，訂閱請求本身使用直連還是代理，取決於客戶端設定與目前網路。若某筆訂閱只能透過目前代理存取，就會形成對現有可用節點的依賴。此時至少保留一台已驗證、且不會在更新前被清理的伺服器。不要在取得新內容前先刪除所有舊記錄，否則一次暫時性的更新失敗就會失去恢復路徑。

處理同名伺服器與重複內容

不同來源可能使用相同伺服器名稱，甚至提供參數相同的記錄。名稱相同不代表設定相同，不能只依顯示文字批次刪除。應結合分組、位址、連接埠、協定與傳輸參數判斷。若客戶端支援依分組檢視，先限制在單一來源內執行操作。跨分組去重前，先確認重複記錄是否發揮備援來源的作用。

同一筆訂閱被重複匯入時，最明顯的現象是每次更新都產生兩批相似記錄。處理前先暫停相關分組的自動更新，確認要保留哪筆訂閱設定，然後刪除多餘分組及其產生的伺服器。完成後重新更新保留的分組，並檢查目前活動伺服器是否仍然存在。直接在總清單中逐筆刪除，無法解決重複訂閱的根本原因。

伺服器選擇應與分組管理分開

分組用於來源管理，延遲測試用於判斷連線階段，實際使用還要考慮頻寬、穩定性與目標服務。不要因為某個分組最近更新，就預設其中所有伺服器都可用。每次更新後先執行真實連線延遲測試，排除無法完成代理握手的記錄，再對少量候選進行實際存取。具體選擇思路可參考節點選擇說明。

若自動選擇功能依賴定期測試，應了解測試目標、逾時時間與切換條件。測試位址無法存取會使所有伺服器被錯誤判斷，逾時過短會排除高延遲但可用的線路，切換過於頻繁則會中斷既有連線。先手動確認測試目標能透過多台伺服器存取，再考慮自動化。需要持續工作階段的應用程式通常更重視穩定性，而不是每次選擇最低的單次延遲。

訂閱遷移與本機記錄

更換裝置時，應分別處理訂閱位址、手動伺服器、路由規則與 DNS 設定。只遷移訂閱可以重新產生遠端伺服器，但不會自動帶回本機自訂規則；只複製執行設定又可能包含暫時產生的內容，後續難以更新。遷移後依來源逐筆更新，確認分組與伺服器數量合理，再匯入自訂規則。

訂閱位址與伺服器憑證都屬於敏感設定。用於排錯的截圖應隱藏完整位址、使用者識別與權杖。提交日誌前也要檢查請求參數與伺服器資訊。公開範例可使用 https://example.com/sub?token=xxxx 這類明顯假值，不應將真實訂閱內容寫入腳本、網頁或共用筆記。

當多訂閱體系已經穩定，日常維護只需要檢查更新失敗、異常重複與長期無法使用的記錄。不要為了讓清單整齊而頻繁重建所有分組。保留清楚的來源界線、可回復的活動伺服器與少量說明，比追求完全自動化更容易長期維護。

自訂出站、鏈式連線與完整診斷

出站標籤是路由與連線方式的介面

核心透過出站定義連線如何離開本機。常見的 proxy、direct 與 block 分別表示使用目前代理伺服器、直接連線與阻斷。自訂出站可以增加本機 SOCKS 服務、特定直連參數或其他支援的協定，再由路由規則透過標籤選擇。標籤必須唯一，規則中的 outboundTag 必須與出站的 tag 完全一致。

增加出站前先明確用途：是讓某類請求交給本機另一項服務，還是為特定目標設定獨立連線路徑。沒有對應路由規則的自訂出站不會自動接管流量；標籤拼寫錯誤時，核心可能拒絕載入設定，或在請求階段報錯。名稱應使用穩定、易讀的英文短詞，避免使用伺服器名稱作為標籤，因為伺服器名稱可能隨訂閱更新而變更。

{
  "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 服務。使用前必須確認該連接埠確實有服務監聽，且不會再把流量轉回目前 v2rayN 入站。兩個本機服務互相指向會形成迴圈，表現為連線不斷建立後立即失敗。自訂連接埠也不要與 v2rayN 已使用的本機 HTTP、SOCKS 或 API 連接埠衝突。

鏈式連線需要明確確認每一跳

鏈式連線會增加故障點與握手成本，只應在確有需要時設定。每一跳都應能夠單獨驗證：第一跳從本機到中間出站可達，中間出站能夠存取下一個目標，DNS 解析發生在預期位置。若鏈路中的任一跳依賴前一跳提供 DNS 或路由，應記錄依賴關係，避免啟動階段互相等待。

測試鏈式連線時，先使用簡單目標，不要同時啟用複雜網域規則。日誌應能顯示請求進入哪個入站、命中哪條規則、選擇哪個出站，以及在哪個階段失敗。連線逾時涵蓋範圍很廣，可能是連接埠未監聽、路由無法到達或後續目標沒有回應；驗證失敗則優先檢查對應出站的憑證與協定參數。不要透過延長所有逾時時間來掩蓋明確的設定錯誤。

按層次讀取日誌

完整診斷可以分為六層：客戶端程序是否啟動、核心設定是否解析、入站連接埠或 TUN 是否接管請求、DNS 是否取得可用結果、路由是否選擇預期出站，以及出站是否完成連線。日誌中最早出現的錯誤通常最接近根本原因；核心設定解析失敗時，後續的「代理無法使用」沒有獨立診斷價值；DNS 已失敗時，也不應先調整伺服器測速參數。

排錯期間可暫時提高日誌層級，確認問題後恢復一般層級。詳細日誌可能包含目標網域、伺服器位址與本機路徑，分享前需要清理敏感內容。截取日誌時保留錯誤前後的時間段與操作步驟，不要只複製最後一行。一次清楚的重現過程比大量無關日誌更容易定位。

建立可重現的診斷流程

遇到「V2Ray 無法連線」時，先記錄發生時間、目前伺服器、代理模式、是否啟用 TUN、是否啟用 FakeDNS，以及受影響的程式。然後選擇一個最小測試目標，關閉與問題無關的自訂規則，重新發起連線。若基礎連線恢復，再依原本順序逐項啟用設定，直到錯誤再次出現。這種方法能將複雜問題收斂到單一變更。

如果所有伺服器同時失敗，應優先檢查本機網路、訂閱是否剛更新、系統時間、DNS 與客戶端執行狀態，而不是逐一修改伺服器參數。只有單一伺服器失敗時，再比較同分組的其他記錄與該伺服器的協定參數。只有單一應用程式失敗時，先確認應用程式是否進入目前代理入口。更多簡短問題可前往常見問題頁逐項核對。

長期維護與升級檢查

客戶端與核心更新後，先使用原有基礎設定啟動，再檢查自訂欄位是否仍受支援。不要在更新客戶端的同時重構所有路由與 DNS。若設定無法載入，查看與欄位棄用或格式變更相關的日誌，將問題縮小到具體片段。下載與客戶端選擇統一從本站下載頁進入，桌面平台優先使用 v2rayN，Android 可依核心需求選擇 v2rayNG 或 v2flyNG。

每隔一段時間檢查訂閱分組、篩選條件、路由項目、DNS 專用規則與自訂出站。刪除已無法說明用途的暫時規則，確認區域網路排除仍符合目前網路，並檢查自動更新是否持續成功。進階設定的目標不是增加選項數量，而是讓每一層行為都可解釋、可驗證、可回復。