V2Ray 用戶端完整設定手冊

核心概念與用戶端選擇

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

V2Ray 的使用流程可以拆分為四個層次。用戶端提供視窗、選單、訂閱管理與系統接管能力；核心負責解析協定、建立出站連線並執行路由規則；節點是一組可用的伺服器連線參數；訂閱則是批次分發節點及更新變更的網址。v2rayN、v2rayNG 與 v2flyNG 都屬於用戶端，而不是協定本身。Xray 與 V2Fly 是常見的核心家族，用戶端會依設定呼叫對應核心完成實際連線。

理解分層後，許多故障會更容易定位。用戶端視窗能開啟，只能表示介面層正常；訂閱清單出現節點，只能表示訂閱內容已完成解析；節點被設為活動伺服器，也不代表應用程式流量已交由用戶端處理。還需確認核心成功啟動、本機監聽連接埠沒有衝突，以及系統代理或 TUN 已接管目標應用程式。任何一步中斷，最後都可能表現為「網頁無法開啟」，但處理方式完全不同。

三款用戶端如何選擇

Windows、macOS 與 Linux 桌面環境首選 v2rayN。它能統一管理訂閱、伺服器、路由規則、系統代理與 TUN，適合從首次使用逐步進階到複雜分流。Windows 可在桌面版與經典 WPF 版之間選擇：桌面版採用跨平台介面，方便不同桌面系統維持相近的操作流程；WPF 版面向 Windows，介面與相依環境較為傳統。具體安裝套件應前往Windows 下載區，依目前環境選擇。

Android 裝置優先使用 v2rayNG，它以 Xray 核心作為主要執行層，常見協定與路由設定集中在同一個介面中。需要使用 V2Fly 核心體系時，可選擇 v2flyNG。兩者的訂閱匯入、節點選擇與啟動連線流程相近，但核心能力與部分設定欄位並不完全相同。不要假定一個用戶端匯出的所有進階設定，另一個用戶端都能完全讀取；遷移時應先確認協定欄位與路由規則。

協定名稱不等於用戶端名稱

VMess、VLESS、Trojan 等名稱描述連線協定或驗證方式，REALITY、TLS 等欄位描述傳輸安全性與握手特徵，TCP、WebSocket、gRPC 則屬於傳輸層設定。用戶端負責將這些欄位整理成核心可執行的設定。匯入節點時，必須讓位址、連接埠、使用者識別碼、傳輸方式、加密或安全選項彼此匹配，不能只因協定名稱相同，就認定兩個節點的設定相等。

新手階段不需要逐項手動填寫所有欄位。可靠的做法是先透過訂閱匯入，由提供方維護完整參數，再學習查看節點資訊與日誌。手動修改前先複製一份節點，避免覆蓋原始設定。想進一步理解各欄位含義，可以搭配術語表查閱協定、核心、訂閱與路由概念。建立「介面管理、核心執行、節點提供參數、訂閱負責分發」的模型，是後續安裝與故障排查的基礎。

安裝與首次啟動

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

安裝套件必須同時符合作業系統、處理器架構與用戶端介面分支。Windows 常見裝置使用 x64 套件；macOS 需先判斷 Apple Silicon 或 Intel；Linux 除了發行版套件格式，也要區分 x64 與 arm64；Android 主流裝置通常優先選擇 arm64，只有架構不明或安裝遭系統拒絕時，才改用通用套件。所有入口集中在下載頁面，不要將其他平台的檔案重新命名後嘗試安裝。

Windows 使用者還需要決定桌面版或 WPF 版。若希望與 macOS、Linux 採用相近的介面流程，可先選擇桌面版；若現有操作習慣與設定流程建立在經典 Windows 介面上，則可選 WPF 版。兩者都是 v2rayN，但執行環境、介面元件與部分選單位置不同。遇到教學截圖與目前介面不一致時，先確認使用的分支，而不要直接判斷功能不存在。

Windows、macOS 與 Linux 的啟動重點

Windows 安裝後應從正常使用者目錄啟動，設定目錄需要具備寫入權限。若雙擊後沒有出現視窗，先檢查系統所需執行環境是否完整，再檢查安裝路徑是否過深、目錄是否唯讀，以及防護策略是否阻止程式建立設定與日誌。不要在壓縮檔預覽視窗中直接執行程式，應先完整解壓縮或完成安裝。啟動閃退的分層檢查可參考執行庫與權限排查。

