訂閱分組、路由、DNS 與 TUN 設定

一、訂閱分組與伺服器篩選

訂閱分組解決「設定從哪裡來」，伺服器篩選則決定「清單顯示哪些內容」。兩者應分開設定：分組負責管理來源，篩選器只改變可見範圍，不應用來刪除設定。

建立穩定的分組界線

在 v2rayN 匯入多個訂閱時，請先為每個來源建立獨立分組，不要長期把所有伺服器堆在預設分組中。分組名稱應描述用途或來源，例如「日常」「辦公測試」「手動設定」，不要使用容易變動的地區名稱。地區、協定與線路標籤更適合交由篩選規則處理。如此一來，調整訂閱網址時，既有的路由與篩選邏輯不會因名稱變更而失效。

新增訂閱後，先執行一次單一分組更新，再確認該分組內是否出現設定。確認無誤後再啟用自動更新。若更新結果為空，不要立即刪除舊分組；先檢查訂閱網址是否完整、目前分組是否啟用了排除規則，以及更新請求是否需要沿用目前的系統代理。更完整的檢查順序可參閱訂閱更新失敗自我檢查清單。保留舊資料直到新資料驗證完成，可避免一次錯誤更新覆蓋可用設定。

手動新增的 VMess、VLESS、Trojan 或 Shadowsocks 設定，建議放入獨立分組。訂閱更新通常會以遠端內容為準重建清單；如果把手動設定混在訂閱分組中，後續更新時很難判斷某筆記錄來自本機還是訂閱。獨立分組也方便匯出、移轉及逐項核對傳輸參數。

包含、排除與正規表示式篩選

篩選器通常包含「包含關鍵字」與「排除關鍵字」兩類條件。包含條件用於縮小候選範圍，排除條件則用來剔除已知不需要的標籤。建議先設定排除條件，再逐步加入包含條件。若兩者同時設定，通常只有符合包含條件且未命中排除條件的記錄才會顯示。篩選只針對備註或訂閱提供的標籤，不會驗證伺服器的實際位置、協定能力或可用狀態。

簡單情境優先使用一般關鍵字。需要表達「任一項」時，可使用正規表示式中的直線，例如 家用|辦公。要比對開頭可使用 ^，比對結尾則使用 $。正規表示式中的括號、句點與加號具有特殊意義，若要直接比對這些字元，必須先進行跳脫。設定後應立即查看篩選結果數量及首尾記錄，避免表示式範圍過大。

包含：^(家用|辦公).*(VLESS|Trojan)$
排除：測試|到期|維護
說明：只顯示以「家用」或「辦公」開頭，且以指定協定標籤結尾的記錄

篩選後清單為空時，請分三個層次排查。第一層是暫時清除所有篩選條件，確認原始清單是否存在；第二層是只保留一個一般關鍵字，確認備註欄位確實包含該詞；第三層才恢復正規表示式，並逐段增加表示式內容。不要一開始同時修改訂閱網址、分組與正規表示式，否則無法判斷是哪一步造成結果變化。

排序、選擇與更新後的穩定性

伺服器排序只是介面顯示順序，不等同於路由優先順序。依備註、位址或協定排序後，目前選取的伺服器仍由用戶端狀態決定。訂閱更新可能改變清單順序，也可能重建記錄識別碼，因此不要把「第幾列」當作長期選擇條件。更穩定的做法是使用清楚的備註、固定分組與可重複的篩選規則。

完成分組後，分別檢查每組的更新方式、自動更新開關與篩選條件。經常使用的分組可以啟用定時更新；臨時測試分組適合手動更新，避免遠端變更頻繁干擾比對測試。更新前後若伺服器數量差異明顯，應先查看用戶端日誌與篩選結果，再決定是否切換目前設定。

二、路由規則實戰與比對順序

路由規則負責將連線送往不同出站。判定結果取決於目標資訊、規則順序與出站標籤。設定時應先定義策略，再填寫語法。

理解由上而下的命中流程

