V2Ray 從零到進階完整手冊

一、核心概念：先釐清用戶端、核心與設定的界線

圖形化用戶端不等於代理核心

學習 V2Ray 時最容易混淆的地方，是把圖形化用戶端、代理核心、節點設定與系統代理視為同一件事。實際上，它們位於不同層級。v2rayN、v2rayNG 與 v2flyNG 提供視窗、訂閱清單、節點選擇、日誌與開關等互動介面；Xray 或 V2Fly 核心負責解析設定、建立傳輸連線、比對路由規則並提供本機代理連接埠；訂閱或單一分享連結負責將伺服器位址、連接埠、使用者識別碼、協定與傳輸參數交給用戶端；系統代理與 TUN 則決定應用程式流量如何進入本機核心。只有四個層級都正確銜接，瀏覽器或其他程式的請求才會依預期路徑轉送。

因此，「用戶端已顯示執行中」只能證明本機程序已啟動，不能單獨證明訂閱有效、節點可連線或應用程式流量已進入代理。排錯時應依資料流逐層檢查：先確認設定能被用戶端識別，再確認核心啟動成功，接著確認本機監聽連接埠存在，最後確認系統或應用程式確實使用該連接埠。拆開檢查這些階段，會比反覆點擊連線按鈕更快找到問題。

入站、出站與路由如何協同運作

核心設定中常見三個關鍵部分。入站負責接收本機應用程式送出的請求，例如本機 SOCKS 或 HTTP 代理連接埠；出站描述請求離開本機後的處理方式，通常包括遠端代理、直連與阻斷；路由位於兩者之間，依據網域、IP、協定類型或程序條件選擇某個出站。圖形化用戶端將這些概念包裝成「系統代理」「路由模式」「繞過區域網路」「封鎖特定連線」等選項，但底層仍遵循接收、判斷、轉送的流程。

網域解析在整條鏈路中也有獨立位置。應用程式可能先由系統解析網域，再將 IP 交給代理；也可能直接將網域交給本機代理，由核心依設定進行解析。兩種路徑會影響網域規則是否能命中，也會影響分流結果。初學階段不必立即修改複雜的 DNS 項目，只需知道：如果某條網域規則看似正確卻未生效，應檢查請求進入核心時仍是網域，還是已經變成 IP。

協定名稱與傳輸參數應分開理解

VMess、VLESS、Trojan 等名稱通常描述代理協定層；TCP、WebSocket、gRPC 等屬於傳輸方式；TLS、REALITY 等則涉及連線安全與握手特徵。分享連結會將多層參數壓縮成一串字串，匯入後再由用戶端還原為核心可讀取的設定。不能只因協定名稱相同，就認為兩個節點設定可以互換：傳輸方式、主機名稱、路徑、安全選項與伺服器端設定必須彼此吻合。手動編輯節點時尤其不要憑經驗補值，缺少的資訊應回頭向設定提供者確認。

完成本章後，應能用一條清楚的鏈路描述請求：應用程式發出請求，系統代理或 TUN 接管流量，本機入站接收請求，路由選擇出站，核心依節點設定建立連線。後續所有設定都可以放回這條鏈路中理解。

二、選擇用戶端：依平台、核心與維護方式做決定

桌面平台優先選擇 v2rayN

Windows、macOS 與 Linux 的桌面使用情境，首選 v2rayN。它將訂閱分組、伺服器清單、系統代理、路由、日誌與 TUN 集中在同一個介面，適合從基礎使用逐步進階到規則管理。Windows 可依介面技術與使用習慣選擇桌面版或經典 WPF 版；macOS 需依處理器架構選擇對應安裝包；Linux 則依發行版的套件體系選擇 deb 或 rpm。具體入口與目前檔名由下載頁統一展示，本手冊不記錄固定版本號。

同一份訂閱在不同桌面系統上的節點內容通常相同，但系統代理、權限管理、憑證儲存、開機啟動與防火牆行為並不相同。移轉設定時可以沿用訂閱位址與自訂規則的思路，不應直接假設所有本機設定都能照搬。尤其是 TUN 模式，它依賴各系統提供的虛擬網路介面與權限機制，排錯方法需結合目前平台。

