V2Ray 進階設定指南

訂閱分組與伺服器篩選

先分清訂閱來源與伺服器選擇

訂閱是遠端提供的一組伺服器設定；分組是用戶端用來整理這些設定的本機分類；目前選取的伺服器則是這次連線實際使用的出口。三者不能互相取代。將不同來源的伺服器分別放入不同分組，更新失敗時才能確認是哪個來源出了問題，也能避免名稱相近的伺服器混在同一份清單中。新增訂閱時，先為分組取一個容易辨識的名稱，再輸入訂閱網址並手動更新一次。更新完成後，檢查分組內的伺服器數量與通訊協定類型，不要只看介面是否顯示成功訊息。

v2rayN 的訂閱設定和伺服器清單可選擇分組；不同版本的介面可能將分組放在側邊欄、頂端選項或訂閱設定中。操作順序相同：選取分組、執行更新、篩選目前清單，再選擇伺服器。更新後若仍看到舊項目，先確認目前檢視的確實是剛更新的分組。切換分組通常只會變更清單範圍，不一定會自動切換目前使用的伺服器；仍須另外確認作用中的項目。不要把清單中顯示的第一個項目當成目前正在使用的連線。

篩選只會變更檢視，不會修改訂閱

伺服器篩選適合用來整理項目眾多的訂閱。例如先按名稱中的地區標記縮小範圍，再依通訊協定或備註辨認目標。伺服器名稱由訂閱來源提供，命名方式不一，因此篩選文字只是本機搜尋條件，無法證明伺服器所在地、可用性或安全性。篩選後若看不到原有項目，先清除搜尋文字並取消分組範圍，再確認項目是否真的在更新時遭到移除。也不應直接依篩選結果批次刪除，尤其是多個訂閱使用相同伺服器名稱時。

比較伺服器時，請固定測試方式與網路環境。TCP 連線測試只涵蓋建立連線的一部分；網頁載入還會受到 TLS 交握、網域解析、路由及目標服務影響。若把單次延遲排序當成穩定性結論，可能會忽略這些差異。建議先參閱延遲測試方法比較，再實際連線測試候選伺服器。測速結果僅供選擇時參考，不宜寫入訂閱備註並視為長期不變的指標。

為本機修改保留明確界線

訂閱伺服器的網址、連接埠與憑證由來源提供。直接修改由訂閱管理的項目，可能會在下次更新時被覆蓋。若要暫時調整某台伺服器，請先複製成獨立的本機項目，並在備註中寫明修改目的；確認連線正常後，再決定是否保留。複製項目不會同步更新遠端訂閱，因此要分清原始項目與測試項目。尤其在排查傳輸設定時，一次只修改一個參數，避免混淆訂閱異動與本機測試。

訂閱更新後若出現大量同名項目，先確認是否重複新增相同來源，不要立刻刪除清單。兩個分組可能使用同一個訂閱網址，但更新設定不同；也可能只是來源重複使用相同名稱。確認分組來源與項目所屬關係後再處理。清除分組前，記下目前使用的伺服器屬於哪個分組，並準備可復原的替代選項。刪除清單項目和移除訂閱來源的影響不同，操作前請確認用戶端顯示的提示文字。

若更新要求本身失敗，先確認訂閱網址仍可連線，再檢查目前的系統代理是否讓更新流量經過無法使用的出口。部分用戶端可為訂閱更新設定獨立的連線方式，請依目前的網路環境選擇。若錯誤訊息指出解析失敗或連線逾時，先排除網路路徑問題；若更新成功卻沒有伺服器，則確認回傳內容是否符合用戶端支援的訂閱格式。不要反覆點選更新來取代檢查錯誤訊息。訂閱來源恢復後，再次更新並確認項目變化，才算完成這次排查。

多訂閱管理與更新範圍

依用途建立分組，不要合併所有來源

管理多個訂閱時，最常見的問題不是項目太多，而是無法判斷設定來自哪裡。可依工作情境、使用裝置或來源維護方式建立分組，並為每個分組設定獨立名稱與更新選項。名稱應能清楚區分來源，避免全部命名為「預設」或「常用」。即使兩份訂閱包含同名伺服器，分組仍可作為辨識依據。桌面端以 v2rayN 為主；Android 端的 v2rayNG 和 v2flyNG 各自管理訂閱記錄，不要假設桌面端的分組會自動同步至行動裝置。