macOS 首次開啟時，系統可能要求確認應用程式來源與網路相關權限。應在系統設定的隱私權與安全性頁面完成明確授權，再重新啟動用戶端。開啟系統代理或 TUN 時，系統也可能要求管理員確認，這是修改網路設定所需的操作。完整流程請見macOS 安裝與網路權限步驟。如果程式可以開啟但無法修改網路設定，應優先檢查權限，而不是重複匯入訂閱。

Linux 使用者先依發行版選擇 deb 或 rpm 套件，再確認目前桌面工作階段是否提供系統代理介面。安裝成功只代表程式檔案已就緒；系統匣圖示、自動啟動與系統代理寫入仍取決於桌面環境。若使用最精簡的視窗管理環境，可能需要在瀏覽器或終端機中個別指定本機代理。用戶端日誌目錄與設定目錄應由目前使用者擁有，避免每次啟動都依賴提升權限。

Android 的安裝與系統連線確認

在 Android 安裝 v2rayNG 或 v2flyNG 後，首次啟動連線時會出現系統層級的連線確認。確認後，狀態列通常會顯示系統提供的連線狀態標示。這項確認只代表系統允許用戶端建立本機網路介面，不代表所選節點一定可用。若按下啟動按鈕後立即停止，應開啟應用程式日誌，檢查節點欄位、網域解析、連接埠連通性與核心啟動結果。

系統的省電策略可能在螢幕關閉後限制背景執行。需要長時間維持連線時，應在系統應用程式管理中，依實際需求允許用戶端在背景執行，並觀察網路切換後的恢復情況。不同裝置的電量管理名稱各異，判斷依據是用戶端程序是否被系統暫停，而不是機械式開啟所有權限。若只在前景使用，維持預設電量策略通常更節省資源。

首次啟動後的基準檢查

進入主介面後，先不要立即開啟多項進階功能。依序確認用戶端能儲存設定、核心檔案可被呼叫、本機連接埠沒有被其他程式佔用，以及日誌視窗能產生啟動記錄。桌面端可先保留預設本機監聽位址，避免直接暴露至區域網路。接著匯入一筆設定或訂閱，選取活動節點，最後再開啟系統代理。每次只變更一個變數，出現異常時才能確認是哪一步引入問題。

Windows:
netstat -ano | findstr LISTENING

macOS / Linux:
lsof -nP -iTCP -sTCP:LISTEN

以上指令用於查看本機監聽連接埠。若用戶端回報連接埠已被佔用，先在設定中確認 HTTP、SOCKS 與 API 等本機連接埠，再利用程序清單找出衝突程式。不要任意結束不熟悉的系統程序；較穩妥的做法是替用戶端改用未被佔用的連接埠，並同步修改瀏覽器、終端機或其他手動代理應用程式中的連接埠。

訂閱匯入與節點管理

訂閱的作用與匯入順序

訂閱網址用於批次取得節點設定，通常也負責名稱調整、參數更新與移除失效節點。它不是用戶端安裝套件，也不是固定節點。匯入時應複製完整網址，在用戶端的訂閱群組或訂閱設定中新增項目，填寫易於辨識的備註，然後手動更新一次。更新完成後回到伺服器清單，確認新增節點位於預期群組，並查看更新日誌是否包含解析錯誤。

在 v2rayN 中，通常先建立訂閱項目，再執行更新；v2rayNG 與 v2flyNG 的入口名稱可能略有不同，但邏輯相同。網址若包含查詢參數或較長的編碼內容，複製時不能遺漏結尾字元，也不要在通訊軟體轉發後繼續使用被截斷的顯示文字。訂閱屬於敏感設定，只應儲存在需要使用的用戶端中，不要放進截圖、公開日誌或共用文件。

更新成功、解析成功與節點可用是三件事

用戶端提示取得完成，只能表示訂閱內容已下載；清單出現節點，表示內容已被辨識；某個節點能建立連線，才表示目前網路、節點參數與核心能力共同符合要求。排查時應查看三項結果：網路請求是否回傳有效內容、解析後是否產生節點、活動節點啟動後是否出現明確的成功或錯誤日誌。將三者混為一談，容易在節點故障時反覆修改訂閱網址。

