v2rayN 設定指南

第一階段：核心概念

了解介面、核心與遠端服務的分工

先將連線拆解為三個部分。v2rayN 是圖形化用戶端，負責儲存節點、管理訂閱、產生設定並啟動核心；核心負責監聽本機連接埠、處理協定、查詢網域名稱及選擇輸出；遠端服務則接收連線並轉送請求。安裝用戶端不會自動取得可用節點，填入訂閱也不代表遠端服務已可使用。排查問題時分別確認這三個環節，才能避免把遠端故障誤判為介面設定問題。

了解 Project V、V2Fly 與 Xray 的關係。Project V 是相關工具與協定的生態背景，V2Fly 延續 V2Ray 的開發，Xray 則是相關核心分支。用戶端可透過不同核心建立連線，但「支援某種協定」不代表支援該協定的所有傳輸與安全組合。匯入成功只表示設定格式可辨識，還需確認實際使用的核心能否解析產生的欄位，並與伺服器成功協商。

沿著一次請求了解各項參數

從應用程式發出請求開始追蹤連線路徑。讀取系統代理設定的瀏覽器會先連到本機監聽連接埠；核心收到目標網域名稱或位址後，依規則選擇直連、代理或阻擋。接著由代理輸出連至節點伺服器，完成相應的交握程序。使用 TUN 時，流量改由虛擬網路介面進入，但後續仍須進行路由判斷並具備可用的輸出。因此，變更流量接管方式，無法修正錯誤的節點位址、認證資訊或傳輸參數。

閱讀節點參數時，可分成幾個部分。伺服器位址與連接埠決定連線目標；使用者識別碼或密碼用於身分驗證；傳輸類型決定資料的承載方式；TLS、REALITY 等設定則決定相應的安全交握方式。VMess、VLESS、Trojan、Shadowsocks 是不同協定，REALITY 並非與這些協定並列的訂閱格式。請依服務提供者提供的完整組合填寫參數，不要只因名稱相似就互換欄位。

建立可觀察的判斷依據

區分網域名稱解析、傳輸連線與應用程式回應。解析失敗時，請求可能尚未送達節點；連線遭拒通常需檢查監聽狀態或遠端連接埠；交握錯誤則應核對安全參數與系統時間；網頁回傳錯誤狀態也可能是目標服務所致。不要把所有狀況都概括成「代理沒開」。先記錄發生問題的應用程式、目標、時間與模式，再查看同一時間的核心記錄。

了解測試結果的限制。清單中的連線測試只涵蓋用戶端採用的測試方式，不代表所有網站、應用程式與網路環境都能正常使用。某個測試目標受到限制時，測試可能失敗，但實際服務仍可存取；反過來說，測試成功也不能證明網域解析、長連線與檔案傳輸都正常。請另外保留一個實際網頁與一個實際應用程式作為驗證樣本。

完成本階段時，試著不使用介面名稱來描述連線路徑：哪個應用程式透過哪個入口，把什麼目標交給哪個核心，再由哪條輸出路徑送出。能回答這些問題後，再查閱概念速查補足術語。後續章節都以這條路徑為主軸，不必一次記住所有協定欄位，也不需要在尚未成功連線時就加入複雜規則。

第二階段：選擇用戶端

先依作業系統與處理器架構篩選

桌面平台建議優先選用 v2rayN，再依作業系統與處理器架構前往用戶端下載頁。Windows 使用者可先到「設定 → 系統 → 系統資訊」查看系統類型；macOS 使用者請在「關於這台 Mac」查看晶片或處理器；Linux 使用者則需確認發行版套件格式與機器架構。不要只憑電腦品牌挑選安裝套件，也不要因介面相似就認為不同平台的套件可以互換。

在 Windows 下載區，請分辨桌面版與經典 WPF 版。桌面版採用跨平台介面，適合希望在多種桌面系統上維持相近操作方式的使用者；WPF 版則專為 Windows 設計，保留經典介面與操作習慣。兩者都應依各自套件說明確認執行需求。不要只憑「新版」或「經典版」判斷一定具備某項功能；選單位置、設定範圍與執行環境都可能因發行分支而異。