Android 上區分 v2rayNG 與 v2flyNG

Android 平台首選 v2rayNG，它採用 Xray 核心，適合需要較廣泛協定與傳輸特性支援的設定。v2flyNG 使用 V2Fly 核心，可作為偏向 V2Fly 生態系的備選。兩者都能完成訂閱匯入、節點切換與本機 VPN 接管，但核心能力、設定項目名稱與部分設定相容性可能不同。如果訂閱明確依賴某項核心特性，應先確認用戶端使用的核心是否支援，而不是只比較介面外觀。

安裝包架構也需要選擇。較新的主流 Android 裝置通常使用 arm64，通用版則適合無法確認架構或需要涵蓋更多裝置類型的情況。架構只決定安裝包中的本機程式碼類型，不會改變訂閱內容。若系統提示安裝包與裝置不相容，先改用通用版即可，不必重新建立訂閱。

不要以節點數量取代相容性判斷

選擇用戶端的核心不在於「能匯入多少筆記錄」，而在於目前設定能否被核心完整解析，以及系統流量是否能穩定交給核心。訂閱清單顯示節點，只代表文字格式或分享連結已被識別；連線時仍可能因傳輸參數缺失、核心不支援、系統時間偏差或網路無法連線而失敗。更可靠的判斷方式，是選取一個已確認可用的設定，在目標用戶端中觀察核心能否啟動、日誌是否出現設定錯誤，以及本機代理是否能處理請求。

若同時使用桌面與 Android，可以讓不同裝置引用同一個訂閱位址，但建議分別維護各用戶端的本機設定。桌面端常用系統代理與細分路由，行動裝置則更常依賴系統提供的 VPN 介面；兩者對背景執行、電池策略與區域網路存取的處理不同。訂閱負責同步遠端設定，不負責同步每台裝置的流量接管策略。

完成選型後，應固定一個主要用戶端進行後續學習。頻繁在多個用戶端之間切換，容易把介面差異誤判為設定故障。桌面從 v2rayN 開始、Android 從 v2rayNG 開始，是較清楚的學習路徑。

三、安裝準備：系統架構、權限與首次啟動檢查

下載前確認系統與處理器架構

安裝前先確認三項資訊：作業系統類型、處理器架構，以及目前帳戶是否具備安裝或網路設定權限。Windows 使用者還需決定使用新一代桌面介面或經典 WPF 介面；macOS 使用者需區分 Apple Silicon 與 Intel；Linux 使用者應確認發行版使用 deb 或 rpm 套件，並區分 x64 與 arm64；Android 使用者若能確認裝置架構，可選擇 arm64，否則使用通用版。架構選錯通常會表現為無法安裝或啟動，而不是節點連線錯誤。

下載入口應從站內用戶端下載頁進入。下載頁依四個平台整理安裝包，並提供對應架構說明。安裝包更新時檔名可能變更，因此不建議把某個舊檔名寫進長期筆記。較穩妥的記錄方式是保存用戶端名稱、平台與架構，例如「v2rayN、macOS、arm64」，需要重新安裝時再進入對應平台面板。

首次啟動先檢查目錄與權限

桌面用戶端通常需要儲存訂閱、日誌、路由規則與介面偏好。若程式放在唯讀目錄，或目前帳戶無法寫入設定目錄，可能出現設定無法儲存、重新啟動後訂閱消失、核心解壓縮失敗等問題。首次啟動後先修改一個非關鍵的介面選項再重新啟動，確認設定能保留。若用戶端提供日誌目錄入口，也應確認該目錄可以正常建立檔案。

系統代理修改、開機啟動與 TUN 模式所需的權限並不完全相同。一般系統代理通常只會修改目前使用者的代理設定；TUN 需要建立虛擬網路介面或調整路由表，往往需要更高權限。基礎階段先使用系統代理完成連線，不要在首次啟動時同時開啟 TUN、複雜路由、區域網路共用與自訂 DNS。一次只引入一個變數，遇到錯誤時才容易回復。

