V2Ray 系統教學：從核心概念到進階設定

// FOUNDATION

核心概念：客戶端、核心、節點與訂閱

先釐清介面層與執行層

日常所說的「V2Ray 客戶端」通常不是單一程式，而是圖形介面、代理核心、設定檔與系統網路設定的組合。v2rayN、v2rayNG、v2flyNG 負責顯示伺服器清單、儲存訂閱、切換代理模式與讀取日誌；真正建立連線、解析協定並處理流量的是核心。v2rayN 可管理桌面系統上的相關核心，v2rayNG 以 Xray 核心為主要執行層，v2flyNG 則面向 V2Fly 核心。理解這層關係後，排錯時就不會把「介面按鈕沒有變化」、「核心啟動失敗」和「遠端伺服器無法連線」混為同一個問題。

圖形客戶端會根據介面中的選擇產生執行設定，接著啟動本機代理連接埠。瀏覽器或作業系統會將請求交給這個本機連接埠，核心再依據協定、傳輸、安全參數與路由規則決定請求如何送出。因此，一個節點能否使用至少涉及四組條件：伺服器位址能否解析、連接埠能否建立連線、驗證參數是否一致、傳輸與安全設定是否相互匹配。任何一組不匹配，都可能表現為連線逾時、握手失敗或啟動後無法存取目標網站。

節點不是訂閱，訂閱也不是代理開關

節點是一組具體的連線參數，通常包含位址、連接埠、使用者識別碼、協定類型、傳輸方式與安全設定。訂閱則是一個可更新的資料入口，能一次回傳多個節點及分組資訊。將訂閱新增至客戶端，只代表客戶端知道要去哪裡讀取設定；還需要執行更新、選擇一台使用中的伺服器，並啟用合適的代理模式，流量才會進入核心。匯入成功後伺服器清單為空，通常是尚未更新、訂閱內容格式不被目前的客戶端識別，或更新請求本身尚未完成。

分享連結與訂閱連結也應分開理解。分享連結通常只描述單一節點，適合臨時匯入或移轉一筆設定；訂閱連結則用於持續維護一組伺服器，更新後可能新增、刪除或調整節點。詳細格式可參閱訂閱連結格式詳解。長期使用時，應保留訂閱分組，不要將所有節點複製成彼此無關的本機項目，否則後續更新無法準確覆蓋舊設定。

協定、傳輸與安全參數是三層設定

VMess、VLESS 等名稱主要描述連線協定及驗證欄位；TCP、WebSocket、gRPC 等屬於傳輸層選擇；TLS、REALITY 等則負責安全握手或身分驗證。客戶端介面常把這些欄位放在同一個編輯視窗中，但它們不能任意互換。伺服器提供的協定是 VLESS 時，客戶端不能只把下拉選單改成 VMess；傳輸設為 WebSocket 時，也必須保持路徑、主機欄位等參數一致。協定基礎差異可繼續閱讀VMess 與 VLESS 的差異。

// CLIENT AND INSTALL

選擇客戶端並完成易於維護的安裝

依平台選擇，不要只看名稱猜測

桌面平台首選 v2rayN。它支援 Windows、macOS 與 Linux，適合需要管理多個訂閱、編輯路由規則、查看詳細日誌及使用 TUN 的使用者。Android 平台優先選擇 v2rayNG；如果訂閱或既有設定明確以 V2Fly 核心執行，也可以選擇 v2flyNG。三款客戶端的職責並不完全相同，不建議為了讓多台裝置的介面看起來一致，而強行使用不相容的平台方案。具體安裝包入口集中在下載頁，其中會依處理器架構與安裝格式分別列出。

選擇安裝包前先確認兩項資訊：作業系統類型與處理器架構。Windows 常見桌面裝置選擇 x64；macOS 需要區分 Apple Silicon 與 Intel；Android 近年的主流裝置通常使用 arm64，無法確認時可選擇通用包；Linux 除了 x64 與 arm64，還需依發行版使用 deb 或 rpm。架構不相容時，程式可能無法啟動；安裝格式不相容則通常會被系統套件管理員直接拒絕。

安裝位置決定後續維護成本

