V2Ray 從零到精通：安裝、訂閱、分流與 TUN

先分清核心、用戶端、節點與訂閱

核心負責連線，用戶端負責操作介面

V2Ray 不是某個固定的安裝程式，而是一套包含協定、傳輸、路由與連線管理能力的技術體系。實際使用時，核心會讀取設定並建立網路連線，圖形用戶端則負責將訂閱匯入、節點切換、系統代理與日誌檢視等操作整理成可點選的介面。v2rayN、v2rayNG 與 v2flyNG 都屬於圖形用戶端，會呼叫相應核心完成連線。排錯時要區分「介面設定未生效」與「核心連線失敗」：前者通常檢查用戶端狀態與系統代理，後者則要檢查節點參數、網路與核心日誌。

節點是一組連線參數，不等於訂閱

一個節點至少會描述伺服器位址、連接埠、協定與身分憑證，部分協定還會包含傳輸方式、TLS、伺服器名稱、路徑或服務名稱。節點決定用戶端要連線到哪裡，以及如何建立連線。訂閱則是用來批次分發節點與分組資訊的連結。用戶端更新訂閱後，會解析連結回傳的內容並產生節點清單；更新動作不代表每個節點都可用，也不能取代線路品質測試。節點清單為空時，應先確認訂閱是否解析成功，而不是立即反覆切換代理模式。

系統代理與流量轉送是兩層設定

核心正在執行，只代表本機代理連接埠已開始監聽，不代表應用程式流量一定會經過它。瀏覽器等遵循系統網路設定的程式，通常會透過「系統代理」進入用戶端；不讀取系統代理的程式，可能需要個別設定代理，或由 TUN 模式在網路層接管。判斷連線是否完成時，要連續核對三件事：用戶端核心處於執行狀態、系統或應用程式已將流量交給本機代理連接埠，以及目前節點能夠連至目標。只看系統匣圖示或單一網頁是否能開啟，無法準確定位問題所在層級。

協定、傳輸與路由分別解決什麼問題

VMess、VLESS、Trojan 等名稱屬於連線協定層，TCP、WebSocket、gRPC 等則是承載資料的傳輸方式；路由規則決定請求應直連、代理或阻擋。三者可以組合，但不能互相取代。例如，節點使用 VLESS 並不決定某個網站是否直連；是否直連取決於用戶端產生的路由設定。反過來，路由規則寫得再準確，也無法修正伺服器位址或身分參數填寫錯誤。遇到問題時，將設定拆成「連線參數、傳輸參數、流量去向」三組，逐組核對，比整份設定一起盲目修改更有效。

日誌是可驗證的事實，不是附加資訊

用戶端日誌通常會記錄設定載入、連接埠監聽、DNS 查詢、建立連線與失敗原因。看到逾時，優先檢查網路可達性、節點狀態與線路；看到解析失敗，檢查網域名稱與 DNS；看到設定欄位錯誤，回到節點詳細資料核對協定、傳輸與安全選項。日誌中的時間順序也很重要：先出現的設定錯誤，後續連線失敗往往只是連帶結果。完整理解這些物件後，再進入用戶端選擇與安裝階段，後續每個開關才有明確意義。

依平台與核心需求選擇用戶端

桌面平台優先選擇 v2rayN

Windows、macOS 與 Linux 桌面環境優先使用 v2rayN。它將訂閱管理、節點清單、系統代理、路由規則與 TUN 模式集中在同一套操作邏輯中，適合從首次設定一路使用到自訂分流。Windows 使用者可在桌面版與經典 WPF 版之間選擇：桌面版採用跨平台介面，適合希望不同桌面系統維持相近操作方式的使用者；經典 WPF 版則更貼近傳統 Windows 桌面程式。兩者目標相同，不必同時安裝，選一個作為固定工作環境即可。

Android 在兩種核心取向之間選擇