確認核心能力符合現有設定

Android 建議優先使用採用 Xray 核心的 v2rayNG，也可選用採用 V2Fly 核心的 v2flyNG。選擇時應考量現有節點使用的協定與功能，而非安裝多款用戶端後反覆切換。兩款應用程式的設定不一定完全相同；即使匯入方式相似，也不表示設定資料庫可以直接複製。初次使用可先閱讀Android 入門步驟，並只保留一個正在運作的網路接管入口。

區分用戶端功能與訂閱內容。更換用戶端不會自動將一般節點轉成另一種安全組合，也無法補上伺服器未提供的參數。匯入後若發現欄位缺漏，請先確認訂閱適用的用戶端類型、是否提供完整連結，以及節點所需的核心。不要為了完成匯入就任意刪除參數；簡化後雖能儲存的設定，可能要到實際交握時才會顯露不相容。

遷移前保留可還原的工作環境

準備更換桌面介面時，先在舊環境記錄訂閱群組、目前使用的節點、監聽連接埠、路由模式與 DNS 設定，再匯出用戶端支援的備份。請將新環境視為獨立安裝，先用一個節點驗證基本連線。不要同時執行兩套用戶端並占用相同監聽連接埠，也不要讓兩者輪流修改系統代理，否則介面顯示的模式可能與系統實際生效的位址不同。

評估執行需求時，請分開檢查介面啟動與流量接管。主視窗能開啟，不代表核心已成功啟動；核心能啟動，也不代表目前帳戶有權建立虛擬網路介面。一般系統代理通常不需要讓整套程式長期以系統管理員權限執行；TUN 則可能需要提高權限或使用相應的服務機制。請依目標功能授權，不要把提高權限當成所有錯誤的通用解法。

選定後，請明確記下作業系統、處理器、所選用戶端及預計採用的入口模式。接著查看下載頁上該平台的需求，避免安裝到一半才臨時更換方案。若要比較兩種桌面介面，可閱讀v2rayN 桌面版與 WPF 版的差異，著重確認系統支援與功能差異，而不只是外觀。

本階段的驗收重點是「選對套件」，而非「開啟所有功能」。先滿足目前裝置與既有節點的需求，保留一套簡單且可重複使用的連線方案。之後若需接管更多應用程式或調整規則，再加入相應功能；如此也能大幅縮小故障後的檢查範圍。

第三階段：安裝與首次啟動

準備固定目錄與執行環境

從Windows 用戶端下載頁選取已確認的版本類型，再依安裝套件的實際形式操作。若是安裝程式，請依照精靈完成安裝；若是壓縮檔，先解壓縮至固定目錄再執行程式，不要直接從壓縮檔視窗啟動。持續使用的資料目錄不宜放在會定期清理的位置。程式需要儲存設定、記錄與核心檔案，目錄是否可寫入比路徑名稱是否簡短更重要。

首次啟動時若提示缺少執行元件，請依目前發行套件的說明安裝相應元件，不要根據舊教學隨意安裝架構不符的版本。記下提示中的完整名稱，並分辨是缺少執行環境、檔案遭封鎖，還是核心無法啟動。若系統顯示安全性警告，請先確認來源與檔案資訊，再決定如何處理；不應只為了開啟介面就全面關閉系統防護，或允許所有未知程式執行。

確認介面與核心是否分別啟動

開啟主視窗後，先找到記錄或資訊區域。此時尚未加入節點，無法建立連線是正常情況；請著重檢查是否發生設定讀取失敗、路徑無法寫入或監聽失敗。介面能正常回應，只表示圖形程式運作正常，不代表核心已開始監聽。新增節點後，再次查看啟動資訊，確認核心沒有立即結束或不斷重新啟動，之後才設定系統代理，避免瀏覽器指向尚未運作的連接埠。

