v2rayN 進階設定指南

訂閱分組與伺服器篩選

訂閱分組先用來區分來源，再進一步篩選伺服器。單一訂閱通常包含多筆伺服器資料；分組負責保存訂閱網址、備註與更新選項，伺服器資料則保存協定、位址、連接埠及連線參數。兩者屬於不同資料層。修改分組備註不會變更遠端伺服器，刪除本機資料也不一定能避免下次更新時重新匯入。若要長期排除特定類型的資料，應使用分組篩選，而非一再手動刪除。

建立容易辨識的分組

在 v2rayN 的訂閱分組設定中新增分組，先填寫能說明來源或用途的備註，再貼上完整網址。教學網址為 https://example.com/sub?token=xxxx，實際使用時請換成自己的授權網址。不要刪除問號後的查詢參數，也不要把網頁顯示網址誤認為訂閱網址。貼上後請檢查前後空格、換行及全形標點；網址中的存取參數應視為敏感資訊。

建議先建立一個分組並手動更新。匯入後，檢查伺服器備註、協定及數量是否符合來源說明，再加入其他來源。分組名稱可採用「來源簡稱／用途」格式，避免以目前速度或單次測試結果命名。線路表現可能改變，來源歸屬則應保持穩定。分享截圖、記錄或設定備份時，都要遮住訂閱參數，切勿因為它只是一個連結就公開分享。

啟用自動更新前，請確認該分組確實需要持續同步。更新會重新讀取遠端內容，可能新增或刪除資料，也可能變更既有項目的連線參數。手動修改訂閱匯入的伺服器後，不要假設修改會永久保留。需要特殊參數的資料可另存為獨立設定，並註明來源與修改原因；原訂閱分組則繼續負責同步，避免同一筆資料同時依賴遠端更新與本機覆寫。

篩選關鍵字與正規表示式的界線

篩選通常套用於伺服器備註，但實際比對範圍及包含或排除的判定方式，取決於用戶端介面。先用明確的一般關鍵字確認結果，再啟用正規表示式。不要把路由中的 geosite: 貼進備註篩選欄，兩者處理的對象不同。篩選後的清單只表示哪些資料會被匯入或顯示，不代表伺服器已通過連線測試，也不代表地區標籤經過獨立確認。

需要比對多個備註片段時，正規表示式中的直線符號代表「或」，例如 (實驗|備用)；若要比對字面上的括號，應寫成 \(備用\)。除非介面明確要求，否則不要直接貼上使用斜線分隔符的程式碼格式正規表示式。大小寫處理方式及正規表示式引擎可能各不相同。測試時保留一筆應符合及一筆不應符合的範例，觀察結果比猜測清單筆數可靠。

分開處理更新失敗與清單為空

更新失敗表示取得或解析階段發生問題；更新成功但清單為空，則應檢查篩選條件與訂閱內容。疑難排解時，先暫時清除篩選條件，只更新目前分組。若資料恢復，逐一加回關鍵字；若仍是空清單，請確認來源是否有回傳有效訂閱、授權是否失效，以及回應內容是否變成登入頁面。不要靠頻繁更新掩蓋錯誤，連續送出請求也可能觸發來源端的存取限制。

若網路必須透過已建立的代理才能存取訂閱來源，且用戶端支援，可選擇經由代理更新。但這會依賴目前的伺服器與代理入口，不能使用尚未成功匯入的分組來建立該分組自己的更新通道。請先保留可用設定，並分開檢視直連更新與代理更新的失敗記錄。其他情況請參閱訂閱更新失敗疑難排解；公開求助時不要附上完整網址。

路由規則實作

路由的核心是依序比對請求，並將請求交給既有出站。規則不會建立伺服器，也不會自動修復無法使用的連線。請先確認目前的代理出站可正常使用，再新增分流規則。閱讀規則時，依序檢查比對對象、條件及出站標籤：網域條件處理網域、位址條件處理 IP，連接埠與網路類型則進一步縮小範圍。分清這些層次，才能判斷規則為何符合或略過。

