V2Ray 從零開始完整使用手冊

用戶端、核心與設定檔各自負責什麼

日常所說的 V2Ray 用戶端，通常由圖形介面、代理核心與設定資料三部分組成。圖形介面負責接收訂閱、管理節點、切換模式及顯示日誌；核心負責監聽本機連接埠、建立出站連線、執行路由規則；設定資料則描述入站、出站、DNS 與路由之間的關係。遇到故障時，先判斷問題屬於哪一層，比反覆重新安裝更有效。介面能開啟只代表管理層正常，節點顯示「已選取」也不等於出站握手已成功，真正的連線結果應結合測試請求與執行日誌確認。

v2rayN 是 Windows、macOS 與 Linux 桌面平台的首選圖形用戶端，能管理 Xray、V2Fly 等核心對應的設定；v2rayNG 面向 Android，常用 Xray 核心；v2flyNG 同樣面向 Android，但採用 V2Fly 核心，適合已有對應設定或希望維持 V2Fly 設定語意的使用者。三個名稱中的「用戶端」與「核心」不能混為一談：訂閱中的某項協定只有在目前核心支援時才能建立連線，介面是否顯示該節點並不是最終判斷依據。

一次網頁存取會經過哪些環節

以瀏覽器存取網頁為例，應用程式先將網域交給 DNS 解析，再依據系統代理、應用程式代理或 TUN 接管狀態，決定請求是否進入本機代理入口。進入用戶端後，路由模組根據網域、目標位址、連接埠、網路類型或程序資訊選擇一個出站；代理出站接著使用節點參數與遠端服務建立連線，最後將回應原路傳回。任何一個環節設定錯誤，都可能表現為「網頁打不開」，但錯誤位置完全不同：DNS 失敗通常沒有可用的目標位址，系統代理未生效時請求不會進入核心，路由誤判可能將目標送往錯誤的出站，節點握手失敗則會在錯誤日誌留下連線或驗證資訊。

因此，排查時應沿著資料流由近至遠推進：先確認核心已啟動並監聽本機連接埠，再確認目標應用程式確實使用該入口，接著檢查 DNS 與路由決策，最後才評估節點與線路。直接以速度測試取代連通性檢查，容易混淆問題。節點能完成 TCP 測試，只能表示某個連接埠可連線；是否能完成協定握手、DNS 是否正確、目標網站是否依預期分流，仍需透過實際請求與日誌共同驗證。

不要將協定、傳輸層與安全層混為一談

VMess、VLESS、Trojan 等名稱主要描述代理協定及驗證方式；TCP、WebSocket、gRPC 等描述資料如何承載；TLS、REALITY 等則會影響握手與加密層。訂閱負責將這些參數組合成節點，匯入用戶端後應維持與伺服器要求相符的關係。手動編輯時，位址、連接埠、使用者識別碼、傳輸方式、主機名稱、路徑與安全層只要有一項不匹配，就可能出現逾時、握手失敗或驗證拒絕。不要根據協定名稱自行猜測傳輸參數，也不要為了「最佳化」而同時修改多個欄位。

還需要區分「訂閱管理」與「單一節點設定」。訂閱是一組由服務商維護的節點描述，更新訂閱可能新增、刪除或調整節點；單一節點則是用戶端目前可選擇的具體出站。手動修改訂閱節點的名稱通常影響不大，但直接修改位址、連接埠與協定參數，可能在下次更新時被覆寫。真正需要長期保留的本機路由、DNS 與代理模式，應放在用戶端提供的獨立設定區域，而不是混入訂閱內容。建立這套分層觀念後，後續章節中的每個操作都有明確歸屬：下載頁面處理軟體來源，訂閱提供出站資訊，系統代理或 TUN 處理流量入口，路由規則決定去向，日誌則負責還原整條鏈路。

依平台與核心需求選擇

桌面平台優先選擇 v2rayN。Windows 使用者可以在桌面版與經典 WPF 版之間選擇：桌面版採用新一代跨平台介面，適合希望在不同桌面系統維持相近操作邏輯的使用者；經典 WPF 版適合熟悉傳統 Windows 介面與既有操作流程的使用者。macOS 需要依 Apple Silicon 或 Intel 晶片選擇對應安裝套件，Linux 則依發行版的套件體系選擇 deb 或 rpm，並確認 x64、arm64 架構。所有入口都集中在用戶端下載頁，不應將其他平台的安裝套件重新命名後強行執行。