Windows 的桌面版與經典 WPF 版採用不同的介面技術。桌面版適合希望在多種桌面系統上維持相近操作方式的使用者；經典 WPF 版則適合已熟悉傳統 v2rayN 工作流程的 Windows 使用者。若下載的是壓縮檔，應解壓縮至固定且具備寫入權限的位置，不要直接在壓縮檔預覽視窗中啟動。設定、日誌或暫存檔需要正常寫入，路徑頻繁變動也會使捷徑與自動啟動設定失效。

macOS 首次開啟時，應透過系統允許的應用程式啟動流程完成確認，並注意所選安裝包是否對應處理器。Linux 使用者安裝 deb 或 rpm 後，應從桌面選單啟動，並確認系統匣或主視窗可見。Android 安裝完成後，首次啟用連線會出現系統網路連線確認，這是建立本機虛擬網路所需的權限步驟。權限遭拒時，即使節點本身正確，也無法接管裝置流量。

首次啟動只做三項檢查

第一項是確認主視窗可以開啟，且沒有持續出現核心啟動錯誤；第二項是找到日誌入口、訂閱入口與代理模式入口；第三項是確認系統時間與時區正確。部分協定的驗證或安全握手依賴時間，裝置時間偏差過大時，可能表現為參數看似一致卻始終無法建立連線。首次執行期間不要同時修改 DNS、路由、TUN、連接埠與核心選項，否則一旦失敗，很難判斷是哪項設定造成影響。

安裝完成後可以先保留預設的本機監聽設定。常見圖形客戶端會管理 HTTP、SOCKS 或混合代理連接埠，具體數字以客戶端目前設定頁為準，不應因為另一台裝置使用某個連接埠就照搬。若連接埠已被其他程式占用，日誌通常會出現監聽失敗或位址已被使用的提示。此時應關閉衝突程式，或在客戶端中更換本機連接埠，並同步修改依賴該連接埠的瀏覽器、終端機或開發工具設定。

Windows：開啟「工作管理員」確認客戶端程序正在執行
macOS：開啟「活動監視器」搜尋 v2rayN
Linux：使用桌面系統監視器，或執行：
ss -lntp

// SUBSCRIPTION

訂閱匯入、分組與更新策略

完整匯入流程包含四個動作

訂閱管理的穩定流程是：新增訂閱位址、執行更新、檢查伺服器清單、選擇使用中的伺服器。只將連結貼到編輯框並儲存，不代表節點已經寫入清單。v2rayN 中應先建立清楚的訂閱分組名稱，再執行對應分組的更新；v2rayNG 與 v2flyNG 也應在訂閱設定中儲存位址後主動重新整理。更新結束後查看提示訊息，確認取得的是可識別的設定，而不只是看到請求完成。

複製連結時要保留完整內容。聊天工具或網頁排版可能在連結中插入空格、換行，某些參數也可能因只複製可見部分而遺失。遇到匯入後為空時，先重新複製原始位址，再確認連結開頭、查詢參數與結尾字元完整。不要手動刪除看似多餘的編碼字元來「修復」訂閱，因為這些字元可能是必要的資料內容。

分組用於控制更新範圍

訂閱分組不只是介面分類。它建立伺服器項目與來源之間的關聯，讓客戶端知道更新時哪些舊項目需要替換。建議每個訂閱來源分別建立分組，名稱使用可識別的用途或裝置範圍，不要全部命名為「預設」。多個來源混在同一分組時，更新後較難判斷某個節點來自哪裡，也容易在清理失效項目時誤刪仍在使用的設定。

手動新增的伺服器應放在本機設定分組或加上明確標記，避免被訂閱更新覆蓋。需要暫時修改訂閱節點時，先複製成獨立項目，再編輯複製項。直接修改受訂閱管理的節點，下一次更新可能會還原遠端內容。客戶端提供的「更新時刪除舊伺服器」、「保留本機修改」等選項含義不同，啟用前應確認分組內是否有必須保留的手動項目。

更新頻率依變動需求決定

