V2Ray 從零到精通完整指南

核心概念：先釐清用戶端、核心與設定的關係

圖形化用戶端不等於協定本身

開始操作前，最重要的是先分清幾個經常混用的名稱。V2Ray 通常指由 Project V 發展出的技術生態，也常被用來概括一組代理協定、核心與圖形化用戶端。v2rayN、v2rayNG 和 v2flyNG 是針對不同平台的圖形化用戶端，負責儲存設定、切換伺服器、控制系統代理、顯示日誌，並將整理後的參數交由核心執行。Xray 與 V2Fly 則屬於核心家族，實際處理連線建立、協定編解碼、傳輸層與路由匹配。理解這層關係後，遇到問題時就能判斷是介面操作、設定資料、系統接管還是核心執行出現偏差。

協定描述用戶端與伺服器如何交換必要資訊，例如 VMess、VLESS 或 Trojan；傳輸方式描述資料如何承載，例如 TCP、WebSocket、gRPC；TLS、REALITY 等安全層則位於不同位置。一個可用節點並非只由協定名稱決定，而是由位址、連接埠、使用者識別碼、傳輸方式、安全層、網域等參數共同組成。任何一項與伺服器端不一致，都可能造成連線失敗。不要只憑名稱猜測參數，也不要將某個節點的欄位機械式複製到另一個節點。

設定從哪裡來，又流向哪裡

常見的設定入口有兩類。單一節點分享連結適合臨時加入一筆設定，訂閱網址則用來管理由服務提供者維護的一組節點。用戶端讀取訂閱後，會將其中的項目轉換成內部設定並歸入訂閱群組；連線時，目前選取的節點、代理模式、路由規則與本機連接埠會共同產生執行設定。由此可見，更新訂閱不等於「啟動連線」：更新只負責重新整理清單，仍須選擇節點並啟動連線，新設定才會套用到目前工作階段。

系統代理與 TUN 也不是同一個層級。系統代理通常會修改作業系統提供的代理設定，只有遵循該設定的應用程式才會將要求送到用戶端；TUN 會建立虛擬網路介面，在更低層接收流量，因此涵蓋範圍更廣，但對權限、路由與 DNS 的要求也更高。剛開始使用時，應先掌握系統代理，確認節點與訂閱本身正常，再考慮是否需要 TUN。如此能將問題範圍控制在較小的層面。

以分層思路處理故障

系統化排查應從最短鏈路開始。先確認用戶端能正常啟動，再確認訂閱能夠讀取，接著選擇一個節點查看核心是否成功執行，最後檢查應用程式流量是否進入代理。若用戶端啟動後立即退出，優先檢查執行環境、目錄權限與殘留程序；若訂閱更新失敗，檢查網址格式、網路可達性與系統時間；若核心已執行但瀏覽器沒有變化，檢查系統代理與瀏覽器本身的設定；若只有個別應用程式無法運作，再考慮該程式是否忽略系統代理，以及是否需要 TUN。

延遲測試只能作為篩選線索，不能單獨證明節點具備完整可用性。不同測試方式可能只檢查 TCP 建立連線、握手或特定目標，結果也會受到本機網路、測試目標與瞬間負載影響。更可靠的判斷方式是：先確認設定握手成功，再使用實際需要的應用程式進行存取測試，同時查看日誌中是否有重複重試、DNS 失敗或路由拒絕。建立「用戶端—設定—核心—系統—應用程式」的分層模型，是後續各章的基礎。

選擇用戶端：依平台、核心與使用情境取捨

桌面平台優先選擇 v2rayN

Windows、macOS 與 Linux 桌面環境優先選擇 v2rayN。它將訂閱群組、伺服器清單、系統代理、路由規則、TUN 與日誌集中在同一套介面中，適合作為長期維護的主要用戶端。桌面端經常需要同時處理瀏覽器、開發工具、辦公室應用程式與命令列程式，v2rayN 的群組與路由功能更容易形成穩定的工作流程。Windows 使用者也會在下載頁看到桌面版與經典 WPF 版：桌面版採用新一代跨平台介面，經典 WPF 版適合習慣傳統 Windows 介面的使用者。選擇其中一個長期使用即可，不需要同時執行。

macOS 下載時要依處理器架構選擇 Apple Silicon 或 Intel 安裝包；Linux 則依照發行版的套件系統選擇 deb 或 rpm，並繼續區分 x64 與 arm64。架構選錯通常會表現為無法安裝或無法啟動，而不是網路連線問題。因此，安裝前先查看系統資訊，比安裝後反覆調整節點更有效。所有安裝入口都集中在安裝包頁面，該頁依四個平台列出對應的選擇方式。

Android 上的 v2rayNG 與 v2flyNG

