V2Ray 進階設定手冊

先建立可復原的設定工作模型

將問題拆分為入口、決策與出口

進階設定容易變得混亂，通常不是因為某個參數太難，而是多個層級同時發生變化。一次完整的連線至少會經過三個階段：應用程式流量先進入系統代理或虛擬網卡，核心再依據網域、IP、連接埠與程序資訊比對路由，最後交由代理、直連、阻擋或自訂出站處理。訂閱負責提供遠端伺服器，路由負責決定流量交給誰，DNS 負責將網域轉換為位址，TUN 則改變流量進入核心的方式。先將這四個層級分開，排查時就不必反覆重新安裝客戶端。

例如，瀏覽器可以連線，但命令列工具無法連線時，應優先檢查入口層：瀏覽器可能讀取了系統代理，終端程式卻直接建立連線。一般代理可用，但啟用 TUN 後出現異常，則應優先檢查虛擬網卡、路由表與 DNS 接管。某個網域始終走錯線路，應檢查路由規則的比對順序，而不是立即更換訂閱。能解析網域卻無法建立連線時，還要區分解析結果錯誤、出站無法連線與協定參數不一致。將現象對應到不同層級，是整本手冊最重要的工作方法。

每次只修改一個變數

開始實驗前，先保留目前可正常運作的基準狀態。記錄已選伺服器、系統代理狀態、路由模式、DNS 模式與 TUN 開關；如果客戶端支援匯出或備份設定，請保存一份副本。接著每次只修改一組相關設定，並立即進行驗證。不要在同一次操作中同時啟用 TUN、切換 DNS、匯入新路由與更換伺服器。四項設定一起變動後，即使連線恢復，也很難判斷真正生效的是哪一項；一旦連線中斷，定位成本會大幅增加。

驗證也要分層進行。先檢查客戶端記錄中的核心是否正常啟動，再檢查本機監聽連接埠或虛擬網卡是否建立，接著測試網域解析，最後測試目標應用程式。記錄中的第一個錯誤，通常比後續連鎖錯誤更有價值。若核心因設定格式錯誤而啟動失敗，後續的連線逾時只是結果。可以搭配系統命令觀察基本狀態，但命令輸出只代表目前作業系統看到的結果，不能取代客戶端記錄。

Windows:
ipconfig /flushdns
ipconfig /all

macOS:
scutil --dns
route -n get default

Linux:
resolvectl status
ip route

準備一組穩定的驗證樣本

驗證樣本應涵蓋三類請求：一個預期直連的網站、一個預期經過代理的網站，以及一個只用來檢查 DNS 的網域。不要頻繁更換測試對象，否則目標服務本身的波動會干擾判斷。使用瀏覽器測試時，先關閉可能獨立接管代理或 DNS 的擴充功能，並留意瀏覽器自己的安全 DNS 設定；使用終端測試時，明確指定是否讀取 HTTP_PROXY、HTTPS_PROXY 與 ALL_PROXY 環境變數。不同程式進入代理鏈路的方式並不相同。

修改前後都要記錄時間點。v2rayN 記錄會持續捲動，準確的操作時間有助於定位對應請求。若記錄中只有 IP 而沒有網域，表示網域可能在進入核心前已由應用程式解析；此時只撰寫網域路由規則未必能命中，需要調整嗅探、DNS 或 IP 規則。若記錄顯示的網域與預期一致，但最後使用的出站不正確，再檢查規則優先順序與標籤。完成這套基準後，後續各章都能沿用相同的復原與驗證方法。

訂閱分組與伺服器篩選

分組的目標是隔離來源，而不是堆疊標籤

v2rayN 可以同時保存手動伺服器與多個訂閱來源。伺服器數量增加後，最先需要解決的不是「如何顯示更多」，而是「如何維持來源可追蹤」。建議每個訂閱網址對應一個訂閱分組，分組名稱清楚寫明用途或來源，不要只寫「訂閱一」、「備用二」。當某批伺服器參數異常、名稱重複或更新後消失時，來源清楚就能直接縮小排查範圍。手動新增的測試伺服器也應放入獨立分組，避免更新訂閱時誤判其歸屬。