Android 首選 v2rayNG，使用 Xray 核心，適合需要較完整協定與傳輸支援的情境。v2flyNG 使用 v2fly 核心，可作為明確需要 V2Fly 體系時的備選。兩款用戶端都能完成訂閱匯入、節點切換、路由設定與本機 VPN 接管，但設定欄位與選單位置可能不同。不要因連線失敗就在兩款應用程式之間頻繁切換；先確認訂閱提供的協定是否受目前用戶端支援，再根據日誌判斷是否需要更換核心路線。

架構與安裝套件格式必須相符

選對用戶端後，還要確認處理器架構與安裝套件格式。macOS 可從「關於這台 Mac」查看晶片類型，Apple 晶片選擇 arm64，Intel 處理器選擇 x64。Android 近年的主流裝置通常使用 arm64；無法確認或裝置架構較特殊時，可選擇通用版，但通用套件通常較大。Linux 不只區分 x64 與 arm64，還要區分套件體系：Debian、Ubuntu 等使用 deb，Fedora、RHEL 系列通常使用 rpm。架構不相符時，常見情況是安裝程式無法啟動，或系統直接提示不支援。

不要用功能數量取代實際需求

選擇用戶端時，先列出必要操作：是否需要系統代理、是否有不讀取系統代理的程式、是否需要自訂網域分流、是否需要區域網路共享。一般瀏覽器與辦公應用通常只需訂閱、節點切換與系統代理；需要涵蓋更多應用程式流量時才考慮 TUN；需要精確控制流量去向時，再進入自訂路由。功能越多，設定層級越多，故障來源也越多。首次使用應先建立最小可用設定，再逐項增加能力，每增加一項都保留一個可驗證的結果。

移轉用戶端前先保留設定來源

更換裝置或用戶端前，至少記錄訂閱來源、目前路由模式與自訂規則。節點若來自訂閱，不必逐一手動複製；在新用戶端重新匯入訂閱，接著恢復路由與代理模式即可。手動節點則需要完整保留協定欄位，不能只記伺服器與連接埠。涉及身分資訊的設定應存放在受控位置，不要貼到公開頁面。本網站的用戶端比較進一步整理三款用戶端的適用範圍，確定選擇後再進入安裝階段。

完成安裝並建立可回復的初始設定

安裝前先關閉舊用戶端的接管狀態

同一台裝置上可以保留多個用戶端，但不要讓它們同時接管系統代理或 TUN。安裝前先退出舊用戶端，並在系統網路設定中確認沒有遺留的手動代理位址。若舊程式異常退出，系統代理可能仍指向已停止監聽的本機連接埠，結果是所有網頁都無法連線。此時先關閉系統手動代理，再啟動新用戶端。這麼做不是要刪除舊設定，而是確保首次測試只有一個流量入口，方便判斷問題來自新用戶端還是舊設定殘留。

Windows：確認安裝形式與執行權限

Windows 使用 v2rayN 時，先在下載中心的 Windows 區段選擇桌面版或經典 WPF 版。安裝完成後從開始功能表啟動，首次執行應確認主視窗能正常開啟、程式能讀取核心目錄，且日誌中出現本機連接埠監聽資訊。一般系統代理功能通常不需要長期以系統管理員身分執行；只有啟用需要系統網路驅動程式或調整路由的功能時，用戶端才可能要求提升權限。不要把「一律以系統管理員身分執行」當成通用修復方案，這會掩蓋目錄權限或設定路徑問題。

macOS：依晶片選擇並確認系統授權

macOS 安裝 v2rayN 時，先確認處理器類型，再選擇對應的 dmg。開啟磁碟映像後，將應用程式放入系統應用程式目錄，避免長期直接從唯讀映像執行。首次啟動若出現來源確認，依系統安全性設定中的提示完成授權。系統代理與 TUN 所需權限不同：系統代理主要修改目前網路服務的代理設定，TUN 則可能要求額外網路權限。初始階段只設定系統代理，不要同時開啟 TUN，先驗證訂閱與節點連線是否正常。

Linux：匹配發行版並檢查桌面工作階段