Android 首選 v2rayNG。它以 Xray 核心為基礎，適合需要常見協定、訂閱管理、分應用程式代理與系統 VPN 接管的使用者。安裝包通常分為 arm64 與通用版，近年的主流裝置一般使用 arm64；若無法確認裝置架構，通用版涵蓋範圍較廣，但檔案通常也較大。首次連線時，系統會要求授權建立 VPN 連線，這是 Android 將應用程式流量交由用戶端處理的必要步驟。授權僅代表允許建立本機虛擬介面，不代表訂閱已匯入或節點已可用。

v2flyNG 是 Android 上以 V2Fly 核心為主的替代用戶端。它適合設定明確依賴 V2Fly 行為，或希望在同一平台比較不同核心實作的使用者。不要只憑名稱判斷哪款用戶端「比較快」，實際體驗取決於設定協定、本機網路、遠端狀態與核心相容性。對大多數首次設定的 Android 使用者而言，先用 v2rayNG 完成穩定連線會更容易；只有在明確知道設定來源、協定支援與核心要求時，才切換到 v2flyNG。

不要用切換用戶端取代問題定位

遇到連線失敗時，連續安裝多個用戶端通常無法縮小問題範圍。更有效的方法是先固定使用一個用戶端，記錄訂閱是否成功、核心是否啟動，以及日誌在哪個步驟停止。如果同一訂閱中的所有節點都失敗，優先檢查訂閱狀態、系統時間、網路與設定相容性；如果只有一個節點失敗，優先比較該節點與正常節點的協定和傳輸欄位；如果系統代理可用而 TUN 不可用，表示節點鏈路大致正常，應改查權限、DNS 與路由。

遷移用戶端時也要避免直接覆蓋原有設定目錄。先匯出或記錄訂閱群組、路由規則與本機連接埠，再關閉舊用戶端及其核心程序，確認系統代理已恢復，然後啟動新用戶端。兩個用戶端同時接管系統代理或監聽相同連接埠，會造成看似隨機的連線故障。在 Android 上切換 v2rayNG 與 v2flyNG 時，也應先停止目前的 VPN 連線，再啟動另一款用戶端，避免系統仍保留前一個工作階段。

建立清楚的選型界線

選擇用戶端可以歸納為三個問題：目前使用哪個作業系統、訂閱要求哪一類核心、是否需要進階路由或 TUN。桌面平台直接從 v2rayN 開始；Android 從 v2rayNG 開始；設定方明確指定 V2Fly 行為時，再考慮 v2flyNG。介面偏好可以影響最終選擇，但不應凌駕於協定相容性與系統架構之上。三款用戶端的詳細差異可查看橫向評測，安裝包類型則以下載頁的即時清單為準。

選定用戶端後，建議至少連續使用一段時間再調整工具。穩定的設定習慣比頻繁更換介面更有價值：統一訂閱備註、固定路由規則命名、明確系統代理開關、保留必要日誌，就能讓後續維護形成可重複的流程。下一章將依此思路處理安裝與首次啟動。

安裝與首次啟動：先建立可復原的基礎環境

安裝前確認系統與處理器架構

安裝的第一步不是雙擊檔案，而是確認作業系統版本、處理器架構與可寫入目錄。Windows 常見為 x64；macOS 需要區分 Apple Silicon 與 Intel；Linux 除了 x64、arm64 外，還要依發行版選擇 deb 或 rpm；Android 則在 arm64 與通用包之間選擇。系統資訊中的「系統類型」、「晶片」或「處理器」欄位，比裝置的行銷名稱更可靠。若架構不相容，應重新選擇安裝包，不要試圖透過修改副檔名或複製可執行檔來繞過限制。

桌面端建議將用戶端放在路徑清楚、目前帳戶具備讀寫權限的位置。用戶端需要儲存訂閱、日誌、路由規則與介面設定，只讀目錄可能導致設定無法儲存、升級後設定還原或核心無法釋放檔案。路徑盡量不要太長，也不要將執行中的目錄交給會自動依需求釋放檔案的同步工具。需要遷移時，先退出用戶端，再複製完整設定目錄；只複製主程式通常無法保留訂閱群組與自訂規則。

首次啟動只完成必要設定

首次啟動後，先確認介面能正常開啟、核心元件可以呼叫，且日誌視窗沒有持續報錯。此時不要急著啟用 TUN、自訂 DNS 與複雜路由。保留預設本機連接埠與基本代理模式，匯入一個來源明確的訂閱或單一節點，再進行第一次連線。如此可以建立最短驗證路徑：用戶端啟動、讀取設定、核心執行、系統代理生效、應用程式存取。任何一步失敗，都有清楚的前後界線。