Android 平台首選 v2rayNG，訂閱包含 Xray 特性的節點時尤其適合；v2flyNG 是 V2Fly 核心方向的備選。主流裝置一般使用 arm64 安裝套件，無法確認架構或安裝失敗時，再考慮通用版。兩個用戶端都能讀取常見訂閱與分享連結，但核心支援範圍並不完全相同。選擇時先查看訂閱實際包含的協定與傳輸方式，再決定用戶端，而不是依介面名稱推斷相容性。

安裝前先辨識系統架構

Windows 可在「設定—系統—系統資訊」中查看系統類型；macOS 可在系統資訊中查看晶片名稱；Linux 可以透過終端機讀取架構。判斷架構的目的不是追求更複雜的套件，而是避免安裝程式無法啟動或軟體執行後找不到對應元件。Linux 常見指令如下，輸出為 x86_64 時選擇 x64，輸出為 aarch64 或 arm64 時選擇 arm64：

uname -m

# Debian、Ubuntu 等系統可查看套件架構
dpkg --print-architecture

# 使用 rpm 套件體系時可查看機器架構
rpm --eval '%{_arch}'

安裝或解壓縮目錄應保持穩定且可寫入，並避免頻繁搬移。用戶端通常還會儲存訂閱、日誌、路由規則與介面設定；如果每次更新都換到全新目錄卻不遷移設定，就會造成「節點突然消失」的錯覺。桌面版首次啟動後，先確認介面能顯示核心狀態與日誌入口，不要立即匯入多個訂閱或啟用 TUN。行動版首次連線時會出現系統層級的網路連線授權，這是系統將流量交給用戶端所需的步驟；授權完成後還應檢查電池管理，避免背景執行過早停止。

將首次啟動拆成三個檢查點

第一個檢查點是「用戶端能否正常開啟」，用於發現架構、執行環境或權限問題；第二個檢查點是「核心能否啟動」，此時即使沒有節點，也不應出現連接埠被占用、設定解析失敗或元件缺失；第三個檢查點才是「匯入節點後能否連線」。如此拆分後，如果錯誤發生在第二步，就不必懷疑訂閱內容。桌面版還要觀察本機監聽連接埠是否與其他代理程式衝突，同時執行多個網路工具時尤其容易發生同一連接埠被占用。

升級用戶端前先退出正在執行的核心，並保留用戶端設定目錄的備份。升級後先檢查原有訂閱與路由是否仍在，再以一般代理模式進行一次連線測試。不要在升級當天同時更換用戶端、切換核心、重寫 DNS 並啟用 TUN，否則出現問題時很難建立因果關係。如果系統策略阻止安裝，應先確認下載的平台與架構是否正確，再依作業系統正常的軟體授權流程處理，不要透過修改未知系統檔案來繞過錯誤。

安裝階段的最終驗收標準很簡單：用戶端可以穩定啟動，核心日誌沒有持續重複的啟動錯誤，本機代理連接埠處於監聽狀態，設定目錄位置明確，並且知道如何完全退出用戶端。完成這些基礎工作後再進入訂閱階段，可以避免將軟體安裝問題誤判為節點問題。若只想先完成一次連線，可前往快速入門主線；需要長期管理多組訂閱，則繼續按下一章建立命名、更新與回復規則。

訂閱匯入的正確順序

訂閱網址本質上是用戶端定期讀取的一個設定來源。匯入時先在用戶端的訂閱管理區域新增網址，為它填寫能辨識來源與用途的本機備註，然後執行一次更新。更新成功後，節點會進入相應分組；此時再選擇一個節點作為目前伺服器並啟動連線。不要將訂閱網址直接貼到瀏覽器網址列，也不要在公開頁面或截圖中展示完整網址，因為其中可能包含用於辨識訂閱的參數。