Linux 使用者依發行版選擇 deb 或 rpm，並同時確認處理器架構。安裝後從桌面應用程式清單啟動；若介面沒有出現，可在終端機直接執行應用程式命令以查看啟動錯誤。不同桌面環境讀取系統代理的方式不完全相同，部分應用程式遵循桌面代理設定，部分則使用自己的網路設定。因此，在 Linux 上「用戶端正在執行」不等於「所有應用程式都已接管」。首次驗證建議選擇明確遵循系統代理的瀏覽器，再處理需要個別設定代理的程式。

sudo apt install ./v2rayN-linux-x64.deb

# rpm 系發行版使用對應安裝套件
sudo rpm -Uvh v2rayN-linux-x64.rpm

Android：只保留一個作用中的本機 VPN

Android 安裝 v2rayNG 或 v2flyNG 後，首次連線會要求建立本機 VPN，這是系統將應用程式流量交給用戶端的必要步驟。同一時間只能由一個應用程式維持這類接管狀態，因此測試新用戶端前要中斷其他網路工具。匯入訂閱後先選擇一個節點，維持預設路由，再點選連線。狀態列出現連線標誌只代表系統授權已建立，仍要透過日誌與實際存取驗證節點是否成功連線。

首次啟動後的五項核對

第一，確認用戶端視窗與系統匣選單都能正常開啟；第二，確認核心啟動後沒有設定錯誤；第三，記錄本機 HTTP、SOCKS 或混合代理連接埠，避免與其他程式衝突；第四，檢查開機啟動是否符合使用習慣，不需要時先保持關閉；第五，確認退出用戶端時是否會自動恢復系統代理。完成這五項後再匯入訂閱。若安裝階段已經出現錯誤，不要帶著錯誤繼續設定訂閱，否則後續日誌會混入多層問題，排查成本會明顯增加。

匯入訂閱、更新節點並判斷解析結果

將訂閱名稱寫成容易辨識的來源

在用戶端的訂閱管理中新增訂閱時，名稱應能說明用途或來源，例如「日常線路」或「測試線路」，不要只寫「訂閱一」或「新建分組」。名稱不會影響連線，但會直接影響更新與排錯效率。連結必須完整複製，開頭與結尾不能帶有空格，也不要把網頁顯示文字誤當成訂閱位址。儲存後執行一次手動更新，並觀察提示與日誌。只有節點清單實際增加或重新整理，才算完成這次匯入；僅儲存訂閱記錄不代表解析成功。

更新失敗時依回傳階段分類

訂閱更新大致分為取得、解碼、解析與寫入四個階段。取得失敗通常表現為逾時、網路錯誤或伺服器回傳異常，應先確認目前網路能否存取訂閱位址。解碼失敗表示回傳內容不是用戶端預期的格式，可能是連結複製不完整、訂閱已過期，或伺服器回傳了提示頁面。解析失敗多半與節點欄位格式、編碼或用戶端支援範圍有關。寫入失敗則要檢查設定目錄權限、磁碟空間與舊設定狀態。分清階段後再處理，比連續點選更新更容易找出原因。

分別查看更新前後的節點變化

更新訂閱可能新增、刪除或修改節點。更新前正在使用的節點若被移除，用戶端可能切換到其他節點，也可能保留一筆已失去訂閱關聯的舊記錄。更新後應確認目前選取的節點仍然存在，並檢查自訂分組是否符合預期。若用戶端提供「清除舊節點」或「依訂閱覆蓋」選項，啟用前要確認手動新增的節點是否會受到影響。手動節點與訂閱節點最好分組管理，避免更新時無法判斷某筆記錄的來源。

延遲測試只能回答特定問題

節點延遲測試通常用來判斷目標位址能否在一定時間內回應，不等於實際下載速度，也不等於所有網站的存取品質。部分節點可能不回應某種探測方式，但實際代理仍可運作；也可能延遲很低，卻因線路壅塞導致吞吐量下降。正確做法是先用用戶端測試排除明顯無法連線的節點，再用固定網頁或檔案進行實際存取比較，並維持本機網路條件一致。一次測試結果波動較大時，應在不同時段重複測試，而不是立即修改協定參數。