分組名稱應保持穩定，伺服器備註則可以變動。將地區、用途、協定等資訊全部塞進分組名稱，會讓選單與篩選條件越來越長；較合適的做法是用分組表示來源，用伺服器備註表示節點特徵。例如分組記錄服務來源，備註保留「地區｜線路｜協定」這類固定順序。統一的備註格式能讓關鍵字篩選真正發揮作用，也方便在更新前後辨識同一批伺服器。

先做包含篩選，再補上排除條件

伺服器篩選通常包含兩類邏輯：只保留符合關鍵字的項目，或排除符合關鍵字的項目。開始時建議使用一個明確的包含詞，例如地區名稱或用途標記，確認結果正確後再增加排除詞。複雜的正規表示式雖然精簡，但維護成本高；訂閱來源只要調整命名方式，原有表示式就可能將所有伺服器篩掉。篩選結果為空時，先暫時清除條件並更新分組，確認原始資料存在後，再逐項恢復條件。

如果使用正規表示式，需要注意大小寫、空格、全形符號與括號。訂閱備註中看起來相同的橫線，可能分別是連字號、短橫線或其他字元。較穩妥的表示式應抓住穩定文字，不要依賴裝飾符號。以下範例表示保留名稱中包含「東京」或「首爾」的項目，同時排除含有「測試」或「過期」標記的項目。具體輸入框是否分為包含與排除兩項，取決於客戶端介面；應分別填寫，不要將兩段邏輯拼成難以閱讀的表示式。

包含條件：
東京|首爾

排除條件：
測試|過期

理解更新、覆寫與刪除的差異

更新訂閱時，客戶端會重新讀取訂閱內容並更新所屬伺服器。某個伺服器消失，可能是上游刪除、篩選條件變更、分組選擇錯誤，或訂閱解析失敗。不要立即手動補回同名伺服器；先開啟更新記錄，確認訂閱請求是否成功，再查看未經篩選的原始結果。如果手動伺服器與訂閱伺服器使用相同備註，也不要只憑名稱判斷它們是同一項，應檢查位址、連接埠、協定與分組歸屬。

修改訂閱網址前，先確認是在編輯現有分組還是建立新分組。直接以新網址覆寫舊分組，可能使歷史來源與新來源混在同一個名稱下。來源發生實質變化時，建立新分組、完成測試後再停用舊分組，通常比直接覆寫更容易復原。清理舊分組前，還要檢查目前使用中的伺服器是否屬於該組，以及路由規則或自訂設定中是否引用了相關標籤。

多來源整理的完整實務可繼續閱讀多機場訂閱分組管理：v2rayN 伺服器篩選與備註實務。篩選穩定運作後，再進入下一章設定路由；不要用篩選功能取代路由功能。篩選決定清單中看見哪些伺服器，路由決定一次請求使用哪個出站，兩者屬於完全不同的層級。

路由規則實戰：從命中順序到出站標籤

規則是一條有順序的決策鏈

路由系統會根據請求攜帶的資訊選擇出站。常用條件包括網域、目標 IP、目標連接埠、網路類型與程序名稱。關鍵不在規則數量，而在命中順序：較具體的規則應放在較通用的規則之前，最後再用兜底規則處理剩餘流量。如果「所有網域都走代理」的規則排在「內部網域直連」之前，後者通常沒有執行機會。調整規則時，應從記錄中選取一個真實請求，沿著規則清單逐條判斷，而不是憑視覺猜測。

網域規則適合表達網站歸屬，IP 規則適合處理明確網段，連接埠規則適合限制特定服務。程序規則取決於客戶端與作業系統是否能取得程序資訊，跨平台移轉時需要重新驗證。一個請求也可能先以網域形式進入核心，隨後解析為 IP；是否保留網域取決於入口、嗅探與 DNS 設定。因此，同一條網域規則在一般系統代理與 TUN 模式下可能有不同表現。