同一個用戶端可以管理多組訂閱，但不建議第一次設定時一次匯入許多來源。先用一組訂閱完成連線閉環，確認更新、選擇、啟動與驗證流程都正常，再依工作、日常或測試用途增加分組。名稱應描述用途，而不是寫「訂閱一」、「訂閱二」，否則幾個月後很難判斷哪些規則與哪些節點相關。訂閱更新只負責同步服務商提供的節點，不會自動證明每個節點都適合目前的網路環境。

理解更新、覆寫與本機設定

執行訂閱更新時，用戶端通常會根據新的訂閱內容重建該分組中的節點。服務商刪除的節點可能隨之消失，參數變更的節點會被替換，本機手動編輯的訂閱節點也可能恢復為遠端值。因此，不應只將長期路由策略或重要說明寫在某個訂閱節點內。需要長期保留的內容應放入用戶端獨立的路由設定、DNS 設定或備份記錄中。若必須臨時調整節點，先複製為本機設定並寫清楚用途，避免下次更新覆寫後無法判斷變更來源。

更新後節點數量沒有變化，不代表更新失敗；服務商可能只修改了位址、連接埠或傳輸參數。判斷更新結果應查看用戶端提示與訂閱更新日誌，並抽查節點的更新時間或關鍵欄位。如果日誌顯示網路請求失敗，先確認目前網路能否存取訂閱來源，再檢查系統時間、代理狀態與網址是否完整。如果訂閱更新需要透過現有代理，必須確保目前節點仍可用，否則會形成「需要更新才能連線、需要連線才能更新」的循環。此時可暫時切換到已知可用的本機節點再更新。

節點測速要分清測試目標

用戶端常見的測試包括連接埠連通性、協定延遲、實際請求或速度測試。連接埠連通性只檢查遠端連接埠是否能建立基礎連線，耗時短但資訊有限；協定延遲會經過更多握手步驟，更接近日常使用；實際請求還會受到 DNS、目標網站與路由規則影響。單次結果只能描述當時環境，不應將幾毫秒的差異視為長期品質結論。穩定性、封包遺失、尖峰時段壅塞與協定額外負擔，都可能比一次延遲數字更重要。

正確的選擇方法是先排除持續失敗的節點，再從可用節點中挑選數個進行實際存取比較。每次測試維持相同代理模式、相同目標與相近時間，避免一邊更換節點一邊修改 DNS。速度異常時可參考節點、線路與本機設定三層排查，分開驗證節點負載、網路路徑與本機設定。測速期間不要同時執行大量下載工作，否則測試反而會占滿頻寬。

手動匯入與分享連結的界線

單一分享連結適合臨時匯入一個節點，QR Code 適合在可信任裝置之間轉移簡短設定，訂閱則適合持續同步一組節點。手動輸入時應逐項核對位址、連接埠、使用者識別碼、傳輸方式、TLS 或 REALITY 參數、主機名稱與路徑。文字看起來相似不代表含義相同，例如傳輸路徑中的斜線、服務名稱的大小寫、伺服器名稱指示欄位都可能影響握手。匯入後若立即出現設定解析錯誤，優先檢查格式；若能啟動但連線逾時，再檢查位址、連接埠與網路；若日誌出現驗證拒絕，則回頭核對使用者識別碼與安全參數。

節點管理的目標不是累積越多項目越好，而是維持來源清楚、分組明確、更新可控。建議定期刪除長期失效的本機測試節點，保留必要備註，並避免在多個用戶端同時手動修改同一份設定。跨裝置使用時，讓每台裝置獨立更新訂閱，再分別維護本機路由與代理模式，通常比複製整個用戶端資料目錄更穩妥。本章完成後，應能回答三個問題：目前節點來自哪組訂閱、上次更新是否成功、節點失敗發生在讀取訂閱還是協定連線階段。

先區分流量入口與路由結果

「系統代理」和「全域代理」經常混用，但它們屬於不同層次。系統代理決定遵循作業系統代理設定的應用程式是否將請求送到用戶端；路由中的全域模式則決定已進入用戶端的請求是否統一使用代理出站。前者是入口，後者是去向。只開啟全域路由卻沒有讓應用程式進入用戶端，請求仍會直接存取；只啟用系統代理但路由將目標判定為直連，也不會經過遠端節點。排查時必須分別確認這兩個狀態。