Windows 若出現啟動後立即退出，可檢查系統執行環境、程式目錄權限、舊程序與設定檔是否損壞。macOS 若系統阻止首次開啟，應透過系統設定確認該應用程式的開啟操作，而不是反覆複製應用程式檔案。Linux 安裝後無法啟動時，先從終端機執行一次，以查看缺少的相依元件或權限提示。Android 安裝完成後先允許必要的通知顯示，便於觀察連線狀態；首次建立連線時，再處理系統 VPN 授權。

Windows：設定 → 系統 → 系統資訊 → 系統類型
macOS：蘋果選單 → 關於這台 Mac → 晶片
Linux：uname -m
Android：在系統資訊工具中查看 ABI，優先辨識 arm64-v8a

退出、重新啟動與系統代理復原

桌面用戶端關閉視窗後不一定會立即退出，部分設定會讓程式繼續常駐。更新、遷移或排查連接埠佔用前，應使用用戶端的退出指令，並確認核心程序也已結束。若直接終止程序，系統代理可能保留上一次指向本機連接埠的設定，之後瀏覽器會表現為所有要求都失敗。此時即使節點本身正常，也需要先恢復系統代理，再重新啟動用戶端。

較穩妥的退出順序是：停止目前連線、關閉系統代理或 TUN、退出用戶端、確認程序已結束。重新啟動時則反過來：先開啟用戶端，確認設定載入完成，選擇節點並啟動核心，最後開啟系統代理或 TUN。這個順序能避免流量被送到尚未監聽的本機連接埠。Android 上直接從最近使用的工作中劃走應用程式，也可能被裝置廠商的背景策略終止；需要持續連線時，應配合後續維護章節設定省電白名單與背景執行權限。

為後續排查保留基準

首次成功連線後，先不要立即疊加設定。記錄目前的用戶端、訂閱群組、節點類型、代理模式與是否啟用 TUN，並確認一個瀏覽器與一個日常應用程式能穩定存取。這個狀態就是後續調整的基準。修改路由或 DNS 後若出現問題，可以回到基準判斷是哪項變化造成影響，而不是重新安裝所有元件。

建議同時熟悉日誌入口與設定備份位置。日誌中最有價值的是錯誤發生的階段、目標位址、協定握手結果與 DNS 提示，不需要長期保留冗長的除錯等級輸出。備份則應在用戶端完全退出後進行，至少包含訂閱資訊、路由規則與主要偏好設定。關於執行庫與權限導致的啟動問題，可繼續閱讀用戶端啟動閃退修復指南。

訂閱與節點：將設定來源整理成易維護的群組

訂閱網址、分享連結與手動設定

訂閱網址用於一次取得並持續更新一組節點，適合長期維護；分享連結通常只描述單一節點，適合臨時匯入或精確測試；手動設定則要求逐項填寫位址、連接埠、使用者識別碼、傳輸與安全參數，適用於無法使用匯入格式或需要核對細節的情境。三種入口最終都會形成可由用戶端選擇的伺服器項目，但更新方式不同。訂閱中的節點應由訂閱更新維護，手動修改後可能在下次重新整理時被覆蓋。

新增訂閱時，先建立容易辨識的群組備註，再貼上完整網址。備註可以使用服務名稱、用途或環境，不建議只寫「訂閱一」、「備用二」，因為多個來源並存後很難判斷更新對象。儲存後主動執行一次更新，觀察用戶端是否回傳項目以及是否出現格式錯誤。訂閱網址含有存取憑證，應只儲存在受控裝置與用戶端設定中，不要放入公開文件、截圖或共用日誌。

更新不等於立即切換

訂閱更新通常會新增、刪除或修改目前群組中的節點，但不會自動取代正在使用的連線。更新完成後，應查看目前選取的項目是否仍然存在，必要時重新選擇節點並重新連線。若清單沒有變化，先確認執行更新的是目標群組，再檢查是否啟用了關鍵字篩選、去重或排序規則。部分名稱相同的節點可能因篩選結果看似沒有變化，實際上內部參數已經更新。

更新失敗時，依序檢查網址格式、網路可達性、系統時間與用戶端日誌。複製網址時不要帶入前後空格或換行；瀏覽器能開啟某個頁面不代表訂閱介面一定可達；系統時間偏差可能影響安全連線；日誌中的狀態碼或解析提示則能區分是要求失敗，還是內容格式不受支援。不要在同一時間反覆點擊更新，連續要求既不能修復格式問題，也會讓日誌難以閱讀。

訂閱群組命名範例：
工作環境｜主要訂閱
行動裝置｜常用
協定測試｜臨時

篩選規則範例：
保留關鍵字：VLESS|Trojan
排除關鍵字：維護|到期|剩餘

節點選擇要結合協定、位置與實際任務