訂閱更新失敗時，先確認裝置目前的網路本身可用，再檢查系統日期與時間是否有明顯偏差，然後核對網址是否完整。若用戶端正透過已失效的代理執行訂閱更新，可暫時關閉系統代理，或在訂閱設定中調整更新時使用的代理策略。更新後節點數量沒有變化，不一定代表失敗；伺服器端內容未變更時，清單可能維持原樣，應以更新時間與日誌結論為準。

群組、命名與活動節點

有多個訂閱時，應為每個來源設定清楚的名稱，避免將所有節點堆在同一個未命名清單中。群組有三個作用：更新時辨識來源、故障時快速切換、清理時避免誤刪其他設定。節點備註建議保留伺服器端提供的地區或用途資訊，不要只寫「節點一」「備用二」。手動設定應獨立放置，防止訂閱更新時被覆蓋，或與遠端項目混淆。

活動節點是目前用戶端用來建立主要出站連線的項目。選取節點後，還要確認它確實被設為活動伺服器，而不只是清單中反白顯示。不同介面可能透過雙擊、右鍵選單或獨立指令完成設定。切換後觀察狀態列與核心日誌，確認出站設定已重新載入。如果只是選取清單列，但核心沒有重新載入，實際流量仍可能使用上一個節點。

更新策略與設定保留

自動更新適合內容變化較頻繁的訂閱，但更新間隔不宜過短。頻繁重新整理不會提升節點品質，反而會增加無意義的請求，也讓手動排錯時難以判斷清單何時發生變化。日常可保留合理的週期更新，準備使用前再手動更新一次。出現連線故障時，先測試目前設定，再決定是否更新，避免同時變更節點清單與用戶端設定。

訂閱更新可能替換同名節點，或刪除遠端已移除的項目。若曾修改某個節點的本地傳輸參數，應先複製為獨立設定並記錄修改原因，否則下次更新可能恢復遠端值。整體遷移用戶端前，應使用其內建的設定備份或匯出功能，保存訂閱群組、路由設定與偏好選項；單獨複製節點分享文字，通常無法涵蓋所有用戶端設定。

如果更新後所有節點同時異常，優先檢查訂閱內容、用戶端核心與本地網路；如果只有單一節點異常，則更可能是該項目的參數或伺服器端狀態問題。詳細的失敗分支可透過站內搜尋詞「v2rayN 訂閱更新失敗」進入相關說明。完成本章後，應能手動更新訂閱、清楚管理節點群組、明確切換活動節點，並透過日誌區分取得與連線結果。

系統代理與代理模式

本機監聽與系統代理的關係

核心啟動後，會在本機建立 HTTP、SOCKS 等監聽連接埠。應用程式將請求交給這些連接埠後，用戶端再依據路由規則選擇直連、代理或阻斷。系統代理是一種「告訴遵循系統設定的應用程式應將請求送往何處」的機制，本身不負責協定連線。用戶端關閉後，若系統仍殘留舊的代理位址，瀏覽器可能因無法連到本機連接埠而無法存取網路，因此退出時應讓用戶端正常還原系統設定。

多數桌面瀏覽器會讀取系統代理，但命令列工具、部分開發環境、遊戲與獨立網路元件可能忽略它。看到瀏覽器已生效，不能推斷所有應用程式都已被接管；反過來，終端機未生效也不代表節點異常。應依應用程式類型選擇系統代理、應用程式內手動代理或 TUN。相關分線檢查可參考瀏覽器與終端機代理排查。

全域、規則與直連模式

全域模式通常表示大部分符合接管條件的流量都交由代理出站，適合短時間驗證節點與本機監聽是否正常。規則模式會依網域、IP、連接埠、程序或規則集決定出口，是日常使用的主要方式。直連模式讓已接管的流量直接經由本地網路送出，常用於比對測試或暫時停用代理路徑。不同用戶端對模式名稱的翻譯可能略有不同，應以實際出站行為為準。

首次排錯可以先切換至全域模式。如果全域模式可用、規則模式不可用，問題多半位於路由匹配或 DNS 判斷；若兩者都不可用，應回頭檢查節點、核心與本機連接埠；若直連模式也異常，問題可能來自系統代理殘留、應用程式本身設定或本地網路。這種比對方法能快速縮小範圍，但不建議長期用全域模式取代規則設計。

手動代理應用程式如何填寫