訂閱不是更新得越頻繁越好。日常使用時，可在節點出現變化、目前伺服器無法使用，或來源明確通知設定調整時更新。自動更新間隔過短會產生不必要的請求，也可能在客戶端啟動時延長準備時間。較穩妥的策略是保留適度的自動更新週期，並在需要時手動觸發。行動網路環境中，也應避免在連線頻繁切換時連續重新整理多次，以免將網路中斷誤判為訂閱失效。

更新失敗時要區分請求失敗與解析失敗。請求失敗通常表現為逾時、名稱解析錯誤或連線遭拒，應檢查目前網路、系統時間與訂閱位址是否可存取；解析失敗則表示已取得內容，但客戶端無法識別其格式，可能回傳了登入頁面、提示文字或不相容的資料結構。此時繼續按更新不會改變結果，應查看日誌中的回應類型，並確認目前客戶端是否支援該訂閱格式。

測速結果只適合在相同條件下比較

客戶端中的延遲測試、連通性測試與下載測試並不是同一項指標。延遲測試通常只反映特定探測方式的往返時間，無法直接代表網頁載入或大型檔案傳輸效果；連通性測試關注目標是否可達；實際使用體驗還會受到頻寬、封包遺失、目標網站與目前網路影響。因此，節點排序應在相同網路、相同測試方式及接近的時間內進行，不要直接比較不同裝置上的數字。

選擇使用中的伺服器後，應透過一至兩個穩定目標進行驗證，而不是連續切換大量節點。頻繁切換會讓 DNS 快取、既有連線與應用程式重試相互疊加，日誌也更難閱讀。如果只有特定應用程式無法使用某個節點，應先記錄代理模式、目標網域與失敗時間，再到日誌中定位對應連線。更多介面位置說明可參閱v2rayN 介面功能分區速覽。

訂閱排錯記錄建議：
1. 分組名稱與更新時間
2. 更新提示或錯誤文字
3. 更新後伺服器項目數量是否變化
4. 目前使用中的伺服器名稱
5. 使用的代理模式與測試目標

// PROXY MODE

系統代理、應用程式代理與流量接管範圍

本機連接埠是流量進入核心的入口

客戶端啟動後，通常會在本機監聽一個或多個代理連接埠。HTTP 代理適合支援標準系統代理的瀏覽器與桌面應用程式；SOCKS 代理可供支援該協定的軟體個別填寫；混合連接埠則可在同一個連接埠上相容多種入口。連接埠本身不決定流量最終使用哪個節點，只負責將請求交給核心。節點選擇、DNS 處理與路由規則仍由執行設定決定。

檢查代理是否生效時，需要同時確認「核心正在監聽」與「應用程式確實指向該入口」。客戶端顯示執行中，但系統代理未啟用時，遵循系統設定的應用程式不會自動進入核心；瀏覽器設定了獨立代理時，即使系統代理關閉，該瀏覽器仍可能繼續使用本機連接埠。排錯前應先確認目前使用哪種接管方式，避免系統設定、瀏覽器擴充功能與應用程式內代理同時存在。

系統代理適合一般桌面應用程式

啟用系統代理後，客戶端會修改作業系統的代理設定，支援系統代理的應用程式會將 HTTP 或 HTTPS 請求交給本機連接埠。這種方式設定簡單，適合瀏覽器、部分通訊軟體與常見桌面工具。它的限制也很明確：不讀取系統代理的程式、使用自訂網路堆疊的應用程式、部分命令列工具與某些 UDP 流量，可能不會經過該入口。

關閉客戶端前應正常退出，或先清除系統代理。若程式異常結束，系統可能仍保留指向本機連接埠的設定，但該連接埠已沒有程序監聽，結果就是瀏覽器突然無法存取網路。此時先檢查系統代理是否仍指向回送位址，再關閉該設定或重新啟動客戶端。反覆更換節點無法解決本機連接埠不存在的問題。

應用程式內代理用於精確控制

開發工具、終端機程式與部分瀏覽器允許個別指定代理。應用程式內設定的優點是範圍清楚，不會影響其他軟體；缺點是每個程式都需要維護位址與連接埠。代理位址通常填寫 127.0.0.1，連接埠必須與客戶端設定頁目前的值一致。若應用程式執行於容器、虛擬機器或另一台裝置中，回送位址指向的是它自己的網路環境，不能直接代表主機。

