V2Ray 設定進階手冊

先建立可回復的設定模型

區分客戶端設定、核心設定與系統網路

進階設定的第一步不是增加規則，而是釐清每項設定由哪一層負責。v2rayN、v2rayNG 與 v2flyNG 都是圖形化客戶端，負責訂閱管理、伺服器選擇、啟動核心及寫入系統網路設定；Xray 或 V2Fly 核心負責協定連線、DNS 查詢、路由比對以及入站與出站處理；作業系統則負責預設路由、系統代理、虛擬網卡及應用程式本身的網路權限。三層同時生效時，介面顯示「已連線」只代表客戶端與核心程序已啟動，不表示網域解析、路由命中及系統流量接管都正確。

故障排查時應沿著資料流檢查：應用程式先產生網域或目標位址，作業系統決定流量是否交給本機代理或虛擬網卡，核心再執行 DNS 與路由規則，最後選擇直連、代理或阻斷出站。如果瀏覽器可用但命令列工具不可用，應優先檢查系統代理的繼承方式；如果網域不可用但直接連線位址正常，應優先檢查 DNS；如果只有個別網站路徑異常，應優先檢查規則順序、協定能力及目標網站的位址族。依層判斷可避免反覆重裝客戶端這類資訊量低的操作。

建立基準設定與變更記錄

開始調整前，應保留一份已確認可連線的基準設定。基準只包含一個可用訂閱、一台目前使用的伺服器、預設 DNS、預設路由及系統代理模式，不啟用 TUN、FakeDNS 或複雜的自訂出站。接著記錄客戶端類型、目前設定檔、所選伺服器、系統代理狀態及測試應用程式。v2rayN 桌面版適合將不同用途的設定儲存為獨立設定；Android 版則應記錄目前選取的設定項目、分應用程式代理狀態與電池策略，避免將系統背景限制誤判為核心故障。

每次變更只處理一個主題。例如先完成訂閱篩選並測試，再增加路由規則；路由穩定後再調整 DNS；最後才評估是否需要 TUN 與 FakeDNS。一次同時變更 DNS、路由及虛擬網卡，失敗後便無法判斷是哪一步造成。變更記錄不需要複雜工具，一張包含「修改前、修改項目、預期結果、實際結果、回復動作」的表格即可。規則越多，回復能力越重要，因為訂閱更新、網路切換及系統升級都可能暴露原本未觸發的邊界情況。

定義可重複的驗證動作

驗證動作必須固定，否則不同測試結果便無法比較。基本檢查至少包括：客戶端日誌沒有持續重試；測試網域可以解析；瀏覽器與一個非瀏覽器應用程式都能建立連線；關閉客戶端後，系統代理或虛擬網卡狀態能正確恢復。路由驗證應選擇明確屬於直連規則、代理規則及阻斷規則的三個目標，不能只測試一個常用網頁。DNS 驗證則應同時觀察查詢結果與最終連線路徑，避免將瀏覽器快取誤認為設定成功。

Windows 可使用 Get-NetIPInterface 查看介面優先順序，macOS 可使用 scutil --dns 查看系統解析器，Linux 可使用 ip route 檢查路由表。命令輸出只用於確認系統狀態，不代表客戶端內部規則一定命中。Android 版更適合結合客戶端日誌、網路切換及分應用程式測試進行判斷。若尚未安裝合適的客戶端，請先前往客戶端頁面按平台選擇；桌面版首選 v2rayN，Android 可依核心需求選擇 v2rayNG 或 v2flyNG。

訂閱分組與伺服器篩選

分組解決管理問題，路由解決流量問題

訂閱分組常被誤解為路由分流。分組只負責整理伺服器、縮小選擇範圍及指定更新邊界，本身不會決定某個網站經由哪個出站。真正控制流量路徑的是路由規則與出站標籤。合理的結構是先按來源儲存訂閱，再按用途或能力建立檢視，最後由路由規則引用穩定的出站。不要將訂閱名稱、伺服器名稱及出站標籤混為同一層，否則訂閱更新後名稱一旦變更，依賴名稱的篩選與規則可能同時失效。

建議保留「來源分組」與「工作分組」兩個維度。來源分組對應訂閱網址，方便獨立更新、暫停或刪除；工作分組則依協定、傳輸方式、區域文字或實際用途進行篩選。v2rayN 的伺服器清單適合利用備註、訂閱歸屬與篩選運算式縮小範圍；v2rayNG 和 v2flyNG 的行動介面更適合維持較少分組，避免在小螢幕上維護過度複雜的篩選條件。分組名稱應穩定且易讀，不要將短期狀態寫入名稱。