新增來源後，先只更新該分組。確認項目數量是否符合預期、伺服器通訊協定是否正確識別，以及原本使用的伺服器是否仍可連線，再考慮啟用自動更新。這樣能區分首次匯入錯誤與日後來源變動。自動更新間隔並非越短越好：頻繁要求更新會增加失敗記錄，也可能在使用期間變更清單。若來源變動不頻繁，手動更新並在調整設定前後核對結果，通常更容易追蹤。

了解更新會影響哪些設定

訂閱更新可能新增、修改或移除屬於該來源的伺服器，但不等於還原用戶端的所有設定：本機路由、DNS、系統代理狀態及其他分組都要分別檢查。反過來說，修改本機路由也不會寫回訂閱。更新後若無法連線，先釐清是伺服器設定改變，還是剛好也修改了路由或 DNS。以先前可用的本機項目作為對照，再查看更新記錄與目前使用的項目，通常比直接重新安裝用戶端更快找出原因。

部分來源會沿用項目名稱，但實際網址或傳輸參數已經變更。因此，「名稱沒變」不能證明設定沒有變。若更新前正在進行複雜的路由測試，可先匯出用戶端設定，或記錄不含敏感資訊的變更內容；更新後，優先檢查目前使用的伺服器所依賴的欄位。完整匯出的設定可能包含訂閱網址或伺服器憑證，請妥善保管，不要直接貼到公開討論區。分享排錯資料時，只截取相關欄位並移除憑證。

處理失效來源與重複項目

某個來源長期更新失敗時，不要讓它妨礙其他來源的排查。先單獨確認網址是否可連線、回傳內容是否為空，再決定暫停更新或移除分組。暫停與刪除是不同操作：暫停會保留現有伺服器供比較；刪除則可能一併清除該分組的本機清單。刪除前先切換至其他可用伺服器，並確認自動選擇或路由規則沒有依賴該分組。不要因為一次網路逾時就認定訂閱已永久失效。

重複的伺服器項目不一定有問題。名稱相同的項目可能使用不同通訊協定、連接埠或傳輸方式；網址相同的項目也可能來自不同來源，並採用不同參數。清理時請逐一比較，不要只根據顯示名稱批次刪除。若確認是重複來源，保留更新穩定且說明清楚的一份，並將另一份從更新排程中移除。完成後清除清單篩選條件，確認目前使用的項目仍屬於保留的分組，再實際測試連線。依照這個順序操作，可避免清理完成後目前連線卻失效。

每次調整只需記下一行簡要變更記錄：異動的分組、執行的操作、目前使用的伺服器及驗證結果即可，不必記錄伺服器憑證。在多訂閱環境中，這類記錄能回答兩個關鍵問題：從哪次更新開始失敗，以及復原時應選擇哪個分組。若問題只在某台裝置上重現，也要分別核對兩台裝置的訂閱更新時間與本機路由；使用相同來源網址，不代表各用戶端目前的項目狀態完全一致。

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

先確認流量能否進入用戶端

路由規則決定已進入核心的連線要交給哪個出站；它無法讓尚未進入用戶端的應用程式自動使用代理。瀏覽器使用系統代理時，通常會由本機 HTTP 或 SOCKS 入口接收要求；不遵循系統代理設定的程式則需個別設定，或由 TUN 接管。撰寫規則前，先確認目標應用程式的流量如何進入用戶端，否則即使規則正確，也不會有預期效果。規則比對還取決於是否能取得網域資訊：只有目標 IP 的連線，無法憑空比對網域分類。

常見的路由模式可概分為依規則分流、全部代理或全部直連，但實際行為仍取決於用戶端產生的設定。依規則模式通常會由上而下檢查，符合條件後使用指定出站；未符合規則的連線則使用預設出站。檢查規則時，要一併確認比對條件、順序、出站識別名稱及預設路徑。若將範圍太廣的規則放在前面，後續細部規則便沒有機會生效。測試時先加入少量且容易理解的規則，再逐條增加，不要一次匯入多組來源各異的規則集。