以命令列驗證時，可以明確指定本機代理，藉此區分「代理鏈路有問題」還是「程式沒有讀取系統代理」。以下命令使用示例網站，只驗證 HTTP 請求能否透過指定入口送出。連接埠數字應替換為客戶端實際顯示的本機連接埠，而不是照抄其他裝置的設定。

curl --proxy http://127.0.0.1:本機連接埠 https://example.com/

若不希望在命令中出現說明文字，可先從客戶端設定頁讀取連接埠，再使用實際數字執行。回傳正常網頁回應，表示本機 HTTP 代理與使用中的節點基本可用；命令提示無法連線本機位址，表示核心未監聽該連接埠或連接埠填寫錯誤；連線建立後長時間沒有回應，則需要繼續查看節點、路由與 DNS 日誌。

// ROUTING

路由分流：比對條件、順序與預設出口

路由只決定出口，不負責修復節點

路由分流的工作，是依據網域、IP、連接埠、網路類型等條件，將連線交給代理出口、直連出口或阻擋出口。它建立在基本連線已可用的前提上。如果使用中的節點本身無法連線，增加更多規則不會讓鏈路恢復；如果 DNS 回傳異常結果，網域規則也可能無法如預期命中。因此，設定路由前應先在簡單模式下驗證節點，再逐步加入規則。

常見規則集包含 domain、ip、port、network 與 protocol 等欄位。網域規則適合依網站分類，IP 規則適合比對明確位址範圍，連接埠規則用於限定服務類型，網路規則可區分 TCP 與 UDP。規則的 outboundTag 會指向既有的出口標籤，標籤拼寫不一致時，即使比對條件正確，也無法得到預期結果。

規則順序由具體到一般

路由通常依清單順序判斷，先命中的規則先執行。因此，較具體的例外規則應放在較寬泛的規則之前。例如某個子網域需要代理，而其所屬網域集合整體直連，子網域規則就應排在集合規則之前。將「所有網域」或「所有 IP」這類兜底條件放在最上方，會讓後續規則失去作用。編輯完成後，應由上到下閱讀一次，確認每條規則的涵蓋範圍不會提前吞掉下一條。

domain: 前綴用於比對指定網域及其子網域，full: 只比對完整網域，keyword: 依關鍵字比對，regexp: 使用正規表示式。一般設定優先使用明確網域或維護良好的 geosite 分類，只有無法用一般規則表達時才考慮正規表示式。正規表示式範圍過寬會造成意外命中，也會增加後續維護成本。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": [
          "full:service.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "udp",
        "port": "53",
        "outboundTag": "dns-out"
      }
    ]
  }
}

以上片段展示欄位結構，不包含伺服器驗證資訊。第一條將兩個示例網域交給代理出口；第二條讓私有位址走直連，避免存取區域網路裝置時繞行；第三條將 UDP 的 DNS 請求交給專用出口。實際使用時必須確認執行設定中確實存在 proxy、direct 與 dns-out 標籤。若客戶端透過介面產生標籤，應以產生結果為準。

網域策略會影響 IP 規則何時參與

domainStrategy 控制路由遇到網域請求時是否解析 IP。使用 AsIs 時，路由主要依原始網域比對，不會只為了 IP 規則主動解析；IPIfNonMatch 表示網域規則未命中時才解析位址，以便繼續比對 IP 規則；IPOnDemand 則會在可能需要 IP 比對時較早執行解析。選擇策略時應配合 DNS 設定，不要將策略名稱理解為連線速度檔位。

若規則以網域為主，通常應先確保網域資訊能保留至路由層；若大量依賴 geoip 分類，則應確認 DNS 結果穩定，且解析路徑符合預期。某些應用程式直接連線 IP，不會攜帶可供比對的網域，這時 geosite 或一般網域規則無法生效，需要 IP 規則或其他識別方式。反過來，內容傳遞網路的位址可能變動，不適合長期手動撰寫單一公網 IP。

用日誌驗證命中，不要靠結果猜測