先確認規則順序

一般欄位規則會由上而下評估，第一條符合的規則便決定出站。較具體的例外應排在較廣泛的集合之前。例如某個網域需要走代理，即使它屬於直連網域集合，也應將該網域的代理規則放在集合規則之前。不要只按「直連、代理、封鎖」分類排列所有規則；實際優先順序應由例外關係決定。單一規則中的不同條件通常必須同時符合，同類清單則可包含多個候選項目。

以下是 Xray 的 routing 局部範例。此設定要求已存在 block、direct 及預設代理出站，並依賴對應的 geo 資源。廣告集合會先遭封鎖，接著是私有位址直連，最後是中國網域集合直連。此片段未宣告預設代理；未符合規則的請求如何處理，仍須查看完整配置中的出站順序或用戶端補上的兜底規則。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

私有位址規則適合保護區域網路存取，但不是萬用例外。若應用程式送出的是網域，且路由採用 AsIs，系統不會為了這條 IP 規則主動查詢位址。內部服務最好另加明確的內部網域規則，並讓內部網域交由正確的本機解析器處理。共用資料夾、印表機服務及管理頁面也可能依賴廣播或其他流量；不能只因為網頁開得了，就認定所有區域網路功能都正常。

網域、IP 與解析策略

domain:example.com 可用於比對該網域及其子網域；full:example.com 則用於精確比對。若網域集合具有明確結構，適合使用正規表示式；但應避免範圍過廣的表示式，將不相關網域導向同一出站。範例網域僅用於說明語法，實際規則應依自身存取需求設定。網域規則無法查看網址路徑，因此不能用來區分同一網域底下的不同網頁。

AsIs 盡量依照請求現有資訊進行比對；IPIfNonMatch 會在網域規則未符合時嘗試解析，以繼續比對 IP 規則；IPOnDemand 則會在比對需要 IP 資訊的規則時進行解析。後兩者會增加 DNS 依賴及等待時間，結果也可能受到解析位置影響。不要只為了「更完整」就選擇更積極的解析策略，應先確認規則是否真的需要目標 IP。

若入口只將 IP 傳給核心，網域規則可能無法符合。嗅探有時能從應用程式交握中還原網域資訊，但會受到協定、加密方式及用戶端設定限制。不要把嗅探當成所有流量都能還原網域的保證。TUN 與 FakeDNS 可提供不同的網域關聯路徑，但仍須確認流量實際經過對應入口；否則即使規則正確，也缺少比對依據。

規則命中驗證與資源問題

驗證規則時，請選擇明確的測試目標，並比對記錄中的目標位址、入口標籤及出站標籤。每次只修改一條規則，重新發起連線，避免舊連線沿用先前的出站。瀏覽器連線池及應用程式背景連線都可能影響觀察結果。必要時先關閉相關應用程式再測試，不要只重新整理頁面；規則修改是否需要重新啟動核心，也應依用戶端實際的儲存方式確認。

若核心回報 geo 檔案或集合不存在，請先核對資源路徑與集合名稱，不要將所有 geosite 規則改成正規表示式來避開錯誤。資源內容會依來源而異，某個標籤存在，不代表其分類適用於所有情境。更詳細的記錄判讀方式請參閱核心啟動失敗與設定錯誤分析。連線恢復後，再逐步調整集合規則。

DNS 設定最佳化

DNS 設定應先釐清三件事：由誰發起查詢、向哪個解析器查詢，以及查詢連線使用哪個出站。系統解析、核心內建 DNS 與代理伺服器端解析可能同時存在。用戶端介面中的「遠端 DNS」也不代表所有應用程式查詢都會自動交給它。先釐清請求路徑，再修改解析位址，可避免誤以為網頁連線走代理、網域查詢卻仍走另一條路徑。

區分路由解析與連線解析