從明確的比對條件開始

以下片段說明網域分類、指定網域及區域網路位址各自的用途。這是設定結構示意；在用戶端使用時，還需確認 proxy 與 direct 兩個出站識別名稱已存在，並確認核心具備規則所需的網域分類資料。geosite: 比對的是分類資料，不等同於搜尋包含特定字串的內容。domain: 和 full: 的比對範圍不同；若要精確指定目標，適合先用 full: 測試。

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

AsIs 傾向保留網域，以供網域規則判斷；若要依解析後的位址判斷，應先了解所選的網域策略何時觸發解析，以及解析結果是否會進入 IP 規則。修改此設定可能同時影響 DNS 要求量與路由比對結果，不能只依某個網站的連線結果推斷所有流量的行為。geoip:private 適用於私有位址範圍；區域網路裝置無法連線時，除了檢查這條規則，也要確認 DNS 回傳的位址，以及系統是否將區域網路流量送入用戶端。

用對照方式找出規則衝突

新增規則未生效時，先確認前面的規則是否已經比對成功，再核對規則引用的出站識別名稱。網域規則未命中時，檢查要求是否以網域形式進入、應用程式是否已自行解析，以及所需的分類資料是否可用。IP 規則未命中時，確認連線的目的位址及網域策略的處理結果。記錄中的路由目標比「網頁無法開啟」更有助於定位問題。也要避免混淆不同層級的問題：DNS 失敗發生在連線至目標之前；代理伺服器連線失敗則可能與目標網域規則無關。

要暫時測試特定網站，可將精確網域規則放在範圍較廣的分類規則之前，並先記下原本的順序。測試完成後還原順序，再分別確認直連目標、代理目標與區域網路位址。若只有其中一類失敗，就檢查該類的出站或規則；若三類都失敗，優先檢查流量入口與系統代理狀態。連線測試與實際瀏覽的差異，可參閱延遲測試說明。測速成功只代表測試涵蓋的鏈路環節可用，無法證明所有路由分支都設定正確。

更新規則集時，應留意分類意義與項目範圍，而不只是檔案是否成功載入。範圍過廣的分類可能涵蓋原本要個別處理的網域。若連線結果突然改變，先檢查近期更新的規則及比對順序，再考慮修改伺服器。為重要目標保留一條精確規則作為診斷工具，通常比長期累積大量例外規則更容易維護。設計路由時，應確保每條規則都能說明比對對象及流量出口，而不是一味增加規則數量。

DNS 設定最佳化與解析路徑

分開檢查解析、路由與連線

DNS 會將網域名稱轉換為位址，但代理用戶端還必須決定由哪個服務查詢、查詢要求經過哪個出口傳送，以及解析結果是否參與路由判斷。瀏覽器能開啟某個網站，不代表所有應用程式都使用相同的 DNS。應用程式可能使用內建解析機制，也可能快取舊結果。排查時先記錄目標應用程式的接入方式，再檢查用戶端記錄中的網域、解析錯誤與出站選擇。尚未確認流量入口前，不要同時更換系統 DNS、用戶端 DNS 和路由模式，否則很難判斷是哪個步驟改變結果。

在 v2rayN 中，圖形介面設定可能會轉換成不同的核心設定。儲存 DNS 設定後，請確認核心已重新載入，並檢查產生的設定中的 dns 與 routing。系統代理模式主要處理遵循代理設定的應用程式；系統本身的 DNS 查詢不一定會經過代理入口。TUN 模式接管的流量範圍較廣，但仍可能受應用程式自行解析的機制影響。因此，「已啟用系統代理」不代表「所有 DNS 都由用戶端處理」。要確認實際路徑，請查看要求是否進入核心，以及核心將其交給哪個出口。

明確指定查詢伺服器

以下是 Xray 核心 DNS 欄位的簡化寫法，示範備援查詢位址及特定網域規則的結構。範例位址僅用來說明欄位關係；正式使用時，應依所在網路選擇可連線且符合需求的 DNS 服務。區域網路名稱、企業內部網域及公用網域可能需要不同的查詢路徑。domains 用來決定適用的伺服器範圍，而非設定這些網域最終使用的代理出口。