瀏覽器、桌面軟體與命令列程式遵循系統代理的程度不同。有些應用程式會讀取系統設定，有些需要在自身網路設定中指定 HTTP 或 SOCKS 連接埠，還有些會保留啟動時讀取到的舊設定。修改系統代理後，若某個應用程式表現不變，先完全退出並重新啟動，再檢查它是否有獨立代理選項。不要用一個瀏覽器的結果推斷所有程式都已被接管。

三種常見執行方式

規則模式適合作為日常預設：進入用戶端的請求依網域、位址或其他條件選擇代理、直連或阻擋出站。它能減少不必要的遠端連線，但效果取決於規則品質與 DNS 配合。全域模式適合短時間診斷，懷疑規則誤判時，可暫時讓所有已接管請求使用代理出站；若全域模式正常而規則模式失敗，問題大多位於規則或 DNS 分類，而不是節點本身。直連模式則適合驗證關閉代理後的本地網路，以及維護期間暫時停止遠端出站。

模式切換應服務於定位，不應成為永久試錯。建議順序是：預設使用規則模式；單一目標出現異常時暫時切換至全域模式；若全域模式仍失敗，再檢查節點與 DNS；完成判斷後恢復規則模式。長期維持全域模式會掩蓋錯誤規則，也可能讓原本應直連的區域網路或本機服務繞道遠端。直連模式同樣不代表用戶端已完全退出，因為本機連接埠與部分接管能力可能仍在執行。

本機連接埠與環境變數

用戶端啟動後通常會在本機迴路位址上監聽 HTTP、SOCKS 或混合連接埠，實際數值以介面顯示為準。需要讓命令列程式使用代理時，可以在目前的終端機工作階段設定環境變數。以下使用常見的範例連接埠 10809，實際使用時必須替換為用戶端目前的 HTTP 連接埠：

# Linux 與 macOS 目前終端機工作階段
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 測試完成後清除
unset HTTP_PROXY
unset HTTPS_PROXY

環境變數只會影響讀取它們的程式及其子程序，不會改變整個系統。SOCKS 位址與 HTTP 位址也不能任意互換：程式要求 HTTP 代理時，應填寫 HTTP 或混合連接埠；支援 SOCKS5 時才使用對應的 SOCKS 連接埠。連接埠被其他程序占用時，核心通常無法啟動監聽，並在日誌中出現繫結失敗。此時應退出衝突程式，或在用戶端內更換未占用的連接埠，然後重新載入設定。

如何證明代理鏈路確實生效

驗證不應只看用戶端系統匣圖示。先觀察核心日誌中是否出現目標請求，再分別用一般網頁與命令列請求進行測試。如果瀏覽器正常而命令列失敗，通常是兩者入口不同；如果日誌完全沒有新請求，表示流量尚未進入用戶端；如果日誌有請求但出現 failed to dial、連線拒絕或逾時，則繼續檢查節點與出站。關於常見日誌欄位，可閱讀V2Ray 執行日誌定位方法。

當用戶端顯示已連線但網頁打不開時，不要將「已連線」理解為所有環節都已完成。這個狀態可能只表示核心正在執行或節點已選取。應依序檢查系統代理、節點可用性、DNS、路由與系統時間，具體清單請見連線成功卻無法存取網頁的排查順序。掌握入口與去向的差異後，下一章的路由分流才不會變成規則堆疊。

路由規則如何匹配

路由模組接收已進入用戶端的連線，並根據規則選擇代理、直連或阻擋等出站。常見條件包括網域、目標位址範圍、連接埠、網路類型與程序資訊。規則通常依序判斷，先符合的規則先執行；未符合時則進入預設出站。因此，同一組條件的排列順序不同，結果可能完全相反。寬泛規則應放在較具體的規則之後，否則前方的萬用條件會提前攔截請求，使後續規則永遠無法生效。