設計可維護的篩選條件

伺服器篩選通常依據備註文字，因此準確度取決於命名品質。建議採用「先包含、後排除」的策略：先限定明確的協定或用途，再排除測試項目、過期項目及不需要的傳輸類型。篩選運算式應盡量簡短，並在訂閱更新後抽查結果。若上游更改命名格式，應更新篩選條件，而不是逐一手動改名，因為下次更新可能覆蓋本機修改。重要伺服器可以增加本機備註，但要確認客戶端在更新時是否保留該欄位。

正規表示式適合處理命名穩定的內容，不適合猜測含糊文字。以下範例會比對名稱中含有「VLESS」或「REALITY」，同時排除「測試」與「過期」。不同客戶端的篩選輸入框對正規表示式的支援可能不同，應先用少量項目確認結果，再套用至完整清單。若介面只提供一般文字搜尋，應拆成多個簡單檢視，不要試圖在單一關鍵字中表達全部邏輯。

^(?=.*(?:VLESS|REALITY))(?!.*(?:測試|過期)).*$

篩選結果為空時，先移除排除條件，再逐段增加運算式。結果過多時，檢查大小寫、全形符號及上游命名是否一致。篩選不會驗證伺服器是否可連線，也不能取代實際連線測試。延遲只能反映某一時刻的網路往返狀況，不能完整代表吞吐量、穩定性與協定適配度。選擇伺服器時，應結合日誌中的握手結果、持續存取表現及切換網路後的恢復情況，而不是只根據一次排序決定。

更新、刪除與重複項目處理

訂閱更新應按來源逐一執行。先更新一個訂閱，確認伺服器數量、命名及目前選取項目是否變化，再處理下一個來源。若所有訂閱同時更新，重複項目或異常命名會迅速擴散，難以定位來源。刪除訂閱前，應確認目前使用的伺服器及自訂路由沒有依賴該來源。部分客戶端會保留由訂閱產生的歷史伺服器，部分則會在更新時覆蓋；操作前查看介面的更新策略，必要時先匯出客戶端設定。

重複伺服器不能只看顯示名稱。兩個項目可能名稱相同但位址、連接埠及協定參數不同，也可能參數相同卻來自不同訂閱。安全的處理方式是比較協定類型、伺服器位址、連接埠、傳輸層及安全參數，再決定是否保留。若多個來源長期提供相同項目，可以保留來源較穩定、命名較規範的一份，其餘放入停用分組，而不是立即刪除。這樣在更新異常時仍保留回復路徑。

自動選擇功能也需要明確界線。它可以在候選集合中減少手動切換，但候選集合必須先經過篩選，且測試方式應接近實際使用情境。將協定能力、網路路徑各不相同的所有伺服器放進同一個自動群組，可能導致連線行為頻繁變化，干擾 DNS 快取、長連線及故障排查。穩定性優先的情境應固定伺服器一段時間，觀察日誌與應用程式行為；確認候選項目相容後，再啟用自動策略。

路由規則的比對順序與實戰結構

理解由上而下的首次命中

V2Ray 路由的核心不是規則數量，而是比對順序。多數設定會依清單由上而下判斷，連線命中第一條符合條件的規則後，便不會繼續檢查後續規則。具體規則應放在通用規則之前，阻斷規則應涵蓋明確且穩定的目標，最後再設定兜底路徑。若將範圍很大的網域、位址或連接埠規則放在頂部，後面的細分規則即使語法正確也不會生效。

一套可維護的順序通常是：先處理內網位址與本機服務，再處理明確的阻斷項目，接著處理需要指定路徑的網域或位址集合，然後處理常用直連集合，最後放置預設出站。規則條件之間要區分「同一條規則內的組合關係」與「多條規則之間的先後關係」。同一條規則寫入多個欄位時，核心通常要求相應條件同時滿足；同一欄位中的多個值則表示任一值符合即可。設定前應先用自然語言寫出意圖，再轉換為規則。

網域、位址與程序條件的界線

網域規則只有在核心能取得目標網域時才會生效。如果應用程式先自行解析，再直接連線至位址，核心看到的可能只有目標位址，此時需要位址規則、DNS 嗅探或 TUN 配合。位址規則較穩定，但大型服務的位址範圍會變動，手動維護成本很高。GeoSite 適合依網域類別比對，GeoIP 適合依位址歸屬比對；兩類資料都需要持續更新，具體更新方式可參考GeoIP 與 GeoSite 資料庫更新指南。