需要手動設定代理的應用程式，應填寫用戶端實際監聽的位址與連接埠。本機應用程式通常使用 127.0.0.1，協定類型必須與連接埠一致，不能將 SOCKS 連接埠填入只接受 HTTP 代理的欄位。若用戶端修改了預設連接埠，所有手動設定都要同步更新。區域網路裝置不能使用自己的 127.0.0.1 指向桌面用戶端，而應使用執行用戶端裝置的區域網路位址，並明確開啟區域網路共用。

HTTP 代理環境變數範例：
set HTTP_PROXY=http://127.0.0.1:10809
set HTTPS_PROXY=http://127.0.0.1:10809

macOS / Linux 目前終端機工作階段：
export HTTP_PROXY=http://127.0.0.1:10809
export HTTPS_PROXY=http://127.0.0.1:10809

以上變數只會影響讀取它們的程式與目前作用域。關閉終端機後是否保留，取決於是否寫入 shell 設定檔。排錯時建議先進行暫時設定，確認有效後再決定是否持久化。清除時使用對應系統的變數刪除方式，避免用戶端退出後終端機仍持續請求已關閉的本機連接埠。SOCKS 代理還涉及應用程式是否透過代理解析網域名稱，需要查看該應用程式的具體選項。

區域網路共用的界線

開啟區域網路共用會讓用戶端監聽位址可被同一網路中的其他裝置存取。啟用前應確認監聽位址、系統防火牆與目前網路環境。家庭可信任網路與公共網路應採取不同策略，公共網路中不應為了臨時測試而擴大監聽範圍。共用裝置需要將代理伺服器填寫為執行用戶端電腦的區域網路位址，並使用對應連接埠；電腦進入休眠、切換網路或位址變更後，共用連線會中斷。

區域網路共用只提供本地代理入口，不會自動替其他裝置修改系統網路設定。每台裝置仍需個別設定應用程式代理或系統代理。若同網路裝置無法連到連接埠，先在主機本地確認連接埠正在監聽，再檢查防火牆入站規則與網路是否允許裝置互相存取。若能連到連接埠但無法存取目標，繼續查看用戶端日誌與路由結果，不要將連接埠可達與出站成功混為一談。

用日誌確認流量是否進入用戶端

驗證代理是否生效時，最直接的方法不是只看網頁結果，而是觀察用戶端連線日誌。開啟一個未快取的請求，日誌中應出現對應網域、目標位址、入站類型與最終出站。完全沒有記錄，表示應用程式流量未進入用戶端；有記錄但被直連，表示規則匹配到直連；進入代理後連線失敗，則繼續檢查節點或遠端握手。日誌能將「未接管」與「接管後失敗」分成兩條不同路徑。

路由分流與規則設計

路由規則解決什麼問題

路由分流是在流量進入用戶端後，依目標特徵決定使用哪個出口。常見出口包括代理、直連與阻斷。規則可以匹配網域、IP、連接埠、網路類型、程序或預先定義的規則集。設計目標不是規則越多越好，而是讓常見流量獲得穩定且可解釋的結果。規則過度重疊會增加維護成本，也會讓命中順序難以判斷。

一套基礎規則通常從明確邊界開始：本機與區域網路位址直連，確實需要代理的網域或規則集走代理，其餘流量交給一個可預期的最終規則。最終規則非常重要，沒有符合前置條件的請求都會落到這裡。如果預設出口不明確，同一份規則在不同用戶端或不同版本的設定中可能表現不一致。

規則順序與首次命中

多數路由系統會依序檢查規則，採用首次命中的結果。範圍較具體的規則應放在較寬泛的規則之前。例如某個子網域需要代理，而整個主網域通常直連，子網域規則就必須先出現。組合連接埠、程序與網域條件時，還要確認它們是同時滿足還是任一條件滿足。不能只看規則文字，還需配合用戶端對欄位關係的實作說明。

修改規則後應重新載入設定，並透過日誌查看命中項目。若請求走錯出口，先記錄實際網域與解析位址，再檢查它命中了哪一條規則。不要立即新增更多寬泛規則，因為新規則可能遮蔽原有條件。先用一條精確規則完成驗證，確認方向正確後，再判斷是否擴展為網域後綴、IP 網段或規則集。

網域匹配與 IP 匹配的差異