路由解析用來取得 IP 並判斷規則，連線解析則用來找到實際目標位址；兩者可能在不同位置完成。網域透過代理出站交由遠端處理時，用戶端不一定需要預先解析；直連出站通常則需要在本機取得位址。路由的 domainStrategy 與直連出站本身的解析策略不是同一項設定。調整其中一項，不代表另一項也會有相同變化。

以下範例展示 Xray 內建 DNS 的網域分流方式：中國網域集合優先使用本機系統解析，其他查詢則可使用加密 DNS。skipFallback 表示該伺服器不參與一般回退選擇，不等於禁止所有回退。此範例依賴 geo 資源；若要透過代理傳送加密 DNS 請求，還須另行設定路由及可用出站，不能只因網址使用 HTTPS 就認定路徑正確。

{
  "dns": {
    "tag": "dns-query",
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:cn"],
        "skipFallback": true
      },
      "https://1.1.1.1/dns-query"
    ],
    "queryStrategy": "UseIP"
  }
}

範例中的 localhost 表示使用系統解析行為，不是固定連線到某個本機監聽埠。這適合需要依循目前網路或內部解析的情況，也代表結果會受到系統及網路設定影響。若系統 DNS 又被 TUN 攔截並送回核心，就必須檢查是否形成迴圈。直接把「本機」和「直連」視為同義詞，往往會忽略這層依賴。

為解析流量指定出站

若要讓核心 DNS 查詢使用指定出站，可利用 DNS 標籤進行比對，但須確認目前核心如何處理這類請求。以下規則是前述範例的配套片段，應放在可能先行符合的廣泛規則之前。此設定要求已存在 proxy 出站。系統解析呼叫及帶有本機語意的解析位址，可能不會遵循相同的代理路徑；請分別驗證，不要只看標籤就下結論。

{
  "type": "field",
  "inboundTag": ["dns-query"],
  "outboundTag": "proxy"
}

若解析器位址本身是網域，還必須先解決該網域的初始解析。使用明確位址可減少引導依賴，但 HTTPS 憑證驗證及服務支援仍須正確。不要以停用憑證驗證來處理路徑錯誤。若代理伺服器位址也需要內建 DNS 解析，而解析又依賴該代理連線，就可能形成啟動迴圈；應為伺服器位址安排獨立可用的解析路徑，或交由系統完成初始解析。

雙協定堆疊、快取與疑難排解

UseIP 允許依設定取得位址族；選擇僅 IPv4 或僅 IPv6 應有明確理由。網路有 IPv6 位址，不代表 IPv6 出口及路由都可用。遇到部分網站載入很久時，可暫時分別測試單一位址族，比較錯誤與連線狀況，而不是永久移除所有 IPv6 支援。也要確認所用核心支援對應欄位及取值，不要直接套用其他核心的擴充選項。

更換解析器後，系統、瀏覽器及核心快取可能仍在使用舊結果。疑難排解時應分別觀察查詢結果與連線目標，並視需要重新啟動核心或應用程式，不必每次都重設整台裝置的網路。應用程式自帶的加密 DNS 也可能繞過系統設定。先確認應用程式內是否啟用，再決定要維持獨立設定或改用系統解析，避免兩套策略互相抵銷。

網域已解析但網頁無法開啟時，請繼續檢查路由、連線及伺服器能力；若網域完全沒有解析結果，再檢查解析器可達性、查詢出站、內部網域及位址族限制。記錄一次失敗的查詢及其相鄰連線記錄，通常比同時更換多個解析位址更有幫助。DNS 最佳化的目標是讓路徑清楚可查、結果符合存取位置，而不是單純挑選看似較快的位址。

TUN 模式

TUN 透過虛擬網路介面承接流量，適合不遵循系統代理設定的應用程式。它改變的是流量入口，不是伺服器協定，也不是獨立的連線服務。v2rayN 的系統代理主要影響會讀取系統代理設定的應用程式；TUN 則依賴介面、路由及相關網路堆疊。啟用後仍需要可用的代理出站與正確的 DNS 路徑，不能用 TUN 開關取代前面的連線驗證。

啟用前記錄網路基準狀態