1. 安裝用戶端。選擇與作業系統、處理器架構相符的安裝包，完成系統要求的安裝步驟。
2. 啟動並檢查寫入能力。確認用戶端能儲存設定、建立日誌並正常關閉。
3. 確認核心啟動。先不要匯入大量設定，觀察日誌中是否有缺少元件、連接埠占用或權限錯誤。
4. 記錄預設本機連接埠。後續設定應用程式代理或定位衝突時，需要知道 SOCKS、HTTP 或混合連接埠。

了解本機監聽連接埠

核心啟動後通常會在迴路位址監聽一個或多個本機連接埠。迴路位址僅供本機存取，通常寫作 127.0.0.1。SOCKS 入站適合支援 SOCKS 代理的應用程式，HTTP 入站適合支援 HTTP 代理的應用程式，混合連接埠則可能同時接受兩類請求。實際連接埠以用戶端設定頁顯示為準，不應照抄他人的數字。連接埠被其他程式占用時，核心通常無法啟動，日誌會出現監聽失敗或位址已被使用等資訊。

可以在桌面系統中使用網路狀態工具確認連接埠是否正在監聽。以下指令僅用於查看本機監聽狀態，範例中的連接埠 10808 需替換為用戶端介面實際顯示的值。Windows 可在終端機執行第一條，macOS 與 Linux 可執行第二條：

netstat -ano | findstr 10808
lsof -nP -iTCP:10808 -sTCP:LISTEN

如果沒有輸出，先查看用戶端日誌，不要立即修改訂閱。若連接埠已被另一個程序占用，可以關閉衝突程式，或在用戶端中改用未占用的連接埠，然後同步更新手動設定代理的應用程式。由用戶端自動管理的系統代理通常會跟著連接埠變更；瀏覽器、開發工具或終端機中的手動代理則不會自動更新。

安裝階段的目標不是一次開啟所有功能，而是建立可重現的最小環境。記錄用戶端名稱、系統架構、本機連接埠與設定目錄位置，後續升級、移轉與排錯都會更直接。

四、訂閱管理：匯入、更新、分組與格式識別

訂閱位址與單一分享連結的差異

訂閱位址通常會回傳一組設定，用戶端更新時會重新取得，並覆寫或合併該分組內容；單一分享連結只代表一筆節點記錄，匯入後不會自動跟隨遠端清單變更。長期使用時，應優先將訂閱位址放入獨立分組，並為分組設定清楚的名稱。臨時測試的分享連結可以放在單獨分組，避免更新訂閱時分不清哪些項目由遠端管理、哪些是本機手動新增。

常見訂閱內容可能是經過 base64 編碼的多行分享連結，也可能是用戶端可直接解析的原生 JSON 或其他結構。base64 是編碼方式，不是加密協定，也不決定節點採用 VMess、VLESS 還是 Trojan。格式識別失敗時，不要反覆更換代理模式；應先確認回傳內容是否完整、用戶端是否支援該訂閱格式，以及複製位址時是否混入空格或換行。關於格式之間的關係，可繼續閱讀訂閱格式詳解。

建立易於維護的分組結構

分組的價值不只是整理清單，也能將更新策略與本機規則分隔開。建議至少區分「日常訂閱」「臨時測試」與「手動設定」。日常訂閱保留自動更新；臨時測試依需求更新；手動設定則避免被遠端覆寫。若同一個位址重複加入多個分組，更新後會出現內容重複，測速、排序與選擇目前節點時都更混亂。發現重複記錄時，應先檢查訂閱清單，而不是逐筆刪除節點。

更新訂閱前，用戶端需要先存取訂閱位址。這個請求可能透過目前網路直接取得，也可能依用戶端選項經由既有代理取得。如果目前節點已失效，而訂閱更新又設定為經由代理進行，就可能形成「需要更新才能取得可用節點，但更新請求又依賴舊節點」的循環。遇到這種情況，可以暫時切換為直連更新，或使用一筆已確認可用的設定完成更新。更新成功後再恢復原本策略。

• 新增訂閱位址
• 命名分組
• 執行更新
• 檢查節點欄位
• 選擇目前設定

更新後要檢查什麼