先定義出站，再讓路由引用標籤

底層設定通常使用標籤連接路由與出站。例如 proxy 表示目前的代理出站，direct 表示直連，block 表示阻擋。標籤只是內部引用名稱，不會自動建立對應能力。路由規則引用不存在的標籤時，核心可能拒絕啟動，也可能在產生設定階段報錯。使用 v2rayN 圖形化路由編輯器時，介面會處理部分關聯；匯入自訂 JSON 時，則需要自行確保標籤一致。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "block"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:intranet.example"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

上面的結構展示了規則關係，但 proxy 出站需要由客戶端根據目前伺服器產生，不能將片段單獨保存為完整的執行設定。私有位址規則放在前面，可以避免區域網路裝置被交給遠端處理；明確的網域規則接著比對；最後一條規則捕獲剩餘的 TCP 與 UDP。如果只想代理部分流量，就不要加入全捕獲規則，而應為目標網域建立代理規則，並讓預設出站維持直連。

選擇合適的網域策略

AsIs 傾向直接使用進入路由器的網域資訊，不會為了 IP 規則主動解析；IPIfNonMatch 會在網域規則未命中時解析 IP，再嘗試比對 IP 規則；IPOnDemand 則更積極地為可能需要 IP 判斷的請求進行解析。策略越積極，DNS 對路由結果的影響越大。若規則主要以網域為依據，通常先從保留網域資訊的方案開始；若依賴地理 IP 資料，再考慮未命中時進行解析。

不要為了「提高命中率」而同時堆疊大量網域與 IP 規則。網域的解析結果會變動，內容傳遞服務也可能共用位址。過寬的 IP 範圍會誤傷不相關網站。對固定的內部網段使用 IP 規則很合適，公共網站則優先使用網域分類，並透過記錄確認。規則未命中時，檢查記錄中看到的是完整網域、子網域還是純 IP；若只有 IP，就需要回到 DNS 與嗅探層處理，而不是繼續增加網域項目。

驗證路由結果，而不只是確認「能開啟」

網頁能開啟不代表路由正確，它可能只是經由錯誤的出站而碰巧成功。驗證時查看連線記錄中的目標、命中規則與最終出站標籤。分別請求預期直連與預期代理的樣本，確認兩者走向不同。區域網路服務還應測試主機名稱與 IP 兩種存取方式，因為主機名稱可能被 DNS 解析到私有位址，而直接輸入 IP 會跳過網域階段。

遇到規則失效時，依序檢查「規則順序、條件格式、請求可見資訊、出站標籤」四項。先暫時將目標規則移到最上方；仍未命中時縮小條件，只保留一個網域或 IP；再觀察入口是否攜帶所需資訊；最後確認標籤存在。這樣可以將複雜規則還原成可驗證的最小樣本。需要了解 VLESS、VMess、REALITY 等術語與路由的關係，可查閱術語表，但協定名稱本身不應被當作路由結果的替代指標。

DNS 設定最佳化：釐清由誰解析、在哪裡解析

先釐清解析路徑

DNS 問題最常見的根源是「同時存在多個解析者」。應用程式可以自行解析，作業系統有系統解析器，瀏覽器可能啟用獨立的安全 DNS，v2rayN 核心也能處理 DNS，TUN 模式還可能接管系統查詢。設定前要先回答三個問題：由誰發起網域查詢、查詢交給哪台伺服器，以及查詢本身走直連還是代理。只修改 DNS 位址而不確認路徑，往往會出現記錄看似正常，但實際請求仍使用舊快取的情況。