依變更需求決定訂閱更新頻率

不必在每次開啟用戶端時連續更新訂閱。節點來源明確且清單穩定時，可在發現節點無法使用、收到設定變更提示或進入維護週期時手動更新。自動更新間隔不宜設定得過短，頻繁請求不會提升節點品質，反而會讓日誌充滿重複記錄。更新後若整體無法使用，先保留日誌並確認是否所有節點都已被替換，再參考訂閱解析失敗自查清單逐項檢查連結、回傳內容與更新通道。

手動節點要完整核對欄位

手動新增節點時，不要只核對伺服器與連接埠。協定類型、使用者識別碼、加密或流控、安全層、傳輸方式、伺服器名稱、路徑與服務名稱，都必須與提供方的設定一致。空白欄位也有其意義：某項應留空時，不要憑經驗填入預設值。修改節點前可以複製一份記錄作為回復依據，修改時每次只調整一組欄位。連線成功後再為節點命名，名稱應描述用途，而不是寫入敏感參數。至此，訂閱與節點層已完成，下一步才是決定哪些應用程式流量進入本機代理。

理解系統代理、全域模式與應用程式差異

系統代理是多數桌面應用程式的第一個入口

v2rayN 啟動核心後，會在本機監聽代理連接埠；開啟系統代理則會將作業系統的代理位址指向這些連接埠。瀏覽器、辦公軟體與部分系統元件會讀取這項設定，並將請求交給用戶端。系統代理關閉時，核心仍可持續執行，只是遵循系統設定的應用程式不會再自動進入代理。排查「用戶端連線正常但瀏覽器沒有變化」時，應同時檢查用戶端系統匣狀態與系統網路設定，確認代理位址指向本機，且連接埠與用戶端目前設定一致。

全域不是連線強度，而是流量選擇策略

全域模式通常表示進入用戶端的流量優先經由目前代理出口；繞過區域網路與中國大陸等規則模式，會依網域與 IP 資料決定直連或代理；自訂模式則依使用者規則進行比對。全域模式不會讓節點本身變快，也不會修復訂閱欄位錯誤，只是減少分流判斷，適合用於對照測試。如果規則模式下某個目標失敗，而全域模式下成功，表示節點基本可用，問題更可能位於路由或 DNS；如果兩種模式都失敗，應回到節點與網路層排查。

不同應用程式讀取代理設定的方式不同

瀏覽器通常會遵循系統代理，但部分應用程式內建獨立代理選項，部分命令列工具只讀取環境變數，還有些程式會直接建立網路連線而忽略系統代理。因此不能用單一應用程式的結果推論整台裝置。測試時先選一個已知會遵循系統代理的瀏覽器作為基準，再逐一處理其他應用程式。命令列程式有需要時可暫時設定代理環境變數，連接埠應替換為用戶端介面顯示的實際值，而不是照抄範例。

# 目前終端機工作階段使用 HTTP 代理
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

# 使用 SOCKS5，並讓網域名稱透過代理端解析
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

從監聽狀態確認本機連接埠衝突

如果核心啟動時提示位址已被使用，表示另一個程序正在監聽相同連接埠。先退出其他代理用戶端，再重新啟動；若仍然衝突，可在用戶端設定中更換本機連接埠，並同步更新所有手動填寫該連接埠的應用程式。不要只修改系統代理連接埠而不修改核心監聽連接埠，兩者必須一致。連接埠號本身不決定速度，任意反覆更換沒有意義。區域網路共享還涉及監聽位址與防火牆，應與本機系統代理分開設定。

關閉用戶端時要恢復系統狀態

