V2Ray 從零到精通：用戶端、分流與 TUN

01 / concepts

核心概念：先理清一條流量鏈路

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

使用 V2Ray 時，最容易混淆的三個物件是圖形用戶端、代理核心與設定資料。v2rayN、v2rayNG、v2flyNG 屬於圖形用戶端，負責提供訂閱匯入、節點選擇、系統代理、路由規則與執行記錄等操作介面。Xray、V2Fly 等核心負責實際處理連線、協定、傳輸與路由。設定檔則將監聽連接埠、出站參數、網域規則與 DNS 策略交給核心。介面上的一次切換，最後通常會轉換成一組設定欄位，再由核心重新載入。

因此，排查問題時不要只看「用戶端是否啟動」。更準確的順序是：設定是否存在、目前設定是否已選取、核心是否成功載入、本機入站連接埠是否開始監聽、應用程式流量是否進入該連接埠、路由規則是否選中正確出站，以及遠端連線是否完成。任何一環中斷，瀏覽器都會呈現無法存取，但對應的修復方式完全不同。建立這條鏈路，是後續所有章節的判斷基礎。

inbounds、outbounds 與 routing 的關係

inbounds 定義流量如何進入核心。桌面用戶端常見的是本機 SOCKS 與 HTTP 監聽連接埠；啟用 TUN 後，還會增加負責接收系統網路層流量的虛擬入口。outbounds 定義流量從哪裡離開，可以是某個遠端設定，也可以是直接連線或封鎖出站。routing 位於兩者之間，依網域、IP、連接埠、協定或入站標籤判斷應使用哪條出站。

可以把一次請求理解為「應用程式 → 本機入站 → 路由判斷 → 目標出站」。例如瀏覽器設定 SOCKS 連接埠後，請求會先進入本機監聽；路由規則發現目標屬於直連集合，就交給 direct 出站；其他請求則交給目前的遠端出站。規則中的 tag 是各段之間的連線識別，名稱可以自訂，但引用時必須一致。若規則寫有 outboundTag: "direct"，設定中就必須存在標籤為 direct 的出站。