路由排錯應記錄目標網域、存取時間、最終出口與命中規則。客戶端日誌層級過低時，可能只能看到連線成功或失敗，無法看到路由決策；除錯期間可暫時提高日誌詳細程度，完成後再恢復一般層級，避免日誌快速增長。若目標未命中預期規則，依序檢查規則順序、網域寫法、出口標籤與 DNS 策略。

自訂規則應分批加入。先撰寫一條範圍明確的網域規則並驗證，再加入分類規則與兜底規則；每次變更後重新載入設定，確認日誌中沒有解析錯誤。完整語法與優先順序案例可參閱V2Ray 自訂路由規則寫法。當設定越來越長時，應保留規則目的註記，並定期刪除已失去用途的例外項目。

// TUN MODE

TUN 模式：完整接管、DNS 與排除項目

TUN 解決的是接管範圍問題

TUN 會建立虛擬網路介面，讓更多不讀取系統代理設定的應用程式流量進入客戶端。它適合需要處理 UDP、命令列程式、獨立網路堆疊應用程式，或希望統一執行路由規則的情境。TUN 不是更快的代理模式，也不會自動改善節點品質；它改變的是流量進入核心的路徑。基本節點、訂閱與路由設定仍沿用原有邏輯。

啟用 TUN 前應先使用系統代理驗證使用中的節點可用。若在系統代理模式下也無法連線，直接開啟 TUN 只會增加虛擬介面、DNS 與路由表三個新變數。正確順序是：確認客戶端與核心正常，確認節點連線正常，確認基本規則正常，最後再啟用 TUN。如此發生問題時，就能將範圍縮小至權限、虛擬介面或接管規則。

權限與系統網路元件必須就緒

建立虛擬介面、修改路由與處理 DNS 通常需要額外的系統權限。Windows 上應依客戶端提示完成權限確認，macOS 需要允許對應的網路元件，Linux 則要確保目前的執行方式具備管理網路介面的能力。Android 客戶端透過系統提供的網路連線介面建立本機通道，首次啟用時需要使用者確認。若權限步驟未完成，介面可能短暫顯示正在啟動，隨後在日誌中回報介面建立失敗。

與其他虛擬網路軟體、企業網路元件或安全工具同時執行時，路由表可能遭多方修改。表現包括區域網路無法存取、DNS 請求走向異常，以及網路切換後連線中斷。排查時應暫時只保留一個負責接管流量的工具，確認 TUN 能單獨正常運作後，再逐一恢復其他元件。不要在多個程式中同時啟用預設路由接管。

DNS 必須與路由策略一併設計

TUN 模式下，網域解析不僅決定目標 IP，也會影響網域規則是否能取得足夠資訊。客戶端可能提供 DNS 劫持、虛擬位址映射、遠端 DNS 與本機 DNS 等設定。設定目標不是堆疊最多選項，而是確保查詢進入預期路徑、結果能回到發起應用程式，並讓路由層保留正確的網域關聯。若網頁可透過 IP 存取但網域失敗，應先檢查 DNS，而不是立即更換協定。

區域網路名稱、列印裝置與路由器管理網域通常依賴本機 DNS。若所有查詢都交給遠端解析，這些名稱可能無法識別。可以為私有位址、區域網路網域與系統所需的解析保留直連路徑，再依規則處理其他查詢。啟用虛擬位址機制時，也應確保對應位址範圍只由目前客戶端管理，避免與公司網路、容器網路或既有虛擬網段重疊。

排除項目用於保護本機資源

常見排除範圍包括回送位址、私有網路位址、區域網路裝置，以及不應進入代理鏈路的系統服務。排除規則應盡量精確。排除整個應用程式雖然簡單，但該應用程式的所有連線都會繞過路由；排除過大的位址範圍，則可能讓本應命中的目標直接連線。調整前先明確保護對象，再選擇依應用程式、位址或網域排除。

行動裝置還需留意依應用程式代理。只選擇指定應用程式時，未勾選的軟體不會進入通道；選擇排除模式時，清單中的應用程式會直連。兩種語意相反，移轉設定後應重新檢查。桌面端若需要讓虛擬機器或容器存取主機代理，還涉及網路邊界與轉送設定，不應簡單地將監聽位址開放至所有介面。

Windows DNS 快取重新整理：
ipconfig /flushdns