正常退出用戶端前，先關閉系統代理，或確認用戶端已設定在退出時恢復系統狀態。若程式遭系統強制終止，代理設定可能會保留，之後所有遵循系統代理的應用程式都會嘗試存取已停止的本機連接埠。典型現象是網路本身正常，但瀏覽器立即提示代理連線失敗。處理方式是進入系統網路設定關閉手動代理，然後重新啟動用戶端檢查。將這一步加入日常排錯清單，可以快速排除大量「退出後無法上網」的問題。

行動裝置的連線狀態要結合應用程式日誌判斷

Android 用戶端透過系統提供的本機 VPN 介面接管流量；點選連線後，應先確認系統授權成功，再查看用戶端日誌是否完成節點連線。部分應用程式可能有自己的 DNS、網路加速或私有連線設定，這些設定會改變測試結果。首次設定時維持預設路由與 DNS，只選一個節點進行驗證。基礎連線穩定後，再依實際需求新增分應用程式策略或自訂路由，避免一開始同時修改節點、DNS 與應用程式規則。

用網域、IP 與規則順序控制流量去向

路由規則處理的是已進入用戶端的流量

路由不會主動接管應用程式，只會處理已透過系統代理、應用程式代理或 TUN 進入核心的請求。每條規則通常包含比對條件與出口動作：條件可以是網域、IP、連接埠、協定或來源，動作通常是代理、直連或阻擋。若某個應用程式完全不經過用戶端，再精確的路由規則也不會生效。因此設定分流前，先在日誌中確認目標請求已經出現，再觀察它符合哪條規則與哪個出口。

網域規則適合描述服務邊界

完整網域比對只會作用於指定主機名稱，後綴規則則可涵蓋一個網域及其子網域。使用 domain:example.com 時，應確認目前用戶端或核心對此寫法的定義；使用 full:api.example.com 可精確指定單一主機；geosite: 類規則引用維護好的網域集合，適合涵蓋一類服務。規則寫得越寬，誤比對範圍越大。不要為了解決單一子網域的存取問題，就直接將整個頂級網域及所有子網域改為同一出口。

IP 規則取決於解析結果與目標位址

IP 規則可比對單一位址或 CIDR 網段，例如 192.168.0.0/16 表示一段私有網路。區域網路位址通常應直連，避免印表機、路由器管理頁面與檔案共享被送往遠端出口。網域請求是否能進入 IP 規則，還取決於核心是否取得解析後的目標 IP，以及目前網域策略如何設定。只寫 IP 規則卻不檢查 DNS 流程，可能出現規則看似正確卻沒有命中的情況。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:intranet.example.com",
          "domain:office.example.com"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "geosite:category-ads-all"
        ],
        "outboundTag": "block"
      }
    ]
  }
}

規則順序決定衝突時誰先執行

多數路由實作會依序查找，命中後便不再繼續比較。因此具體規則應放在寬泛規則之前。例如，某個辦公子網域需要直連，而其父網域整體走代理，就應先寫辦公子網域直連，再寫父網域代理。若順序相反，寬泛規則會提前攔截請求。修改規則後不要只看設定是否儲存成功，還要重新啟動或重新載入核心，並透過日誌確認新規則已載入。關於語法與比對優先順序，可繼續閱讀domain、ip 與 geosite 規則寫法。

DNS 與路由需要指向一致的目標

分流經常同時涉及網域判斷與 IP 判斷，因此 DNS 結果會影響後續路由。如果某個網域被解析到與預期不同的位址範圍，IP 規則可能會將它送往錯誤出口。排查時應記錄網域、解析結果、命中規則與最終出口四項，而不是只更換 DNS 伺服器。用戶端支援多組 DNS 時，可為直連與代理查詢設定不同路徑，但應先理解每組查詢由哪個出口發出。基礎設定尚未穩定時，維持預設 DNS 通常比疊加多套規則更容易驗證。

用最小測試集驗證分流