網域規則取決於用戶端在路由階段能否看見目標網域。如果應用程式先在本機完成解析，只將 IP 交給代理，網域條件可能無法使用；反過來，IP 規則依賴解析結果與位址歸屬，內容服務使用動態位址時可能頻繁變動。路由器中的網域策略、DNS 設定與入站協定會共同影響可見資訊，因此網域規則失效時不能只檢查拼寫。

網域後綴規則適合涵蓋一組結構穩定的子網域，完整網域規則適合精確例外。IP 網段規則應使用正確的 CIDR 表示法，前綴長度決定範圍，寫得過寬可能連無關流量也一併匹配。區域網路保留位址通常應直連，避免內部服務繞經外部路徑。連接埠規則則適合協定邊界明確的服務，但現代應用程式可能混用多個連接埠，不能僅憑單一連接埠推斷全部流量。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "domain:docs.example.test",
          "domain-suffix:example.test"
        ],
        "outboundTag": "proxy"
      }
    ]
  }
}

範例展示常見的欄位結構：私有位址走直連，指定測試網域走代理。實際用戶端可能透過圖形介面產生設定，出站標籤也必須與用戶端既有的出站名稱一致。範例中的保留測試網域僅用於說明語法。將片段合併至完整設定前，應先匯出或備份目前規則，並確認 JSON 的逗號、括號與陣列層級正確。

為什麼 DNS 與路由必須一起看

DNS 決定網域名稱如何取得位址，路由決定請求經由哪個出口。若 DNS 查詢與後續連線使用不同路徑，可能出現解析結果適合某個網路，但實際連線卻從另一個網路送出的情況。規則模式異常而全域模式正常時，應檢查網域策略、DNS 伺服器選擇、快取結果，以及請求是否由代理端解析。切換設定後，舊快取可能在短時間內持續影響判斷。

不要同時大幅修改 DNS、路由規則與代理模式。較穩妥的做法是先保留預設 DNS，使用精確網域規則驗證分流；確認路由生效後，再依解析需求調整 DNS。出現問題時記錄四項資訊：原始網域、解析出的位址、命中的規則、最終出站。四項資訊完整時，通常可以判斷錯誤位於解析、匹配或連線階段。

建立可維護的規則層次

長期規則可分為四層：最前面放必須優先處理的例外；接著放區域網路與本機服務；再放主要網域或規則集；最後設定預設出口。每條自訂規則都應有清楚的名稱與用途說明。短期測試規則在問題解決後應及時刪除，避免半年後仍持續影響流量。團隊或多裝置使用時，應記錄規則變更原因，而不是只保留最終設定檔。

規則數量增加後，可以定期檢查重複條件、永遠不會命中的後置規則，以及已失效的網域。若某個應用程式表現異常，優先建立針對該應用程式的最小測試規則，而不是重新排列整套規則。完整掌握分流的標誌不是規則表很長，而是能從日誌解釋某個請求為何走直連、代理或阻斷，並能在修改後驗證預期結果。

TUN 模式與全流量接管

TUN 與系統代理的根本差異

系統代理依賴應用程式主動讀取作業系統設定，TUN 則透過虛擬網路介面接收更廣泛的 IP 流量。對於忽略系統代理的應用程式、獨立網路元件或需要統一處理的桌面流量，TUN 通常能提供更完整的覆蓋。但覆蓋範圍擴大也意味著設定更複雜，DNS、路由表、虛擬網卡權限與其他網路軟體都可能影響結果。能用系統代理解決的情境，不必預設開啟 TUN。

TUN 不是「更快」的開關，它改變的是流量進入用戶端的方式。節點連線品質、協定握手與遠端路徑不會因啟用 TUN 而自動改善。若系統代理模式下節點已無法連線，直接切換 TUN 往往只會增加新的變數。正確順序是先用系統代理驗證節點與核心，再在確有應用程式無法被接管時啟用 TUN。

啟用前的準備

啟用 TUN 前應關閉其他可能修改路由表或建立虛擬網卡的網路工具，記錄目前 DNS 與系統代理狀態，並確保用戶端具備建立虛擬介面所需的權限。Windows 需要注意虛擬網卡驅動程式與管理員授權；macOS 會要求網路延伸功能或相關系統確認；Linux 需要具備存取 TUN 裝置與寫入路由的條件。權限不足通常會在啟動日誌中明確表現為介面建立或路由設定失敗。