在一般系統代理下，許多應用程式會先在本機解析網域，再將 IP 交給代理；也有應用程式透過 SOCKS 的遠端解析語意，將網域交給核心。TUN 模式下，系統流量更容易被統一接管，但瀏覽器內部解析仍可能繞過預期路徑。排查時先關閉應用程式層的獨立 DNS 作為對照，清除系統快取，重新發起一個先前未存取過的子網域請求，再觀察客戶端記錄是否出現對應查詢。

本機 DNS 與遠端 DNS 的分工

穩定的策略通常不是將所有網域交給同一個解析器，而是按用途分工。區域網路主機名稱與內部網域應交給能識別它們的本機解析器；需要從代理端視角解析的公共網域，可以交給透過代理存取的 DNS；一般直連網域則使用系統或指定的本機 DNS。分流前必須保留私有位址與內部後綴的直連路徑，否則印表機、路由器管理頁面與開發環境服務可能解析失敗。

DNS 伺服器的位址形式也會影響引導過程。使用網域形式的加密 DNS 端點時，客戶端首先需要解析端點本身，形成「解析解析器」的引導問題。應提供可用的引導 DNS，或使用明確的 IP 端點並正確處理伺服器名稱。不要將互相依賴的兩個解析器設定成迴圈：A 的網域交給 B，B 的網域又交給 A；這類設定通常會表現為啟動後長時間等待或週期性逾時。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

這個範例示範靜態主機對應、內部網域專用解析器與一個備用解析器。實際使用時，應將 192.168.1.1 替換為本地網路中真正可用的 DNS 位址，並確認該位址能回應查詢。skipFallback 表示命中指定網域後不再落到其他伺服器，適合內部網域；如果專用解析器不穩定，這項設定也會直接暴露故障，因此必須先單獨測試。

理解查詢策略與位址族

DNS 可能回傳 IPv4、IPv6 或兩者，應用程式隨後會選擇其中一個建立連線。當網路只有部分 IPv6 能力時，解析器回傳 IPv6 位址不代表路徑可用，常見表現是首次連線等待後才退回 IPv4。此時應先檢查系統是否具備完整的 IPv6 路由，再決定查詢策略。不要只因一次連線變慢就永久關閉某類位址；應先用系統網路工具確認預設路由、DNS 回應與目標可達性。

UseIP、UseIPv4、UseIPv6 等策略會控制核心接受或偏好的結果類型，具體支援範圍取決於目前核心。將設定移轉到不同裝置時，位址族策略不應直接照搬：桌面有線網路、無線網路與行動熱點的能力可能不同。適合固定網路的設定，在另一個網路上可能造成解析成功但連線失敗。

完成調整後，依序清除客戶端快取、系統快取與應用程式快取，再測試新網域。若只重新整理網頁，瀏覽器可能重用現有連線，無法反映 DNS 變化。DNS 最佳化的目標是路徑明確且故障可觀察，而不是不斷增加解析器數量。兩到三個職責清楚的解析入口，通常比一長串自動回退位址更容易維護。

TUN 模式：接管系統流量而不掩蓋邊界

TUN 與系統代理解決的是不同問題

系統代理依賴應用程式主動讀取代理設定，瀏覽器與多數桌面應用程式通常支援，部分命令列工具、遊戲程式或自訂網路元件則可能忽略。TUN 模式透過虛擬網卡與系統路由，將更多 IP 流量送入核心，涵蓋範圍更廣，但同時引入路由表、DNS 接管、權限與虛擬網卡驅動程式等新變數。它不是系統代理的「更強開關」，而是另一條不同的入口路徑。

啟用 TUN 前，應先確認同一台伺服器在一般代理模式下能穩定連線。這能暫時將遠端協定、訂閱參數與伺服器可達性排除在排查範圍之外。接著記錄目前系統 DNS、預設閘道與客戶端路由模式，關閉可能建立其他虛擬網卡的網路工具，再啟用 TUN。首次測試只保留基本路由，不要同時開啟 FakeDNS 與複雜的自訂規則。

權限、虛擬網卡與路由表