準備三個固定測試對象：一個區域網路位址、一個明確要求直連的網域，以及一個明確要求代理的網域。每次修改規則後依序測試，並記錄命中出口。若區域網路失敗，先查私有位址規則；若網域出口不符，查規則順序與網域形式；若日誌中沒有請求，回到流量入口層。不要把隨機網頁當成唯一測試對象，因為網頁可能同時載入多個網域，主頁成功不代表所有資源都經由同一出口。完成規則模式驗證後，再決定是否需要 TUN 來擴大接管範圍。

基礎代理穩定後再啟用 TUN 模式

TUN 解決不讀取系統代理的應用程式流量

TUN 模式透過虛擬網路介面接收更多系統流量，再交由核心執行路由與轉送。它適合不遵循系統代理的桌面程式、需要統一接管的命令列工具，以及希望減少逐一設定應用程式代理的情境。TUN 不是節點加速開關，也不會提升協定效能。基礎節點連線不穩定時啟用 TUN，只會增加虛擬網卡、DNS 與路由表三個新變數，因此必須先在一般系統代理下確認訂閱、節點與規則模式運作正常。

啟用前記錄目前的網路基準

開始前記錄目前的網路介面卡、DNS 取得方式、用戶端本機連接埠與系統代理狀態，並關閉其他可能建立虛擬網卡的程式。接著在 v2rayN 中啟用 TUN，依系統提示完成必要的權限授權，等待核心重新載入。啟動後檢查日誌中是否出現虛擬介面建立、路由寫入與 DNS 初始化資訊。若用戶端只顯示開關已開啟，但日誌提示介面建立失敗，應先處理權限或驅動程式問題，不要繼續修改節點參數。

嚴格路由與自動路由要理解適用範圍

自動路由用於將適合接管的系統流量送入 TUN，嚴格路由則會進一步限制繞過虛擬介面的路徑。具體開關名稱可能隨用戶端介面調整，但判斷原則一致：先啟用最少的必要選項，驗證瀏覽器、命令列與目標應用程式，再依是否存在流量洩漏決定是否增加限制。企業網路、虛擬機器、容器或多網卡環境中，自動產生的路由可能與既有網段重疊，此時應先核對路由表，而不是直接切換全域代理。

DNS 異常是 TUN 排錯的首要重點

TUN 開啟後若 IP 位址可以存取但網域無法存取，應優先檢查 DNS。確認用戶端 DNS 模組已啟動、查詢請求進入預期入口，並查看是否有本機安全軟體攔截。若只有部分網域失敗，記錄其解析結果與命中規則；若所有網域都失敗，檢查 DNS 監聽連接埠、系統 DNS 指向與連接埠衝突。不要同時啟用多套 DNS 接管功能，否則查詢可能在系統、用戶端與其他網路程式之間循環。

區域網路與多網卡環境要保留直連路徑

啟用 TUN 後，印表機、網路儲存裝置、路由器管理頁面等私有位址仍應透過本機網卡直連。確認路由中包含私有位址範圍，並檢查目前區域網路是否使用不常見的自訂網段。裝置同時連接有線、無線與虛擬網卡時，還要確認預設路由實際從哪張網卡發出。若切換網路後出現異常，可先關閉 TUN，等待虛擬介面與路由撤銷，再重新連線網路並啟動用戶端。

判斷是否真的需要長期啟用

若日常使用的應用程式都能穩定讀取系統代理，就沒有必要為了更複雜的設定而長期啟用 TUN。需要涵蓋特定不遵循代理的應用程式時，TUN 才有明確價值。穩定執行的標準包括：重新啟動後能自動恢復、切換網路後路由能重建、區域網路存取正常、DNS 沒有持續錯誤，以及關閉用戶端後系統網路能還原。符合這些條件後，再將 TUN 加入開機流程；否則應保留系統代理作為較簡單的日常方案。

建立更新、備份、測速與分層排錯流程

將維護拆分為固定週期與事件觸發