首次測試時保持規則簡單，優先使用已驗證可用的活動節點。啟動後檢查三項結果：虛擬介面是否建立、預設或策略路由是否依預期寫入、DNS 查詢是否進入指定路徑。若用戶端開關顯示已啟用但介面不存在，應檢查權限與驅動程式；介面存在但沒有流量，檢查路由表；流量進入後網域解析失敗，則轉向 DNS 設定。

嚴格路由、自動路由與繞過範圍

自動路由通常由用戶端產生需要接管的系統路由，減少手動設定。嚴格路由用於降低流量繞過虛擬介面的可能性，但也可能與區域網路服務、虛擬機器、容器或企業網路策略衝突。啟用嚴格策略前，應先確認印表機、檔案共用、開發服務與本地管理頁面是否需要保留直連，並為私有位址設定明確的繞過或直連規則。

區域網路存取異常時，不要立即停用所有 TUN 設定。先檢查私有位址是否被錯誤送入代理、區域網路網域是否由不合適的 DNS 解析，以及系統防火牆是否將虛擬介面視為不同網路。對於虛擬機器與容器，還要確認它們使用的是主機 NAT、橋接網路或獨立介面。在不同網路拓撲下，流量是否經過主機 TUN 並不相同。

常見衝突的定位方法

TUN 啟用後完全斷網，先停止 TUN 並確認基礎網路恢復，再查看啟動日誌中最後一個成功步驟。若停止後仍異常，檢查用戶端是否還原了系統 DNS、預設路由與系統代理。能存取 IP 但無法存取網域時，重點檢查 DNS；只有區域網路無法使用時，檢查私有位址路由；只有特定應用程式失敗時，檢查程序本身的網路堆疊、IPv4 與 IPv6 選擇，以及應用程式是否綁定特定介面。

系統休眠、網路切換與用戶端異常退出，都可能讓虛擬介面狀態與實際連線不同步。恢復後可先停止連線，等待介面與路由清理完成，再重新啟動。不要連續快速切換開關，因為系統網路服務需要時間套用變更。若每次重新啟動都重現問題，應保留啟動前後的路由表與日誌，尋找固定失敗步驟，而不是依賴多次隨機重試。

Windows 查看路由：
route print

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

Linux 查看路由：
ip route

這些指令用於觀察系統路由，不會修改網路。比較 TUN 啟用前後時，應注意預設路由、虛擬介面對應路由與私有網段路徑。只記錄必要的介面與網段資訊，分享日誌前移除訂閱網址、節點憑證與本地裝置識別資訊。完成本章後，應能判斷問題屬於介面未建立、路由未接管、DNS 不一致，還是規則出口錯誤。

日常維護、備份與故障排查

建立穩定的更新節奏

用戶端、核心與訂閱是三條不同的更新線。用戶端更新可能改變介面、設定遷移與系統整合；核心更新可能影響協定實作與路由行為；訂閱更新主要改變節點內容。日常維護應分別記錄，不要在出現故障時一次更新所有元件。一次只變更一個層級，完成啟動、連線與分流驗證後再繼續，出現回歸問題時才能定位來源。

更新用戶端前先閱讀介面中的變更說明，確認目前作業系統與安裝分支仍然匹配。更新後不要立即刪除舊設定備份，應先驗證訂閱清單、活動節點、路由規則、本機連接埠、系統代理與 TUN。若新介面重新產生了預設設定，重點檢查連接埠與出站標籤，因為手動代理應用程式與自訂規則可能仍引用舊值。

備份什麼，而不只是複製節點

完整備份至少應涵蓋訂閱群組、手動節點、自訂路由、DNS 設定、連接埠偏好與用戶端一般選項。單一節點分享文字通常不包含系統代理模式、視窗設定、自動更新排程與全部路由規則。優先使用用戶端提供的備份或匯出功能，並將備份放在受控位置。還原時先關閉正在執行的核心，避免設定檔同時被寫入。

備份應以「可還原」而不是「檔案存在」來判斷。完成一次備份後，可以在不影響主要設定的環境中查看其內容結構，確認訂閱與路由檔案確實包含在內。跨平台遷移時，不要直接覆蓋與系統路徑、權限或介面分支相關的全部檔案；較穩妥的做法是匯入通用設定，再個別重建系統代理、開機啟動與 TUN 權限。

日誌的閱讀順序