建立虛擬網卡與寫入系統路由通常需要較高權限。權限不足時，介面開關可能已變更，但記錄會提示網卡建立或路由寫入失敗。Windows 的重點是虛擬網卡狀態、防火牆與路由優先順序；macOS 的重點是系統授權、網路延伸功能狀態與 DNS 服務順序；Linux 的重點是 TUN 裝置權限、策略路由、網路管理服務以及防火牆規則。遇到問題時，先查看記錄中的第一個系統呼叫錯誤，不要反覆點擊開關。

建立虛擬網卡後，檢查是否新增預期的位址與路由。預設路由未改變不一定代表失敗，部分實作會使用更具體的路由或策略路由接管流量。相反地，看到新的預設路由也不代表所有流量都能正確返回；還要確認私有網段、目前閘道與 DNS 伺服器沒有被錯誤送入代理而形成迴圈。區域網路存取中斷時，首先檢查私有位址是否直連，以及「允許區域網路連線」之類的監聽設定是否與本機防火牆一致。

MTU 與 UDP 邊界

TUN 連線可以建立，但部分網站卡住時，需要考慮 MTU。資料封包經過額外封裝後會變大，底層網路若無法正確分片或回報路徑 MTU，較大的請求可能會無聲遺失。典型現象是小型頁面或文字請求正常，但上傳、圖片與長連線異常。調整 MTU 應小幅進行，並在每次修改後測試相同請求；不要直接將數值降得過低，過小會增加分片與處理開銷。

UDP 也需要單獨驗證。DNS 常用 UDP，但部分應用程式還會使用其他 UDP 協定。伺服器出站、核心、TUN 堆疊與路由規則都必須允許相應流量。若 TCP 正常而 UDP 異常，先確認路由記錄中的 UDP 請求是否進入核心，再檢查出站能力與本機防火牆。不要將所有 UDP 故障都歸因於 DNS，因為 DNS 也可以透過 TCP 或加密傳輸完成。

退出 TUN 後恢復系統狀態

正常關閉客戶端時，虛擬網卡、路由與 DNS 設定應被清除；系統強制關機、客戶端當機或權限變更時，可能留下舊狀態。關閉 TUN 後若網路仍異常，先完全退出客戶端，檢查虛擬網卡與路由是否仍存在，再重新連線目前的網路。必要時重新啟動系統網路服務，不要直接刪除不熟悉的系統介面。刪除錯誤介面可能影響正常網路。

穩定性測試應涵蓋啟動、關閉、睡眠恢復、網路切換與系統重新啟動。一次成功連線只能表示目前狀態可用，不能證明生命週期處理完整。確認這些情境都能恢復後，再進入 FakeDNS 設定。如果只需要讓瀏覽器與一般桌面軟體使用代理，系統代理的維護成本較低；只有確實存在不讀取代理設定的程式時，TUN 的額外複雜度才有明確收益。

FakeDNS：保留網域資訊的位址對應

理解「假位址」的用途

部分應用程式會先在本機完成 DNS 解析，再只將目標 IP 交給 TUN。核心收到純 IP 後，網域路由規則很難判斷請求原本屬於哪個網站。FakeDNS 的概念是為網域分配專用位址池中的暫時位址；應用程式連線到這個位址時，核心再透過對應關係找回原始網域。如此既能維持 TUN 對 IP 流量的接管，也能讓網域規則繼續運作。

專用位址不對應真實的遠端主機，只在本機代理鏈路內有意義。因此，FakeDNS 必須與能識別對應關係的入口、DNS 與路由協同使用。只設定位址池，卻沒有讓系統查詢進入 FakeDNS，就不會產生對應；系統取得假位址，但流量沒有進入對應的 TUN，連線也會直接失敗。設定時要將「查詢回傳假位址」與「連線由核心還原」視為一個完整閉環。

位址池要避開現有網路