Linux 查看路由：
ip route

macOS 查看預設路由：
route -n get default

// MAINTENANCE

日常維護、日誌閱讀與故障隔離

維護對象分為程式、設定與執行狀態

客戶端維護不應只關注安裝包更新。程式檔案決定介面與功能，設定資料儲存訂閱、伺服器、路由與偏好，執行狀態則包括目前節點、系統代理、TUN、日誌與網路介面。升級程式不會自動修復錯誤訂閱，重新匯入訂閱也不會解決連接埠衝突。每次處理問題前先判斷屬於哪一層，可以減少無關操作。

設定備份至少應涵蓋訂閱位址、自訂路由、DNS 設定與手動節點。備份檔案要與程式安裝包分開儲存，並記錄適用的客戶端。v2rayN、v2rayNG 與 v2flyNG 的設定組織方式不同，不應直接相互覆蓋整個資料目錄。還原時先安裝相符平台的客戶端，再透過其提供的匯入方式還原可識別內容，最後檢查本機路徑、連接埠與權限。

依時間與層級閱讀日誌

有效的日誌分析從重現時間開始。先清理或標記舊日誌，執行一次明確操作，例如更新訂閱、啟動核心或存取某個目標，然後立即查看新增記錄。不要從數千行歷史內容中隨機搜尋「error」，因為早期錯誤可能已經解決。記錄操作發生的準確時間，可以將介面行為與核心輸出對應起來。

啟動階段重點查看設定解析、連接埠監聽與核心程序；連線階段重點查看 DNS、路由出口、握手與逾時；執行階段重點查看網路切換、介面關閉與重複重試。連線遭拒通常表示目標連接埠明確拒絕，或本機連接埠不存在；逾時表示在限定時間內未收到回應；名稱解析失敗指向 DNS；設定解析失敗則表示核心尚未進入連線階段。這些錯誤不能用同一種方式處理。

一次有效的故障記錄應包含：
- 作業系統與客戶端名稱
- 目前接管方式：系統代理、應用程式代理或 TUN
- 問題發生時間
- 使用中的伺服器與訂閱分組
- 能重現問題的目標
- 對應時段的日誌文字
- 最近一次設定變更

使用最小化設定隔離變數

當複雜設定出現異常時，先建立最小路徑：保留一個已知可用的伺服器、關閉 TUN、使用系統代理，停用自訂路由與額外 DNS 規則。若最小路徑恢復，再依 DNS、路由、TUN、應用程式排除項目的順序逐項加回，每次只變更一類設定。如此可以明確判斷是哪一層引入故障。

如果最小路徑仍然失敗，繼續檢查本機連接埠、系統時間、目前網路與伺服器參數。切換至另一條網路只是一種隔離手段，用於判斷問題是否與目前的接入環境有關，不能取代日誌分析。若同一設定在不同網路中都失敗，應回到節點參數與核心輸出；若只有某一網路失敗，則檢查 DNS、路由、網路驗證頁面，以及該網路對長連線的處理方式。

更新與回復都要能驗證

更新客戶端前記錄目前可用狀態，包括使用的模式、活動分組與重要自訂設定。更新後先驗證程式能啟動、訂閱能讀取、節點能連線，再恢復進階功能。若升級後出現問題，應區分設定移轉失敗與執行行為變化。直接覆蓋舊目錄可能保留不再適用的檔案，完全清空又可能遺失訂閱與規則，因此較穩妥的方法是保留原目錄副本，在獨立位置完成驗證。

回復時不要同時回復訂閱內容與客戶端程式，否則無法判斷是哪一項恢復了功能。先回復程式並使用同一份設定測試；仍有問題時再檢查設定變化。日常也應清理過期伺服器、重複分組與已不再使用的路由例外。設定越精簡，升級後的行為就越容易驗證。

// ADVANCED PATH

進階路線：從可用設定到可解釋設定

進階的標準不是選項數量

穩定設定的核心，是每一項都有明確目的，並能說明它影響哪一層。能夠匯入訂閱並啟用代理只是起點；能夠解釋某段流量為何走代理、為何直連、DNS 在哪裡解析、TUN 接管了哪些應用程式，才算建立可維護的系統。進階過程不應一次開啟所有進階開關，而應圍繞一個實際需求增加一項能力，並留下驗證方法。