網域規則適合表達網站與服務歸屬，位址規則適合區域網路、保留位址與明確的網路範圍，連接埠規則只表示服務連接埠，不能單獨代表業務類型。程序規則取決於用戶端與平台支援，應用程式更新或路徑變更後可能失效。設計規則時優先使用穩定、易讀的條件，並為自訂規則寫清楚用途。不要讓臨時測試規則長期留在清單頂端。

從三層規則開始，不要一次匯入大型清單

一套容易維護的起點可分為三層：第一層處理本機、區域網路與保留位址，明確走直連；第二層處理需要固定出站的業務網域；第三層作為預設規則，承接其餘流量。如此出現問題時，可以清楚判斷請求在哪一層命中。對於區域網路裝置、路由器管理頁面與本機開發服務，直連規則應放在前面，避免請求被送往遠端後無法返回。

新增規則前先回答「它要解決什麼具體問題」。如果只是某個網域在規則模式下失敗，而全域模式正常，應查看日誌中的目標網域、解析位址與目前命中的出站，再決定補充網域規則或調整 DNS。若網域在進入路由前已被解析成位址，而規則又只匹配網域，實際行為可能與預期不同。此時需要檢查嗅探、網域策略與 DNS 設定之間的關係，而不是重複加入相同網域。

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

這段設定展示結構關係，不應直接覆蓋用戶端產生的完整設定。domain:example.com會匹配該網域及其子網域，full:service.example.net只匹配完整網域，geoip:private用於識別私有位址範圍。最後一條會覆蓋剩餘的 TCP 與 UDP 流量，因此必須放在具體規則之後。實際用戶端可能使用圖形化規則集、預先定義的標籤或不同的設定產生方式，應在介面中完成等效設定，並透過最終執行設定或日誌確認結果。

DNS 與路由必須一起觀察

網域存取包含解析與連線兩個階段。DNS 查詢本身可能有獨立路由，解析結果又會參與後續位址規則。如果 DNS 走直連而連線走代理，或解析得到的位址與遠端環境不一致，可能表現為網頁逾時、部分資源載入失敗或規則命中異常。調整 DNS 時先明確目標：是解決解析失敗、避免本地解析差異，還是讓特定網域由特定伺服器回應。不要同時啟用多個用途重疊的 DNS 方案。

AsIs通常表示盡量保留網域參與匹配，不主動為路由規則額外解析；其他網域策略可能在特定條件下將網域解析為位址，再參與 IP 規則。選擇哪種策略取決於規則結構，而不是簡單判斷哪一個「更快」。以網域規則為主時，應確保網域資訊能夠保留；大量依賴位址規則時，則要確認解析來源穩定。修改後用少量已知目標驗證，並觀察日誌中實際命中的規則與出站標籤。

建立規則變更記錄

每次修改只處理一個明確目標，記錄新增條件、預期出站與驗證結果。出現異常時先暫時停用最近新增的規則，再判斷是否恢復，而不是繼續在清單頂端補規則。規則集更新後也要進行回歸測試：區域網路存取、一般網頁、需要代理的目標、UDP 應用程式各選一個代表。只測試一個網頁無法涵蓋整套路由。

路由分流成熟的標誌不是規則數量多，而是每條規則都能解釋來源、順序與結果。對於無法解釋的舊規則，先移至停用區觀察，不要直接刪除；確認沒有依賴後再清理。保留一份簡單的預設設定作為回復方案，並將複雜實驗放在副本中。如此即使規則更新導致連線異常，也能快速判斷是節點故障還是決策層變更。

TUN 解決的是接管範圍問題

TUN 模式透過虛擬網路介面將更多系統流量交由用戶端處理，適合不讀取系統代理設定的應用程式、部分 UDP 流量，以及需要統一執行路由規則的情境。它不是新的代理協定，也不會改善本身不可用的節點。系統代理已能滿足瀏覽器與常用軟體時，沒有必要只為了「更完整」就立即開啟 TUN。接管範圍越大，DNS、區域網路、其他網路工具與系統路由之間的關係就越需要明確。

啟用 TUN 前應先完成三項基準測試：一般系統代理模式下節點可用；規則模式下主要目標分流正常；關閉用戶端後系統網路能夠恢復。若這三項尚未成立，TUN 會將原有問題包進更複雜的資料路徑。基準穩定後再啟用，並維持原有節點、DNS 與規則不變，才能判斷變化是否來自虛擬介面。