{
  "dns": {
    "servers": [
      {
        "address": "localhost",
        "domains": ["geosite:private"]
      },
      "1.1.1.1"
    ]
  }
}

若區域網路裝置依賴本機解析服務，將所有查詢交給公用解析器，可能會導致內部名稱無法解析。反之，若將所有公用網域交給只認得內部名稱的解析器，也會造成逾時。排查這類問題時，先分別測試目標網域與區域網路名稱，確認故障只發生在哪一類。也要檢查路由規則是否允許 DNS 伺服器位址經由預期出口連線。解析器本身無法連線時，修改網域比對表並不能修復網路路徑。

避免快取與重複解析造成誤判

更換 DNS 後，舊連線與應用程式快取可能仍在使用原位址。驗證時，關閉相關應用程式的連線並重新發出要求；必要時分別檢查系統快取與瀏覽器行為，不要只重新整理頁面。若網域已成功解析但仍無法連線，記錄解析出的目標位址，並確認路由最後選擇直連或代理。若只有瀏覽器無法連線、其他應用程式正常，先檢查瀏覽器是否使用獨立代理或安全 DNS 設定。若只有某個命令列工具失敗，請確認其環境變數及本機 SOCKS／HTTP 連接埠。

DNS 與路由之間還有一個常見的交會點：依 IP 分類的規則需要位址，依網域分類的規則則需要保留可辨識的網域。太早將網域轉成 IP，可能使原本預期命中的網域規則失去比對條件；完全不解析，則無法使用依賴位址的判斷。選擇網域策略時，應先確認哪些目標需要網域分類、哪些目標需要 IP 分類，再觀察實際產生的設定如何運作。不要把任何一種策略視為適用所有網路的固定答案。

完成調整後，保留一組固定的測試目標：一個區域網路名稱、一個明確設定為直連的網域，以及一個明確設定為代理的網域。分別記錄解析是否成功，以及連線選擇了哪個出站。之後更新訂閱或規則集時，也用同一組目標重新測試。如此便能判斷變化發生在解析、規則比對還是遠端連線階段。若查詢正常回應，卻取得非預期的位址，請檢查本機網路提供的解析結果、應用程式快取與網域適用規則，不要只因一次網頁載入失敗就更換整套 DNS 設定。

TUN 模式與系統代理的適用範圍

選擇流量接入方式

系統代理會向支援此設定的應用程式提供本機代理入口。瀏覽器及部分桌面程式會主動連線至此入口，但並非所有程式都會讀取系統代理設定。TUN 模式則會建立虛擬網路介面，讓符合接管範圍的 IP 流量經由用戶端處理。它適合需要涵蓋更多應用程式的情境，但也會增加路由表、虛擬介面、DNS 接管及權限等變數。先用系統代理確認伺服器、訂閱與基本路由正常；確認應用程式不遵循系統代理，或確實需要擴大接管範圍後，再啟用 TUN。

v2rayN 桌面版的 TUN 設定可能需要系統權限與額外的網路元件，實際設定位置也會因系統及用戶端介面而異。啟用前先保存目前可用的狀態：作用中的伺服器、系統代理模式、DNS 設定與路由模式。啟動時留意用戶端是否回報虛擬介面建立成功，不要只看開關是否顯示為開啟。部分系統會要求授予網路延伸功能或管理員權限；若未授權，反覆切換開關通常無法解決介面建立失敗。請先處理記錄所指出的權限或元件問題。

依平台檢查網路環境

表格列出的是排查方向，不代表不同系統可以套用同一個命令。若已啟用其他虛擬網路工具，兩個程式可能都會嘗試修改預設路由或 DNS。此時先逐一關閉其他工具，再單獨啟動 v2rayN 測試。若目標應用程式在系統代理模式下可用，切換 TUN 後卻無法使用，應優先比較兩種模式下的流量入口與 DNS 路徑，不要立刻更換伺服器。伺服器未變、接入方式卻改變時，問題更可能出在本機網路接管環節。