看到「更新完成」並不代表每筆設定都可用。更新後的檢查分為三步。第一步查看分組是否產生節點，若為空，重點檢查回傳格式與篩選條件；第二步隨機開啟一筆設定，確認位址、連接埠、協定、傳輸與安全選項沒有明顯缺漏；第三步選擇一筆設定啟動核心，觀察日誌是否出現解析錯誤。不要只依節點名稱判斷內容，因為名稱只是備註，不會參與實際連線。

訂閱自動更新週期不宜短到頻繁中斷用戶端使用。合理做法是依設定提供者的變更頻率設定，並保留手動更新入口。桌面裝置長時間執行時，可以讓用戶端以固定間隔檢查；行動裝置受背景限制，自動工作可能被系統延遲，此時手動重新整理更可靠。無論是否自動更新，都應知道最近一次成功更新是在何時，以便判斷故障來自舊設定還是目前網路。

訂閱更新失敗的分層排查

更新失敗通常可歸入四類原因：位址本身已變更；目前網路無法存取訂閱服務；回傳內容不是用戶端支援的格式；用戶端的直連或代理更新策略不合適。先在不公開位址的前提下確認連結是否完整，再切換取得策略，接著查看更新日誌中的 HTTP 狀態、解析提示或逾時資訊。如果回應成功但解析失敗，問題在格式層；如果連回應都沒有，問題在網路或位址層。完整排查流程可參考訂閱更新失敗處理步驟。

穩定的訂閱管理應做到三件事：依分組隔離來源、更新路徑可切換、更新結果可驗證。建立這個習慣後，即使遠端清單變更，也不會影響本機自訂規則與臨時測試設定。

五、代理模式：系統代理、應用程式代理與全域選擇

系統代理控制哪些程式

系統代理的作用，是將代理位址寫入作業系統提供的網路設定。遵循系統代理的瀏覽器與桌面程式會將請求交給用戶端本機連接埠，但並非所有程式都會讀取這些設定。部分命令列工具、遊戲、虛擬機器、容器或自行實作網路堆疊的軟體可能忽略系統代理。出現「瀏覽器可用但某個應用程式不可用」時，首先判斷該應用程式是否遵循系統代理，而不是直接認定節點不穩定。

用戶端介面中的「清除系統代理」「自動設定系統代理」「保持不變」等選項，控制的是作業系統設定，不等同於核心路由模式。系統代理回答「流量是否進入核心」，路由模式回答「進入後要走哪個出站」。這兩個開關經常被混為一談。正確順序是先確認流量已進入，再討論直連、代理或阻斷規則。

手動應用程式代理適合精確測試

支援代理設定的應用程式可以直接填寫 127.0.0.1 與用戶端顯示的本機連接埠。這只會影響目標應用程式，不會修改整個系統，適合驗證本機入站是否運作，也適合需要獨立代理的開發工具。選擇代理類型時必須與監聽連接埠一致：SOCKS 設定要指向 SOCKS 入站，HTTP 設定要指向 HTTP 或相容的混合入站。類型填錯時，雖然可以連上連接埠，協定握手仍會失敗。

終端機程式通常會透過環境變數讀取 HTTP 代理。以下範例使用本機位址與示例連接埠，只在目前終端機工作階段生效；關閉終端機後通常需要重新設定。實際使用前應核對用戶端連接埠，並了解目標工具是否支援這些變數。

export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809
export ALL_PROXY=socks5://127.0.0.1:10808

Windows PowerShell 可在目前工作階段使用環境變數形式：

$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
$env:ALL_PROXY="socks5://127.0.0.1:10808"

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

全域代理通常表示進入核心的請求優先交給目前代理出站，適合短時間驗證連線能力。規則模式依網域、IP 或其他條件選擇代理、直連或阻斷，是日常使用的主要方式。直連模式會讓進入核心的請求直接存取目標，常用於對照測試，以判斷問題是否由遠端節點造成。各用戶端的模式名稱可能略有不同，但判斷邏輯基本一致。