節點清單中的名稱通常只是設定方提供的備註，不代表穩定性結論。延遲測試適合快速排除無法建立連線或回應明顯緩慢的項目，但測試結果會受線路、測試方法與瞬間狀態影響。選擇節點時，應結合目前核心是否支援該協定、傳輸參數是否完整、實際應用程式能否穩定運作，以及連續使用時是否頻繁重新連線。一次很低的數值不能取代持續存取測試。

當某個節點無法使用時，先在同一訂閱群組選擇另一個節點。如果其他節點正常，問題範圍通常在單筆設定或遠端狀態；如果整個群組都失敗，檢查訂閱是否過期、更新內容是否異常；如果多個來源同時失敗，則進一步檢查本機網路、系統代理與用戶端核心。這種對照比無順序地修改 DNS、路由與連接埠更有效。

多訂閱群組與篩選策略

同時維護多個訂閱時，應將來源分開，而不是匯入後混在同一個平面清單中。群組能明確劃分更新範圍，也便於為不同來源設定獨立的篩選規則。節點名稱可採用統一的排序方式，例如先按協定或地區，再接原始備註。篩選關鍵字應保持簡單，每次只解決一個目標：隱藏維護提示、保留特定協定或排除不需要的用途。規則過長時，很容易意外隱藏新節點。

修改篩選規則後，先查看未篩選的原始數量與名稱，再逐步增加條件。正規表示式中的直線符號表示「或」，括號用於組合，句號與星號具有特殊含義；如果只是匹配一般詞語，直接使用明確關鍵字更安全。關於多個訂閱來源的群組、備註與篩選實務，可參考多訂閱來源群組管理實務。完成訂閱整理後，再進入代理模式設定，避免將清單問題誤判為系統接管問題。

代理模式：理解系統代理、規則模式與全域處理

系統代理負責將支援它的應用程式導向用戶端

桌面環境中的系統代理，本質上是將作業系統的代理位址設定為用戶端監聽的本機連接埠。瀏覽器與許多桌面應用程式會讀取這項設定，再將 HTTP 或 SOCKS 要求交給用戶端。用戶端隨後依目前節點與路由規則決定如何處理。系統代理的涵蓋範圍清楚、權限要求較低，適合作為首次連線與日常使用的預設入口，但某些應用程式會使用自己的網路堆疊或獨立代理設定，因此不會自動跟隨。

開啟系統代理前，用戶端核心必須已經執行並監聽對應連接埠。若系統代理指向的連接埠沒有程式監聽，所有遵循系統設定的應用程式都會連線失敗。檢查時可以先關閉系統代理，確認本機網路恢復，再啟動用戶端並重新開啟。不要任意修改本機連接埠；若確實需要調整，應同時確認用戶端入站連接埠、系統代理位址與手動設定代理的應用程式保持一致。

規則、全域與直連各自解決什麼問題

規則模式會依網域、IP、連接埠、程序或協定等條件，決定流量走代理、直連或封鎖，是日常使用中最均衡的方式。全域模式通常會讓可接管的流量統一經過目前代理，適合短時間驗證節點是否能處理目標要求，也適合排除路由規則誤判；不應將其理解為連線品質更高。直連模式則繞過遠端代理，可用於臨時恢復一般網路，或確認問題是否來自代理鏈路。

排查時可以利用三種模式進行對照。如果全域模式可用而規則模式不可用，優先檢查路由規則命中情況；如果全域模式也不可用，問題更可能出在節點、核心或系統接管；如果關閉系統代理後應用程式仍然走代理，表示應用程式可能設定了獨立代理，或仍有其他網路工具正在執行。每次切換模式後都要重新連線，並觀察日誌中的出站標籤，才能確認新設定已套用到目前工作階段。

瀏覽器、命令列與獨立代理應用程式

瀏覽器通常會跟隨系統代理，但也可能透過擴充功能或企業政策使用獨立設定。排查瀏覽器時，先關閉額外的代理擴充功能，使用新視窗存取目標，再與系統中的其他應用程式對照。命令列工具不一定會讀取桌面系統代理，可能需要在目前終端機工作階段設定 HTTP_PROXY、HTTPS_PROXY 或 ALL_PROXY。設定只應指向用戶端實際監聽的本機位址與連接埠，測試結束後立即清除，避免後續指令在用戶端關閉時失敗。

# 暫時為目前終端機工作階段指定本機代理，連接埠需與用戶端設定一致
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 測試結束後清除
unset HTTP_PROXY
unset HTTPS_PROXY

部分開發工具、下載工具或遊戲平台擁有獨立的網路設定，應優先查看應用程式本身的文件。不要為了涵蓋一個不遵循系統代理的應用程式就立即切換到 TUN；先判斷它是否支援手動 HTTP 或 SOCKS 代理，通常更容易控制。若應用程式確實無法設定代理，且需要連同 UDP 或子程序一起接管，再評估 TUN 的必要性。