以最小範圍驗證流量接管

啟用 TUN 後，先測試一般網頁、區域網路裝置，以及一個先前不遵循系統代理的應用程式。這三類目標對應不同的故障線索：網頁無法連線可能與解析或預設出口有關；區域網路連線失敗可能是私有位址被錯誤送往代理；特定應用程式失敗則可能與其內建網路堆疊或通訊協定有關。測試期間保持目前使用的伺服器不變。若只要切換 TUN 開關就能穩定重現問題，請檢查介面啟動記錄、路由表與 DNS 狀態，不要重新匯入訂閱。

啟用 TUN 後，其他程式仍可能使用本機代理入口，但不應因此讓同一個應用程式重複設定多種接入方式。若某個應用程式已設定手動 SOCKS，同時又由 TUN 接管，流量路徑會變得難以判斷。排錯時暫時只保留一種明確的入口；確認運作正常後，再決定是否恢復應用程式層級的設定。終端機程式也一樣：請檢查環境變數是否仍指向本機 HTTP 或 SOCKS 連接埠。停用 TUN 後，確認虛擬介面及相關路由已移除，再檢查系統網路是否恢復正常。

停用 TUN 後若仍無法連線，請依序檢查系統代理是否仍指向已停止的本機連接埠、DNS 是否仍使用無法連線的位址，以及預設路由是否已恢復。不要一次重設所有網路設定；先找出仍未復原的變更。若裝置經常在辦公室與住家網路間切換，請分別測試兩種網路的區域網路連線，因為私有位址與內部 DNS 配置可能不同。TUN 設定是否完成，不應只看開關能否維持開啟，而要確認流量接管範圍、區域網路例外與停用後的還原行為都符合預期。

FakeDNS 的用途與限制

了解合成位址的作用

在適用的流量路徑中，FakeDNS 會對網域查詢回傳暫時的合成位址，並保存該位址與原網域的對應關係。應用程式接著連線至合成位址時，核心可從對應資料還原原網域，再繼續執行網域路由。它用來解決部分網路路徑中網域資訊提早遺失的問題，並非可取代所有 DNS 伺服器的公用解析服務。合成位址也不是目標網站的真實位址；將它複製到用戶端以外的網路工具中，通常無法取得相同的連線結果。

啟用 FakeDNS 前，先確認目前遇到的問題是否確實是網域規則無法取得網域資訊。若記錄已顯示目標網域，且規則比對正常，加入 FakeDNS 只會增加設定複雜度。建議依序檢查：確認應用程式流量進入核心、DNS 要求也由相關路徑處理，再確認應用程式的連線是否回到核心。若只接管查詢而沒有接管後續連線，或只接管連線但由系統其他解析器回傳真實位址，都無法形成完整的對應鏈。

確認位址池與路由設定

以下片段展示 Xray 的 FakeDNS 位址池結構。這只是 fakedns 欄位範例，並非完整的用戶端設定；是否使用 IPv6 位址池，應配合目前的接管方式與網路環境。範例位址池不得與正在使用的實際網路衝突。還要讓相關 DNS 要求進入 FakeDNS，並確保合成位址所觸發的後續連線仍由用戶端接管。只新增這段設定而不處理流量入口，功能不會自動生效。

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

規劃位址池時，先檢查目前網路及其他虛擬網路工具的路由範圍。若合成位址落在現有的業務路由範圍內，應用程式可能會將連線送往錯誤介面。測試期間保留原有的 DNS 與 TUN 設定，並一次只啟用一項 FakeDNS 相關設定。啟用後分別測試網域目標與直接使用 IP 的目標：FakeDNS 主要用於網域對應，不應將所有 IP 連線異常都歸因於它。也要測試一個區域網路名稱，避免內部服務因解析路徑錯誤而無法連線。

排查對應資料遺失與應用程式行為