{
  "inbounds": [
    {
      "tag": "socks-in",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

設定、節點與訂閱不是同一個物件

單一節點是一組連線參數，通常包含伺服器位址、連接埠、使用者識別、協定與傳輸設定。訂閱是一個可更新的資料來源，可能回傳多個節點，也可能附帶分組資訊。用戶端設定的範圍更大：除了節點之外，還包含本機連接埠、代理模式、DNS、路由、記錄與介面偏好。刪除訂閱不一定會立即刪除已產生的本機設定，切換節點也不會自動變更系統代理模式。操作前先確認處理的是訂閱來源、設定清單，還是目前執行中的實例。

需要逐欄位理解設定結構時，可繼續閱讀config.json 結構逐段解析。本文會將入站、出站與路由標籤放在一份最小設定中對照說明。

02 / client and install

選擇用戶端與安裝：先配合平台，再確認執行條件

三款用戶端如何分工

桌面平台首選 v2rayN。它支援 Windows、macOS 與 Linux，統一提供設定清單、訂閱管理、系統代理、路由與 TUN 等常用入口。Windows 下載頁同時提供桌面版與經典 WPF 版：桌面版採用跨平台介面，適合希望在不同桌面系統間維持相近操作路徑的使用者；WPF 版面向 Windows 經典使用習慣，介面與系統整合路徑更集中。兩者的主要差異在介面框架與系統適配，而不是節點協定能力的高下。

Android 平台優先選擇 v2rayNG，使用 Xray 核心，常見的訂閱、分應用代理、路由與連線測試都能在圖形介面完成。v2flyNG 使用 V2Fly 核心，可作為需要該核心實作時的備選。兩款 Android 用戶端的設定清單並不共用，切換用戶端時需要重新匯入訂閱或設定。不要直接將某個用戶端產生的內部資料庫檔案複製到另一款用戶端；通用的訂閱連結、分享連結或標準設定更適合遷移。

安裝前檢查系統架構與舊有實例

下載前先確認處理器架構與系統類型。macOS 可在「關於這台 Mac」查看晶片名稱；Linux 可執行 uname -m，輸出 x86_64 對應 x64，輸出 aarch64 對應 arm64；近年的 Android 主流裝置通常採用 arm64，但裝置資訊不明確時可選擇通用套件。安裝套件架構不相容時，常見情況是無法啟動、安裝程式拒絕執行，或啟動後立即退出；這類問題不應透過修改節點參數處理。

升級或更換介面版本前，先退出正在執行的舊實例。桌面用戶端可能保留系統匣程序，關閉主視窗不一定代表程序已結束；應從系統匣選單執行退出，或透過系統工作管理工具確認程序已停止。若舊實例仍占用本機連接埠，新實例會在記錄中回報監聽失敗。保留現有訂閱位址、路由規則與自訂連接埠記錄後再進行遷移，可避免安裝完成後無法判斷哪些設定來自舊環境。

首次啟動後的基本檢查

首次開啟用戶端時，先不要同時啟用系統代理與 TUN。正確順序是：確認用戶端介面可用、匯入一項設定、選取該設定、啟動核心、查看記錄中是否顯示本機監聽成功，再開啟系統代理進行測試。分階段操作可以區分「程式啟動問題」與「網路接管問題」。Windows 若出現執行環境提示，應依用戶端頁面列出的元件要求補齊系統執行庫；Linux 安裝後若未出現選單入口，可從終端機啟動一次並讀取錯誤訊息；macOS 首次啟動時，應在系統安全性設定中確認應用程式的開啟狀態。

安裝完成不代表代理已經生效。用戶端啟動、核心執行、系統代理開啟是三種不同狀態。只開啟介面但沒有啟動設定，本機連接埠不會監聽；核心正在執行但系統代理關閉時，只有手動指定代理的應用程式會進入用戶端；系統代理已設定但核心停止時，應用程式會把請求送到沒有服務的連接埠。理解這三種狀態，可以避免把安裝問題誤判為遠端連線問題。

Windows 平台需要更完整的安裝流程與常見執行環境處理，可參閱Windows 安裝 v2rayN 完整流程；兩種介面版本的選擇差異見v2rayN 桌面版與經典 WPF 版差異比較。

03 / subscription

訂閱與設定管理：分清匯入、更新、選取與執行

匯入訂閱後的四個步驟

新增訂閱通常只是在用戶端中儲存一個資料來源。完整流程包含四個獨立步驟：儲存訂閱資訊、更新訂閱、從結果中選擇設定、啟動所選設定。有些用戶端儲存後會立即更新，有些則需要手動執行「更新訂閱」；因此，新增成功但設定清單為空時，先檢查是否已執行更新，不要立即刪除後重新新增。更新後還要確認目前的分組與篩選條件，避免設定其實存在卻被清單篩選隱藏。

訂閱名稱只用於本機識別，不會參與連線。建議使用能區分用途與來源的簡短名稱，不要把日期寫進名稱後頻繁修改。同時存在多個訂閱時，名稱應有助於判斷更新範圍。更新操作可能替換該訂閱產生的舊設定，手動修改過的節點參數也可能在下一次更新時被覆蓋。需要長期保留的本機變更，應放在用戶端提供的路由、DNS 或全域設定中；若確實要修改單一設定，應先複製為本機獨立項目並標明用途。

更新訂閱時如何保留目前可用狀態

更新前先記下目前設定名稱與執行狀態。更新完成後，用戶端可能依唯一識別保留選取項目，也可能因設定被替換而跳回其他項目。最穩妥的做法是更新後重新確認目前設定，再執行一次連線測試。若訂閱回傳空內容，不要連續覆寫並清除所有設定；先檢查用戶端記錄中的 HTTP 狀態、回應格式與解析提示，並保留上一次可用設定作為對照。

更新失敗可分為「無法請求位址」、「請求成功但內容無法解析」、「解析成功但沒有可用設定」三類。第一類重點檢查網路路徑、系統時間與訂閱位址是否完整；第二類檢查回傳內容是否屬於用戶端支援的訂閱格式，以及是否誤將網頁位址當成訂閱位址；第三類檢查訂閱分組、篩選規則與用戶端核心相容性。若記錄顯示請求成功但解析數量為零，反覆更換代理模式通常沒有幫助，應回到訂閱內容與格式這一層。

分享連結、JSON 設定與訂閱的適用範圍

單一分享連結適合匯入一個明確設定，方便逐項核對位址、連接埠與傳輸設定；JSON 設定適合需要完整控制入站、出站、路由與 DNS 的情境；訂閱適合由同一來源維護多項設定並定期更新。三者可以同時存在，但應避免讓多個來源產生名稱相同的設定，否則切換時很難判斷目前執行的是哪一項。

手動匯入 JSON 前，應先確認它是完整的核心設定，還是用戶端可識別的設定片段。完整設定通常包含 inbounds、outbounds 等頂層欄位，而分享連結只描述一條出站連線。圖形用戶端可能會依自身設定重新產生入站與路由，因此直接編輯用戶端執行時產生的暫存檔案，下一次啟動時往往會被覆蓋。需要持久保存的設定，應透過用戶端介面、自訂設定入口或明確的設定檔管理功能完成。

訂閱資料的基本管理界線

訂閱位址本身可能包含存取識別資訊，應只儲存在需要使用的用戶端中，不應發布到公開頁面、記錄截圖或共享文件。診斷時若需要展示記錄，應遮去完整訂閱位址、伺服器位址與使用者識別，只保留錯誤類型、狀態碼與時間順序。用戶端的匯出功能也可能包含連線參數，傳送前應確認匯出範圍。

日常使用中，可以依序分開執行訂閱更新與用戶端升級。先在現有用戶端環境驗證訂閱更新，再安排用戶端升級；或先升級用戶端並確認舊設定可執行，再更新訂閱。兩個變數同時改變時，一旦出現相容性問題，很難判斷是解析器、核心還是訂閱內容發生變化。穩定維護的關鍵不是頻繁操作，而是讓每次變更都只有一個明確目標。

04 / proxy mode

代理模式與本機連接埠：決定哪些應用程式進入用戶端

系統代理、手動代理與 TUN 的涵蓋範圍

系統代理是桌面平台最適合首次驗證的模式。v2rayN 會將系統代理位址設定為本機監聽連接埠，遵循系統代理設定的瀏覽器與應用程式會把請求交給用戶端。優點是行為清楚、關閉方便；限制是部分應用程式不讀取系統代理，命令列工具與獨立執行環境也可能使用自己的代理設定。遇到「瀏覽器可用、某個應用程式不可用」時，先檢查該應用程式是否遵循系統代理，不要直接判定設定失效。

手動代理適合精確測試。可以在瀏覽器、開發工具或命令列程序中明確填寫 127.0.0.1 與 SOCKS/HTTP 連接埠。它不會自動涵蓋其他應用程式，方便判斷本機入站是否正常。TUN 位於更接近系統網路層的位置，能接收更多不支援顯式代理的流量，但也會引入虛擬網卡、路由表、DNS 接管與權限問題。正確的學習順序應是先用系統代理跑通，再進入 TUN，而不是把 TUN 當成首次連線的預設開關。

如何選擇 SOCKS 與 HTTP 連接埠

SOCKS 入站能承載 TCP，並可在設定允許時處理 UDP；HTTP 代理主要面向支援 HTTP CONNECT 的應用程式。用戶端通常會同時建立兩個本機連接埠，也可能提供混合入站。設定應用程式代理時，必須讓協定類型與連接埠相互對應：將 SOCKS 連接埠填入只接受 HTTP 代理的欄位，會出現連線失敗或協定錯誤；反之亦然。連接埠號沒有固定值，關鍵是用戶端實際監聽值、系統代理值與應用程式設定三者一致。

本機監聽位址通常設為 127.0.0.1，表示只接受本機連線。只有明確需要讓同一區域網路的其他裝置接入時，才考慮允許區域網路連線，並同步檢查系統防火牆與存取範圍。開放區域網路監聽後，不能只修改位址而忽略驗證與網路範圍。一般單機使用時，維持本機監聽更容易管理，也能減少區域網路環境變化對故障判斷的干擾。

連接埠衝突與殘留系統代理

核心啟動時若提示位址已被使用，表示預計監聽的連接埠已被其他程序占用。先退出舊的用戶端實例，再尋找占用程序。Windows 可執行 netstat -ano | findstr :10808 取得程序識別碼；macOS 可執行 lsof -nP -iTCP:10808 -sTCP:LISTEN；Linux 可執行 ss -lntp | grep 10808。確認程序用途後，再結束程序或修改用戶端連接埠；看到占用時不應直接終止未知的系統服務。

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

修改連接埠後，必須同步修改系統代理或應用程式中的代理連接埠。只改用戶端監聽值而保留舊的系統代理，會形成「用戶端已執行，但應用程式仍連線到舊連接埠」的狀態。用戶端異常退出後，系統代理也可能殘留；此時即使核心已停止，瀏覽器仍會嘗試連線到本機代理。處理方式是重新開啟用戶端並關閉系統代理，或在系統網路設定中手動還原。完整的連接埠定位流程可參考連接埠被占用的定位與修改方法。

05 / routing

路由分流：用規則決定各類流量的出口

規則比對順序比規則數量更重要

路由規則通常會由上而下比對，命中後交給指定出站。規則越多不代表結果越準確；真正重要的是條件是否互斥、優先順序是否合理，以及兜底出口是否明確。具體規則應放在寬泛規則之前。例如，某個網域同時屬於自訂直連清單，且會被後方的通用代理規則涵蓋時，應讓自訂規則優先出現。若用戶端提供預設路由模式，先選擇最接近目標的預設模式，再增加少量自訂規則，比從空白開始堆疊大量集合更容易維護。

常見條件包括網域、IP、連接埠、網路類型、協定與入站標籤。網域規則適合依完整網域、後綴或 GeoSite 分類；IP 規則適合私有位址與 GeoIP 分類；連接埠規則適合特定服務；入站標籤可讓不同本機入口採用不同策略。不要把網域條件與最終解析出的 IP 條件視為完全等價。請求進入路由階段時是否保留網域，取決於 DNS 流程與 domainStrategy 設定。

direct、proxy 與 block 三類出口

一套易讀的路由通常至少區分三種結果：direct 表示直接連線，proxy 表示交給目前的遠端出站，block 表示封鎖。名稱只是標籤，實際行為由對應的出站協定決定。規則引用標籤時，必須與出站標籤逐字一致。若介面允許選擇「直連」「代理」「封鎖」，用戶端會代為維護標籤；手寫 JSON 時則需要自行確保引用關係。

私有位址一般應優先直連，以免存取路由器、印表機或區域網路服務時繞行遠端出站。需要封鎖的流量應使用明確條件，避免使用過於寬泛的網域關鍵字。最後保留一個容易理解的兜底策略：未命中規則的流量預設走代理還是直接連線，應與用戶端目前模式一致。故障排查時暫時切換到較簡單的全域策略，可以判斷問題是否來自路由；驗證完成後再恢復分流，不要長期依賴暫時模式。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "direct"
      }
    ]
  }
}