日誌應從首次出現的明確錯誤開始查看，而不是只看最後一行。核心啟動失敗時，後續通常會連續產生連接埠不可用、連線遭拒或狀態停止等衍生訊息。先找出設定載入、監聽連接埠、DNS 初始化、建立出站連線中的第一個失敗點，再判斷屬於語法、連接埠、權限或網路問題。站內文章看日誌定位設定錯誤提供了常見錯誤入口與處理方式。

設定語法錯誤通常會帶有欄位名稱或行列位置；連接埠佔用會指出監聽位址；權限問題通常發生在寫入目錄、建立介面或修改系統網路設定時；節點握手失敗則多出現在出站連線階段。日誌出現網域解析失敗時，還要區分用戶端自身解析、代理端解析與系統解析。不要只截取一句錯誤，應保留其前後的初始化背景。

依症狀建立排查樹

用戶端無法啟動：檢查執行環境、安裝路徑、目錄權限與設定損壞。用戶端能啟動但核心失敗：檢查連接埠佔用、設定欄位與核心日誌。核心啟動但網頁沒有記錄：檢查系統代理、應用程式設定或 TUN 接管。日誌有請求但走錯出口：檢查路由命中與 DNS。請求進入代理但連線失敗：更換同組節點比對，並檢查節點參數與目前網路。

只有一個應用程式異常時，不要重設整個用戶端。先判斷該應用程式是否遵循系統代理、是否快取 DNS、是否使用獨立網路元件，以及是否設定了自己的代理。只有一個節點異常時，不要刪除全部訂閱。更換同組節點可以區分單一節點問題與用戶端問題。所有節點同時異常時，再檢查訂閱變化、核心狀態、本地網路與系統時間。

退出、休眠與網路切換

退出用戶端前，應讓它正常停止核心並還原系統網路設定。直接結束程序可能留下系統代理位址、虛擬介面或暫時路由。出現退出後無法連網時，先檢查系統代理是否仍指向本機連接埠，再檢查 TUN 介面與 DNS。未確認狀態前不要同時重設多個網路元件，否則難以判斷是哪一項恢復了連線。

裝置從休眠恢復，或在有線與無線網路之間切換後，原有節點連線、DNS 快取與區域網路位址可能失效。可先觀察用戶端是否自動重新連線，再發起新請求驗證日誌。若狀態停留在舊連線，應停止並重新啟動核心。若長期出現恢復失敗，記錄網路切換前後的介面與路由差異，並減少同時啟用的自動網路功能。

良好的維護基準包括：設定具備可還原備份，訂閱來源與群組清楚，用戶端與核心分開更新，日誌入口隨時可找到，系統代理與 TUN 的恢復方法明確。具備這些條件後，大多數問題都能在現有安裝上定位，不需要把重新安裝當作第一選擇。

進階設定與長期學習路線

從能用走向可解釋

進階階段的目標不是開啟更多開關，而是能解釋一個請求從應用程式到出站的完整路徑：應用程式透過系統代理、手動代理或 TUN 進入用戶端；入站保留網域名稱或取得目標 IP；DNS 依設定路徑解析；路由規則選擇直連、代理或阻斷；核心依節點協定建立出站連線；日誌記錄每個階段的結果。只要路徑清楚，複雜問題也能拆成有限步驟。

建議先選一個日常使用的應用程式作為觀察對象，在系統代理模式下記錄其入站類型、網域、命中規則與出站。接著切換為 TUN，再比較路徑變化。實驗期間保持節點不變，避免將網路波動誤判為模式差異。完成一次完整比對，比一次匯入大量規則更能建立可靠理解。

理解入站、出站與標籤

入站定義用戶端如何接收流量，例如本機 HTTP、SOCKS 或 TUN；出站定義流量最終如何離開，例如代理節點、直連或阻斷；標籤用於讓路由規則引用這些物件。自訂設定常見的錯誤是規則中的出站標籤與實際設定不一致，或多個入站監聽同一個連接埠。閱讀產生的設定時，應先找到入站清單與出站清單，再查看路由如何連接兩者。

圖形用戶端會自動維護部分標籤與連接埠。手動修改完整設定後，介面再次儲存可能重新產生相關欄位，因此應分清「由用戶端管理的設定」與「使用者自訂片段」。能透過圖形介面完成的常規設定，優先使用介面；只有需要表達更精細條件時才編輯自訂設定，並保留修改前版本。若核心啟動失敗，可參考設定錯誤日誌定位方法。