若應用程式長期快取舊的合成位址，而用戶端已重新啟動或對應資料已變更，連線可能會暫時失敗。此時先讓應用程式重新解析，再確認新要求是否經過預期的入口。有些應用程式會自行解析或直接連線至固定 IP，FakeDNS 對它們的影響可能有限。若只有一個應用程式失敗，請檢查其網路設定與 DNS 行為；若所有網域都無法連線，則檢查 DNS 接管狀態與核心記錄。不要根據瀏覽器頁面上顯示的位址判斷對應是否正確，應確認核心是否已還原目標網域。

依網域分類的路由與 FakeDNS 搭配使用時，要留意規則順序。若合成位址先被範圍較廣的 IP 規則處理，原本預期的網域分流可能無法照計畫執行。查看記錄時，分別尋找查詢、還原對應、路由命中及出站連線四個階段。缺少哪個階段，就優先檢查該階段的入口與設定。DNS 回傳合成位址只代表查詢環節正常；最終目標能否正確連線，還取決於後續連線是否進入核心，以及出站是否能連到目標。

若目前的使用情境透過一般 DNS 與現有路由即可穩定運作，可以維持較簡單的設定。FakeDNS 是用來解決特定網域可見性問題的工具，不是預設應啟用的效能選項。決定保留時，請記錄位址池、接管模式、測試應用程式及復原方式；日後修改 TUN 或 DNS 時，重新驗證完整連線路徑。決定停用時，也要讓應用程式重新解析，避免繼續使用快取中的合成位址，將舊快取誤認為停用後的新故障。

自訂出站與規則引用

出站是路由的目的地

出站描述流量離開核心的方式。常見的 freedom 出站用於直連，blackhole 出站用於封鎖；代理伺服器出站則由伺服器參數決定連線方式。路由規則會透過 outboundTag 引用出站的 tag。因此新增自訂出站時，至少要確認識別名稱不重複、規則引用正確，以及預設出站仍符合預期。為不同用途使用容易辨識的名稱，比使用含義不明的數字更方便排查記錄。

v2rayN 通常會依選取的伺服器產生代理出站。直接修改產生的檔案，可能會在切換伺服器、更新訂閱或重新啟動核心後消失。若要長期保留自訂行為，應使用用戶端提供的自訂設定或合併機制，並在儲存後檢查最終產生的結果。不同設定入口合併欄位的方式可能不同：有些會取代整個陣列，有些只會調整特定部分。操作前先備份原設定；修改後先確認核心能接受 JSON 結構，再驗證實際流量。

建立易於檢查的直連與封鎖出口

以下片段展示兩個出站與一條精確網域規則之間的引用關係。它不包含代理伺服器參數或入站設定，因此不能單獨作為完整的執行設定。範例網域僅用來說明規則結構。封鎖規則應謹慎使用，尤其在診斷期間；若範圍過廣的規則先比對到 DNS 服務或業務介面，後續規則就無法補救該連線。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "blocked",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "blocked"
      }
    ]
  }
}

測試自訂出站時，先從一條精確規則開始，確認記錄顯示預期的出站識別名稱，再逐步擴大比對範圍。封鎖規則命中時，應用程式可能會逾時或連線失敗，但這不代表代理伺服器故障。直連規則命中時，目標也可能因本機 DNS 或網路條件而無法連線。路由選擇正確，只代表流量已交給相應的出站；出站能否連線至目標，仍須另外驗證。

避免伺服器設定與出站識別名稱重複

用戶端切換目前使用的伺服器後，自動產生的代理出站內容可能會改變，但規則引用的識別名稱仍須有效。新增自訂出站前，先檢查最終設定中已有的識別名稱，避免重複定義。識別名稱重複會使記錄難以判讀，也可能讓規則使用非預期的出口。若使用多個自訂代理出口，請明確指定哪個出口用於一般目標、哪個只供特定規則使用，並確認所需的伺服器設定仍存在。不要在公開範例中貼出真實伺服器網址或憑證。

連線路徑中的本機 SOCKS 入口也要與出站分開理解。入口負責接收應用程式流量，不是遠端伺服器。以下片段只展示監聽範圍與連接埠所在欄位；將監聽位址限制在本機，可避免意外向區域網路提供代理入口。實際連接埠應與用戶端介面及使用該連接埠的應用程式設定一致。若連接埠已被其他程序佔用，核心可能無法啟動；相關排查方式請參閱本機連接埠衝突說明。

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ]
}