路由引擎通常會由上而下檢查規則，第一條符合條件的規則決定出站，後續規則不再參與。精確規則應放在前面，範圍較大的規則放在後面，最後保留明確的預設策略。例如，區域網路位址直連應位於大範圍代理規則之前；指定網域的直連或阻擋規則，也應放在分類集合之前。若把涵蓋範圍很廣的規則放在頂端，後續細分規則即使語法正確也不會生效。

常見的比對對象包括網域、IP、連接埠、網路類型與程序。網域規則可使用完整網域、後綴、關鍵字或 geosite 分類；IP 規則可使用單一位址、CIDR 網段或 geoip 分類。連接埠只描述目標連接埠，無法判斷應用程式類型。程序比對取決於系統與用戶端是否能取得程序資訊，跨平台移轉時不能將其視為唯一條件。

一套可解釋的基礎順序

基礎分流可以從三層開始。第一層處理私有位址，避免印表機、路由器與區域網路服務進入遠端出站；第二層處理明確的網域分類；第三層設定預設代理出站。不要一次加入大量來源不明的規則集。規則越多，優先順序衝突越難定位，資源更新也越難管理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 決定網域規則未命中時是否繼續解析 IP。使用 IPIfNonMatch 時，路由會先嘗試網域規則，未命中後再透過 DNS 取得位址並檢查 IP 規則。這適合同時使用 geosite 與 geoip 的設定。若選擇只依網域判斷，依賴目標 IP 的規則可能無法參與；若預先解析所有網域，則會增加 DNS 查詢並改變連線時序。

規則未生效時如何定位

先確認實際目標是網域，還是已解析完成的 IP。瀏覽器通常會提交網域，而部分應用程式會自行解析後直接連線至 IP，此時網域規則看不到原始名稱。其次確認規則命中的出站標籤確實存在；在標籤區分大小寫的情況下，proxy 與 Proxy 會被視為不同目標。再次檢查規則順序，尤其確認頂端是否有涵蓋所有連接埠、所有網路或大範圍網域的規則。

測試單一規則時，應暫時縮小條件。例如將分類規則替換成一個完整網域，將日誌層級調整至能觀察路由判定的位置，建立一次新連線，再確認所選出站。既有連線可能會重用舊鏈路；修改規則後，應關閉對應應用程式的連線或重新啟動用戶端核心。只重新整理頁面不一定會建立新連線。

UDP 與 TCP 可以使用不同規則，但必須先了解應用程式行為。網域解析通常涉及 UDP，也可能回退至 TCP；即時通訊可能同時使用多個目標連接埠。若只允許 TCP 進入某個出站，相關 UDP 請求可能走預設規則，形成「頁面能開啟但部分功能異常」的現象。排查時應同時觀察網路類型、目標連接埠與最終出站，不要只看網域。

三、DNS 設定最佳化與查詢路徑

DNS 設定不只是填入伺服器位址，還需要同時回答三個問題：誰發起查詢、查詢經過哪個出站，以及回應結果如何參與路由。

區分系統解析與核心解析

在系統代理模式下，部分應用程式會自行呼叫系統 DNS，再將解析後的 IP 交給代理；另一些應用程式則會直接把網域交給代理用戶端。兩類請求進入核心時所攜帶的資訊不同。前者可能只剩 IP，路由只能依靠 geoip 或網段規則；後者保留網域，便能先使用 geosite、後綴與完整網域規則。同一網站在不同應用程式中走向不同出站時，應先檢查解析是在應用程式端還是核心端發生。

TUN 模式能接管更多系統流量，也更容易統一 DNS 路徑，但仍要避免系統 DNS、TUN DNS 與瀏覽器內建解析策略互相競爭。設定目標不是讓所有查詢都使用同一台伺服器，而是讓查詢結果與路由策略一致。例如計畫依網域分類分流，就應盡量保留網域資訊；計畫依目標 IP 分流，則要確保用於判斷的解析結果穩定可用。

伺服器類型與比對條件