固定週期維護用於檢查用戶端更新、訂閱狀態、自訂規則與舊設定；事件觸發維護則在節點整體失效、網路環境變化或系統升級後執行。不必每天清空設定或重新安裝用戶端。正常情況下，先更新訂閱並檢查節點變化，再進行少量可重複的連線測試。用戶端升級前記錄目前設定，升級後先驗證核心啟動、系統代理與一個常用節點，確認無誤後再恢復 TUN 或複雜路由。

備份重點是無法重新產生的內容

訂閱節點通常可以重新取得，真正需要備份的是手動節點、自訂路由、DNS 設定、分組方式與區域網路共享參數。備份檔案應存放在受控目錄，因為其中可能含有連線憑證。恢復時不要直接覆蓋所有新設定，先確認用戶端設定結構相容，再分別匯入各類內容。若只是更換裝置，優先重新安裝用戶端並匯入訂閱，然後手動恢復規則，這樣可以避免將舊系統的路徑、連接埠衝突與網路介面資訊一併帶入。

速度問題依節點、線路、本機三層檢查

第一層更換同一訂閱中的少量節點，判斷問題是否只集中在單一節點；第二層在不同時段測試同一節點，觀察線路壅塞是否具有時段性；第三層檢查本機網路、代理模式、DNS、TUN 與安全軟體。測試過程中維持目標網站、檔案與裝置一致，不要一邊更換節點一邊切換無線網路。若所有節點都很慢，優先查看本機網路與訂閱整體狀態；若只有一個節點慢，則不必重新安裝用戶端。詳細流程可參考V2Ray 速度慢分層排查。

日誌蒐集要涵蓋問題發生的時刻

排錯日誌至少應包含啟動核心、重現問題與停止測試三個階段。只截取最後一行錯誤，常會漏掉前面的設定載入失敗。重現前先清理過多的舊日誌或記下目前時間，然後執行單一動作，例如更新一次訂閱、連線一個節點，或存取一個固定網域。分享日誌前應移除伺服器位址、使用者識別碼與訂閱內容等敏感資訊，但保留錯誤類型、時間順序與元件名稱。這樣既能說明問題，也不會暴露連線參數。

常見現象對應的第一個檢查點

用戶端無法開啟，先檢查安裝套件架構、執行環境與設定目錄；訂閱更新失敗，先檢查連結取得與解析日誌；節點全部逾時，先檢查本機網路與訂閱狀態；瀏覽器提示代理連線失敗，先檢查核心監聽與系統代理連接埠；只有某個網域異常，先檢查 DNS 結果與路由命中；開啟 TUN 後整體斷網，先關閉 TUN 並檢查虛擬介面與預設路由。更多依現象整理的答案可在疑難解答中查找。

區域網路共享需要個別維護邊界

允許區域網路連線後，本機代理連接埠不再只服務目前裝置。應確認監聽位址、系統防火牆、路由器網路隔離、裝置端代理位址，並只在可信任的區域網路內使用。電腦 IP 改變後，手機或電視中填寫的代理位址也要同步更新。共享異常時，先從另一台裝置測試電腦的區域網路位址是否可達，再檢查連接埠放行，最後檢查用戶端是否允許外部連線。完整操作請參閱v2rayN 區域網路共享步驟。

維護目標是保留一個已知可用的基準

每次大幅修改前，保留一組能正常運作的節點、預設路由與系統代理組合。修改後若無法在短時間內定位問題，就恢復基準，再逐項重做。不要一次全部替換訂閱、DNS、路由、TUN 與本機連接埠，因為即使最後恢復連線，也無法知道真正起作用的是哪一項。可重複的維護流程比頻繁重新安裝更可靠，也能讓後續進階設定建立在明確狀態上。

從穩定基準進入自訂規則與多裝置管理

進階的起點是能夠解釋目前的設定

完成基礎使用後，不必立即匯入大型規則集。先確認自己能回答五個問題：目前節點使用什麼協定與傳輸方式、應用程式流量如何進入用戶端、DNS 查詢走哪條路徑、目標請求符合哪條路由，以及最終使用哪個出口。只要其中一項無法確定，繼續增加規則只會擴大不確定性。進階設定的目標不是增加設定數量，而是讓不同流量依清晰且可驗證的條件，進入預期出口。