查看「設定」中的本機監聽項目，記下位址、連接埠及支援的入口協定。不同版本可能提供混合入口，也可能分別提供 HTTP、SOCKS 入口，不要根據舊文章猜測目前的預設連接埠。通常只需讓本機應用程式透過回送位址連線。開啟允許區域網路連線會擴大可存取範圍，只有確實需要與其他裝置共用時才啟用，並同時評估防火牆與存取限制。

Get-NetTCPConnection -State Listen |
  Sort-Object LocalPort |
  Select-Object LocalAddress, LocalPort, OwningProcess

以上命令會列出目前的 TCP 監聽連接埠與程序識別碼，不會變更網路設定。將結果中的連接埠與介面記錄對照，再到工作管理員的「詳細資料」查看對應程序。若連接埠已被其他程式占用，請優先結束重複執行的用戶端；確實需要同時執行時，再修改其中一個監聽連接埠，並同步更新依賴該連接埠的應用程式。不要看到不熟悉的程序就直接結束工作。

保存啟動基準與退出方式

先暫時關閉開機啟動、自動更新訂閱與 TUN 等附加功能，完成一次手動啟動與退出。退出前清除系統代理，退出後確認瀏覽器仍可透過原本的網路方式連線。這個步驟可驗證還原方式：即使之後節點故障，也知道如何讓系統不再使用本機代理入口。關閉主視窗可能只會將程式縮到系統匣，請透過系統匣選單確認程式是否真正結束。

其他桌面系統也可依相同順序驗收：程式能否啟動、資料能否儲存、核心能否載入、監聽是否衝突，以及退出後能否還原。macOS 請依晶片選擇安裝項目，Linux 則依發行版套件格式安裝；遇到權限問題時，檢查目前的安裝位置與系統提示，不要一律放寬所有檔案權限。若要進一步排查監聽連接埠衝突，可閱讀本機連接埠遭占用的處理方式。

完成本階段後，簡要記錄安裝位置、資料備份方式與監聽設定。重新啟動一次用戶端，確認設定仍然存在。只有基準狀態穩定，後續匯入訂閱或調整規則時的結果才有比較價值，也不會把安裝層的不穩定誤認為網路變化。

第四階段：訂閱與節點管理

新增群組，再更新訂閱

開啟「訂閱群組設定」，新增容易辨認的群組名稱，再將服務提供者給的訂閱網址貼到對應欄位。檢查網址前後是否有空白、換行或複製時帶入的標點。訂閱連結可能包含存取憑證，請妥善保管，不要放進公開截圖、筆記或問題回報中。儲存群組後返回主畫面，選取該群組，再執行「更新目前訂閱（不透過代理）」。

了解不同更新方式的差異。「不透過代理」通常適用於本機尚未建立代理，或訂閱網址可直接連線的情況；透過代理更新則需要現有的可用連線路徑。若直接更新失敗，先確認目前網路能否連到訂閱網址，再判斷是否需要改用既有代理。完全沒有可用節點時，不要指望透過代理更新來解決首次取得節點的問題，否則會形成相互依賴。

分辨取得失敗與解析失敗

查看更新結果時，先判斷是否已取得內容。網域名稱無法解析、連線逾時及服務拒絕請求，屬於取得階段的問題；若已收到內容卻沒有節點，則可能是格式不適用、回應實際上是登入頁面，或節點參數無法辨識。能開啟網頁不代表取得的是訂閱內容。聯絡服務提供者時，只需提供錯誤類型及已去識別化的回應說明，不要提交完整訂閱網址或身分參數。

更新成功後，請在節點清單核對名稱、協定、位址與所屬群組。名稱相同不代表是同一組設定，節點名稱也無法反映實際網路品質。選取一個節點並設為作用中伺服器，再確認核心能否成功載入。不要一次平行測試大量節點，以免測試本身占用頻寬、觸發服務限制，或讓短時間的結果掩蓋實際使用時的穩定性。

處理手動節點與訂閱更新的覆寫