FakeDNS 位址池必須與本機區域網路、企業網路、容器網路及其他虛擬網卡網段保持隔離。如果位址池與實際路由重疊，作業系統可能將連線送往錯誤介面，核心甚至看不到請求。選擇位址池前，先檢查目前路由表，並考慮裝置經常連線的網路環境。筆記型電腦在家用網路可用，不代表切換到辦公網路後仍不會衝突。

位址池大小會影響可保存的對應數量。一般桌面使用不需要追求極大的範圍，穩定且不衝突比容量更重要。對應關係具有生命週期；應用程式快取時間、核心快取與系統 DNS 快取若不一致，可能出現舊假位址找不到原始網域的情況。修改位址池或切換 FakeDNS 模式後，應清除系統與應用程式的 DNS 快取，並重新建立連線。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "inbounds": [
    {
      "tag": "tun-in",
      "protocol": "dokodemo-door",
      "settings": {
        "network": "tcp,udp",
        "followRedirect": true
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls",
          "fakedns"
        ]
      }
    }
  ]
}

這段內容用於說明 FakeDNS 位址池與入口嗅探的關聯，並不是可以單獨執行的完整設定。v2rayN 通常會根據介面選項產生入口與路由，手動合併設定時應檢查是否重複定義同名入站。destOverride 允許核心根據可識別的資訊還原目標，但嗅探不等於解密內容，它只使用建立連線階段可見的協定資訊。對於無法識別的流量，仍要依賴 FakeDNS 對應或 IP 規則。

哪些請求不適合交給 FakeDNS

區域網路主機名稱、內部服務探索網域，以及需要將真實位址回傳給其他裝置的查詢，通常不應使用 FakeDNS。它們應交給本機 DNS，並透過私有位址規則直連。如果將印表機、儲存裝置或開發環境網域對應成假位址，應用程式或許能將請求送入核心，但區域網路探索、憑證驗證或旁路裝置存取可能失敗。應為內部後綴建立明確的 DNS 分流，並將其放在公共解析規則之前。

會直接向使用者顯示解析結果或將結果傳遞給其他程式的工具，也需要謹慎處理。命令列查詢看到專用位址屬於預期行為，但如果後續程式不經過 TUN，就無法使用這個結果。排查腳本、監控程式與容器環境常出現這種「解析在主機，連線在另一個網路命名空間」的情況。確認查詢與連線是否經過同一個代理入口，是判斷 FakeDNS 是否適用的關鍵。

用閉環方法排查對應失敗

排查順序應固定為四步：先確認 DNS 查詢進入客戶端，再確認回傳位址落在設定的位址池中，接著確認應用程式對該位址的連線進入 TUN，最後確認記錄還原出原始網域並命中正確路由。第一步失敗，檢查系統或應用程式 DNS；第二步失敗，檢查 FakeDNS 規則與快取；第三步失敗，檢查虛擬網卡與路由；第四步失敗，檢查對應生命週期、嗅探與規則順序。

若啟用後只有少數程式異常，不要立即擴大位址池。先比較異常程式與正常程式的 DNS 行為，檢查它是否使用獨立解析、快取舊位址、繞過系統路由，或將解析結果傳給其他程序。FakeDNS 適合解決「網域資訊在進入 TUN 前遺失」的問題，不負責修復所有 DNS 故障。只有在一般 DNS 與 TUN 已穩定時啟用，才能清楚觀察它帶來的具體變化。

多訂閱管理：更新、移轉與失效隔離

將訂閱視為設定來源來管理

當訂閱數量增加後，管理重點會從「挑選最快的伺服器」轉為「控制設定變更」。每個訂閱都是一個會變動的外部來源：伺服器可能增加、刪除、更名或調整參數。應記錄來源用途、更新方式、最近一次成功更新時間，以及目前是否參與日常選擇。客戶端分組名稱負責表達來源，備註前綴負責表達伺服器特徵，篩選條件負責縮小檢視範圍，這三個層級不要混用。