先在一般代理模式下確認伺服器連線正常，再記錄目前的預設閘道、DNS 設定、既有虛擬介面及常用內部位址。使用公司網路、遠端桌面或虛擬機器時，尤其要確認哪些流量不能被接管。既有隧道、容器及虛擬機器軟體也可能安裝路由。若不清楚這些基礎狀態，啟用 TUN 後的異常就很難判斷是新規則造成，還是原有網路路徑一直有問題。

在 Windows 上，建立介面或修改系統路由通常需要系統管理員權限；macOS 和 Linux 則需要相應的系統授權或權限設定。v2rayN 的介面名稱、輔助元件及啟動方式可能變動，請依目前設定說明操作。Android 上的 v2rayNG 和 v2flyNG 通常透過系統提供的隧道授權承接流量，授權方式與桌面版以系統管理員身分執行不同，不要直接套用桌面版的權限處理方式。

首次切換時，可先停用系統代理再啟用 TUN，減少兩個入口同時生效的變因。此處的「清除系統代理」只表示調整應用程式的存取入口，不會關閉代理核心。確認虛擬介面成功建立後，再檢查預設路由及 DNS 是否如預期變更。若目前連線用於遠端維護裝置，請先準備本機回復方式，避免接管路徑改變後失去操作管道。

網路堆疊、路由與排除項目

網路堆疊決定如何處理虛擬介面收到的資料，常見選項包括系統堆疊及 gvisor；實際選項取決於所用實作。不同選項在協定相容性、資源用量及平台支援方面各有取捨，不要只憑名稱判斷速度。先採用用戶端建議的預設選項，遇到特定應用程式相容性問題時再進行比較；測試時使用相同目標及相同出站，避免把伺服器波動誤認為堆疊差異。

代理伺服器本身的連線必須避免被迴送進 TUN，形成迴圈。用戶端通常會透過介面綁定、路由排除或其他機制保護這條出站路徑，但自訂設定可能破壞保護條件。可能的情況包括啟動後一般網路與代理同時失效，或記錄中反覆連線到同一位址。應檢查伺服器位址實際使用的出口，而不是繼續新增預設路由。若伺服器位址使用網域，也要考慮位址變更後的排除規則是否仍有效。

區域網路排除設定須依實際位址範圍調整。常見的家用網段不一定涵蓋所有公司、虛擬機器或專用網路。只排除一段私有位址，可能漏掉其他內部範圍；排除範圍過大，則可能讓原本應走代理的請求改為直連。先確認必須存取的網段與內部網域，再選擇用戶端支援的路由排除或直連規則。DNS 也要一併處理，否則路由雖然可達，內部名稱仍可能無法解析。

接管效果與退出後還原

驗證時請選擇一個不讀取系統代理設定的應用程式，確認請求進入 TUN，再分別測試網頁、區域網路及需要 UDP 的功能。UDP 失敗可能來自出站能力、防火牆、遠端限制或堆疊實作，不能一概歸咎於 TUN。瀏覽器能開啟頁面，只表示其中一類請求成功，不能證明所有系統流量都已接管。也不要以虛擬介面存在取代實際連線測試。

若啟用後無法連線，請先關閉 TUN，確認一般網路是否恢復，再停止核心並檢查殘留介面、路由及 DNS。優先使用用戶端的正常關閉流程，不要立刻刪除所有虛擬網卡或重設整套網路。確認恢復基準狀態後，再依權限、入口、伺服器出站及 DNS 四個層次逐一測試。相關設定概念可先查閱名詞解釋，再回到目前平台的設定視窗。

FakeDNS 與網域關聯

FakeDNS 回傳用於內部映射的位址，而非目標伺服器的真實位址。核心會保存「網域與合成位址」之間的關聯；後續請求進入支援映射還原的入口時，再找回網域並選擇出站。FakeDNS 主要用來保留網域資訊、協助網域路由，不是一般的 DNS 加速選項。啟用前必須確認 DNS 查詢、後續連線及映射還原都位於同一條處理鏈路，否則合成位址會變成無法存取的目標。