首次啟用的順序

先退出其他可能建立虛擬網卡或修改預設路由的網路工具，再在用戶端中啟用 TUN 所需元件與系統權限。啟動後確認用戶端日誌沒有介面建立失敗、路由寫入失敗或權限不足，然後分別測試一般網頁、區域網路位址與一個不讀取系統代理的應用程式。不要只憑系統匣狀態判斷成功。若一般網頁正常但區域網路失效，應檢查私有位址直連規則與嚴格路由選項；若所有網域失敗而直接存取位址有回應，應優先檢查 DNS 接管。

Android 上的系統網路連線由用戶端接管後，應確認目前啟用的是預期設定，並檢查分應用程式代理設定。分應用程式代理可以只接管選定應用程式，或排除不需要經過用戶端的應用程式；選擇哪種方式取決於使用目標。規則過多時先用少量應用程式驗證，再逐步擴展。背景執行還會受到系統電池策略影響，出現鎖定螢幕後斷線時，應先檢查用戶端是否被停止，而不是直接判斷節點失效。相關細節可參考v2rayNG 授權、省電與分應用程式代理設定。

DNS 接管與虛擬位址映射

在 TUN 環境下，用戶端可能同時接管 DNS 查詢，並使用虛擬位址映射網域，讓後續連線仍能還原原始網域以供路由使用。這項機制能改善只提供位址連線資訊的應用程式，但也要求 DNS 查詢與連線經過一致的資料路徑。如果某個應用程式快取了舊解析結果，切換設定後可能繼續存取舊位址；測試時應重新啟動應用程式，必要時等待快取失效。不要頻繁切換多種 DNS 模式後立即比較一次結果。

出現「部分網站能開啟、部分網站逾時」時，應查看失敗請求是否有網域、解析結果與路由命中記錄。若日誌只有位址而沒有原始網域，網域規則可能無法依預期生效；若 DNS 查詢未進入用戶端，則檢查系統是否仍使用其他解析路徑；若查詢成功但連線被送往錯誤出站，則回頭檢查路由順序。DNS 問題與節點問題的差異在於，前者常表現為無法取得目標或取得不合適的位址，後者通常已有明確目標但握手失敗。

處理衝突並安全退出

同時執行多個會修改系統路由、DNS 或虛擬網卡的工具，最容易造成預設路由反覆變更。排查時只保留一個接管者，關閉其他工具後重新啟動用戶端。如果系統從睡眠中恢復後網路異常，可先關閉 TUN、停止核心，再依先啟動核心、後啟用 TUN 的順序重建。直接強制結束程序可能留下尚未恢復的代理或路由狀態，因此應優先使用用戶端的正常退出流程。

TUN 設定完成後的驗收不只是「應用程式能上網」，還應包括區域網路仍可存取、規則模式命中符合預期、DNS 日誌沒有持續錯誤、系統休眠恢復後能重新連線，以及用戶端正常退出後網路可以還原。若其中任何一項不穩定，應回到一般系統代理繼續使用，再逐項解決，而不是將更多例外規則加入設定。TUN 的價值在於擴大可控流量範圍，前提是整條鏈路仍然能夠解釋並回復。

將更新分成三個獨立對象

日常維護中的「更新」至少包含用戶端更新、核心更新與訂閱更新。用戶端更新會改變介面與設定產生邏輯；核心更新可能改變協定支援與執行行為；訂閱更新則只同步節點資料。三者同時進行時，一旦連線異常就難以判斷來源。更穩妥的做法是分批處理：先記錄目前可用狀態，更新一個對象，完成啟動、連線、路由與退出測試後，再處理下一個對象。

用戶端提示更新不代表必須立刻中斷目前工作。先閱讀介面中的變更說明，確認是否涉及正在使用的功能，再安排維護時間。訂閱更新可以更頻繁，但同樣應保留一個可用節點作為回復方案。核心切換尤其要謹慎，因為同一份節點參數在不同核心中的支援範圍與預設行為可能不同。關於 Xray 與 V2Fly 的側重點，可閱讀Xray 核心與 V2Fly 核心差異。