使用單一分享連結時，透過用戶端提供的剪貼簿匯入功能新增，並核對匯入欄位。手動節點適合臨時測試或少量設定；訂閱群組則適合由服務提供者集中更新。不要直接編輯訂閱節點後就認為變更會永久保留，下次更新時可能會重新建立記錄。若要長期自訂，請先複製到獨立的手動群組，並清楚標示該群組不會隨原訂閱同步。

刪除群組前，請確認操作影響的是群組記錄、訂閱節點，還是全部伺服器，避免混淆測試群組與日常使用的群組。訂閱更新後節點數量減少，不一定是匯入失敗，也可能是服務提供者調整了可用項目。先查看更新結果與群組篩選條件，再確認是否選錯群組。還原舊備份只能恢復本機記錄，無法保證已失效的遠端服務重新可用。

核對安全相關參數時，請確保伺服器位址、連接埠、使用者識別碼、傳輸類型、伺服器名稱與對應的金鑰參數彼此一致。不要為了排除交握錯誤就任意關閉憑證驗證，也不要將一個節點的安全欄位複製到另一個節點。系統時間明顯不正確也可能影響交握，請先校正裝置時間再測試。只有確認伺服器端要求後，才手動調整欄位。

安排更新頻率時，請依服務提供者調整設定的頻率而定。頻繁更新不會自動提升速度，反而可能覆蓋正在排查的狀態。重要調整前先備份本機資料並記下目前使用的節點；更新後以相同目標重新驗證。如此可分辨「內容變更」與「連線暫時失敗」，也方便保留當下狀態以便繼續排查。

本階段的完成標準是：能說明訂閱來源、節點所屬群組、目前啟用的記錄，以及下次更新會覆寫哪些內容。基本匯入失敗時，可回到快速入門中的訂閱步驟依序重新操作；不清楚參數名稱時，再查閱術語表，不要反覆刪除整個用戶端資料目錄。

第五階段：系統代理與代理模式

區分流量入口與輸出規則

先區分兩個問題：應用程式如何將請求交給用戶端，以及用戶端收到請求後如何送出。「自動設定系統代理」處理的是前者；路由中的全域或繞過規則處理的是後者。啟用系統代理不代表所有程式都會使用它；選擇全域代理也只會影響已進入核心的流量。了解這兩個層次，才能解釋為何瀏覽器可以連線，某些桌面程式卻沒有變化。

在 v2rayN 中選擇「自動設定系統代理」，再到 Windows「設定 → 網路和網際網路 → Proxy」核對實際位址與連接埠。這些資訊應與用戶端目前用於系統代理的監聽入口一致，不要只看系統匣圖示判斷。通常應指向本機回送位址，而不是節點伺服器位址。遠端節點連接埠供核心連至伺服器使用，不是瀏覽器要填寫的本機代理連接埠。

依應用程式行為選擇接管方式

先用一個確定會讀取系統代理設定的瀏覽器，連線到實際目標。若瀏覽器使用獨立代理、擴充功能代理或特定設定檔，可能不會採用系統設定。排查時先只保留一種代理來源，記下原設定後再關閉衝突項目。命令列工具、遊戲與背景服務也可能使用自己的網路堆疊，應檢查各自設定；瀏覽器連線成功，不代表所有應用程式都能使用。

需要在應用程式中手動設定代理時，請依其支援的協定填入 HTTP 或 SOCKS 入口，並使用用戶端實際監聽的位址與連接埠。這兩種入口的欄位不能直接互換。若用戶端提供混合入口，也要確認該入口確實支援所選協定。若應用程式有獨立的網域名稱解析選項，還要確認解析是否交由代理端處理，避免請求雖然經代理傳送，網域名稱卻透過另一條路徑查詢。

了解清除、保留與自動設定的差異

「清除系統代理」會移除系統目前的手動代理設定，但不會自動關閉各應用程式內部的代理設定。「不變更系統代理」表示用戶端不會主動修改系統項目，並不代表系統目前沒有設定代理。若退出用戶端後所有網頁都無法連線，先檢查系統是否仍指向本機連接埠，再查看瀏覽器是否保留獨立設定。用戶端關閉後，不要繼續使用沒有程式監聽的入口。