建議將訂閱分為常用、備用與測試三類，但分類不必寫成複雜的階層。常用來源參與日常更新，備用來源保留少量驗證樣本，測試來源用來觀察新設定。新訂閱先放入測試分組，完成解析、連線、DNS 與路由驗證後，再納入常用清單。如此即使新來源含有異常參數，也不會立即取代目前可運作的鏈路。

安排可觀察的更新流程

同時更新所有訂閱雖然方便，卻不利於定位失敗。首次整理時應逐組手動更新，記錄每組是否成功、伺服器數量是否明顯變化，以及篩選後是否仍有結果。確認穩定後再使用批次更新。某一組更新失敗時，不要連續高頻率重試；先判斷是回應錯誤、解析錯誤，還是篩選結果為空。網路請求成功只代表取得內容，不代表內容能被客戶端正確解析。

更新前保留一台已驗證的使用中伺服器，更新後不要立即清理舊項目。先從新結果中選取一項測試，確認連線與路由正常後，再刪除明確失效的資料。如果更新行為會覆寫整個分組，進行大幅調整前可以先匯出客戶端設定。備份的價值在於恢復分組、備註與規則關係，而不只是保存訂閱網址。

處理重複伺服器與備註漂移

兩個來源可能提供參數相同但備註不同的伺服器，也可能使用相同備註指向不同參數。去除重複時不能只看名稱。至少應比較協定、位址、連接埠、傳輸方式、安全層參數與關鍵識別資訊。若參數完全一致，可以保留來源較穩定、命名較清楚的一項；若只有部分一致，則視為不同設定，不要合併。

備註漂移會破壞關鍵字篩選。解決方式不是不斷擴充正規表示式，而是為重要伺服器建立本地統一備註，或讓篩選詞只依賴較穩定的地區與用途欄位。若客戶端更新時會重設備註，應將篩選邏輯設計得更寬鬆，再透過分組縮小範圍。篩選表示式越依賴上游排版，維護頻率就越高。

移轉裝置時依層級恢復

跨裝置移轉時，不要一次複製所有與系統相關的設定。先安裝符合平台的客戶端：桌面端優先使用 v2rayN，Android 可依核心需求選擇 v2rayNG 或 v2flyNG。接著匯入訂閱與分組，驗證一般代理連線，再移轉路由規則與 DNS，最後依新系統能力重新設定 TUN。虛擬網卡權限、DNS 服務與程序規則具有平台差異，不應直接照搬舊裝置設定。

移轉後的第一輪驗證只選擇一個訂閱、一台伺服器與一套簡單路由。穩定後再恢復篩選條件與多來源更新。若舊裝置匯出的自訂設定包含絕對檔案路徑、本機連接埠或區域網路 DNS 位址，需要逐項替換。尤其是 127.0.0.1 監聽連接埠：新裝置上可能已被其他程式佔用，導致核心啟動失敗。

建立失效隔離，而不是頻繁刪除

發現異常伺服器時，先移至停用或測試分組，保留記錄與參數作為比對。立即刪除會失去比較樣本，也可能在下次訂閱更新時再次出現。只有確認來源已移除、參數長期失效或重複項目已被取代後，再清理記錄。對於更新後整體異常的訂閱，應暫時停用該組，而不是讓它繼續參與自動選擇。

長期維護可以固定一個簡短週期：更新訂閱、檢查失敗記錄、驗證常用伺服器、清理失效篩選詞、備份設定。不必每天重做所有步驟，但每次大幅修改前都應執行。客戶端本身的更新與訂閱內容更新也要分開處理；更換客戶端安裝套件前可先查看下載頁的平台說明，確認目前平台與客戶端型號，再依基準流程恢復設定。

自訂出站：串接本機服務與明確的回退路徑

什麼時候需要自訂出站

一般使用只需要由目前伺服器產生的代理出站、直連與阻擋。自訂出站適合明確的工程需求，例如將特定流量交給本機另一個 SOCKS 服務、為某類目標指定獨立出口，或建立可控的回退鏈。它不適合用來掩蓋訂閱設定錯誤。當目前伺服器本身無法連線時，應先修復協定參數與網路可達性，再考慮增加出站。