domainStrategy 與 DNS 的配合

AsIs 傾向直接使用進入路由的網域進行比對，不為 IP 規則額外解析；IPIfNonMatch 會在網域規則未命中時嘗試解析，再繼續比對 IP 規則；IPOnDemand 會在遇到可能需要 IP 的規則時更積極地解析。選擇哪一種取決於規則結構。以網域規則為主時，AsIs 路徑更直觀；大量使用 GeoIP 條件時，IPIfNonMatch 更容易讓 IP 規則參與判斷，但也更依賴 DNS 結果。

DNS 與路由構成閉環：DNS 請求本身也需要選擇出口，解析結果又會影響後續路由。若網域解析經由不合適的網路路徑，可能得到無法連線的位址；若規則要求依 IP 判斷但未取得可用解析結果，規則就不會如預期命中。排查時應分別記錄「網域由誰解析」「DNS 請求從哪條出站離開」「結果進入哪條路由規則」，不要只更換 DNS 位址而忽略出站路徑。

GeoIP 與 GeoSite 的更新界線

GeoIP 依 IP 位址分類，GeoSite 依網域集合分類。兩類資料庫過舊時，新網域與位址區段可能無法歸入預期分類。更新後若分流突然改變，應檢查資料庫版本變化帶來的分類調整，而不是立即認定核心異常。自訂高優先順序規則應維持數量有限，並記錄新增原因；當資料庫更新已涵蓋該情境時，可以移除重複規則，避免之後發生衝突。