DNS 伺服器可以依網域條件分組。針對直連網域的查詢，可使用本地網路可達的解析服務；其他查詢則可沿代理出站傳送。設定時要明確知道伺服器位址本身如何解析與連線。如果加密 DNS 的主機名稱還需要另一次 DNS 查詢，必須為它準備可達的引導解析位址，否則會形成循環依賴。

queryStrategy 用於控制回傳 IPv4、IPv6 或兩者。選擇時應以目前網路與目標服務的實際可達性為準。只回傳 IPv4 能減少雙堆疊環境中的不確定分支，但會排除僅提供 IPv6 的目標；同時回傳兩者，則要求系統路由與出站鏈路都能正確處理雙堆疊。不要只因日誌中出現某類位址，就強制關閉另一類；應先測試本地網路是否具備穩定連線。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

expectIPs 用於驗證回應位址是否符合預期分類。它不是強制將結果改成某個地區，而是在回應不符合條件時，讓解析流程嘗試其他候選伺服器。skipFallback 表示該伺服器不參與一般回退流程，適合只服務明確網域集合的解析器。具體欄位是否支援，取決於目前使用的核心設定格式；匯入自訂片段前，應先查看 v2rayN 產生的完整設定與啟動日誌。

快取、回退與污染型錯誤的辨別

修改 DNS 後結果若未立即改變，可能是瀏覽器、系統、用戶端核心或上游解析器仍保留快取。排查時先關閉測試應用程式的現有連線，再重新啟動核心；必要時清除系統 DNS 快取。不要在連續重新整理同一頁面後，只憑一次結果下判斷，因為連線池與快取可能繞過新設定。

解析異常通常分為逾時、回傳空記錄、回傳無法連線的位址，以及回傳類型不符。逾時應檢查 DNS 請求使用的出站與防火牆；空記錄要確認網域本身及查詢類型；無法連線的位址要檢查路由表與目標網路；類型不符則檢查 queryStrategy。若日誌顯示解析成功但連線失敗，問題通常已從 DNS 層轉移到路由、出站或傳輸層。

評估 DNS 設定時，至少選擇三類目標：明確直連的網域、明確經代理的網域，以及只提供特定位址族的測試目標。分別記錄解析結果、命中規則與最終出站。只測試一個常用網站，無法證明回退順序與邊界條件正確。

四、TUN 模式的接管範圍與系統路由

系統代理只會影響主動讀取代理設定的應用程式；TUN 模式則透過虛擬網路介面接管更廣泛的流量。兩者不是單純的強弱關係，而是不同的接入方式。

何時需要啟用 TUN

瀏覽器、下載工具與多數桌面應用程式能讀取系統代理時，優先使用系統代理，路徑較短，也方便單獨停用。遊戲啟動器、命令列程式、部分商店元件或固定直連的應用程式不讀取系統代理時，才需要考慮 TUN。啟用前先確認一般系統代理設定已可正常使用，否則在基礎鏈路尚未驗證時增加虛擬網卡與路由表，只會擴大排查範圍。

TUN 啟動後，用戶端會建立虛擬介面，並依設定寫入系統路由。流量先抵達虛擬介面，再由核心判斷路由與出站。DNS 也可能被重新導向至核心處理。關閉用戶端時應恢復原有路由；若程序異常結束，可能留下暫時介面或路由狀態，表現為用戶端已關閉但網路仍異常。此時先重新啟動用戶端並正常關閉 TUN，再檢查系統網路設定。

常見參數說明

stack 表示 TUN 使用的網路堆疊實作。不同實作對 TCP、UDP、雙堆疊與系統相容性的側重點不同。正常情況下保留用戶端建議值，只有在特定應用程式無法建立連線、UDP 異常或高負載時，才逐項切換測試。切換網路堆疊後需要完整重新啟動核心，既有連線不會自動轉移。