排錯時可以利用三種模式建立對照：全域代理失敗而直連正常，優先檢查節點與遠端傳輸；全域代理正常但規則模式失敗，優先檢查路由命中；關閉系統代理後應用程式仍經由代理，表示應用程式本身可能設定了手動代理，或目前啟用了 TUN。對照測試一次只修改一個開關，測試後再恢復原本設定。

代理模式的關鍵不在於「哪個涵蓋範圍最大」，而在於選擇符合應用程式行為的接管方式。系統代理適合一般桌面流量，手動代理適合精確控制，TUN 則留待確認基礎鏈路穩定後再啟用。

六、路由分流：從規則順序到網域與 IP 比對

路由規則依序比對

路由分流的基本動作，是依請求特徵選擇代理、直連或阻斷出站。多數規則系統會依既定順序檢查，命中後停止繼續比對，因此規則內容正確但順序錯誤，仍會得到意外結果。範圍寬泛的規則放得太前，會攔截後面更精確的規則；範圍狹窄的例外項目通常應位於對應通用規則之前。修改前先記錄目前模式與規則順序，測試失敗時才能快速回復。

常見比對條件包括完整網域、網域後綴、IP 或網段、連接埠、網路類型與程序名稱。網域規則可讀性較高，適合針對穩定網域組織；IP 規則適合明確位址範圍，但目標服務使用動態位址時維護成本較高；程序規則依賴用戶端與系統支援，程式更新或路徑變更後可能失效。初學階段應先使用網域與保留位址網段，確認邏輯後再引入更複雜的條件。

網域比對為何可能失效

規則能否看見網域，取決於請求進入核心時攜帶的資訊。如果應用程式先完成 DNS 解析，只將 IP 交給代理，純網域規則可能無法直接命中；核心可透過嗅探或其他機制嘗試還原目標網域，但並非所有流量都適用。反過來，如果應用程式透過 SOCKS 將網域交給核心，網域規則通常更直接。排查時應查看路由日誌中的目標形式，不要只盯著規則文字。

網域後綴規則還要注意邊界。例如針對 example.com 的後綴規則通常會涵蓋其子網域，但不應把含有相同字串的其他網域誤判為同一個網站。若用戶端提供「完整網域」「網域後綴」「關鍵字」等類型，應優先選擇語意最精確的一種。關鍵字比對範圍較廣，只適合臨時驗證，不適合作為長期規則基礎。

如何閱讀一份最小路由設定

以下 JSON 展示路由部分的基本結構。第一條讓區域網路與保留位址直連，第二條讓示例網域走代理，其餘流量由後續預設出站處理。direct 與 proxy 必須對應完整設定中已存在的出站標籤。此片段用於理解欄位關係，不能脫離入站、出站與 DNS 設定單獨執行。

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

AsIs 表示路由階段優先依請求的原始目標處理，不主動為了 IP 規則解析所有網域。不同策略會改變網域與 IP 規則的協作方式，不能孤立地說某個值始終更好。若現有用戶端規則已經穩定，不必為了追求參數複雜度而修改策略。只有在明確發現網域與 IP 的比對關係不符預期時，才需要結合 DNS 設定與日誌進行調整。

設計規則時從預設行為開始

建立規則集前，先決定「沒有命中任何規則時要如何處理」。預設代理適合以直連例外為主的規則體系；預設直連則適合只讓少數明確目標走代理的體系。兩種思路都能運作，但混用後會很難閱讀。建議在規則說明中寫清楚預設出站，並為每組規則指定用途，例如「區域網路直連」「指定網域代理」「特定協定阻斷」，不要只使用含義模糊的編號。

規則驗證應使用可重複的目標，並觀察日誌中實際命中的出站標籤。僅憑網頁是否開啟，無法確認路由是否正確，因為目標可能同時允許直連與代理。若用戶端提供路由除錯日誌，可先暫時提高日誌層級，完成驗證後再恢復，避免日常日誌被大量請求淹沒。修改多條規則時，按組啟用並逐組測試，比一次匯入完整規則集更容易定位衝突。

可靠的路由體系應具備明確的預設行為、由精確到寬泛的比對順序、可辨認的出站標籤與可重複的驗證目標。規則數量不是成熟度指標，可解釋、可回復才是。