建議將學習路徑拆成四層。第一層是客戶端操作，掌握訂閱、使用中的伺服器、日誌與系統代理；第二層是連線結構，理解協定、傳輸、安全參數及核心關係；第三層是流量控制，掌握網域策略、出口標籤、DNS 與 TUN；第四層是維護工程，能備份設定、隔離故障、評估變更並安全回復。前一層尚未穩定時，不必急著進入下一層。

建立自己的設定基線

設定基線是一份已驗證可用、內容盡量精簡的設定。它應包含一個訂閱分組、一台使用中的伺服器、預設本機連接埠、基本系統代理與少量必要規則。每次新增設定前先複製基線，記錄變更目的與驗證結果。發生問題時可立即回到基線，判斷故障來自新增設定還是外部網路變化。

基線也應記錄平台差異。同一份訂閱在 v2rayN、v2rayNG 與 v2flyNG 中的介面位置、DNS 實作與路由產生方式可能不同，不要要求三台裝置的每個開關完全一致。需要保持一致的是目標行為，例如「區域網路直連」、「指定業務走代理」、「未命中規則使用預設出口」，而不是介面截圖中的選項順序。

將規則寫成可檢查的決策表

規則數量增加後，可以先在文字中寫出決策表，再轉換為客戶端設定。每一行至少包含比對對象、比對條件、預期出口與驗證目標。例如「私有位址—geoip:private—direct—存取路由器管理頁」、「指定網域—domain 規則—proxy—觀察路由日誌」。這種寫法能發現規則重疊，也方便更換客戶端後重新實作。

預設出口必須明確。所有具體規則都未命中時，流量最終要去哪裡，是路由設計中最重要的邊界。採用代理作為預設出口時，應明確哪些本機資源需要提前直連；採用直連作為預設出口時，應明確哪些目標必須進入代理。不要依賴自己記得規則順序，應讓設定結構本身表達優先級。

設定變更記錄範例：

目標：讓區域網路資源保持直連
比對：geoip:private
出口：direct
位置：精確業務規則之後、公網兜底規則之前
驗證：存取本機閘道與區域網路裝置
回復：停用該規則並重新載入設定

逐步學習 DNS 與網路觀察工具

進入進階階段後，建議掌握基本的名稱解析與連接埠觀察方法。nslookup 或 dig 可以確認網域由哪個解析器回傳結果；ipconfig、ip route、route 等工具可以查看介面與路由；ss 能確認本機監聽連接埠。使用這些工具的目的不是取代客戶端日誌，而是從作業系統一側驗證客戶端宣稱建立的狀態是否確實存在。

觀察結果必須結合上下文。網域能夠解析不代表代理連線一定成功，連接埠正在監聽也不代表遠端節點可用，TUN 介面存在也不代表所有應用程式都已被接管。每個工具只回答一個問題。將多個問題拆開驗證，可以避免看到一項正常結果就過早結束排查。

形成長期維護閉環

完整閉環由「記錄目前狀態—提出單一變更—執行驗證—保留或回復」組成。更新訂閱、切換核心設定、增加路由與啟用 TUN 都應遵循這個流程。變更成功後記錄最終結果，失敗則恢復基線並保留錯誤日誌。隨著記錄累積，常見問題會從反覆試錯轉變為可重複使用的判斷路徑。

客戶端選擇也可以定期複核。桌面端以 v2rayN 作為主要管理工具，Android 則依核心與設定需求在 v2rayNG 與 v2flyNG 之間選擇。三者的橫向差異可閱讀v2rayN、v2rayNG、v2flyNG 客戶端對照。選擇依據應是平台、設定相容性與維護需求，而不是介面選項數量。

完成本手冊後，可以回到快速入門教學重新走一遍主要流程，檢查每一步是否都能說明其作用；需要更換或補裝客戶端時，前往下載頁依平台選擇安裝包；遇到具體錯誤時，使用疑難解答依現象搜尋。最終目標不是保存一份永遠不變的設定，而是掌握能夠驗證、調整與恢復的工作方法。