了解完整處理鏈路

完整流程包括應用程式查詢網域、查詢送達 FakeDNS、回傳合成位址、應用程式連線到該位址、入口還原網域，以及出站連線至真實目標。任何環節繞過核心都可能導致失敗。例如，應用程式自行使用另一套加密 DNS，可能無法取得合成位址；應用程式取得合成位址後，若連線繞過 TUN，也不會進行還原。只把 DNS 伺服器改成 fakedns，不足以完成整套設定。

以下展示 Xray 的 FakeDNS 位址池及內建 DNS 片段。所選網段屬於基準測試用途的位址範圍，但仍須確認本機沒有使用相同範圍。poolSize 控制映射池的大小，不是預留給公網伺服器的位址數量。範例僅說明設定結構，實際入口仍需搭配嗅探與路由；v2rayN 若使用其他網路元件承接 TUN，應依該元件的設定方式處理，不能混用不同實作的欄位。

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

入口還必須能辨識 FakeDNS 位址並還原網域。以下是 Xray 對應入口可使用的 sniffing 局部物件，並非獨立的入口定義。metadataOnly 將嗅探限制為中繼資料，適合用來說明映射還原路徑；若還需要 HTTP 或 TLS 嗅探，應重新核對目標清單及選項。不要把不同來源的嗅探片段疊加後，就假設它們會自動協同運作。

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

位址池、例外與相容性

位址池應足以容納實際使用中的映射，同時不得與既有網路重疊。映射空間與位址池大小是不同概念；調大數值也無法解決入口未接管的問題。頻繁重新啟動可能使映射狀態遺失，而應用程式快取仍保留舊位址。此時應用程式繼續連線到舊合成位址，核心可能無法還原網域，導致剛啟動時一切正常、切換設定後部分應用程式卻失敗。

內部網域通常需要真實解析結果，因為其存取可能被排除在 TUN 之外，或依賴本機網路位址。這類網域應設定明確的真實 DNS 路徑，並確認後續連線也依內部網路方式處理。不要只將內部 IP 設為直連，卻仍讓內部網域解析成合成位址。有些應用程式會自行檢查 DNS 結果，或將解析位址用於連線以外的用途，也可能需要額外設定例外。

FakeDNS 回傳的位址屬於內部映射，因此傳統「先解析，再依真實 IP 分類」的判斷方式未必適用。應優先確認網域還原是否發生在路由比對之前，以及目前實作如何處理合成位址、網域與 IP 規則的順序。尤其是直連、內部位址及需要真實位址的規則，不能只依同一組 IP 清單推斷結果。若設定目標主要是網域分流，請先用明確網域驗證，再逐步擴大範圍。

分階段啟用與停用

測試時先保留一般 DNS 與 TUN 的可用基準，再啟用 FakeDNS。確認一次網域查詢是否回傳位址池中的位址，接著查看同一應用程式的連線能否還原為網域。兩個步驟都成功後，再繼續驗證分流及區域網路。若查詢沒有進入 FakeDNS，優先檢查 DNS 入口；若取得合成位址後連線失敗，請檢查連線接管與入口映射，不要反覆更換上游解析器。

停用 FakeDNS 時也要處理快取。先恢復真實 DNS 路徑，再重新啟動仍持有合成位址的應用程式，必要時依系統方式清除解析快取。若直接關閉接管入口，卻保留舊 DNS 結果，可能會短暫無法存取。疑難排解期間，不要將合成位址寫入靜態網域映射、伺服器位址或長期規則；它只在對應的映射情境中有效。確認真實解析已恢復後，才能判斷回復是否完成。

多訂閱管理與更新隔離

多訂閱管理的目標不是把所有資料合併成一份冗長清單，而是確保來源、更新及使用狀態都可追溯。不同來源可能使用相似備註，也可能提供同一伺服器的不同參數。分組應作為更新邊界，目前使用的伺服器應作為連線邊界，路由則作為流量邊界。分開管理這三者，某個來源失效時才能保留其他分組及目前可用的連線，而不必重建整套設定。