七、TUN 模式：虛擬網卡接管、權限與 DNS 路徑

TUN 與系統代理的根本差異

系統代理要求應用程式主動讀取作業系統的代理設定，TUN 則透過虛擬網路介面與路由表接管更廣泛的 IP 流量。對於忽略系統代理的程式，TUN 往往更有效；同時也會引入系統權限、虛擬介面、路由衝突、DNS 路徑與本機網路存取等額外變數。因此 TUN 不是基礎連線失敗時的萬用修復方案，而是基礎代理已穩定後，用來擴大接管範圍的獨立方案。

啟用 TUN 後，應用程式可能仍不知道代理的存在。作業系統會將流量送入虛擬介面，用戶端再將其轉換成核心可處理的連線並執行路由。由於這個過程發生在更低層，瀏覽器、命令列工具與部分不支援代理設定的程式可以被統一處理。但虛擬機器、容器、其他 VPN 類軟體或安全軟體也可能調整路由表，多個元件同時運作時容易產生優先順序衝突。

啟用前建立對照基準

開啟 TUN 前，應先用系統代理確認目前節點、訂閱與路由規則可用，並記錄關閉 TUN 時的表現。接著關閉應用程式中的手動代理，避免同一請求先進入手動代理，又被 TUN 再次接管。啟用後依序檢查：虛擬介面是否建立成功，用戶端日誌是否出現權限錯誤，預設路由是否按預期調整，區域網路存取是否正常，網域解析是否能回傳結果。每一步都正常後，再測試原先不遵循系統代理的程式。

如果用戶端要求提升權限，應透過系統提供的授權流程完成。權限不足通常表現為虛擬介面建立失敗、路由寫入失敗，或模式開啟後立即關閉。這類錯誤與節點協定無關，更換訂閱通常沒有幫助。桌面端還要檢查是否有其他正在運作的虛擬網路介面；Android 端則應確認系統的 VPN 接管狀態與背景執行限制。

1. 關閉重複入口。清除應用程式內的手動代理，只保留一個明確的資料入口。
2. 啟用 TUN 並完成系統授權。觀察用戶端是否成功建立虛擬介面。
3. 檢查基礎網路。分別測試網域存取、直接 IP 存取與區域網路裝置存取。
4. 驗證規則命中。確認原有直連、代理與阻斷規則在 TUN 下仍依預期執行。
5. 測試目標應用程式。最後檢查先前無法透過系統代理接管的程式。

DNS 是 TUN 排錯的重點

開啟 TUN 後出現「可以存取 IP、無法存取網域」，通常表示連線路徑存在，但 DNS 環節異常。可能原因包括 DNS 請求沒有進入預期路徑、用戶端 DNS 設定與系統設定衝突、路由規則阻斷了解析請求，或其他網路軟體仍在接管 DNS。此時應先查看用戶端日誌是否記錄解析逾時，再比較關閉 TUN 後的解析結果。不要同時更換節點、DNS 伺服器與路由規則，否則無法判斷哪項修改生效。

另一種情況是網域可以解析，但規則以錯誤的目標命中。在 TUN 環境下，核心可能透過嗅探還原網域，也可能只能看見解析後的 IP。應結合目前的路由策略判斷規則究竟比對的是網域還是 IP。若必須依賴網域分流，需確保 DNS 與流量接管路徑能保留足夠資訊；若目標位址穩定，也可以使用明確的 IP 或網段規則作為補充，但要考慮位址變更所帶來的維護成本。

區域網路與休眠恢復問題

TUN 修改路由後，本機印表機、儲存裝置或開發服務可能被錯誤送入代理。區域網路與保留位址通常應優先直連，並放在寬泛代理規則之前。若只有關閉 TUN 後才能存取區域網路，請檢查私有網段規則與繞過設定，不要把整個規則體系改為直連。也應分別測試裝置名稱與區域網路 IP，因為前者涉及本地域名解析，後者主要涉及路由。