資料庫的用途、更新入口與驗證方法見GeoIP 與 GeoSite 資料庫更新指南。比較多個用戶端的路由能力與適用平台時，可查看用戶端比較。

06 / tun

TUN 模式：從系統代理延伸至網路層接管

什麼時候需要啟用 TUN

TUN 模式透過虛擬網路介面接收系統流量，適合不讀取系統代理設定的應用程式、需要 UDP 支援的程式，以及希望減少逐一設定應用程式工作的桌面環境。它不是提升連線品質的開關，也不會自動修復錯誤的遠端參數。若在系統代理模式下連基本網頁都無法開啟，應先解決設定、連接埠、DNS 或遠端連線問題，再啟用 TUN。否則新增的路由表與虛擬網卡只會增加排查變數。

啟用前應完成三項基準測試：目前設定能夠啟動；在系統代理下至少有一個應用程式能穩定存取；用戶端記錄中沒有持續的連線或解析錯誤。接著關閉系統代理，或依用戶端建議處理兩者的關係，再開啟 TUN。測試時先保留預設網路堆疊與預設 MTU，不要同時修改 DNS、嚴格路由、繞過規則與網卡參數。只有確認預設設定存在具體問題後，才調整對應選項。

虛擬網卡、路由表與權限

TUN 需要建立虛擬網路介面並修改系統路由，因此桌面系統通常需要相應權限。權限不足時，常見情況是虛擬網卡建立失敗、路由新增失敗，或用戶端顯示已啟用但沒有流量進入。應從用戶端記錄確認具體失敗步驟，再依系統權限模型處理。重複點擊開關可能留下多個短暫介面或殘留路由，使問題更複雜。