autoRoute 用於自動新增路由，讓目標流量進入虛擬介面。關閉後需要自行維護系統路由，適合已有明確網路拓撲的環境，不適合初次設定。strictRoute 用於更嚴格限制繞道路徑，可減少部分流量脫離 TUN，但也可能影響區域網路探索、虛擬機或其他網路工具。mtu 控制單一封包的最大傳輸單位；設定過大可能在部分鏈路上造成分片或丟包，設定過小則會增加額外開銷。

區域網路、虛擬機與其他網路工具

啟用 TUN 後若無法存取路由器管理頁面、網路儲存裝置或印表機，先確認 geoip:private 是否設為直連，並檢查嚴格路由是否攔截本地網段。區域網路可能使用不常見的私有網段，不能只依賴分類資料；必要時可為實際網段新增 CIDR 直連規則，例如 192.168.50.0/24。規則必須位於預設代理規則之前。

虛擬機、容器與企業網路用戶端也會寫入路由表。多個工具同時啟用時，系統可能依據前綴長度與躍點值選擇不同介面。不要反覆開關所有工具碰運氣。先記錄 TUN 啟動前後的路由表差異，再關閉其他會修改網路堆疊的軟體，確認單獨執行時是否正常。若單獨執行正常，再逐一恢復其他元件。

從睡眠喚醒、網路由有線切換至無線，或從家庭網路切換至辦公網路後，原有介面索引可能改變。出現連線停滯時，先關閉 TUN，等待虛擬介面退出，再重新啟用。若用戶端持續提示建立介面失敗，需要檢查執行權限、系統網路元件狀態，以及是否存在同名殘留介面。

五、FakeDNS 的運作方式與適用範圍

FakeDNS 會為網域暫時分配保留位址，讓只攜帶目標 IP 的連線仍能恢復原始網域。它主要用來解決網域資訊在應用程式解析階段遺失的問題。

從查詢到連線的對映流程

啟用 FakeDNS 後，被接管的 DNS 查詢不會立即將真實目標位址交給應用程式，而是回傳專用位址池中的暫時位址。應用程式接著連線至該位址，核心依據對映表找回原始網域，再執行網域路由與真實解析。這讓 TUN 情境中的網域規則更穩定，因為即使應用程式先解析再連線，核心仍能知道該連線最初對應的名稱。

暫時位址只有在目前對映有效期間內才有意義，不能將它視為目標伺服器的真實位址加以保存、分享或寫入長期規則。如果應用程式長時間快取解析結果，而核心對映已經過期，連線可能會失敗。重新啟動應用程式或清除其 DNS 快取，通常能建立新的對映。用戶端核心重新啟動後，舊的暫時位址也可能不再對應原網域。

位址池與例外網域

FakeDNS 位址池不能與目前的區域網路、虛擬機網路、容器網路或其他通道位址段重疊。發生重疊時，系統可能將暫時位址送往錯誤介面，日誌中甚至看不到連線進入核心。選擇位址池前，應查看本機路由表與常用網路環境，而不只是檢查目前的無線網路。

並非所有網域都適合使用 FakeDNS。區域網路裝置名稱、企業內部網域、需要由特定系統解析器處理的名稱，以及依賴真實 IP 進行本機判斷的應用程式，都可以加入例外。例外清單應保持精確，優先填寫完整網域或明確後綴。將範圍過大的分類全部排除，會削弱 FakeDNS 恢復網域的作用。

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

198.18.0.0/15 常用於基準測試網路，不應直接理解為任何真實目標的位置。設定前仍需確認它未被目前的虛擬網路佔用。poolSize 決定可維護的對映數量，日常桌面使用通常不需要盲目擴大。過大的位址池不會提升單次解析速度，反而會讓衝突範圍更難檢查。

與真實 DNS、嗅探及路由的關係

FakeDNS 不會取代真實 DNS。它先向應用程式回傳暫時位址，核心準備建立連線時仍需取得目標的真實位址。真實解析所使用的伺服器、查詢策略與出站路徑，仍由 DNS 設定決定。若真實解析逾時，應用程式看到的現象可能是連線暫時位址失敗，因此排查時要同時查看 FakeDNS 對映與後續解析日誌。