最小化實驗設定

測試新規則時建立最小條件：一個已驗證的節點、一種接管方式、一條精確規則與一個明確目標。先確認請求依預期命中，再逐步擴展為網域後綴、規則集或程序條件。如果最小設定都無法運作，增加更多 DNS 與路由選項只會擴大排查範圍。每次實驗都記錄修改項目、預期結果、實際日誌與回退方式。

{
  "type": "field",
  "domain": [
    "full:api.example.test"
  ],
  "network": "tcp",
  "outboundTag": "proxy"
}

這段規則表示僅匹配指定測試網域的 TCP 流量，並交給名為 proxy 的出站。實際使用前必須確認出站標籤存在、用戶端核心支援對應欄位，並將規則放在較寬泛規則之前。驗證成功後，若需要涵蓋子網域，再明確改為後綴規則；不要一開始就使用範圍過大的條件。

效能判斷應以可重複的比對為基礎

連線體驗會受到本地網路、節點路徑、協定設定、DNS、並行連線與應用程式行為共同影響。判斷某項設定是否改善效能時，應固定節點與目標，分別測試修改前後，並多次觀察建立連線與持續傳輸。單次開啟網頁的速度容易受快取影響，不能作為穩定結論。用戶端介面中的即時狀態也只反映當下條件，不適合用來建立長期評分。

若建立連線速度慢，先區分 DNS 等待、TCP 建立連線、TLS 或協定握手；若建立後傳輸不穩定，觀察封包遺失、網路切換與節點路徑；若只有規則模式變慢，檢查 DNS 與規則集；若只有 TUN 變慢，檢查虛擬介面、MTU，以及是否出現重複接管。不同症狀對應不同層級，將問題一律歸因於用戶端，通常會錯過真正原因。

多裝置設定如何保持一致

桌面與 Android 可以使用同一訂閱來源，但不應假定所有用戶端偏好都會自動同步。訂閱解決節點分發，路由規則、DNS、系統代理與 TUN 仍可能需要分別設定。維護多台裝置時，先定義共同策略，例如私有位址直連、指定網域代理、其餘使用預設出口，再依各用戶端能力實作。不要將依賴某個平台路徑或程序名稱的規則複製到另一個平台。

v2rayN、v2rayNG 與 v2flyNG 的選單結構及核心體系存在差異。遷移時先比較協定欄位是否完整，再重建路由與 DNS。桌面端的區域網路共用、終端機環境變數與開機啟動設定不屬於 Android 設定；Android 的系統連線授權與背景電量策略也不能由桌面設定取代。保持策略一致，比強求設定檔逐字相同更實際。

建議的學習順序

第一階段掌握訂閱、活動節點、系統代理與日誌；第二階段掌握全域與規則模式的比對方法；第三階段能夠撰寫精確網域規則並解釋首次命中；第四階段理解 DNS 與路由的關係；第五階段再啟用 TUN，分析虛擬介面與系統路由；最後學習完整設定結構、標籤引用與跨裝置策略。每個階段都應保留一份可運作的基準設定。

遇到新術語時查閱術語表，需要重新進行首次連線流程時回到快速上手教學，比較三款用戶端定位時查看用戶端比較。系統問題優先閱讀對應平台文章，啟動閃退、系統代理未生效與核心設定錯誤都有獨立的排查路徑。將知識依層次整理，能避免每次故障都從頭搜尋零散答案。

完成手冊後的能力清單

完成全部章節後，應能依平台選擇正確的用戶端與安裝套件，獨立匯入及更新訂閱，明確設定活動節點，區分系統代理與 TUN，使用日誌判斷流量是否進入用戶端，設計包含例外、私有位址、主要規則與預設出口的路由層次，並在更新前完成設定備份。更重要的是，能將異常歸入執行環境、核心、節點、接管、DNS、路由或系統網路中的某一層。

下次遇到連線異常時，先保留現場並回答五個問題：用戶端是否穩定執行，核心是否成功監聽，應用程式流量是否進入，路由選擇了哪個出口，出站連線在哪個步驟失敗。這五個答案通常足以確定後續行動。需要重新安裝用戶端時，前往下載頁選擇目前平台；已完成安裝但不熟悉操作流程，則從快速教學重新建立一份最小可用設定。