路由表決定哪些目標進入虛擬網卡，繞過規則則讓區域網路、特定位址或指定應用程式維持原本路徑。啟用嚴格路由後，系統可能阻止未明確處理的旁路流量，有助於維持路徑一致，但也可能影響本機開發環境、虛擬機器或區域網路服務。若啟用後無法存取區域網路裝置，應先檢查私有位址繞過與 direct 規則，而不是關閉所有分流。

MTU、網路堆疊與 UDP 問題

MTU 表示介面能承載的封包大小。設定過大時，某些網路路徑可能無法正確分片，表現為小型頁面可以開啟、大型檔案或特定網站停滯；設定過小則會增加分包負擔。沒有明確證據時應保留用戶端預設值。若懷疑 MTU，可比較不同網路環境，觀察是否只在大型回應或特定協定中重現，再逐步降低測試，每次記錄修改值與結果。

不同 TUN 網路堆疊在相容性、效能與系統整合方式上有所差異。選擇時應先使用用戶端推薦的預設項目，只有遇到明確的 UDP、休眠恢復或虛擬化衝突時才切換。切換網路堆疊後需要重新啟動 TUN，並確認舊虛擬介面已清除。Android 的 VPN 接管由系統提供，v2rayNG 與 v2flyNG 啟動連線時會申請相應權限；若系統中已有其他使用同類接管機制的應用程式，同時執行可能產生互斥。

DNS 洩漏誤判與解析路徑

TUN 開啟後，DNS 請求可能由用戶端接管，也可能仍由系統網路介面發出，取決於用戶端設定。常見故障是網域無法開啟，但直接存取已知 IP 有回應，這表示應優先檢查 DNS，而不是遠端協定。另一種情況是 DNS 能回傳結果，但該結果經路由後走錯出口。排查需要同時查看 DNS 記錄、路由命中與連線記錄，三者時間應能對應。