協定嗅探也能從部分流量中恢復網域，例如從 TLS 握手或 HTTP 請求讀取主機資訊，但它取決於流量中是否存在可識別欄位。FakeDNS 則在建立連線前透過對映恢復網域，兩者的工作階段不同。啟用其中一項不代表另一項也必須開啟。設定應以日誌中實際缺少的資訊為依據，而不是同時開啟所有相關選項。

要判斷 FakeDNS 是否適用，可以先選擇一條明確的網域規則，在未啟用時觀察 TUN 連線是否只能命中 IP 規則；接著啟用 FakeDNS，清除應用程式快取並建立新連線，查看日誌是否恢復網域及命中預期出站。若網域已能穩定傳入核心，額外啟用 FakeDNS 的效益有限。

六、多訂閱管理與更新治理

多訂閱管理的重點不是匯入更多位址，而是讓更新、篩選、切換與回退都能追蹤。每個訂閱都應有獨立界線與明確用途。

命名、更新與責任分離

訂閱名稱建議包含用途與來源類別，例如「日常主用」「臨時測試」「手動封存」。不要把更新時間寫入名稱，時間很快會失效，也會讓自動化篩選變得困難。若同一來源提供不同協定或用途的訂閱，仍應分開匯入，讓每組都能獨立更新與停用。

不宜讓所有分組都使用完全相同的短週期自動更新。主用分組依穩定週期更新，測試分組手動觸發，暫時不用的分組可以關閉自動更新但保留位址。更新時用戶端需要存取訂閱網址；若該請求依賴目前代理，應確認「更新訂閱時使用代理」或對應選項與目前網路一致。目前伺服器失效時，依賴它更新訂閱可能形成循環，因此應保留可直接存取更新網址的路徑，或可手動恢復的舊設定。

執行批次更新前，先單獨更新一個分組並觀察結果。需要檢查的不只是是否提示成功，還包括記錄數量是否異常、備註是否變更、協定欄位是否完整，以及篩選器是否仍能命中。遠端訂閱格式變更時，用戶端可能完成下載但解析結果為空；成功取得與成功產生伺服器清單並不是同一回事。

去重與衝突處理

不同訂閱可能包含位址、連接埠與協定相同但備註不同的記錄，也可能備註相同而傳輸參數不同。只依備註去重容易誤刪有效設定，只依位址去重又會忽略連接埠、使用者識別、傳輸層與安全參數。長期管理時，應將協定、位址、連接埠、身分欄位、傳輸方式與安全設定視為一組設定指紋，依用戶端實際顯示的欄位逐項比較。

發現重複記錄後，不必立即刪除來源。先確認哪個分組負責長期更新，另一個分組是否只是臨時備份。刪除單筆記錄可能在下次訂閱更新後再次出現，真正的管理位置通常是分組篩選或訂閱來源。遇到備註衝突，可在用戶端允許的範圍內使用分組前綴區分，而不是修改遠端產生的核心參數。

安全回退與移轉

更換訂閱來源或調整大範圍篩選前，先匯出目前的用戶端設定與路由設定。匯出檔案應存放在受控位置，其中可能包含訂閱網址與伺服器驗證資訊，不適合公開分享。恢復時先匯入新分組，不要直接覆蓋正在使用的分組。驗證連線、路由與 DNS 後，再停用舊來源。

跨裝置移轉時，需要區分「伺服器設定」與「用戶端偏好」。伺服器連結通常不包含系統代理模式、TUN 參數、路由規則、DNS、自動啟動與介面篩選等設定。只匯入訂閱並不能完整複製工作環境。建議使用一份移轉清單，分別記錄訂閱分組、目前伺服器、路由規則、DNS、TUN、自動更新週期與自訂出站。