先建立命名與分組規範

訂閱名稱、節點備註、出站標籤與規則名稱應維持一致語意。例如依「來源－地區－用途」命名節點分組，使用 proxy、direct、block 表示出口用途，自訂規則則寫明目標與動作。命名規範能直接改善日誌可讀性，也能降低移轉時的判斷成本。不要在名稱中加入完整憑證或訂閱位址。多台裝置共用規則時，保留一份不含裝置路徑與本機連接埠的通用版本，再由各裝置補充本機差異。

自訂規則要有測試、發布與回復流程

新增規則前先寫出預期，例如「辦公子網域直連，其他同網域服務依預設策略處理」。接著新增最小規則，在日誌中驗證命中，再擴大網域或網段範圍。規則發布至日常設定前，至少測試區域網路、直連目標、代理目標與 DNS。若修改涉及規則順序，保留舊順序副本。出現異常時依最近一次變更回復，而不是繼續疊加修補。長期維護時，應刪除已失效或已被更寬規則覆蓋的項目。

{
  "rules": [
    {
      "name": "private-network-direct",
      "match": [
        "geoip:private"
      ],
      "action": "direct"
    },
    {
      "name": "office-domain-direct",
      "match": [
        "full:portal.example.com",
        "domain:corp.example.com"
      ],
      "action": "direct"
    }
  ]
}

上方片段用於說明規則設計方法，不是可以直接覆蓋用戶端設定的完整檔案。實際欄位應以目前核心的路由結構與用戶端匯出格式為準。匯入前先確認標籤名稱與現有出站一致，否則即使規則命中，也可能找不到對應出口。

多裝置管理應區分共用設定與裝置差異

Windows、macOS、Linux 與 Android 可以使用同一訂閱來源，但系統代理、TUN 權限、安裝套件架構與區域網路介面屬於裝置差異，不應強行複製。共用部分包括訂閱分組、核心路由意圖與測試目標；裝置部分包括本機連接埠、開機啟動、系統權限與應用程式接管方式。移轉時先恢復共用部分，再依裝置逐項設定。這樣能保持邏輯一致，也不會將某個平台的網路介面設定帶到另一個平台。

進階 DNS 設定必須以可觀察結果為核心

只有在預設 DNS 明確造成解析失敗、出口不符或特定網域遭污染時，才需要拆分查詢路徑。設計前先記錄目標網域由哪組 DNS 解析、查詢透過哪個出口，以及結果用於哪條路由。增加快取、備用查詢或依網域分流後，應分別驗證首次查詢與快取命中結果。若設定後出現間歇性失敗，優先簡化為單一路徑，再逐項恢復。DNS 設定不能取代網域路由，也不能修復無法連線的節點。

將學習路線固定為三個循環

第一個循環是連線：理解協定欄位，確認單一節點穩定；第二個循環是接管：掌握系統代理、應用程式代理與 TUN 的邊界；第三個循環是分流：理解網域、IP、DNS 與規則順序。每個循環都依「建立基準—增加一項—驗證結果—記錄回復」執行。遇到新問題時先判斷它屬於哪個循環，再回到對應章節，不必從頭重新安裝。快速操作可回到入門指南，用戶端套件與平台要求可在下載中心核對，具體異常則透過疑難解答依現象查找。

最終設定應簡單到可以重現

一套成熟設定不一定規則最多，而是換一台裝置後仍能依記錄重建。保留訂閱來源說明、用戶端選擇理由、代理入口、路由目標、TUN 使用條件與維護週期六項文件。刪除無法說明用途的開關與規則，定期核對訂閱與自訂設定是否仍然相符。至此，從核心概念到進階管理形成完整閉環：先讓連線成立，再讓流量進入，接著控制流量去向，最後透過日誌、備份與基準確保設定能長期維護。