程序條件依賴作業系統與客戶端實作，不應作為唯一依據。程序名稱可能因安裝方式、輔助程序或應用程式更新而改變，同一個應用程式也可能透過系統服務發出網路請求。桌面版可將程序規則用於補充精細分流，但仍應準備網域或位址規則作為基礎。Android 的分應用程式代理會在系統層選擇哪些應用程式進入虛擬網路，它與核心路由是前後兩道判斷：前者決定是否進入，後者決定進入後使用哪個出站。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:telemetry.example.invalid"
        ],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "domain": [
          "geosite:cn"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

範例中的 IPIfNonMatch 表示先依網域規則判斷，網域未命中時再解析位址，用於位址規則。它可以提高位址規則的涵蓋率，但也會讓核心 DNS 參與決策，因此必須與 DNS 章節中的伺服器及查詢策略一併設計。若設定為始終依位址判斷，網域請求會產生更多解析；若完全不解析，只有網域資訊的連線便無法命中位址集合。不存在適用於所有網路的固定值，應依規則是否依賴 GeoIP、應用程式是否提供網域，以及 DNS 路徑進行選擇。

用日誌驗證規則，不要從頁面結果推測

規則驗證應檢查目標、命中條件及最終出站三項資訊。先清除瀏覽器 DNS 與連線快取，關閉會重用連線的測試頁面，再發起新的請求。若日誌顯示目標已直接變成位址，應檢查應用程式解析或嗅探；若目標網域正確但命中錯誤出站，應檢查規則順序及網域寫法；若出站正確但連線失敗，應轉向檢查協定參數、伺服器狀態與網路路徑，不要繼續修改路由。

網域寫法也有明確差異。完整網域只會匹配單一主機名稱，網域後綴會涵蓋其子網域，關鍵字匹配範圍最廣，也最容易誤傷。優先使用完整網域或維護良好的網域集合，只有在目標命名穩定且無法逐一列舉時才使用關鍵字。連接埠規則應註明協定，因為同一連接埠可能同時存在 TCP 與 UDP 行為。阻斷 UDP 時還要考慮應用程式是否會自動退回 TCP；表面上「仍可存取」不代表阻斷規則沒有生效。

修改路由後，應依序測試內網服務、明確直連目標、明確代理目標、遭阻斷目標及未命中目標。內網存取異常通常是私有位址規則位置錯誤；所有目標都走同一路徑，通常是兜底規則放得太前；只有網域失敗可能是 DNS 與路由形成迴圈；連線後無法開啟網頁，可繼續依十二項故障排查清單，從本機設定、節點、路由及解析四個層面檢查。

DNS 設定最佳化與解析路徑

先畫出查詢從哪裡發出

DNS 問題難以定位，通常是因為系統解析器、瀏覽器安全 DNS、客戶端核心 DNS 及遠端解析同時存在。應用程式可能將網域交給系統，也可能自行發出加密查詢；系統代理模式下，部分應用程式仍會直接使用系統 DNS；TUN 模式可以接管更廣泛的查詢，但仍可能遇到硬編碼解析器或特殊協定。設定前應先確認測試應用程式使用哪條路徑，再決定是否讓核心接管，不能只因客戶端填寫了 DNS 位址，就假定所有查詢都會經過它。

解析路徑至少包含三個決策：查詢交給哪台伺服器、查詢流量經由哪個出站，以及回傳結果用於路由還是僅用於連線。若 DNS 伺服器位址本身需要經過代理，而建立代理連線又依賴同一個 DNS，便會形成啟動迴圈。解決方式是為基礎連線保留一個可直接存取的解析器，或讓伺服器位址使用已可解析的固定網域及獨立路徑。任何最佳化都應先確保啟動鏈路閉合，再討論快取、並行或位址族偏好。

依網域範圍選擇解析器

不同網域可以使用不同 DNS 伺服器，但分流依據必須清楚。內部網域與區域網路裝置通常交給系統或區域網路解析器，因為它們可能依賴搜尋網域、私有區域及本機位址；公共網域可以交給核心設定的解析器；需要與特定出站保持一致的網域，應讓查詢沿相同路徑發出，減少解析結果與連線出口不一致。不要簡單地將所有查詢並行傳送給多台伺服器並採用最先回應者，這會讓結果來源不穩定，增加故障排查難度。

設定中的 hosts 適合儲存少量且穩定的對應，例如本機測試服務或需要固定別名的內部資源。它不是大規模網域規則資料庫，也不應取代正常解析。對應變化頻繁時，靜態項目很容易過期。若一個網域同時存在 IPv4 與 IPv6 記錄，應確認系統網路是否具備相應位址族的可用路徑；僅停用某類回應雖能避開表面故障，卻可能掩蓋系統路由或上游網路設定問題。

{
  "dns": {
    "hosts": {
      "router.home.arpa": "192.168.1.1"
    },
    "servers": [
      {
        "address": "localhost",
        "domains": [
          "domain:router.home.arpa",
          "domain:service.example.invalid"
        ]
      },
      "1.1.1.1"
    ],
    "queryStrategy": "UseIP"
  }
}

範例只用於說明欄位關係：本地域名優先交給本機解析器，其餘查詢使用後續伺服器。實際部署時，應選擇目前網路可達且用途明確的解析器。queryStrategy 控制回傳位址族的範圍，UseIP 允許查詢可用位址；僅查詢 IPv4 或 IPv6 應根據實際網路能力決定。客戶端產生的設定可能使用不同欄位形式，若圖形介面已提供 DNS 模式，應避免同時匯入重複設定，否則後產生的欄位可能覆蓋前者。

快取、瀏覽器與污染判斷

修改 DNS 後立即重複存取同一頁面，通常仍在使用舊快取。快取可能存在於瀏覽器、系統服務、核心及目標應用程式四個位置。驗證時應建立新連線、使用先前未查詢過的測試網域，或依系統方式重新整理解析快取。若瀏覽器啟用了獨立安全 DNS，需要暫時關閉或明確設定，讓測試路徑與客戶端設計一致。否則瀏覽器正常而其他應用程式失敗，只能代表兩者使用了不同解析路徑。

判斷異常結果時，應比較「系統查詢結果、核心查詢結果、最終連線位址」三項，而不是只看單一命令輸出。系統查詢正常但核心失敗，檢查核心 DNS 的出站與路由；核心查詢正常但應用程式仍失敗，檢查應用程式是否繞過代理或重用舊連線；結果位址正確但連線逾時，問題已離開 DNS 層，應轉查路由、協定及伺服器。解析耗時偶爾升高不一定需要更換伺服器，先觀察是否由網路切換、首次握手或快取未命中造成。

DNS 與路由必須一起驗證。使用 IPIfNonMatch 等策略時，路由判斷可能主動觸發解析；DNS 查詢本身也會進入路由系統。如果 DNS 伺服器網域又被一條依賴解析結果的規則比對，就可能形成遞迴。為解析器設定明確出站、讓基礎伺服器位址具備直接可達路徑，並將相關規則放在通用規則之前，可以降低迴圈風險。設定穩定後，再增加依網域分配解析器的細分規則。

TUN 模式的啟用順序與界線

TUN 與系統代理處理的物件不同

系統代理會向遵循作業系統代理設定的應用程式提供代理位址，設定簡單、回復清楚，但無法涵蓋忽略系統代理的程式及部分 UDP 流量。TUN 模式會建立虛擬網路介面，讓更廣泛的 IP 流量進入客戶端，再由核心執行 DNS、路由與出站選擇。它不是「更強的開關」，而是改變系統資料路徑的網路模式，因此需要額外處理路由表、DNS 接管、介面優先順序及本機網路存取。

是否啟用 TUN 應由應用程式需求決定。瀏覽器、常見桌面軟體及開發工具若能正確使用系統代理，沒有必要只為增加設定複雜度而切換。需要處理不讀取代理設定的應用程式、UDP 請求或統一分流時，再評估 TUN。Android 客戶端通常透過系統虛擬網路能力接管流量，也可搭配分應用程式選擇；桌面版則可能需要系統權限建立介面並寫入路由。不同平台的權限表現不同，但驗證邏輯一致：確認介面建立、預設路徑調整、DNS 進入預期通道，以及停止客戶端後網路恢復。

依最小設定啟用

啟用前先關閉其他會建立虛擬網卡、修改預設路由或接管 DNS 的網路工具，避免兩套路由同時競爭。保留一台已驗證可用的伺服器，暫時使用最小路由集合，不啟用 FakeDNS，也不要同時調整系統防火牆。啟動 TUN 後，先檢查客戶端日誌是否成功建立介面，再測試本機閘道、一般網域及一個明確經由代理的目標。若第一步便無法存取本機閘道，應優先檢查私有位址直連與路由排除，不要繼續修改遠端協定參數。

Windows 可在 PowerShell 中查看介面與路由優先順序；macOS 可檢查目前預設路由及 DNS 解析器；Linux 應同時查看路由表、策略路由及 DNS 服務狀態。以下命令只讀取狀態，不會修改系統設定。輸出中應出現客戶端建立的虛擬介面，但介面名稱由客戶端與系統決定，不應依固定名稱編寫自動判斷。

# Windows PowerShell
Get-NetIPInterface | Sort-Object InterfaceMetric

# macOS
route -n get default
scutil --dns

# Linux
ip address
ip route
ip rule

處理區域網路、回環與路由迴圈

TUN 最常見的故障，是將不應接管的流量再次送回虛擬介面。代理伺服器本身的連線必須排除在 TUN 路由之外，否則核心建立出站時又會被系統送回入站，形成迴圈。區域網路網段、回環位址、本機服務及必要的系統網路探測，也應依需求直連。私有位址規則通常是基礎，但企業網路可能使用更複雜的內部網段與網域，需要依實際路由表補充，不能只依賴通用清單。

如果啟用後客戶端顯示連線正常，但所有應用程式都逾時，先檢查伺服器位址是否被 TUN 重新捕獲；若網際網路正常但區域網路裝置無法連線，檢查私有位址直連與本機介面路由；若只有 UDP 應用程式異常，檢查核心出站是否支援對應流量、路由是否允許 UDP，以及系統防火牆是否攔截虛擬介面。停止 TUN 後仍無法上網時，確認客戶端是否正常退出並恢復系統 DNS、預設路由與系統代理。

行動網路與無線網路切換會改變底層介面、位址及 DNS。TUN 客戶端需要重新繫結目前網路，短暫中斷屬於路徑重建過程；持續失敗則應重啟連線，並查看是否仍引用舊介面。筆記型電腦從休眠恢復後也可能出現相同情況。故障排查時記錄問題發生在「首次啟動、切換網路、休眠恢復或長時間執行」的哪個階段，比單純描述「無法連線」更有價值。

效能與 MTU 的判斷

TUN 增加了一層使用者空間處理，但效能問題不能直接歸因於虛擬網卡。應先在相同伺服器、相同網路及相同路由規則下，比較系統代理與 TUN 的表現，再觀察 CPU、日誌重試及特定網站行為。若小型請求正常、大型頁面或檔案傳輸停滯，可能涉及 MTU 或路徑分片；若所有請求都均勻變慢，更應檢查 DNS、伺服器路徑及協定握手。沒有對照測試時，不要同時修改 MTU、並行數及緩衝區。

MTU 應從客戶端預設值開始。只有出現穩定且可重現的「大封包異常、小封包正常」現象，並且更換伺服器與網路後仍存在，才逐步降低數值並測試。調整數值後要重新建立連線，確保舊連線沒有繼續重用。更完整的虛擬網卡原理、平台操作與衝突情況可參閱V2Ray TUN 模式詳解；本章重點是將 TUN 納入整個設定鏈，而不是將它當作獨立開關處理。

FakeDNS 的運作方式與適用條件

FakeDNS 解決的是網域資訊遺失問題

部分應用程式會先在本機解析網域，再以目標位址建立連線。核心接收到流量時只看到位址，網域路由規則便無法直接匹配。FakeDNS 會為網域回傳專用位址池中的暫時位址，並記錄網域與該位址的對應；連線抵達核心後，再從對應中還原原始網域並執行網域路由。它的價值在於保留路由所需的網域資訊，而不是提供更快的公共解析服務。

FakeDNS 通常搭配 TUN 或能夠接管 DNS 的入站使用。若應用程式的 DNS 查詢沒有進入核心，它便不會取得專用位址，也無法建立對應；若查詢進入核心但後續連線繞過 TUN，系統會嘗試直接存取專用位址並失敗。因此，DNS 查詢路徑與連線路徑必須同時被接管。啟用前應先確認一般 TUN 與真實 DNS 運作正常，否則疊加 FakeDNS 只會增加變數。

位址池、對應與回退

專用位址池不能與真實區域網路、企業網路或其他虛擬網路使用的網段重疊。重疊時，系統可能將真實內部服務誤送給 FakeDNS，或將暫時位址交給錯誤介面。位址池容量決定可同時保存的對應數量，但不必盲目擴大；容量不足通常表現為舊對應被回收，長期連線與快取型應用程式可能出現不一致。應優先維持合理的快取週期，並在客戶端重啟、切換網路後重新建立測試連線。

並非所有流量都適合 FakeDNS。區域網路裝置探索、內部網域、需要系統搜尋網域的服務及依賴真實位址判斷的應用程式，應保留真實解析或設定繞過。對無法正確處理專用位址的應用程式，可以使用分應用程式排除，或讓相應網域使用一般 DNS。不要將相容性問題簡單歸咎於伺服器故障：如果關閉 FakeDNS 後同一台伺服器立即恢復，而一般 TUN 始終正常，應檢查網域對應、嗅探與位址池衝突。

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

這段內容展示常見欄位關係，實際客戶端可能會由介面產生相應設定。198.18.0.0/15 常用於基準測試網路，適合作為專用對應池，但仍要確認本機環境沒有使用該網段。設定後不應透過外部網路直接存取池中的位址；這些位址只有在本機核心對應中才有意義。如果日誌顯示請求已抵達該位址，卻沒有還原網域，表示 DNS 查詢與連線沒有使用同一個對應內容，或對應已經失效。

與嗅探、路由及真實 DNS 的協作

嗅探可以從部分 TCP、TLS 或 HTTP 流量中還原網域，FakeDNS 則從受控 DNS 對應中還原網域，兩者解決的問題相近，但來源不同。嗅探依賴流量中存在可識別資訊，並非適用於所有協定；FakeDNS 則依賴查詢與連線都經過核心。可以依客戶端預設策略協同使用，但要明確路由最終採用哪個目標。若日誌中的目標網域與應用程式請求不一致，應檢查目標覆蓋策略，避免嗅探結果錯誤取代原始目標。

FakeDNS 回傳暫時位址，不代表完全不再需要真實 DNS。核心最終連線至目標伺服器時，仍可能需要取得真實位址；路由規則使用 GeoIP 時，也可能需要真實解析結果。因此設定中通常會同時存在 FakeDNS 與一般解析器，並在不同階段執行不同任務。若一般解析器的出站設定錯誤，便可能出現網域已成功還原，但最終連線仍然失敗的現象。日誌中應分別觀察對應命中與真實位址解析。

啟用後的驗證應分四步：首先確認應用程式查詢取得專用位址；其次確認該連線進入 TUN；接著確認核心日誌還原出原始網域；最後確認網域路由命中預期出站並完成真實連線。只看到第一步不能證明設定完成。若瀏覽器可用但某個應用程式失敗，檢查該應用程式是否快取位址、使用獨立 DNS 或繞過虛擬網路。完全關閉應用程式並清除其連線狀態後再測試，避免舊對應造成干擾。

回復時應同時關閉 FakeDNS 伺服器、位址池及依賴其目標覆蓋的設定，並恢復一般 DNS。只關閉其中一個元件，可能留下專用位址快取，使系統短時間內仍嘗試存取無效目標。回復後重啟客戶端與測試應用程式，確認解析結果恢復為真實位址。FakeDNS 適合有明確網域路由需求且一般嗅探涵蓋不足的情境，不應作為所有設定的預設前提。

多訂閱管理與更新策略

將訂閱視為外部設定來源

多訂閱管理的重點不是將更多伺服器放進清單，而是控制外部設定的變化。每個訂閱都可能改變名稱、協定參數、項目數量及可用範圍，因此應有獨立名稱、更新節奏與停用狀態。訂閱網址只應儲存在客戶端的訂閱管理中，不要複製到路由備註、腳本輸出或分享的螢幕截圖。若需要在多台裝置使用，應分別匯入，並依裝置用途建立本機分組，而不是假設桌面版與行動版需要完全相同的伺服器集合。

建議為每個來源記錄用途、客戶端範圍、上次成功更新時間及異常處理方式。這裡的「更新時間」用於本機管理，不必寫入伺服器名稱。長期不用的訂閱先停用自動更新，確認沒有依賴後再刪除。直接刪除可能同時移除目前使用的伺服器或打亂分組。v2rayN 更適合作為桌面多訂閱管理中心，利用較大的清單介面檢查差異；v2rayNG 與 v2flyNG 應保留行動版真正需要的來源，減少背景更新與手動選擇的負擔。

錯峰更新與變更審查

多個訂閱不要在同一時間批次更新。先更新低風險來源，檢查新增、刪除、重新命名及協定變化，再繼續下一個。若更新後目前伺服器被替換，先選擇同一來源中已確認的項目進行測試；若大量項目消失，不要立即重複更新或清空清單，應保留現況並查看客戶端日誌。重複操作可能覆蓋仍可用於回復的資訊。自動更新週期也不應過短，過於頻繁會在切換網路或來源暫時異常時反覆改變清單。

變更審查至少要關注四項：項目數量是否出現異常跳變；顯示名稱是否仍能被篩選規則識別；目前選取的伺服器是否保留；協定與傳輸參數是否發生變化。名稱變化只影響整理，參數變化則可能影響連線。若某個來源開始使用不同的協定能力，應調整工作分組，而不是只修改顯示名稱。涉及訂閱格式識別與轉換界線時，可參考V2Ray 訂閱格式完整解析，避免將分享連結、編碼清單及原生設定視為同一種結構處理。

去重、優先順序與故障隔離

去重應根據連線識別，而不是只看名稱。可比較協定、位址、連接埠、使用者識別、傳輸方式及安全參數。完全相同但來自不同訂閱的項目仍有來源價值：當一個來源更新失敗時，另一個來源可能仍持續維護。可以將重複項目放入較低優先順序的分組，避免日常清單過於擁擠，同時保留回復能力。若客戶端不支援複雜檢視，至少要在訂閱名稱中清楚區分來源。

優先順序應以穩定性為目的。固定用途的應用程式使用經過持續驗證的伺服器，不要與臨時測試項目混合；測試來源放入獨立分組，並避免自動成為預設選擇。多訂閱自動選擇只能在相容的候選集合內進行。協定、傳輸及網路路徑差異很大的項目不適合放入同一個快速切換群組，否則連線變化可能被誤判為 DNS、路由或應用程式問題。

進行故障隔離時，先停用自動更新與自動選擇，固定一台已知可用的伺服器，再逐一檢查來源。若所有來源都失敗，問題更可能位於本機網路、系統接管或共用設定；若只有一個來源失敗，集中檢查該來源的解析、參數變化及項目狀態。若同一來源在 v2rayN 正常、Android 客戶端異常，應比較核心家族、傳輸支援、系統網路權限及行動網路限制，不要直接複製桌面版的全部設定。

備份範圍與恢復順序

備份應涵蓋訂閱定義、手動伺服器、自訂路由、DNS、出站及客戶端偏好，但恢復時不要一次匯入全部內容。先恢復訂閱與一台伺服器，確認基礎連線；再恢復路由與 DNS；最後恢復 TUN、FakeDNS 及自訂出站。跨客戶端移轉時，優先移轉通用連線參數與規則意圖，不要假設介面匯出的所有私有欄位都能被另一個客戶端識別。

備份檔案屬於敏感設定，應只儲存在受控位置，不要公開分享。需要展示問題時，刪除訂閱網址、伺服器位址、使用者識別及驗證欄位，只保留與結構相關的片段。日誌同樣可能包含目標網域與連線資訊，提交故障排查資料前應先檢查。恢復完成後重新建立變更記錄，避免混用舊備份與目前訂閱狀態。

多訂閱管理最終應達成三項結果：任一來源異常時不會影響全部設定；更新後能快速看出變化；刪除或停用來源時不會破壞路由與出站。實現這三點依賴穩定命名、分層分組、錯峰更新及明確回復，而不是增加更多自動化開關。來源越多，越應減少隱含行為。

自訂出站、鏈式路徑與統一故障排查

用穩定標籤連接路由與出站

自訂出站是路由規則的執行目標。常見的基礎出站包括代理、直連及阻斷，複雜設定還可能增加指定伺服器、DNS 專用路徑或鏈式前置路徑。每個出站都應使用穩定且語意明確的標籤，例如 proxy、direct、block 及 dns-out。路由規則引用的是標籤，而不是介面中的臨時顯示名稱。修改標籤前要檢查所有路由、DNS 與鏈式關係，避免出現設定語法正確但引用物件不存在的情況。

出站數量應維持最少。若兩個出站只有名稱不同，而實際協定與路徑完全一致，應合併，並由路由規則區分目標。只有當連線參數、前置路徑、位址族或網路策略確實不同時，才建立獨立出站。大量相似出站會增加日誌閱讀難度，也容易在訂閱更新後指向過期伺服器。圖形化客戶端自動產生的主要代理出站可能隨目前伺服器變化，自訂規則應確認引用的是穩定入口，而不是可能被替換的內部標籤。

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

範例展示直連與阻斷出站的基本結構。實際客戶端通常會自動產生代理出站，手動片段不應覆蓋客戶端維護的伺服器設定。freedom 出站的網域策略決定直連時如何解析目標，應與全域 DNS 及系統位址族保持一致。blackhole 用於明確拒絕符合條件的流量；阻斷後應用程式可能顯示逾時或連線失敗，這是預期結果。判斷規則是否生效時，應查看出站標籤，而不是依賴應用程式提示文字。

鏈式路徑的前置條件

鏈式出站會讓一個連線先經過前置出站，再建立後續出站。它適用於路徑要求明確的情境，但會增加握手層級、故障點及日誌複雜度。設定前應分別確認前置伺服器與最終伺服器可單獨使用，並明確哪一段負責 DNS 解析。若前置連線本身依賴最終路徑，便會形成迴圈；若兩個階段進行不一致的網域解析，最終目標位址可能與預期不同。

鏈式路徑不是提升穩定性的通用方法。每增加一段，就增加一次連線建立、逾時及參數匹配。應先使用單一出站驗證應用程式、路由及 DNS，再加入前置路徑。測試時分別記錄第一段是否握手成功、第二段是否發起，以及最終目標是否建立。日誌只顯示「連線失敗」時，應從最前面的一段開始檢查，不能直接將錯誤歸因於最終伺服器。

除非所有候選項目都已驗證具備相同的協定能力與網路行為，否則不要使用動態自動選擇作為鏈式前置。前置路徑頻繁變化會中斷長連線，也會改變 DNS 與出口的關係。更穩妥的做法是固定前置出站，觀察一段時間後再評估自動策略。鏈式設定發生問題時，第一個回復動作是取消鏈式關係並恢復單一出站，而不是繼續增加路由例外。

DNS 專用出站與流量隔離

為 DNS 建立專用出站可以讓查詢路徑更明確，但必須避免自舉迴圈。專用出站所需的伺服器位址應能透過基礎網路解析或直接存取，路由規則也要確保 DNS 流量不會再次回到需要該 DNS 才能建立的代理。設定完成後，應在日誌中區分 DNS 查詢與一般連線，確認解析流量使用 dns-out，業務流量仍依原有路由選擇。

流量隔離也可用於將特定協定或連接埠送往獨立出站，但條件必須能穩定識別。連接埠不等於應用程式，程序名稱也不等於全部連線；優先使用目標網域、位址集合及明確的網路類型。若需要組合多項條件，先在測試規則中只寫入一個條件，確認命中後再增加限制。一次寫入完整的複雜條件，未命中時很難判斷是哪個欄位不符合。

統一故障排查順序

複雜設定發生故障時，應執行統一回復：關閉自動伺服器選擇，固定一台已知可用的伺服器；取消鏈式出站；關閉 FakeDNS；保留一般 DNS；從 TUN 退回系統代理；將路由恢復為私有位址直連加預設代理。若此時仍然失敗，問題很可能位於伺服器參數、本機網路或客戶端啟動層。若基準設定恢復正常，再依原順序逐項重新加入，出現故障的第一步就是重點對象。

閱讀日誌應依時間線進行。先尋找設定載入與語法錯誤，再查看入站是否接收連線，接著確認 DNS 是否回傳結果、路由命中哪個標籤，以及對應出站是否開始握手。錯誤發生在哪一步，就只檢查該步及其直接依賴。出站握手已成功但頁面內容異常，應繼續檢查應用程式協定、位址族或目標服務，不要回頭修改訂閱分組。日誌層級可以暫時提高，但確認問題後應恢復正常層級，避免長期產生大量無關記錄。

故障排查資料應包含客戶端名稱、作業系統、使用系統代理還是 TUN、問題發生前的單項變更、關鍵日誌階段及回復結果。不要直接提交完整訂閱或完整設定。對照實驗比大量截圖更有效：同一台伺服器在基準設定下是否正常，同一份設定更換網路後是否正常，關閉新增模組後是否恢復。這三項結果通常足以將範圍縮小至本機系統、核心設定或伺服器路徑。

完成設定後，應儲存一份結構說明，列出訂閱來源、工作分組、路由順序、DNS 路徑、TUN 排除項目、FakeDNS 位址池及自訂出站依賴。之後更新客戶端、核心資料或訂閱時，依說明逐項複核。若需要重新整理客戶端選擇，可閱讀v2rayN、v2rayNG、v2flyNG 橫向比較；基本操作仍以快速上手為準，本頁用於長期維護與系統故障排查。