v2rayN 適用於 Windows、macOS 與 Linux 桌面環境；Android 可使用 v2rayNG，或依核心需求選擇 v2flyNG。不同用戶端的選單結構與可匯入欄位並不完全相同。移轉路由時，應轉換為目標用戶端支援的規則表達方式，而不是假設整份桌面設定可以原樣使用。用戶端入口與平台說明可在下載頁面查看。

七、自訂出站與鏈式選擇

出站定義連線最終如何離開核心。常見標籤包括代理、直連與阻斷。自訂出站的關鍵是標籤唯一、引用一致，並避免形成循環。

出站標籤與路由引用

每個出站都透過 tag 被路由規則引用。標籤應使用簡短且穩定的英文名稱，例如 proxy、direct、block 或 dns-out。修改標籤後，所有路由規則、DNS 出站引用、鏈式代理設定與統計策略都要同步調整。啟動日誌中的「找不到出站」通常是因為拼寫不一致，或設定合併時標籤被覆蓋。

直連出站用於透過本機網路直接建立連線，阻斷出站則用於明確拒絕符合條件的流量。阻斷規則應保持精確，先從完整網域或特定連接埠開始測試。範圍過廣會讓一般連線表現為無回應，而不是顯示清楚的錯誤。代理出站通常由目前伺服器設定產生，手動編輯時不要遺漏傳輸、安全與身分欄位。

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

freedom 出站的 domainStrategy 決定直連階段如何處理網域。若路由階段已完成解析，出站可能直接使用取得的位址；若仍保留網域，出站會依策略進行解析。此設定要與全域 DNS 及路由策略協調，避免同一網域在不同階段得到不一致的結果。

自訂出站的實際用途

獨立直連出站可以繫結特定介面或位址，用於多網卡環境；獨立阻斷出站可以處理明確不需要的目標；DNS 專用出站可以讓解析請求走指定鏈路。每增加一個出站，都應記下它的入口規則、依賴條件與回退方式。只有出站而沒有任何路由引用時，它不會自動參與連線。

繫結多張網卡時，要確認所選來源位址確實屬於目前的活動介面。網路切換後，舊位址可能失效，表現為只有繫結的出站無法連線。需要長期在不同網路間移動的裝置，不宜固定容易變動的來源位址。較穩妥的方式是交由系統路由決定出口，只有在確實需要介面隔離時才進行繫結。

鏈式出站與循環風險

鏈式代理表示某個出站的連線再透過另一個出站建立。它適合具有明確上游關係的情境，但會增加握手、解析與故障點。設定前先分別驗證每一段都能獨立運作，再組合鏈路。若基礎出站本身不穩定，鏈式設定只會讓錯誤更難判斷。

鏈式關係不能形成閉環。例如 A 透過 B 建立連線，而 B 的連線又被路由回 A，就會不斷遞迴直到失敗。避免循環需要為上游伺服器位址設定更精確的直連或指定出站規則，並放在一般代理規則之前。若上游位址使用網域，還要考慮該網域解析請求應走哪個出站。

測試鏈式出站時，先檢查日誌中的連線順序，再確認目標請求與上游連線分別命中了哪條規則。不要只根據最終頁面是否開啟來判斷設定正確，因為系統可能繞過預期鏈路而使用預設出站。關閉預設回退進行短時間測試，有助於找出遺漏；測試結束後應恢復可控的兜底策略。

建立完整自訂設定前，建議保留 v2rayN 自動產生的設定作為對照。先匯出產生結果，找到 outbounds、routing 與 dns 三個區塊，再以最小變更加入新標籤。儲存後查看核心啟動日誌，確認設定解析成功。若啟動失敗，先撤回最近加入的一個區塊，不要同時重寫整個結構。

八、設定驗證、日誌讀取與回退流程

完成進階設定後，需要透過分層測試證明每個環節有效。測試順序應從設定載入開始，依序檢查解析、路由、出站與系統接管。

先確認核心接受設定