電腦休眠、網路切換或從有線切換至無線後，舊的虛擬介面與路由狀態可能沒有立即重新整理。表現為用戶端仍顯示執行中，但新請求逾時。可以先在用戶端中關閉再開啟 TUN，讓它重新建立介面；若仍未恢復，再重新啟動核心並檢查系統路由。將重新啟動系統放在最後，因為直接重啟會遺失最有價值的錯誤現場。

TUN 設定成功的標準不是開關維持開啟，而是虛擬介面、DNS、路由規則、區域網路與目標應用程式都能產生可解釋的結果。將基礎代理與 TUN 分階段驗證，可以大幅縮短排錯時間。

八、日常維護：更新、日誌、備份與故障分層

將用戶端、核心與訂閱更新分開處理

日常維護包含三類更新：圖形化用戶端本身更新、核心元件更新與訂閱內容更新。三者解決的問題不同。用戶端更新可能改變介面、系統整合與設定管理；核心更新會影響協定解析、傳輸能力與執行行為；訂閱更新只會變更遠端設定清單。遇到問題時先確認最近變更的是哪一層，不要把訂閱更新失敗等同於用戶端需要升級，也不要在節點故障時同時更新所有元件。

更新前應記錄目前可用的設定、代理模式與重要自訂規則。更新後先使用原有設定進行基準測試，再檢查新增能力。若在更新後直接匯入新訂閱、修改路由並開啟 TUN，一旦出現異常就無法判斷來源。對長期穩定使用的環境而言，維護目標是控制變更，而不是始終追逐所有設定項目。

日誌應依時間線閱讀

日誌通常包含用戶端操作、核心啟動、設定解析、DNS、路由與連線錯誤。有效的閱讀方式是先記下觸發操作的準確時間，然後只查看該時間點前後的一小段。啟動階段優先關注設定檔路徑、欄位解析、連接埠監聽與權限；連線階段優先關注網域解析、握手、逾時與路由出站；訂閱階段則關注請求狀態與內容解析。不要孤立截取日誌最後一行，因為根因往往出現在更早的位置。

提高日誌層級可以提供更多細節，但也會快速產生大量記錄。應在重現問題前暫時提高，完成一次明確測試後立即收集，再恢復日常層級。公開討論日誌時，只保留錯誤類型、時間順序與必要欄位，隱藏訂閱位址、節點位址、使用者識別碼與本機目錄中的個人名稱。日誌用於還原過程，不應變成設定備份。

備份重點是可恢復資訊

值得備份的內容包括訂閱分組結構、自訂路由規則、用戶端偏好、本機手動節點與必要的設定說明。訂閱位址本身可以恢復遠端節點，但無法恢復所有本機修改。備份檔案應放在受控位置，不要直接公開分享。若用戶端支援匯出設定，應先了解匯出範圍：有的只匯出節點，有的包含路由與介面設定，有的還會引用本機路徑。

恢復時不要一次覆寫所有現有設定。較穩妥的流程是先安裝並啟動用戶端，確認核心基準正常，再匯入訂閱，接著恢復路由，最後處理 TUN 與開機啟動。每一步都啟動一次並查看日誌。即使備份來自不同系統或較早的環境，也能在出現不相容時準確停在對應階段。

建立最小重現設定

複雜故障應縮減為一個用戶端、一個訂閱分組、一筆已知設定、系統代理與預設路由。關閉自動選擇、複雜 DNS、程序規則、區域網路共用與 TUN，再重現問題。如果最小設定正常，逐項恢復進階設定；如果最小設定仍失敗，檢查設定欄位、網路與核心日誌。最小重現不是永久刪除功能，而是暫時減少變數。

節點選擇也應依實際連線結果，而不是只看清單中的延遲值。延遲通常反映某種探測請求的往返時間，無法完整代表目標連線、傳輸握手與持續流量的表現。選擇方法可參考節點挑選思路，重點比較實際可用性、協定相容性與目標情境。

維護的核心是控制變數。更新分層、依時間線閱讀日誌、按階段恢復備份、將故障縮減為最小設定，這四個習慣可以涵蓋多數長期使用問題。

九、進階路線：從會用用戶端到能解讀設定

第一階段：能夠重述完整資料流