切換模式前記下目前狀態，切換後核對系統設定，再測試新建立的連線。既有長連線可能沿用舊路徑，瀏覽器的連線池也可能使結果稍後才顯現。可以關閉測試頁面後重新開啟，必要時完全結束測試應用程式再試。每次測試之間不要同時更換節點、DNS 與路由，否則即使結果改變，也無法判斷是哪項調整造成影響。

完成本階段後，至少進行一次正向與反向驗證：啟用自動設定，確認瀏覽器透過本機入口正常運作；清除系統代理，確認網路恢復原本的行為。將這組操作留作故障時的還原步驟。只有確定某個應用程式不讀取系統代理，且確實需要接管時，才進入後續的 TUN 階段，不要為了多顯示幾個開關就全部啟用。

第六階段：路由分流與 DNS

從內建模式建立規則基準

先在路由選單選擇符合目前需求的內建規則，例如「繞過中國大陸」模式，再觀察實際連線結果。不同規則集可能包含不同的私人位址、網域分類及預設輸出組合，不要只看模式名稱就推斷所有細節。使用前先查看規則內容與順序，確認本機網路資源是否直連、未符合規則的目標會前往何處，以及規則引用的資料檔是否能正常載入。

了解規則比對順序。常見路由會依序由前往後比對，前方較寬泛的規則可能導致後方的細分規則永遠無法生效。為特定服務新增例外時，應先確認它與現有規則的關係，再放到適當位置。若將「所有流量代理」放在最上方，就不要期待末尾的私人位址直連規則還能生效。調整後請查看記錄確認命中結果，不要只憑網頁能否開啟判斷規則是否正確。

區分網域規則與位址規則

網域規則依請求中可用的網域資訊比對，位址規則則依目標位址比對。同一服務可能使用多個網域與分散式位址，只新增首頁網域未必涵蓋登入、靜態資源與下載請求。反過來說，依某次解析出的位址新增規則，也可能影響共用該位址的其他服務。優先使用明確的業務網域範圍，避免以單次解析結果代替長期穩定的規則。

{
  "type": "field",
  "domain": ["geosite:cn"],
  "outboundTag": "direct"
}

這是一個規則物件，不是完整設定。它必須放入相應核心設定中的規則陣列，而且環境中必須有可用的網域分類資料，實際輸出標籤也必須是 direct。用戶端產生的標籤可能不同，請先查看產生的設定再對應。不要用這段內容覆蓋整個設定檔，也不要直接貼到只接受分享連結的匯入欄位；請優先使用用戶端支援的規則編輯功能。

讓解析路徑與流量路徑一致

DNS 負責將網域名稱轉換為位址，但用戶端核心、系統與應用程式可能各自進行解析。遠端 DNS 與直連 DNS 的用途不同，不是把同一個位址填兩次就完成分流。若遠端解析服務本身需要經代理才能連線，也要確保連至該服務的連線有明確的輸出路徑，避免解析依賴代理、代理連線又依賴尚未完成的解析，形成啟動循環。

檢查時先確認由誰解析網域名稱，再確認解析請求經由哪條路徑傳送。瀏覽器啟用加密 DNS 後，可能會繞過預期的系統解析流程；應用程式直接連至位址時，核心也可能無法取得原始網域名稱。嗅探在特定條件下能擷取協定資訊，但無法辨識所有連線，也不能取代完整的 DNS 設計。遇到分流異常時，先簡化路徑，再逐步恢復功能。

排查規則比對錯誤時，記錄完整目標網域名稱、實際解析位址、規則順序與目前使用的輸出。規則資料更新後，同一網域的分類也可能改變，因此應將資料更新視為設定變更。若臨時例外規則解決了問題，請繼續確認根本原因後再決定是否保留，不要長期累積互相覆蓋的修補規則。相關檢查步驟請參閱DNS 洩漏測試與防漏設定，著重核對預期的解析路徑。