儲存設定不代表核心已經使用新設定。第一步查看啟動日誌，確認設定檔可以解析、連接埠沒有衝突、引用的出站標籤存在，以及資源檔案可以讀取。語法錯誤通常會指出欄位位置或附近結構。遇到錯誤時，從最近一次變更開始撤回，特別檢查 JSON 逗號、陣列與物件層級、標籤拼寫，以及不受支援的欄位。

核心成功啟動後，確認本機監聽連接埠與系統代理指向一致。若用戶端狀態顯示正在執行，但應用程式無法連線，可能是系統代理仍指向舊連接埠，或另一個程式佔用了監聽位址。TUN 模式還要確認虛擬介面已建立、路由表已寫入，以及 DNS 接管沒有失敗。

分層測試，不要用單一結果取代所有結論

第一層測試訂閱與伺服器設定：選擇一筆已知可連線的記錄，暫時使用最小路由。第二層測試 DNS：分別查詢直連網域與代理網域，記錄回傳類型及使用的解析器。第三層測試路由：為一個完整網域加入暫時規則，從日誌確認命中。第四層測試系統接管：先使用系統代理，再啟用 TUN。每層通過後，再增加下一層設定。

延遲測試只能說明特定探測方式當下是否收到回應，不能取代真實連線。某些伺服器允許實際協定連線卻不回應簡單探測，也可能探測正常但目標連線失敗。判斷設定時應結合核心日誌、連線建立結果與應用程式行為，而不是只看清單中的單一狀態。

修改規則後要建立新連線。瀏覽器連線池、DNS 快取與應用程式背景程序可能繼續重用舊鏈路。可靠的測試方式是關閉測試應用程式，等待連線釋放後再重新開啟；必要時重新啟動核心。若問題只在睡眠喚醒或網路切換後出現，應將網路狀態變化納入重現步驟。

建立最小可用設定

最小設定包含一台可用伺服器、一個代理出站、一個直連出站、私有位址直連規則，以及明確的預設策略。DNS 使用簡單且可達的伺服器，暫不啟用 FakeDNS、鏈式出站與複雜的程序規則。若最小設定正常，再依「訂閱篩選、網域路由、條件式 DNS、TUN、FakeDNS、自訂出站」的順序逐項恢復。

每恢復一項，都記錄變更內容、測試目標與結果。設定筆記不需要保存驗證欄位，只需記錄開關、標籤與規則順序。如此一來，在後續更新核心或移轉裝置時，就能判斷問題來自版本行為變化、系統網路變更，還是本機規則調整。

驗證清單
1. 核心啟動日誌沒有設定解析錯誤
2. 目前伺服器與本機監聽連接埠正確
3. DNS 查詢回傳預期的位址類型
4. 測試網域命中預期的路由規則
5. 目標連線進入正確出站
6. 關閉系統代理後網路恢復
7. 關閉 TUN 後虛擬介面與暫時路由退出

常見現象的定位方向

所有應用程式都無法連線時，先檢查核心、監聽連接埠與伺服器設定。只有某個應用程式異常時，檢查它是否讀取系統代理、是否自行解析 DNS，以及是否使用 UDP。只有區域網路異常時，檢查私有網段直連與嚴格路由。網域規則未命中時，檢查應用程式是否只提交 IP，以及 FakeDNS 或嗅探能否恢復網域。訂閱更新成功但清單為空時，檢查解析結果與分組篩選。

若日誌資訊不足，可以暫時提高日誌層級完成重現，記錄一次完整連線後恢復一般層級。長期保留過細的日誌會增加檔案大小，也會讓關鍵錯誤被大量正常記錄淹沒。分享日誌前，應移除訂閱網址、使用者識別、伺服器驗證參數與本機檔案路徑。

仍無法定位時，先查閱FAQ 故障排查，再對照v2rayN 主介面功能速覽確認設定位置。協定欄位之間的差異可參考VMess、VLESS、Trojan 與 Shadowsocks 對照。提交問題描述時，應包含作業系統、用戶端名稱、接管模式、重現步驟與經處理的錯誤日誌，不要只寫「無法使用」。