要備份什麼，恢復時依什麼順序

有價值的備份包括訂閱分組資訊、本機節點、自訂路由、DNS 設定、代理連接埠、介面偏好設定以及必要的日誌片段。訂閱網址可能帶有辨識參數，備份檔案應只保存在受控裝置上，不要直接上傳至公開空間。僅複製安裝程式無法恢復使用狀態，真正決定行為的是設定資料。用戶端提供匯出功能時應優先使用，同時記錄匯出時的用戶端類型與作業系統。

恢復時先安裝符合平台與架構的用戶端，再匯入基礎設定，確認核心能夠啟動；接著恢復訂閱並更新節點；最後恢復自訂路由、DNS 與 TUN。不要一開始就將所有舊檔案覆蓋到新環境，因為路徑、權限或設定結構可能已變更。分層恢復雖然多幾個步驟，卻能準確找出哪一層引入錯誤。恢復後還應檢查本機連接埠是否與新系統中的其他程式衝突。

閱讀日誌採用「時間—入口—決策—出站」順序

透過日誌定位問題時，首先確認時間範圍。清除或標記目前日誌後，只執行一次能穩定重現問題的操作，避免舊錯誤與背景請求混在一起。接著確認請求是否進入本機入口；沒有入口記錄時，檢查系統代理、應用程式代理或 TUN。進入後查看路由選擇的出站標籤；出站符合預期後，再查看連線、握手與驗證結果。這樣的順序比在整份日誌中搜尋「error」更可靠。

failed to dial通常表示建立出站連線失敗，還要結合後續的逾時、拒絕或網路無法連線資訊判斷；connection rejected可能來自遠端拒絕、路由阻擋或服務未監聽；驗證相關提示則應核對使用者識別碼、時間與安全參數。單獨一行錯誤無法涵蓋完整上下文，應同時查看前後的請求目標、使用的出站與重試行為。詳細欄位說明可繼續查閱常見 V2Ray 日誌錯誤定位。

用最小變數法處理常見故障

連線失敗時先切回已知可用節點與一般系統代理，停用自訂 DNS、複雜路由與 TUN，只保留最短鏈路。如果基礎鏈路恢復，再依路由、DNS、TUN 的順序逐項啟用；若基礎鏈路仍失敗，則檢查訂閱參數、節點狀態、本機時間與網路環境。每次只變更一個變數，並在記錄中寫下結果。連續嘗試十幾個節點卻不查看日誌，通常只能證明問題仍然存在，無法說明發生在哪一層。

速度慢也要區分握手耗時、首個封包等待時間、持續吞吐量與個別目標限制。先用相同節點在不同時間測試，再比較同一時間的多個節點；接著關閉可能增加額外負擔的實驗選項，檢查本機下載、無線網路與系統資源。不要將最低延遲直接等同於最高持續速度。完整的分層方法請見V2Ray 速度慢逐級定位。

定期清理，而不是頻繁重設

維護期間可以清理長期失效的節點、重複訂閱、廢棄的路由副本與過舊日誌，但應先確認它們不再擔任回復用途。頻繁重設用戶端會遺失問題現場，也會讓相同設定錯誤反覆出現。若某個故障能穩定重現，先匯出必要設定與日誌，再進行最小化測試；只有確認設定已無法恢復時，才考慮重新建立環境。

一套健康的設定應符合：訂閱來源明確、目前節點可追蹤、代理入口清楚、規則能夠解釋、TUN 可獨立關閉、用戶端退出後系統網路正常。日常維護的重點不是持續調整，而是減少未知狀態。只要基準、變更與回復都能記錄，大多數故障都能在有限步驟內定位。

第一階段：能夠解釋目前設定

進階並不是從增加規則數量開始，而是從解釋現有設定開始。應能說明目前用戶端使用哪一類核心、節點參數來自何處、本機監聽哪些入口、系統代理或 TUN 如何將流量送入、預設路由選擇哪個出站，以及 DNS 查詢由誰處理。可以用一張簡單的資料流圖記錄這些關係：應用程式產生請求，入口接收請求，DNS 提供位址，路由決定出站，節點完成遠端連線。任何無法放入這條鏈路的開關，都值得先查清用途再啟用。