依來源區分更新責任

建議每個獨立來源各建一個分組，不要把多個網址拼在同一個網址欄位中。備註可註明用途，但不要寫入存取參數或身分資訊。先逐一手動更新，檢查匯入格式、篩選條件及伺服器變化，再決定自動更新的安排。若兩個分組確實來自同一來源，只是篩選範圍不同，請留意它們會重複向同一服務送出請求；不必要的重複更新應適度合併。

更新頻率應依來源變動情況及實際需求設定，不是越頻繁越好。頻繁更新會增加請求次數，也可能使伺服器資料在測試期間變動。需要比較連線表現時，可先暫停相關分組的自動更新，固定設定後再測試。更新完成後，請確認仍選取預期伺服器，尤其是原有資料遭刪除或重新建立參數時；用戶端保留選取狀態的方式不能取代人工確認。

某個分組更新異常時，只需針對該分組進行疑難排解。先確認網址及授權，再比較直連與經代理取得的結果，最後檢查回傳格式。其他分組能正常更新，只能證明相應來源可連線，不能證明失敗來源的網址沒有問題。若所有分組同時失敗，則較可能是共用網路、解析或代理入口發生變化。依此判斷問題範圍，可避免無謂地重新匯入所有來源。

重複資料與測試結果

判斷重複資料不能只看備註。同名伺服器可能使用不同連接埠、協定、傳輸或加密參數；備註不同的資料也可能指向同一連線。刪除前請比較重要的連線欄位，並保留來源關係。教學或求助時可以描述差異，但不要公開完整連線參數。若要長期保留某個項目，應記錄其來源及用途，避免下次更新後無法辨識。

延遲測試、實際請求及頻寬測試衡量的項目不同，不能把一次排序當成固定的選擇結論。測試結果也會受到本機網路、測試位址、並行數量及伺服器負載影響。比較多個分組時，請使用相同測試方式、相同目標及相近的時間範圍；並保留一筆已知可用的資料作為對照。詳情請參閱Tcping、實際連線延遲與下載測速的差異。

不要只依地區名稱選擇伺服器。地區標籤通常是來源提供的備註，未必能完整說明入口位置、出口位置及實際線路。倍率、協定相容性及用途限制也會影響選擇。某筆資料的測試延遲較低，不代表它一定適合持續傳輸或特定應用程式。保留少量「日常、特定用途、備用」候選項目，比維護一份不斷變動的完整排名更方便。

備份與移除來源

設定備份可能同時包含訂閱網址、伺服器身分參數、自訂出站及路由。備份應保存在受控位置，不要當成一般截圖附件分享。還原時先確認用戶端與核心相容，再逐一匯入分組。舊備份中已失效的網址不應自動成為新的更新來源；還原成功也只代表設定已讀取，仍須重新驗證連線、DNS 及目前網路下的路由效果。

不再使用某個來源時，請先切換目前使用的伺服器、停用該來源的更新，再確認是否有路由或自訂出站引用相關資料。確認沒有依賴後，再刪除分組。刪除本機分組不會取消來源端的授權或服務，仍須依來源本身的管理方式處理。若只是暫時停用，保留分組並明確停用，比把網址複製到多筆臨時資料中更容易還原，也更容易控管敏感資料的保存範圍。

自訂出站與核心界線

自訂出站用來定義請求離開核心的方式。常見用途包括直接連線、封鎖，以及透過既有代理服務轉送。路由會以標籤引用出站；標籤是內部識別名稱，不是伺服器備註或訂閱分組名稱。先清楚規劃各出站的職責，再撰寫比對規則，可避免標籤拼寫不一致、預設路徑改變，以及用戶端產生的設定覆蓋本機編輯等問題。一般使用仍建議優先透過 v2rayN 圖形介面完成。

定義標籤與預設路徑