連線狀態與實際存取要分開判斷

用戶端顯示「已連線」通常表示核心已啟動或本機 VPN 介面已建立，不代表每個遠端要求都成功。實際存取還要經過 DNS 解析、路由匹配、協定握手與目標回應。遇到「顯示已連線但無法存取」時，查看日誌是否出現 DNS 失敗、連線逾時、路由至直連或遠端拒絕。透過日誌中的目標與出站標籤，可以判斷流量是否進入預期路徑。

建立穩定習慣後，日常使用可以固定採用規則模式，並保留全域模式作為診斷工具。每次修改訂閱、節點或模式時，只改動一項並重新連線，再用同一測試目標驗證。如此累積的結果具有可比性，也為下一章編寫路由規則打下基礎。

路由分流：用明確規則控制各類流量的出口

規則由匹配條件、目標與順序組成

路由分流的核心不是堆積規則，而是回答兩個問題：哪些流量需要特殊處理，以及它們應該走哪個出口。常見匹配條件包括完整網域、網域後綴、IP 網段、連接埠、網路類型與程序名稱；目標通常是代理、直連或封鎖。用戶端會將介面中的規則轉換為核心設定，並依既定順序進行匹配。一般而言，越具體的規則越應排在前面，範圍較大的兜底規則則放在後面。

網域規則在 DNS 解析前後可能有不同表現。若應用程式直接存取 IP，單純的網域後綴規則不會命中；若用戶端沒有取得原始網域，只能依解析後的 IP 判斷。程序規則依賴系統權限與程序辨識能力，在不同桌面平台上的支援也可能不同。因此，編寫規則前先確認用戶端介面提供哪些條件，不要直接貼上其他工具的語法。

從最小規則集開始

一組容易維護的規則通常包含明確直連項、明確代理項與最終兜底。先寫最確定的條件，例如區域網路位址直連、特定工作網域使用指定出口，再決定其餘流量的預設路徑。不要一開始就匯入大量來源不明的規則，因為規則之間可能重疊，更新後也難以追蹤變化。每新增一條規則，都應知道它匹配什麼、為何需要，以及放在目前位置的原因。

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

上面的結構展示了常見的核心路由邏輯：私有位址先直連，指定網域走代理，其餘 TCP 與 UDP 使用代理出口。實際在 v2rayN 或行動用戶端中，出站標籤可能由介面產生，不應自行假設名稱。複製設定片段前，先確認用戶端是否支援直接編輯完整設定；若使用圖形化規則編輯器，應將條件逐項填入對應欄位，而不是把整段 JSON 放進單一輸入框。

理解網域策略與 DNS 的配合

AsIs 表示優先依原始網域進行匹配，不為路由判斷額外解析 IP；其他策略可能在網域規則未命中時繼續解析，並嘗試匹配 IP 規則。策略越積極，越可能增加 DNS 查詢，也越依賴 DNS 設定正確。若需求主要是依網域後綴分流，保持網域邏輯簡單會更容易排查；若必須依 IP 網段處理，則需要確認解析結果、DNS 出口與 IP 規則保持一致。

DNS 與路由會互相影響。DNS 查詢本身也是流量，需要決定由哪個伺服器解析、透過哪個出口傳送；解析結果又會參與後續 IP 規則。常見異常包括網域被解析到不適合目前線路的位址、查詢經由錯誤出口傳送、快取仍保留舊結果。排查時先觀察特定網域的解析結果，再檢查該查詢與業務連線分別命中了哪些規則。不要同時更換多個 DNS、網域策略與路由集，否則很難確認是哪項修改生效。

規則命中測試與衝突定位

驗證規則時，應選擇特徵明確的目標，並查看日誌中的網域、目標 IP 與出站標籤。若具體規則沒有命中，檢查它是否排在較寬泛的規則之後、網域格式是否正確、應用程式是否直接使用 IP，以及舊連線是否仍在重用。瀏覽器可能維持長連線，修改規則後只重新整理頁面不一定會重建所有要求，必要時關閉相關分頁或重新啟動應用程式再測試。

程序分流還要考慮子程序。例如瀏覽器主程式與網路服務程序可能使用不同名稱，啟動器與實際程式也可能分開。行動端的分應用程式代理更適合依應用程式套件選擇，規則結果取決於用戶端的「繞過所選應用程式」或「僅代理所選應用程式」語意，切換前必須仔細閱讀選項。關於 Android 的授權、省電白名單與分應用程式代理，可查看v2rayNG Android 使用要點。

保持規則易讀、可撤銷

為每組規則寫清楚用途，並在大幅修改前匯出備份。規則名稱可以直接描述業務，例如「區域網路直連」、「工作網域代理」、「特定應用程式直連」，比抽象編號更容易維護。刪除規則前先停用並觀察一段時間，確認沒有依賴後再移除。若訂閱規則集由外部來源更新，應與個人規則分層存放，避免更新覆蓋手動調整。