這一階段的練習是建立最小設定副本，只保留一個可用節點、預設 DNS 與三層路由。在副本中分別測試系統代理、應用程式內代理與 TUN，並記錄日誌差異。目標不是追求複雜功能，而是讓每次切換都有可觀察的結果。完成後，即使換到另一台裝置，也能根據資料流重新建立環境，而不是依賴對舊介面位置的記憶。

第二階段：將路由與 DNS 變成測試對象

選擇幾個固定測試目標，分別代表區域網路、直連業務、代理業務、TCP 與 UDP。每次調整規則後都執行同一組測試，並記錄實際命中的出站。對於網域規則，比較保留網域與先解析位址時的差異；對於位址規則，觀察解析變化是否影響結果；對於程序規則，測試程式更新或路徑變更後的行為。如此就能將「感覺分流不對」轉化為可重現的條件。

DNS 進階的重點是理解查詢路徑、快取與網域還原，而不是堆疊伺服器。先確認系統查詢是否進入用戶端，再確認用戶端選擇哪條解析路徑，最後查看結果如何參與路由。遇到異常時分別測試網域解析與目標連線，避免將兩類錯誤混為一談。任何 DNS 調整都應有明確目標，並保留恢復預設設定的方法。

第三階段：理解核心差異與協定界線

Xray 與 V2Fly 同源於 Project V 生態系，但在協定擴充、功能推進與設定支援方面各有側重。使用者不需要背熟每項內部實作，但應知道某些節點特性依賴特定核心，用戶端名稱也不能取代核心相容性判斷。v2rayN 可在桌面環境中管理相應核心設定，v2rayNG 常用於 Xray 方向，v2flyNG 則對應 V2Fly 方向。切換時應先確認訂閱協定與傳輸層是否受支援。

閱讀設定時依「位址與連接埠—驗證—協定—傳輸—安全層—路由」的順序拆解。位址與連接埠解決遠端位置，驗證欄位識別使用者，協定決定封包語意，傳輸描述承載形式，安全層負責相應握手，路由則決定何時使用該出站。出現錯誤時依照這個層級核對，比整份複製另一個設定更容易找出差異。

第四階段：建立自己的排錯手冊

將實際遇到的問題整理為「現象、環境、最小重現、日誌、原因、修復、回復」七項。現象應寫下可觀察的結果，例如「瀏覽器請求未出現在日誌」，而不是「代理壞了」；環境記錄平台、用戶端與目前模式，不需要堆疊無關資訊；最小重現只保留觸發問題所需的步驟；原因要落實到入口、解析、路由或出站中的具體環節。這類記錄比收藏大量零散教學更適合長期使用。

問題無法立即解決時，優先恢復工作狀態，再繼續分析。例如規則模式異常但全域模式可用，可以先保留暫時可用的方案，同時複製設定用於排查；TUN 異常則退回系統代理；新核心異常則回到原本的核心方向。回復不是放棄定位，而是保護基準。只有存在穩定基準，實驗結果才有比較價值。

持續學習的內容順序

建議先熟悉用戶端日誌與路由命中，再深入 DNS、TUN 與協定細節。日誌提供事實，路由決定行為，DNS 與 TUN 則擴大變數範圍；順序顛倒後，容易在尚未理解基礎請求路徑時同時面對多個系統層。日常遇到具體問題，可從資訊與排錯文章依主題查閱；需要重新建立最短連線時，回到入門指南；更換平台或重新安裝時，使用用戶端下載頁核對安裝套件類型。

從零開始到熟練掌握，最終形成的是一種穩定的工程方法：先建立基礎鏈路，再逐層增加功能；先觀察日誌，再提出原因；先保存基準，再進行實驗；每次只變更一個關鍵變數。依照這套順序，用戶端更換、訂閱變化或網路環境變更，都不會迫使你從頭猜測設定。能夠將一次請求從應用程式追蹤到出站，並在任一階段恢復至已知狀態，就已具備獨立維護 V2Ray 用戶端環境的核心能力。