復原自訂設定時，先停用新增規則，再移除僅供這些規則使用的出站，最後重新載入核心。若先刪除出站，仍在生效的規則就會指向不存在的目標。復原後分別測試一個直連目標與一個代理目標，確認預設路徑未受殘留規則影響。若用戶端無法啟動，請查看錯誤訊息指出的欄位或識別名稱；不要在錯誤狀態下繼續疊加新片段。設定越複雜，就越應確保每條新增規則都有明確用途及獨立的驗證結果。

設定驗證、復原與日常維護

依連線路徑順序排查

進階設定涉及多個層級，排查時應沿著連線路徑依序進行：應用程式是否將流量交給用戶端、本機入口是否啟動、DNS 是否取得預期結果、路由是否選擇正確出站，以及出站是否能連線至目標。跳過前面的環節直接更換伺服器，可能暫時改變現象，卻無法說明原本的問題。每次只修改一個可觀察的變數，並記錄同一目標修改前後的結果。若所有應用程式都無法連線，優先檢查用戶端啟動狀態與系統代理；若只有某個網域失敗，再檢查 DNS 與規則。

記錄通常比網頁錯誤訊息提供更具體的線索，但必須配合操作時間判讀。先明確重現一次問題，再查看該時段的入口、解析、路由及連線記錄。若啟動時閃退或核心未載入，就不會產生完整的目標連線記錄；這類問題應先檢查執行環境與系統權限，可參閱啟動閃退排查。若記錄中沒有目標要求，請回頭檢查應用程式代理設定或 TUN 接管範圍，不要先修改網域規則。

準備可重現的測試項目

建議固定測試四類目標：一般網頁、依規則應直連的目標、依規則應走代理的目標，以及區域網路服務。每個目標都記錄「應用程式入口、DNS 結果、命中規則、出站、最終結果」，不要只寫「能開啟」或「無法開啟」。修改 DNS 時，重點比較解析與後續連線；修改路由時，重點比較命中規則與出站；修改 TUN 時，重點確認要求是否進入用戶端。保持測試目標不變，結果才有比較價值。

表格是排查起點，不能只憑現象直接判定原因。例如網域解析成功後，仍可能在路由階段被送往錯誤出口；出口正確，也可能因目標網路或伺服器連線問題而失敗。單次延遲數值不能取代實際連線測試，三種常見測量方式的涵蓋範圍請參閱連線測試與下載測速比較。判斷前應確認測試使用的伺服器與目前瀏覽器使用的是同一個出口。

建立最簡復原方案

每次修改前，先保存目前可正常運作的狀態：目前使用的伺服器所屬分組、路由模式、DNS 設定、TUN 狀態及新增的自訂片段。記錄設定項目即可；若完整匯出檔案包含憑證，請妥善保管。修改後若出現異常，請依變更的相反順序復原：先停用新增規則或功能，再還原 DNS 與接入方式，最後檢查系統代理狀態。每次只復原一項，並重複測試同一組目標，才能找出與故障有關的設定。

用戶端更新、訂閱更新及規則資料更新應分別記錄為三種事件，因為它們影響的項目不同：用戶端更新可能改變介面與產生設定的方式；訂閱更新會變更伺服器清單；規則資料更新則會改變分類比對。若同一天連續執行三種更新，之後發生路由異常就很難確認原因。一次完成一種更新後，先執行固定的測試項目，確認正常再進行下一種。需要安裝桌面版或 Android 用戶端時，請透過安裝檔頁面選擇相應平台，不要把下載操作混入規則排查。

向他人說明問題時，請提供作業系統、用戶端名稱、接入方式、故障環節、相關錯誤訊息及已進行的對照測試。v2rayN、v2rayNG 和 v2flyNG 的介面與核心選擇並不完全相同，請註明使用的用戶端。分享記錄前，先遮蔽訂閱網址、伺服器憑證及個人網路資訊。若問題只發生在首次匯入與連線階段，請回到快速入門教學依主要步驟重新檢查；若問題出在訂閱、路由或 TUN 的組合設定，則依本指南逐層縮小範圍。