以下是 Xray 的直連與封鎖出站片段，未提供代理伺服器。此範例可用來了解 freedom 與 blackhole 的結構，不應整段覆蓋目前的出站清單。若只保留這兩個出站，未符合規則的連線通常會使用第一個直連出站。需要預設代理時，應保留用戶端產生的代理出站，並檢查出站順序及兜底路由；不能只把標籤改成 proxy。

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

標籤應簡短且職責穩定，例如直連、封鎖及特定代理入口各使用不同標記。避免重複標籤，也不要在不同檔案中讓同一標籤代表不同含義。路由引用的標籤必須與出站完全一致。修改出站時，請搜尋所有相關規則及其他引用，特別是 DNS 查詢與特殊應用程式規則。即使某個出站存在，若沒有規則引用，也不代表任何請求會自動使用它。

封鎖出站適合處理明確不應送出的請求，但不要用來取代所有連線失敗處理。若封鎖所有未知網域，應用程式所需的驗證、資源及更新請求也可能一併失敗。直連出站則依賴目前裝置的網路與解析能力，不代表所有目標都能連線。為每個出站訂定使用範圍及驗證目標，比將它命名為「快速」或「安全」更有實際幫助。

本機轉送與代理鏈

以下展示轉送至本機 SOCKS 服務的出站片段。此設定假設已有獨立服務正在監聽 127.0.0.1:10808，範例本身不會建立該服務。若該連接埠實際上是同一個核心的入口，而入口又回到此出站，就可能形成迴圈。務必確認監聽服務、入口去向及最終出口；本機連接埠能建立連線，不代表轉送路徑已正確完成。

{
  "tag": "local-socks",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 10808
      }
    ]
  }
}

代理鏈會串接多個處理環節，增加連線、解析及故障依賴。規劃時先畫出每一跳的入口與出口，再確認目標網域在哪一跳解析、UDP 是否能轉送，以及任一環節停止後會如何處理。並非每種出站都支援相同的鏈式設定欄位。需要鏈式轉送時，應依目前核心的配置結構設定，不要將其他實作的欄位直接貼進現有物件。

監聽位址也是安全界線。僅供本機使用的入口通常應限制在回環位址；監聽所有介面會擴大可存取範圍，必須搭配驗證與防火牆。不要只為了讓另一台裝置連線，就直接開放未經授權的代理入口。搭配本機 SOCKS 片段的服務也應明確設定連接埠衝突、啟動順序及關閉方式，避免開機後只啟動下游核心，上游服務卻未運作。

用戶端產生設定與核心相容性

v2rayN 會依介面選項產生執行配置。直接修改暫存的產生檔案，可能在切換伺服器、儲存設定或重新啟動時遭到覆寫。優先使用用戶端提供的自訂設定或擴充入口，並確認它採用「合併片段」還是「完整取代」。兩種方式的責任不同：完整取代通常需要自行提供入口、出站、路由及 DNS；合併則必須了解標籤衝突及覆寫順序。

Xray 與 V2Fly 共用部分基本概念，但協定能力及擴充欄位不能視為完全相同。v2rayNG 的設定主要參考 Xray 生態系；v2flyNG 則應依 V2Fly 的支援狀況核對。介面能辨識某個協定名稱，不代表所有傳輸組合都可用。核心差異請參閱用戶端與核心對照及Xray 與 V2Fly 差異說明。

切換核心前先保存基準設定，再逐項核對協定、傳輸、安全參數、路由及 DNS 欄位。測試時先只驗證單一連線，再逐步恢復自訂出站及複雜規則。若啟動失敗，應依記錄修正欄位，不要直接刪除所有不熟悉的選項。能夠啟動只代表語法及部分初始化通過，仍須透過實際請求確認每個出站與路由都符合預期。

設定驗證與回復流程

完成進階設定後，應建立固定的驗證流程，而不是只憑某個網頁能否開啟就判定一切正常。至少要分別驗證啟動、代理連線、網域解析、規則命中、特殊入口及退出後還原。每項測試都要設定明確目標，並記錄修改內容及觀察結果。發生異常時，從最近修改的模組開始回復，保留其他可用設定。如此可避免誤刪正常設定，也能為下次調整留下可重複的測試條件。