若某些區域網路網域依賴本機 DNS，應為這些網域保留本地解析路徑，同時讓公共網域依既定策略解析。不要用單一 DNS 伺服器涵蓋所有情境，再靠大量靜態位址補救。企業網路、家庭區域網路與公共網路切換時，本機 DNS 的可達性也會變化，因此行動裝置與筆記型電腦應重點驗證切換網路後的恢復行為。

TUN 啟用後若整個系統立即失去連線，應先關閉 TUN，確認預設路由恢復，再檢查記錄中的權限、介面與路由新增錯誤。不要在網路完全中斷時繼續疊加 DNS 與分流修改，否則恢復路徑會變得難以追蹤。

07 / maintenance

日常維護與故障定位：分層收集證據

建立可重複的維護節奏

穩定使用仰賴可回復的變更流程。用戶端升級、核心更新、訂閱更新、路由資料庫更新與系統網路調整應分開執行。每次變更前記錄目前用戶端類型、所選設定、本機連接埠、代理模式、路由預設與 DNS 策略；變更後依相同測試清單驗證。如此即使出現異常，也能清楚比較前後差異。

訂閱可依實際變化頻率更新，不需要每次啟動時反覆重新整理。GeoIP 與 GeoSite 應在分流規則出現明顯分類偏差，或依維護計畫更新時處理。用戶端升級前閱讀介面中的遷移提示，確認設定儲存位置與權限要求是否改變。更新完成後先使用原有設定驗證，再引入新功能。把升級與設定重構放在同一次操作中，會失去清楚的回復點。

從記錄判斷故障所在層級

記錄應依時間順序閱讀。啟動階段重點查看設定解析、連接埠監聽、核心程序與 TUN 介面；連線階段重點查看網域解析、路由命中、出站撥號與握手；執行階段重點查看逾時、連線重設與網路切換。第一個關鍵錯誤通常比後續重複錯誤更有價值，因為後續失敗可能只是前一環節中斷的結果。

設定解析錯誤通常包含欄位路徑或 JSON 行列位置，應先修復語法與欄位類型；監聽錯誤通常指向連接埠占用或權限；解析錯誤指向 DNS 路徑；連線逾時表示請求已嘗試離開本機，但目標路徑未在時限內完成；握手錯誤則需要核對協定、傳輸與時間。不要只截取最後一行記錄，診斷時至少保留啟動前後以及一次完整請求所對應的連續片段。

最小化重現，不要同時重設所有設定

有效的重現環境應盡量簡單：選擇一項已知設定，使用預設本機連接埠，關閉自訂路由，先不開啟 TUN，只保留系統代理或單一應用程式的手動代理。若最小環境可用，再逐項恢復 DNS、路由、TUN 與應用程式規則；若最小環境仍失敗，就集中檢查設定參數、系統時間、連接埠與網路路徑。如此可以將複雜問題拆解成有限步驟。

「恢復預設」適合用來確認設定是否受到污染，但執行前應記錄現有設定。直接清空所有設定會失去對照，也可能刪除仍可用的訂閱資訊。更好的做法是建立獨立測試設定，或使用用戶端提供的備份與複製功能。測試完成後，將確認有效的變更寫入維護記錄，包括修改項目、原因、驗證方式與回復方式。記錄不必很長，但必須能在下一次故障時還原判斷過程。

網路切換、休眠與系統更新後的檢查

筆記型電腦從一個網路切換到另一個網路後，舊 DNS、虛擬網卡狀態與路由快取可能暫時保留。若切換後連線異常，先停止並重新啟動目前設定；TUN 使用者還應重新建立虛擬介面。系統從休眠恢復時，用戶端介面可能仍顯示執行中，但底層網路介面已經改變，應以新請求記錄而不是介面狀態判斷。

系統更新後出現問題時，應檢查防火牆權限、虛擬網卡驅動程式狀態、系統代理是否被重設，以及用戶端是否仍有建立網路介面的權限。Android 裝置切換網路後，可以停止並重新啟動連線，讓系統重新授予目前網路路徑。任何平台都應避免在問題尚未穩定重現時連續更換多個設定，因為這會把系統狀態變化與設定差異混在一起。

08 / advanced route