設計自訂出站時，先寫清楚三項資訊：入口請求命中哪條規則、目標出站使用什麼協定與位址，以及出站失敗後是否允許回退。每個出站都應設定唯一且語意清楚的標籤，例如 local-socks、direct。不要使用 proxy1、proxy2 這類缺乏意義的名稱，設定增加後很難從記錄判斷實際路徑。

連線至本機 SOCKS 出站

以下範例會將命中 domain:service.example 的流量交給本機 127.0.0.1:1081 上的 SOCKS 服務。該本機服務必須已啟動，且不能再次將流量送回 v2rayN 目前的入口，否則會形成迴圈。監聽位址使用迴環介面可以限制存取範圍；若確實需要連線至區域網路服務，應另外評估防火牆與存取控制。

{
  "outbounds": [
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1081
          }
        ]
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": [
          "domain:service.example"
        ],
        "outboundTag": "local-socks"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

保存前檢查 JSON 結構、連接埠類型與標籤拼寫。連接埠應為數字，不要寫成帶引號的文字。若 v2rayN 使用設定片段合併功能，還要確認合併位置：將完整的 outbounds 陣列覆寫到客戶端產生的設定上，可能會刪除目前伺服器對應的代理出站。較穩妥的方式是使用客戶端支援的自訂出站或進階設定入口，並在產生後的執行設定中確認原有出站仍然存在。

避免迴圈與重複代理

迴圈通常發生在兩個本機服務互相將流量交給對方。例如 v2rayN 的入口監聽於 127.0.0.1:10808，自訂出站連線至另一個本機服務，而該服務的上游又指回 127.0.0.1:10808。記錄會迅速出現重複連線、連接埠耗盡或連線逾時。繪製一條從應用程式到最終網路出口的單向鏈路，確認任何一步都不會返回上游入口。

系統代理與環境變數也可能製造隱藏迴圈。本機上游程式如果自動讀取系統代理，它建立出站連線時可能再次進入 v2rayN。執行本機上游程式時，應明確確認它是否忽略系統代理，或為其程序設定直連規則。程序規則在不同平台上的支援情況不同，因此還應準備以目標位址直連作為補充，但位址變更時需要維護。

回退不是自動的「容錯」

多個出站並列存在，不代表核心會自動從失敗線路切換到下一條。回退、負載平衡或健康檢查需要相應的策略物件與可觀察條件。若沒有明確設定，請將每條路由視為確定選擇：命中後就交給指定出站。為了讓排查更清楚，初期只設定一個自訂出站，確認穩定後再增加策略。

回退路徑還要區分連線失敗與業務回應失敗。核心通常能觀察網路連線是否建立，卻無法判斷所有應用程式層級狀態是否「應該切換線路」。過於積極的回退可能讓同一個請求重複傳送，對提交類操作並不合適。設計策略時應依據協定與業務性質決定，不要將所有失敗都視為可重試。

從啟動記錄到單一請求驗證

保存自訂設定後，先重新啟動核心並查看設定載入階段。若出現未知欄位、標籤不存在、連接埠格式錯誤或陣列覆寫，先修正第一個錯誤。核心成功啟動後，只傳送一個目標請求，確認記錄中顯示目標網域、命中規則與 local-socks 標籤。接著停止本機 SOCKS 服務後再次請求，觀察錯誤是否明確指向本機連接埠；這項反向測試可以證明流量確實經過自訂出站。

如果核心點擊啟動後立即退出，可參考從記錄逐行定位設定錯誤。系統代理啟用後，瀏覽器與終端表現不一致，則閱讀分開排查瀏覽器與終端兩條線。完成自訂出站後，再保存一份可正常運作的設定副本，並記錄所依賴的本機連接埠與服務啟動順序。如此在系統重新啟動、客戶端移轉或連接埠衝突時，就能快速恢復到明確基準。