成熟的路由方案不是規則數量最多，而是能穩定解釋每次命中。先滿足主要情境，再處理少量例外；當例外持續增加時，重新檢視預設出口是否合理。完成路由基礎後，如果仍有不遵循系統代理的應用程式、UDP 流量或複雜子程序需要接管，才進入 TUN 模式。

TUN 模式：擴大流量接管範圍並控制複雜度

TUN 為何能涵蓋更多應用程式

TUN 模式透過虛擬網路介面接收系統流量，再交由用戶端核心判斷路由。它不要求每個應用程式主動支援 HTTP 或 SOCKS 代理，因此能涵蓋忽略系統代理的程式、部分 UDP 流量與多程序應用程式。Android 用戶端建立的系統 VPN 連線也屬於類似的接管方式。涵蓋範圍擴大後，系統路由、DNS、權限與排除項目都會參與運作，因此 TUN 更適合在基本節點與規則模式已驗證正常後啟用。

TUN 不代表所有流量都必須經由遠端代理。流量進入虛擬介面後，仍會依路由規則選擇代理、直連或封鎖。若區域網路存取、列印服務或開發環境需要保持直連，應在啟用前確認私有位址與相關網域規則。錯誤的預設路由可能使本機裝置無法連線，錯誤的 DNS 設定則可能表現為「IP 可以存取、網域無法存取」。

啟用前的檢查清單

先關閉其他可能建立虛擬介面或修改路由表的網路工具，再確認 v2rayN 的一般系統代理連線可用。檢查目前節點是否支援所需的網路類型，記錄原有 DNS 設定與路由模式，然後再啟用 TUN。桌面系統可能要求管理員權限或安裝必要元件，應依用戶端的明確提示完成。若權限遭拒，反覆切換開關並不能解決問題，需要回到系統權限設定處理。

啟用後先測試三個層次：一般網域存取、直接 IP 存取、區域網路資源存取。一般網域失敗而 IP 成功，優先檢查 DNS；兩者都失敗，檢查虛擬介面、預設路由與核心日誌；外部存取正常但區域網路失敗，檢查私有網段直連規則。測試目標保持固定，每調整一項就重新連線，避免快取與舊工作階段干擾判斷。

DNS、嚴格路由與迴環問題

TUN 通常需要接管 DNS，確保網域解析與後續連線使用一致的路由策略。設定過多 DNS 伺服器不會自動提高可靠性，反而可能造成結果不一致。起步時使用用戶端推薦的簡單方案，確認查詢能夠進入核心，再依實際需求區分直連與代理解析。若出現解析迴圈，要檢查 DNS 要求是否又被送回同一個本機監聽連接埠。

嚴格路由用於降低流量繞過虛擬介面的可能性，但也可能影響虛擬機器、容器、區域網路共用與自訂網卡。開啟前應記錄系統中既有的網段與介面，尤其是開發環境使用的私有位址。若容器存取突然失敗，不要先修改節點協定，而應比較啟用 TUN 前後的路由表，並為必要網段加入明確處理。規則必須精準且範圍適當，避免用過大的網段覆蓋正常系統路由。

Android 上的連線授權與分應用程式代理

v2rayNG 或 v2flyNG 首次連線時會要求系統 VPN 授權。系統通常同一時間只允許一個作用中的 VPN 工作階段，因此切換用戶端前要停止目前連線。分應用程式代理有兩種相反的邏輯：只讓選取的應用程式進入代理，或讓選取的應用程式繞過代理。設定時先核對介面描述，再用一個容易驗證的應用程式測試，不要一次選取大量應用程式。

如果連線在鎖定螢幕後頻繁中斷，問題往往與系統省電策略、背景限制或裝置廠商的工作管理有關。將用戶端加入省電白名單、允許背景執行，並保留持續通知，有助於維持 VPN 服務。日誌等級不宜長期保持詳細除錯狀態，否則會增加寫入與處理負擔。更完整的行動端續航排查方法見v2rayNG 耗電與背景執行排查。

什麼時候應退回系統代理

如果主要需求只是瀏覽器和少量支援代理的桌面應用程式，系統代理通常更簡單。TUN 應該解決明確問題，而不是預設增加複雜度。啟用後若長期遇到區域網路、容器或 DNS 衝突，可以先退回系統代理，讓日常工作恢復，再單獨分析需要接管的應用程式。保留一個已驗證的一般代理設定，是處理 TUN 故障的重要退路。