進階路線：從介面設定轉向可維護規則

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

進階不是先增加欄位，而是能夠解釋現有設定。應明確目前有哪些入站、每個入站監聽哪個位址與連接埠、預設出站是哪一條、direct 與 block 如何定義、路由規則依什麼順序比對，以及 DNS 請求從哪裡發出。可以從用戶端匯出的設定或執行記錄逐項核對，但不要直接修改暫時產生的檔案。先建立介面選項與最終欄位的對應關係，之後才能判斷用戶端升級後某項行為為何改變。

建議繪製一張自己的流量路徑表：應用程式名稱、進入方式、入站標籤、匹配規則、目標出站、DNS 路徑。表格中的每一欄都應能從設定或記錄找到依據。若某一欄只能憑感覺填寫，表示該環節仍需驗證。完成這一步後，再處理複雜的分應用程式、多入口或多出站情境，避免規則數量增加後失去可解釋性。

第二階段：用標籤組織多入口與多出口

多入口適合隔離不同應用程式或用途。例如一個 SOCKS 入站用於瀏覽器，另一個入站用於開發工具，再透過 inboundTag 指向不同出站。多出口則可組合 direct、block 與多個遠端連線。標籤命名應表達職責，例如 socks-browser、direct、block，不要使用難以回憶的暫時編號。引用標籤時，若修改名稱，必須同步更新所有引用。

多出口不代表需要複雜的自動選擇。先建立明確的靜態規則，確認各類流量穩定進入預期出口，再考慮故障轉移或負載策略。自動策略依賴健康檢查、連線狀態與核心能力，發生故障時也需要更多記錄。若基礎路由尚未穩定，增加自動策略只會讓實際出口更難預測。

第三階段：將 DNS 作為獨立子系統維護

複雜設定中的 DNS 不應只是一個伺服器位址。需要明確查詢類型、網域分類、解析出口、快取行為與回退條件。區域網路網域可能需要本機 DNS，公共網域可以依路由策略選擇解析路徑，特定網域也可使用獨立規則。任何拆分都應有實際需求，不要因為存在選項就全部啟用。

驗證 DNS 時，先確認請求由哪一層發起，再確認回傳位址是否符合預期，最後確認該位址經過哪條路由。若只看解析結果而不看查詢出口，可能忽略網路路徑差異；若只看路由而不看結果，可能把錯誤位址造成的連線失敗誤判為分流問題。DNS 調整應與 GeoIP、GeoSite 更新分開進行，確保一次只改變一個判斷來源。

第四階段：建立設定變更與回復規範

長期維護的設定應保留易讀的註解記錄，但標準 JSON 本身不接受註解，因此註解可以放在獨立說明文件、用戶端備註或變更記錄中。每次修改都記錄目標、原值、新值、驗證結果與回復步驟。對路由規則尤其要記錄「為什麼存在」，否則幾個月後很容易把過期規則當成必要條件。

設定備份應包含訂閱名稱、自訂路由、DNS、監聽連接埠與 TUN 選項，但儲存位置要控制存取範圍。恢復時不要一次匯入所有舊狀態；先恢復訂閱與基本設定，確認可執行後，再恢復路由與 TUN。跨平台遷移時只遷移通用邏輯，不要假定系統代理、虛擬網卡與權限設定可以直接複製。

第五階段：建立固定驗證清單

一份完整的驗證清單可以包含：用戶端正常啟動；核心設定載入成功；本機連接埠正在監聽；系統代理或 TUN 狀態符合預期；網域解析可用；私有位址維持直連；指定網域命中預期規則；切換網路後能夠恢復；關閉用戶端後系統代理與虛擬介面正確清除。清單中的每一項都應有具體觀察方式，而不是只寫「網路正常」。

遇到新問題時，先將現象歸入設定、入站、DNS、路由、出站或系統接管其中一層，再使用本手冊對應章節。快速入門操作可回到入門指南，重新選擇安裝套件可進入用戶端下載頁，用戶端能力差異可查看用戶端比較。若問題涉及設定結構、連接埠衝突或路由資料庫，則分別使用本文連結的專題文章繼續定位。