完成本階段後，應能說清楚三種結果：明確直連、明確代理，以及未命中規則時的預設行為。接著確認重新啟動後規則仍然保留，並查看核心是否回報不支援的欄位或缺少資料。只有路由與解析在系統代理模式下都穩定後，才啟用 TUN；否則更大的接管範圍會讓原本的局部問題影響更多應用程式。

第七階段：TUN 模式與接管範圍

先判斷是否真的需要虛擬介面

TUN 透過虛擬網路介面接管符合路由條件的系統流量，適合處理不讀取系統代理、但需要納入統一分流的應用程式。它改變的是流量入口，不會讓節點具備額外的協定能力，也無法讓錯誤的認證資訊自動恢復正常。啟用前先確認同一節點在一般系統代理模式下已可正常使用，並保留這組可用設定作為基準；若基本連線仍不穩定，應先回到訂閱、監聽與路由章節排查。

評估接管範圍時，請分別列出本機、區域網路與遠端資源。印表機、共用資料夾、開發服務、遠端桌面及其他虛擬網路，可能需要特定的直連路徑。TUN 不代表所有位址都應經代理；啟用前先確認私人位址與必要網段的處理方式。不要等遠端管理連線中斷後，才第一次考慮如何恢復網路；透過遠端操作裝置時，更應準備好本機還原方式。

依序啟動並確認權限、介面與路由

儲存設定後，依目前用戶端的要求使用系統管理員權限或相應的服務機制，再開啟「啟用 Tun 模式」。不同介面與核心的啟動方式可能不同，請以實際提示為準。開啟開關後，不要立刻因連線失敗就判定設定錯誤；先確認核心仍在執行、虛擬介面已建立，且系統路由已完成設定。記錄中若出現權限不足、介面建立失敗或路由寫入失敗，請分別處理。

若出現介面或驅動程式相關問題，先退出重複執行的用戶端，並確認其他虛擬網路軟體是否占用相近資源。不要直接刪除系統中的所有虛擬網卡，也不要批次解除安裝驅動程式。有些介面來自虛擬機器、容器或企業網路，刪除後可能影響既有環境。請先關閉 TUN 並重新啟動用戶端，再依明確錯誤處理對應元件，並記錄每個操作步驟。

驗證 TCP、UDP 與 DNS 的實際行為

先測試原本可透過系統代理連線的網頁，再測試先前未被接管的目標應用程式。兩者都成功，才能確認入口變更達到預期。若應用程式使用 UDP、語音或即時通訊，還需確認遠端服務與相應協定組合能支援所需流量。網頁可正常開啟不代表 UDP 一定正常；應用程式能啟動也不代表後續媒體連線使用相同路徑，請實際操作相關功能進行驗證。

DNS 是 TUN 疑難排解中的獨立環節。啟用後，系統解析、應用程式加密解析與虛擬介面接管可能同時作用。若位址看似可以連線，但網域名稱無法存取，請優先檢查解析流程、遠端解析服務的可達性及路由循環。不要以永久固定目標位址來掩蓋解析問題，也不要直接清除所有 DNS 設定；請先保留目前數值，再逐項比對核心支援的設定方式。

若無法連線區域網路裝置，先確認目標位址、子網路遮罩與目前路由，不要只新增一條網域例外。透過位址直連的共用服務不會符合網域規則。若同時執行其他網路通道，路由優先順序與預設出口可能互相競爭；請逐一關閉非必要入口進行比對。測試完成後再恢復原有組合，確認是哪個組合造成衝突，不要把所有問題都歸咎於節點。

裝置從睡眠恢復、切換 Wi-Fi 或插拔有線網路後，應重新確認虛擬介面與解析路徑。若無法恢復，先嘗試關閉再開啟 TUN，讓用戶端重新建立相關狀態；仍然失敗時請查看新的記錄，不要反覆提高權限。正常退出後，確認網路能否恢復；異常結束後，也要檢查系統代理與路由的現況。詳細原理與步驟請參閱v2rayN TUN 模式設定筆記。