關閉 TUN 時，應透過用戶端開關正常停止，讓虛擬介面與路由得到清理，然後確認系統網路恢復。若強制結束程序後網路異常，可重新啟動用戶端並正常關閉一次，或在系統網路設定中檢查殘留介面。完成這些基礎工作後，下一章將把更新、備份、日誌與故障定位整理成可重複的維護流程。

日常維護：更新、備份、日誌與穩定性排查

將更新分為用戶端、訂閱與規則三類

日常更新並不是單一動作。用戶端更新會改變介面、核心或功能行為；訂閱更新會重新整理節點參數；規則更新則可能改變流量出口。三類更新最好分開執行，每次更新後完成一次基本驗證。若同一天同時更換用戶端、重新整理訂閱並匯入新規則，出現異常時很難找出變化來源。在穩定環境中，可以先備份設定，再更新用戶端，確認啟動與舊設定正常，接著重新整理訂閱，最後處理規則。

用戶端更新前先退出正在執行的核心，記錄目前使用的安裝類型與架構。不要在舊程式仍執行時覆蓋檔案。更新後先檢查訂閱群組、路由模式、本機連接埠與 TUN 設定是否保留，再啟動一個已知可用的節點。訂閱更新則應查看項目數量、目前選擇與篩選規則；規則更新後需要重新連線，並透過日誌確認主要目標仍走預期出口。

備份的重點是可復原，而不是檔案數量

有價值的備份至少應包含訂閱群組、手動節點、自訂路由、DNS 偏好與重要的用戶端設定。執行備份時要完全退出用戶端，避免複製到尚未寫入完成的設定檔。備份目錄可以按日期與用戶端名稱區分，但不要將含有訂閱憑證的檔案上傳到公開位置。復原時先在相同的用戶端系列中測試，再考慮跨版本或跨用戶端遷移。

建議同時保留一份簡短的環境記錄，例如系統平台、處理器架構、用戶端名稱、使用中的代理模式、自訂本機連接埠與是否啟用 TUN。它不需要包含節點憑證，卻能在重新安裝後快速還原操作邏輯。複雜的路由規則應附上用途說明，避免數個月後只剩下無法解釋的條件。可復原的設定應能回答「從空白環境開始，最少需要哪些步驟才能回到穩定狀態」。

用日誌定位階段，不要只搜尋錯誤詞

排查日誌時先看時間順序：用戶端讀取設定、核心啟動、本機連接埠監聽、DNS 查詢、路由匹配、遠端連線與應用程式要求分別發生在哪個位置。單獨一個 error 字樣可能只是某次重試，連續重複的同類錯誤才更能說明阻塞階段。記錄問題發生的準確時間，再截取前後相關行，比複製整份日誌更容易分析，也能降低暴露訂閱網址等敏感內容的風險。

排查記錄範本
1. 平台與用戶端：Windows / v2rayN
2. 接管方式：系統代理或 TUN
3. 影響範圍：所有應用程式、單一應用程式或單一網域
4. 最近變更：用戶端、訂閱、規則、DNS
5. 對照結果：直連、規則、全域分別如何
6. 日誌階段：啟動、解析、路由、握手或逾時

若用戶端無法啟動，優先查看執行環境、目錄權限、設定損壞與連接埠佔用；若訂閱無法更新，檢查網址與要求錯誤；若核心啟動後所有節點都失敗，檢查系統時間、網路與協定相容性；若只有規則模式失敗，檢查規則順序；若只有 TUN 失敗，改查權限、DNS 與系統路由。依階段分類後，大多數問題都能縮小到一兩個模組。

處理連接埠佔用、殘留代理與背景限制

連接埠佔用常發生在用戶端異常退出、重複啟動或同時執行多個工具時。先正常退出所有相關用戶端，再檢查殘留程序。若修改本機連接埠，應同步更新系統代理與手動指定代理的應用程式。系統代理殘留會讓用戶端關閉後的瀏覽器無法存取，此時先恢復作業系統代理設定，再重新啟動用戶端，不需要刪除訂閱或重灌系統。

Android 背景中斷時，應檢查省電最佳化、背景活動限制、自動啟動權限與持續通知。不同裝置的設定入口不同，但判斷方法相同：前景穩定、鎖定螢幕後中斷，通常與背景管理有關；前景也無法連線，則先檢查設定與 VPN 授權。不要透過無限提高日誌等級來維持服務，日誌只負責觀察，不會改變系統排程。

建立週期性的輕量檢查

日常維護不需要頻繁變更。可以定期更新訂閱、刪除明確失效的臨時設定、檢查篩選規則是否誤傷新節點，並確認用戶端設定仍符合目前需求。路由規則只在業務變更時調整，TUN 只在確實需要擴大涵蓋範圍時啟用。長期穩定比不斷追逐新選項更重要。