進階不等於立刻手寫大型設定。第一階段應能解釋一個請求從應用程式到遠端的完整路徑，並指出每個環節的觀察方式：應用程式是否讀取系統代理，本機連接埠是否正在監聽，核心是否成功啟動，路由選擇了哪個出站，節點傳輸參數是否完整，以及 DNS 在哪裡解析。能回答這些問題，就能將模糊的「連不上」拆解為具體層級。

練習時可以使用同一筆已確認可用的設定，分別測試系統代理、手動應用程式代理與 TUN，並記錄日誌差異。再於規則模式中加入一條明確的網域規則，觀察出站標籤的變化。練習目標不是製造複雜環境，而是建立操作與日誌之間的對應關係。

第二階段：讀懂用戶端產生的設定

圖形化用戶端最終需要將介面選項轉換成核心設定。匯出或查看產生的設定時，先找出入站、出站、路由與 DNS 四個部分，再將它們與介面設定逐一對應。以下範例展示一個僅監聽本機的 SOCKS 入站。它可用於理解欄位，不包含可連線的遠端出站，因此不是完整設定。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

tag 用於在設定內部引用該物件，listen 限定監聽位址，port 是本機連接埠，protocol 指定入站類型。若將監聽位址改為所有網路介面，區域網路中的其他裝置可能存取該連接埠，這會改變安全邊界。沒有明確的共用需求時，應保持迴路位址。學習設定時，先理解既有欄位的作用，不要為了「最佳化」而加入來源不明的參數。

第三階段：比較 Xray 與 V2Fly 核心界線

Xray 與 V2Fly 同屬 Project V 相關生態系，但維護方向與特性集合並不完全相同。用戶端只是載體，真正決定某項協定擴充或傳輸能力是否可用的，是核心與用戶端的設定適配。遇到「同一分享連結在不同用戶端表現不同」時，應檢查連結使用了哪些協定與安全特性，再確認目標核心是否支援，而不是簡單歸因於平台差異。

比較核心時應以實際需求為中心：目前訂閱使用哪些協定，是否依賴 VLESS、REALITY 或 XTLS 相關能力，用戶端能否正確產生對應設定，日誌能否提供足夠的排錯資訊。若目前設定只使用兩者都支援的常規能力，選擇更符合平台與維護習慣的用戶端即可。更詳細的比較請見Xray 與 V2Fly 核心差異。

第四階段：建立可測試的規則體系

成熟的路由規則不靠數量取勝，而是具備清楚的預設行為、分組目的與驗證方法。可以從三組規則開始：區域網路與保留位址直連，一組明確網域依需求選擇出站，其餘流量進入預設策略。為每組規則準備一個可重複的測試目標，並在修改後查看日誌命中情況。新增規則前先說明它要解決什麼問題，無法說明用途的規則不應直接加入長期設定。

DNS 調整也應圍繞具體問題。只有在確認解析路徑導致規則失效、逾時或結果不一致時，才修改查詢方式與路由關係。將 DNS、嗅探、路由策略與 TUN 同時改成一套複雜方案，短期可能碰巧可用，長期卻難以維護。進階能力體現在能縮小修改範圍，並解釋為何需要這項變更。

第五階段：建立個人運作手冊

個人運作手冊不必很長，但應包含用戶端與平台、安裝包架構、設定目錄、本機連接埠、訂閱分組、自訂規則、TUN 是否啟用、更新方式與回復步驟。再補充兩項最小測試：一項驗證系統代理，另一項驗證路由命中。裝置移轉或升級後，依這份清單逐步恢復，比依賴記憶更可靠。

環境出現新問題時，先更新運作手冊中的現象與處理結果，再決定是否引入額外規則。長期累積後，手冊會形成適合自身裝置與應用程式的穩定基準。此時用戶端介面變化不會造成太大影響，因為核心判斷仍然圍繞入站、出站、路由、DNS 與流量接管展開。

從零到進階的路線可以概括為：先建立最小可用鏈路，再擴大流量接管範圍；先讀懂規則命中，再增加規則數量；先形成可恢復基準，再升級用戶端與核心。遇到問題時始終回到資料流，而不是隨機切換設定。