本階段的驗收標準不是「開關維持開啟」，而是新增的應用程式能正確接管、直連資源仍可使用，而且有明確的退出還原方式。確認符合實際需求後再保留 TUN；若一般系統代理已涵蓋所有使用情境，也可以繼續採用較簡單的入口，減少權限、介面與路由之間的相互影響。

第八階段：日常維護與疑難排解

將備份與更新分開處理

連線穩定時建立備份，內容包含訂閱群組、手動節點、路由、DNS 與必要的自訂設定。使用用戶端提供的匯出方式，並記下備份未包含的項目。備份可能含有訂閱憑證與節點身分資訊，請存放在安全的位置，分享前務必移除敏感資訊。只備份主程式檔案不足以還原使用狀態，只截取節點名稱也無法還原完整參數。

區分用戶端更新、核心更新、訂閱更新與規則資料更新。這些更新變更的項目不同，應分開執行並逐項驗證。更新用戶端前先正常結束程式，避免檔案仍被占用；更新後檢查選單、監聽狀態與設定遷移結果。若目前套件統一管理核心元件，請依相應機制操作，不要隨意覆蓋其他來源的核心檔案，以免介面產生的欄位與核心功能不相容。

沿著入口到出口逐步排查

發生問題時，先停止繼續變更設定，記下故障前最後一次調整。依序檢查「應用程式是否使用入口、本機是否正在監聽、核心是否啟動、網域是否解析、節點是否完成交握、目標是否回應」。每確認一個環節正常，再檢查下一個。如此能將問題縮小到明確的環節，而不是同時切換多個節點、更新訂閱並重設系統網路，導致現場無法重現。

若只有瀏覽器連線失敗，其他應用程式正常，先檢查瀏覽器的獨立代理、擴充功能、加密 DNS 與快取連線。若所有應用程式都失敗，先查看監聽狀態與核心記錄。若只有特定目標失敗，先判斷目標本身、網域規則及分散式資源是否有差異。若換網路後才發生問題，則比較 DNS、網路認證與路由環境。分類排查比反覆點選連線測試更有效，也能減少不必要的設定重建。

Get-Date
Resolve-DnsName example.com

以上命令會查看目前的系統時間與系統解析結果，不代表已測試用戶端內部的遠端 DNS。可用這些結果作為對照：若系統解析失敗但核心解析正常，表示兩條解析流程不同；系統解析正常也不能證明代理輸出正常。遇到交握錯誤時，也要核對系統時間，並記錄時區與時間同步狀態。不要把單次命令成功視為整條代理路徑都正常，仍須透過實際應用程式驗證。

記錄最小重現步驟與還原方式

查看記錄時，優先尋找第一筆相關錯誤，而不只是後續連鎖逾時。記下錯誤所屬模組、目標類型與發生時間，再對照操作順序。回報問題時，請移除完整訂閱網址、使用者識別碼、密碼與其他敏感欄位；需要展示規則時，只保留相關片段與輸出關係。提高記錄層級後可能留下更多連線資訊，完成排查後請恢復適當層級，並清除不再需要的副本。

還原備份後也要進行驗證，不要假設匯入成功就代表環境已完整還原。先確認群組存在，再核對作用中節點、監聽連接埠、路由與 DNS，最後檢查系統代理或 TUN。舊環境中的介面、權限與安裝路徑可能不適用於新裝置，應依新系統重新設定。還原時保留目前的備份，避免用來源不明的舊設定覆蓋唯一可用的狀態。

行動裝置的維護還需檢查電池最佳化、自動啟動與背景執行限制。鎖定螢幕後連線中斷，與桌面端監聽連接埠衝突並非同一類問題，不應照搬桌面端的排查步驟。可參考v2rayNG 背景執行與電池設定建立裝置端檢查清單。不論使用哪一款用戶端，都應先保留可還原的設定再安排更新，並將網路可用性與軟體變更分開驗證。

完成本階段後，準備一份簡短的還原清單：清除系統代理、關閉 TUN、確認原有網路、啟動用戶端、載入基準節點、恢復分流。真正發生故障時依清單操作，比臨時搜尋零散建議更能維持一致的判斷，也能避免將原本局部的問題擴大到整個系統。