遇到異常時，先回想最近一次變更，再依「關閉進階功能—恢復基本節點—驗證系統代理—逐項加回設定」的順序處理。若需要重新安裝，也應先備份設定並確認舊程序已退出。更多啟動崩潰、權限與殘留程序的處理方法，可繼續查看執行庫與權限問題排查。下一章將把這些基礎能力延伸到協定、核心與設定閱讀。

進階路線：從會使用用戶端到看懂設定

第一階段：看懂一個完整節點

進階學習不必從編寫整份設定開始。先選擇一個已可使用的節點，對照用戶端介面逐項理解位址、連接埠、使用者識別碼、協定、傳輸方式、安全層、網域與指紋等欄位。重點不是記住所有選項，而是知道哪些參數必須與伺服器端一致，哪些屬於本機偏好。將可用設定複製為測試項目，每次只修改一個非關鍵欄位並觀察日誌，可以建立欄位與行為之間的關聯。

協定層與傳輸層要分開學習。VLESS、VMess、Trojan 描述身分與協定互動，TCP、WebSocket、gRPC 描述資料承載，TLS 或 REALITY 則處理相應的安全與握手要求。名稱相似不代表參數可以互換。閱讀設定時由外向內拆解：先確認伺服器位址與連接埠，再確認協定身分，接著查看傳輸，最後檢查安全層與網域。這個順序也適用於連線失敗時的手動核對。

第二階段：理解 Xray 與 V2Fly 的生態關係

Xray 與 V2Fly 都源自 Project V 技術生態的發展分支，用戶端會依自身定位整合相應核心。v2rayN 常用於桌面端綜合管理，v2rayNG 主要以 Xray 核心為基礎，v2flyNG 則提供以 V2Fly 核心為方向的 Android 選擇。核心不同會影響協定支援、設定欄位與更新節奏，因此若訂閱設定明確依賴某項能力，應使用相符的用戶端與核心。

學習核心差異時，不要把「支援清單」簡化成絕對優劣。更有用的問題是：目前設定使用了哪些協定與傳輸欄位、用戶端整合的核心能否辨識、升級後行為是否改變，以及日誌是否提示未知欄位。關於兩條核心路線的演進與用戶端選擇，可閱讀Xray 與 V2Fly 核心差異詳解。

第三階段：從圖形化規則過渡到結構化設定

熟悉用戶端路由編輯器後，可以開始閱讀核心設定的基本結構。常見設定由日誌、DNS、入站、出站與路由組成。入站負責接收來自系統代理或 TUN 的流量，出站定義代理與直連等出口，路由則將匹配條件指向出站。閱讀時先找出標籤之間的引用關係，再查看每個物件的具體參數。標籤拼寫不一致會使規則指向不存在的出口，是手動編輯時常見的問題。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

這段範例只展示本機 SOCKS 入站、直連出站與私有位址規則，不包含遠端伺服器憑證。實際用戶端通常會自動產生入站與主要出站，手動設定前應先匯出目前結果進行閱讀，不要直接替換正在使用的設定。每次修改後先檢查 JSON 結構是否完整，再透過用戶端日誌確認欄位已被核心接受。

第四階段：建立可重複的實驗方法

進階設定最容易陷入「改了很多卻不知道哪項有效」。建議為實驗建立獨立的訂閱群組或測試設定，保留一個穩定基準，記錄每次修改、預期結果與實際日誌。測試路由時固定節點，測試節點時固定路由，測試 DNS 時固定目標網域。控制的變數越少，結論越可靠。出現異常後先回復最後一次修改，而不是繼續疊加新參數。

日誌等級可以在短期測試時提高，但完成定位後應恢復一般等級。詳細日誌會產生更多資訊，也可能包含存取目標與設定片段，分享前要刪去訂閱網址、使用者識別碼與其他存取憑證。命令列測試應只使用本機迴路位址與用戶端實際連接埠，不要將臨時憑證直接寫入長期腳本。

第五階段：建立自己的維護文件

當設定包含多個訂閱、路由群組、TUN 與分應用程式規則時，應為環境撰寫一份簡短說明。內容包括用戶端選擇理由、訂閱群組用途、預設代理模式、重要路由、DNS 方案、備份位置與復原順序。說明不需要記錄敏感參數，但應讓使用者在重新安裝或升級後知道如何還原。每次大幅修改後同步更新說明，比依賴記憶可靠得多。

從零到精通並不是把所有選項全部開啟，而是能夠解釋目前設定為何如此運作，出現異常時知道從哪一層開始檢查。建議的長期路線是：維持一個穩定的用戶端，掌握訂閱群組與系統代理，寫出最小路由集，再依明確需求啟用 TUN，最後閱讀結構化設定與核心日誌。若尚未完成首次連線，回到快速入門依主線操作；需要更換平台或架構時，前往安裝包頁面選擇對應用戶端。