從啟動到連線逐層檢查

第一層是核心能否啟動。查看第一筆明確錯誤及附近的欄位提示，區分 JSON 語法錯誤、未知欄位、資源缺失及連接埠占用。JSON 不能包含註解或尾隨逗號；局部片段也不能直接拼接成多個頂層物件。即使用戶端介面顯示「執行中」，仍須確認核心沒有隨即退出。若錯誤重複出現，先停止自動重新啟動或反覆啟動，再檢視一次完整錯誤記錄。

第二層是入口能否接受請求。確認應用程式使用的代理位址及連接埠與目前監聽設定一致，系統代理狀態也符合實際入口。入口能接受連線後，再檢查伺服器連線及協定交握。逾時、拒絕連線及驗證失敗屬於不同情況，不要一律用「更換 DNS」處理。伺服器參數來自授權設定，應核對完整欄位，不要只比較伺服器位址。

第三層是解析與路由。選擇一個預期直連目標及一個預期走代理的目標，對照記錄中的目標資訊與出站標籤。測試新規則時應重新建立連線，避免重用舊連線。若記錄中只出現 IP，先檢查入口是否保留網域、嗅探是否生效，或 FakeDNS 是否已完成還原。網域資訊缺失與規則優先順序錯誤都可能導致未符合，但修正方式並不相同。

建立有限且可重現的測試組合

測試組合不必很大，但應涵蓋設定目標：一般網頁、明確直連的內部服務、需要代理的請求，以及實際使用的特殊應用程式。記錄測試時是否啟用 TUN、是否使用 FakeDNS、所選伺服器及網路環境。行動網路與固定網路的結果不能直接混在一起比較。若問題只在特定網路發生，請保留這項差異，優先檢查網路端的解析、出口及防火牆條件。

測速可作為輔助觀察，但不能取代功能測試。交握延遲低不代表應用程式驗證成功，下載速度快也不表示路由與 DNS 符合設計。測試失敗時，先讓最簡單的設定完成一次實際請求，再逐步恢復篩選、路由、TUN 等模組。不要同時切換伺服器與核心後再比較結果，否則無法判斷是哪項變更讓問題恢復。每次少量修改，反而更容易找出能長期保留的修正方式。

只在疑難排解期間將記錄層級提高到所需程度，問題定位後應恢復日常設定。記錄可能包含目標網域、伺服器位址及敏感參數，分享前務必逐項檢查。保留錯誤類型、欄位名稱、必要上下文及重現步驟即可。不要公開完整訂閱、完整設定或長時間累積的全部記錄。求助時應說明「修改了什麼、預期結果為何、實際結果為何」，而不只是貼上連線失敗的截圖。

分層回復與維護紀錄

回復應依修改順序反向進行：先還原最後新增的規則或出站，再還原 DNS，最後撤銷 TUN 與 FakeDNS 等入口變更。若最後修改的是入口，應優先關閉該入口以恢復操作管道。每次回復後都重新測試，避免一次撤銷多個模組而失去判斷依據。確認基準狀態已恢復後，再複製一份工作設定進行下一輪調整，不要在無法說明的混合狀態上繼續補規則。

維護紀錄只需記下日期、模組、修改原因、驗證結果及回復位置，不要保存憑證。訂閱自動更新、網路切換及核心切換都是需要重新驗證的時機。來源更新後，重點檢查目前使用的伺服器；切換網路後，檢查內部解析與路由；更換核心後，檢查欄位相容性。依變更範圍重新測試，比每次從頭重建設定更省事，也更容易找出真正的故障界線。

若目前只想恢復日常連線，請回到匯入訂閱與建立連線流程即可，不必一次完成所有進階功能。需要調整安裝環境時，請使用平台下載入口；其他問題可繼續查閱說明中心。本指南各章可依需求單獨套用；保留少量清楚且可驗證的設定，比堆疊更多選項更適合長期維護。