第九階段：進階設定與學習路線

從閱讀產生的設定開始

進階設定的第一步不是撰寫整份設定，而是閱讀用戶端實際產生的內容。找到目前設定的檢視入口，區分入站、出站、路由、DNS 與記錄模組，觀察這些內容如何對應介面設定。產生的檔案可能會在啟動或切換節點時重建，直接編輯後不一定能永久保留。先了解用戶端支援的自訂入口與合併規則，再決定哪些內容適合由介面管理。

練習追蹤一個出站標籤。先找出代理出站與直連出站各自實際使用的標籤，再確認規則中的引用是否相符，最後檢查未命中規則時的預設行為。標籤是設定內部的引用關係，不是固定的中文名稱，也不是節點備註。複製其他資料中的規則前，務必先完成這項對照。欄位格式合法但引用了不存在標籤的設定，可能在啟動時失敗，也可能無法依預期選擇出口。

為每項測試訂出預期結果

每次測試都先寫下目標、變更內容與還原方式。例如，讓特定網域直連時，預期該網域會符合指定規則，而其他目標的路徑維持不變；為特定應用程式啟用 TUN 時，預期該應用程式的新流量會進入核心，同時本機資源仍可存取。預期結果寫得越具體，就越清楚該觀察哪些項目。只憑「好像變快了」判斷複雜設定，無法排除快取、節點與網路波動的影響。

保留一份專供測試的設定副本，避免在日常工作環境中反覆疊加參數。先完成單一例外規則，再嘗試組合多條規則；先了解基本解析，再研究更複雜的網域處理方式。出現新問題時，立即回到最近一次可用狀態並比較變更，不要繼續加入修補設定。測試記錄應讓你隔天重新開啟裝置時，仍能理解每個自訂欄位的用途。

依問題類型選擇下一步學習方向

協定路線適合經常遇到匯入或交握問題的使用者。依序了解伺服器位址、認證、傳輸、安全層與伺服器名稱，並確認哪些參數必須由遠端提供。不要把協定名稱當成效能排名，也不要只憑單次測試就認定某種組合普遍優於其他組合。協定選擇首先受伺服器支援與實際網路環境限制，用戶端只能在相容範圍內套用既有設定。

路由路線適合需要存取區域網路資源、區分服務流向或處理複雜應用程式的使用者。先掌握規則順序、網域與位址的差異，再學習分類資料與預設輸出。DNS 路線則進一步追蹤由誰發起解析、經由哪個出口送出，以及解析結果如何參與規則比對。兩條路線需要相互驗證，但初次調整時仍應分開測試，否則一次存取結果改變可能同時牽涉解析結果與規則命中。

系統網路路線適合需要長期使用 TUN 的使用者。學習介面、路由表、位址範圍與權限界線，了解網路切換、虛擬機器及其他通道為何可能互相衝突。不要只為了使用更多功能就開放區域網路監聽，也不要在不了解存取範圍時共用本機連接埠。將服務開放給其他裝置後，還需要額外評估認證、裝置可信度與防火牆，這就不再只是本機代理設定。

整理出方便維護的設定

整理最終設定時，刪除已無用途的臨時例外，為保留的規則簡要記錄原因，並註明所需的核心功能與資料檔。規則數量多不代表涵蓋更完整，彼此重疊反而會增加閱讀成本。不要保留自己無法說明用途的整段參數；確實需要保留時，先在測試副本中確認它解決了什麼問題，再合併到長期設定，並確認重新啟動後仍然生效。

建立固定的閱讀順序：忘記操作時回到快速入門，不清楚術語時查閱概念速查，遇到具體錯誤時閱讀技術筆記，需要更換平台時前往用戶端下載頁。系統指南負責串連這些知識，不要求一次啟用所有功能。維持一套能說明、驗證與還原的工作設定，再依實際問題逐步擴充，就是這條學習路線的目標。