V2Ray 使用手冊

核心概念：分清接入、匹配與出站

用戶端、核心與伺服器

V2Ray 通常泛指 Project V 相關的代理技術與工具生態，並非單一圖形化軟體。用戶端負責儲存伺服器資料、匯入訂閱、切換設定及顯示日誌；核心負責建立連線、辨識流量、執行路由及處理協定。伺服器則在遠端運作，接收協定連線並繼續連往目標。三者各司其職：介面能開啟只代表用戶端可以執行，不代表核心已成功啟動，更不代表遠端連線可用。

V2Fly 與 Xray 是相關生態中的不同核心專案。兩者共用部分設定概念，但功能範圍、協定擴充及參數細節並不完全相同。v2rayN 可提供不同核心的管理介面，實際選項視使用的發行版本而定；v2rayNG 主要使用 Xray，v2flyNG 則使用 V2Fly。遇到不支援的欄位時，先確認目前啟動的是哪個核心，再查閱相應的設定說明；不能只憑用戶端名稱判斷支援範圍。

一條連線會經過哪些環節

將一次連線拆成四個階段，較容易找出問題：應用程式先將連線交給本機接入點，核心再依規則選擇出站，代理出站連上遠端伺服器，最後由遠端連往目標位址。HTTP 代理、SOCKS 代理與 TUN 是不同的接入方式；direct、proxy 等標籤則用來選擇出站。接入失敗時，調整遠端協定沒有幫助；規則選錯時，一再更換本機監聽連接埠也無法解決根本問題。

伺服器資料通常包含位址、連接埠、協定、身分資訊、傳輸方式與安全層。協定用來約定用戶端與伺服器如何通訊，傳輸方式描述資料如何承載，TLS 或 REALITY 等設定則屬於連線安全機制。VLESS 不是傳輸方式，WebSocket 也不是加密協定。匯入後應逐層核對；不能因位址相同就認定兩份設定等同，路徑、服務名稱與伺服器名稱等欄位都可能影響連線。

網域解析與路由的關係

DNS 會將網域名稱解析為位址，但網域名稱不一定會在進入用戶端前就消失。有些應用程式會將完整網域名稱交給代理，有些則先在本機解析，再傳送位址。核心取得的資訊不同，可匹配的規則也不同。因此網域規則未命中時，應檢查接入方式及日誌中的目標類型，而不是立刻認定規則庫已損壞。不同應用程式即使存取同一網站，也可能因解析位置不同而使用不同出站。

路由匹配與 DNS 查詢是兩個不同動作。設定網域解析策略，可能會讓核心為了匹配位址規則而發出查詢，但不代表應用程式的所有 DNS 請求都會改走指定通道。使用 TUN 時，還需考慮系統解析器、用戶端 DNS 接管及瀏覽器自行解析等路徑。先釐清實際請求經過哪些元件，再檢查設定，通常比一次啟用多個 DNS 選項更有效。

建立可驗證的起點

初次設定只需要一份來源明確的伺服器資料、一種接入方式，以及一套容易理解的路由。先讓瀏覽器透過系統代理連線，再查看連線日誌是否顯示目標及預期的出站。不要同時啟用 TUN、自訂 DNS、應用程式分流及複雜規則，否則出問題時難以判斷原因。建立基準設定的重點不在於選項少，而是每一步都能與前一個狀態比較。

本手冊中的設定區塊用於說明個別欄位，不包含完整的伺服器連線資料。實際使用時，請優先透過圖形介面修改，再檢查用戶端產生的結果。直接編輯執行中的設定檔，可能在重新啟動、切換伺服器或更新訂閱後遭到覆寫。讀完本章後，應能用「流量從哪裡進入、匹配哪條規則、交給哪個出站」描述一次連線；若術語仍不清楚，可接著查閱術語手冊。

選擇用戶端：平台、核心與資料相容性

桌面平台優先選用 v2rayN

Windows、macOS 與 Linux 桌面環境建議從 v2rayN 開始。它將伺服器、訂閱群組、路由與執行日誌整合在圖形介面中，適合建立可重複的操作流程。Windows 提供桌面版與傳統 WPF 版：桌面版採用跨平台介面，WPF 版則保留經典桌面操作方式。請依作業系統環境與使用習慣選擇，不必為同一條連線同時執行兩個版本。

macOS 選擇安裝套件前，先查看「關於這台 Mac」中的晶片資訊；Apple Silicon 對應 arm64，Intel 對應 x64。Linux 除了處理器架構，也要確認發行版使用的套件格式：使用 deb 套件的環境選 deb，使用 rpm 套件的環境選 rpm。架構決定程式能否在處理器上執行，套件格式則決定安裝工具如何管理檔案，兩者都要符合，不能只看副檔名判斷。

Android 平台：區分首選與備選

Android 平台首選 v2rayNG，主要使用 Xray 核心；需要相容 V2Fly 設定時，再評估 v2flyNG。兩者都是圖形化用戶端，但不能假設支援的協定完全相同。若伺服器資料依賴特定核心擴充功能，應先確認用戶端使用的核心是否支援，再考慮匯入方式。成功匯入不代表相容，解析連結與建立實際連線是兩個不同階段。

Android 套件架構應優先依裝置作業系統與處理器支援情況判斷。多數較新的裝置適用 arm64，但仍可能遇到處理器支援、系統環境卻不相容的情況。無法確認時可考慮通用套件，通常代價是檔案較大。安裝程式若顯示不相容，請回頭檢查裝置資訊與套件選擇，不要反覆安裝同一個檔案。相關下載入口集中在Android 下載區，不必從不同來源拼湊安裝檔。

依需求核對，不要只看名稱猜測

選擇前先整理三項需求：伺服器使用的協定與傳輸方式、需要代理的應用程式，以及是否必須使用 TUN。桌面環境以瀏覽器為主時，通常可從系統代理開始；不遵循系統代理設定的應用程式，需要個別設定或評估 TUN；Android 則要了解系統 VPN 接入方式與應用程式清單。功能多不代表設定更合適，選擇能滿足目前需求且容易維護的組合即可。

訂閱相容性也應另外確認。同樣稱為訂閱網址，回傳內容可能是協定連結清單、編碼後的列表，或專用設定檔。用戶端支援某種協定，不代表支援所有訂閱格式。若下載前已取得伺服器資料，請先確認提供者建議的用戶端類型及匯入說明。格式不符時，優先向來源取得正確的原始入口，不要將私人訂閱網址提交給來源不明的線上轉換網站。

遷移時保留回復方案

從另一台裝置遷移時，先在新用戶端建立獨立的訂閱群組，只測試一台伺服器，不要立刻複製所有路由、DNS 與接入設定。不同平台的系統代理、權限管理及網卡行為各有差異，原裝置可用的設定不一定能原封不動地搬過去。確認基本連線正常後，再逐項遷移使用需求相關的規則，並記錄每次變更對應用程式存取的影響。

同時執行多個用戶端，容易搶用代理連接埠、修改系統代理或佔用 VPN 接入。評估替代方案時，先停止舊用戶端的接入功能，再啟動新用戶端。保留舊設定以便回復，但不要讓兩者同時管理系統流量。三款用戶端的詳細差異請參閱用戶端核心與平台比較筆記；選定用戶端後，下一章將說明安裝與首次啟動。

安裝與初始化：權限、目錄與監聽

安裝前先確認程式與資料的存放位置

前往用戶端下載頁面，依平台與處理器架構選擇下載項目。安裝前先結束已執行的程式，確認下載的是預計使用的用戶端，而非其他平台的套件。使用安裝程式時依照精靈完成安裝；若發行套件需要解壓縮後執行，請先完整解壓縮到獨立資料夾再啟動。不要直接從壓縮檔預覽視窗執行程式，否則可能找不到相關檔案，也容易造成後續更新或儲存資料異常。

程式目錄與設定資料目錄不一定相同。有些發行版本會在使用者目錄儲存資料，有些則可使用獨立資料目錄。首次啟動後，先查看設定中的資料位置或備份功能，確認訂閱與路由會儲存在哪裡。若計畫遷移裝置，應備份用戶端提供的資料，而不只是複製桌面捷徑。也不建議將執行目錄放在多人可寫入或經常清理的暫存位置。

桌面系統的首次啟動

Windows 安裝後，先以一般使用者身分啟動，確認介面與日誌能否正常顯示。若 WPF 版提示缺少執行元件，請依發行套件的要求安裝相應環境，或改選適合目前系統的安裝項目。不要因為啟動失敗就長期以系統管理員身分執行。一般代理與管理虛擬網卡所需的權限不同，後者在啟用相關功能時再依提示授權。

macOS 將應用程式移至預定位置後再開啟，避免在暫存的掛載位置反覆執行。若系統顯示安全性提示，先確認檔案來源、套件類型與系統支援範圍，再依照系統提供的應用程式安全流程處理。Linux 使用相應的套件管理工具安裝後，從應用程式選單啟動並檢查日誌；若桌面元件或權限不足，請針對提示處理，不要為了繞過問題而大幅修改系統目錄權限。

Android 安裝後的系統授權

Android 安裝時，只授予實際安裝來源所需的權限，完成後可視需要撤銷。首次啟動時先匯入一份伺服器資料，再啟動連線；系統跳出的 VPN 連線要求，是允許用戶端建立本機流量接入。授權不代表遠端連線成功，仍須檢查伺服器設定與存取結果。若已有其他 VPN 類應用程式在執行，請先中斷其連線，避免接入資源衝突。

為了區分安裝問題與背景執行問題，首次測試時讓應用程式保持在前景並亮著螢幕，先確認連線本身正常，再測試鎖定螢幕與背景執行。若只有鎖定螢幕後才中斷，應優先檢查電池最佳化、背景執行限制及廠商系統的工作清理設定，而不是重新安裝。相關操作請接著閱讀Android 授權、省電與應用程式分流設定。

檢查核心與本機監聽

桌面用戶端開啟後，請在日誌或狀態區確認核心確實已啟動。找不到執行檔、設定解析失敗與連接埠遭佔用是不同問題：第一種請檢查安裝內容是否完整，第二種撤銷最近的變更，第三種確認是否有舊程式執行中或其他程式使用相同連接埠。監聽尚未啟動前，不要測試瀏覽器代理，否則瀏覽器只會顯示本機連線遭拒。

確認監聽位址、連接埠與代理協定後，再決定如何讓應用程式接入。系統代理應指向用戶端實際監聽的位置；手動設定應用程式時，也要分清 HTTP 與 SOCKS 入口。連接埠沒有固定必用的數字，請以目前設定為準。變更連接埠後，應同步更新應用程式設定；不要讓應用程式繼續連到舊連接埠，也不要把伺服器的遠端連接埠誤填成本機代理連接埠。

初始化階段先不要啟用開機自動啟動或自動接管。先完整測試「啟動核心、讓應用程式接入、停止接入、結束程式」的流程，確認結束後系統網路恢復正常，再啟用自動化選項。這樣才能清楚知道用戶端實際修改了哪些系統設定。若結束後仍無法連線，先檢查系統代理是否殘留，不要立刻重設整個網路環境；常見問題請參閱常見問題與故障排查。

匯入訂閱：群組、更新與欄位核對

先確認資料類型與存取範圍

訂閱網址是用來更新資料的入口，不等於單一伺服器連線。它可能回傳多筆伺服器資料，並在日後更新時增刪內容。單一協定連結則描述一條連線，QR Code 只是承載連結的方式。匯入前先確認取得的是訂閱入口、單一分享連結，還是完整設定檔，再選擇相應操作。若將訂閱網址貼到單一伺服器位址欄，通常只會產生無法連線的錯誤設定。

訂閱網址可能包含可存取私人資料的識別資訊，應像連線憑證一樣妥善保存。請人協助排查時，不要傳送完整網址，也不要將 QR Code 直接公開發布。說明回傳格式、錯誤類型與用戶端名稱，通常已足以進行初步檢查。若網址曾意外公開，應透過資料提供者的管理方式更換入口，而不只是刪除聊天記錄或瀏覽器歷史。

在群組中建立更新關聯

v2rayN 可從訂閱群組管理功能新增群組，填入易於辨識的備註與實際訂閱網址，儲存後執行更新。每個來源使用一個群組，方便掌握更新影響範圍。備註僅供本機辨識，不會改變連線能力。首次更新後，請檢查是否新增伺服器項目、項目是否位於正確群組，以及日誌有無格式解析錯誤；不要只看介面是否顯示成功。

在 v2rayNG 與 v2flyNG 中，選擇訂閱管理相關功能，新增網址並更新；選單名稱以實際介面為準。若持有單一分享連結，則使用剪貼簿匯入或 QR Code 掃描等相應功能。匯入前確認剪貼簿內容沒有前後說明文字；掃描後核對協定、位址與備註。連續匯入多個 QR Code 時，更要確認有沒有重複新增，以免從清單選到舊項目。

更新失敗時，分別檢查網路與格式

更新失敗時，先確認網址是否完整，包含協定前綴、路徑與查詢參數；有些複製方式可能漏掉末尾字元。接著判斷是連線逾時、存取遭拒、憑證錯誤，還是內容解析失敗。前兩種優先檢查網路路徑與入口權限；憑證錯誤還要檢查系統時間與憑證環境；解析失敗則須確認回傳內容是否為用戶端支援的訂閱格式，而非網站登入頁或錯誤說明。

用戶端可能提供透過代理更新訂閱的選項。若直接連線無法取得內容，可在已有可用連線的前提下嘗試；若目前沒有任何可用連線，就不能把「透過代理更新」當成自動修復方法。先建立一條可用的初始連線，或向資料提供者確認可存取的更新方式。不要同時切換更新路徑、DNS 與核心，否則很難判斷真正影響結果的是哪項設定。

核對匯入結果，不要只看備註

從清單選擇一台伺服器，逐層核對協定、位址、連接埠、身分欄位、傳輸方式與安全層。WebSocket 設定要留意路徑與 Host；gRPC 設定要確認服務名稱；TLS 設定則要核對伺服器名稱與憑證驗證條件。不同協定的欄位不能互相替代；欄位留空可能是允許的，也可能表示資料不完整，應依伺服器端要求判斷。

更新前記錄目前選取的伺服器與群組，更新後再確認選取狀態。有些用戶端會保留相符項目，有些情況下原項目可能遭到取代或刪除；即使介面仍顯示類似備註，也不能證明底層參數沒有改變。若問題只在更新後出現，應比較實際欄位與核心錯誤，不要立刻刪除所有資料。保留一個已驗證的獨立測試項目，有助於分辨訂閱變更與本機環境變更。

訂閱管理完成的標準是：來源明確、群組易於辨識、更新行為可說明，且至少一個項目能成功建立連線。伺服器清單中的測試結果只代表當下狀況，不能取代實際應用程式驗證。下一步先讓目標應用程式透過明確的接入方式連線，再考慮最佳化路由。若只想完成初次設定，可返回快速入門流程；若對協定欄位有疑問，則請查閱協定與傳輸術語。

代理模式：接入範圍與流量方向

系統代理負責讓應用程式接入

系統代理是作業系統提供給應用程式參考的代理設定。桌面用戶端啟用後，通常會將 HTTP 等代理入口寫入系統設定；遵循該設定的應用程式才會將連線交給用戶端。瀏覽器通常會採用系統代理，但部分遊戲、命令列工具及內建網路元件的程式不一定會遵循。系統代理已啟用但只有部分應用程式生效，屬於接入範圍問題，不應直接歸咎於遠端伺服器。

在 v2rayN 中先啟動可用的伺服器，再設定系統代理，接著重新建立瀏覽器連線。測試前先關閉或檢查瀏覽器的獨立代理擴充功能，避免其覆蓋系統設定。已建立的長連線可能仍沿用原本路徑，因此變更代理設定後應重新載入頁面，必要時重新開啟應用程式。只看開關顏色，無法證明新的連線確實已進入用戶端。

全域與繞過模式決定接入後的流量走向

全域代理通常表示將進入用戶端、且未被必要例外規則處理的流量交給代理出站；這不代表系統中的每個應用程式都會自動接入。繞過中國大陸等模式則依網域與位址規則，讓部分目標直連，其他目標走代理。兩者屬於路由選擇，與系統代理是不同層次。可以啟用系統代理並使用繞過規則，也可以透過 TUN 接入後採用相同的路由方式。

使用全域模式排查時，目的是暫時減少目標分流造成的變數，而不是永久忽略所有本機需求。區域網路裝置、回環位址及遠端伺服器本身的連線仍需妥善處理。不同用戶端預設的例外規則可能不同，因此「全域」不代表刪除所有規則。若要確認某個目標實際走哪條路徑，應檢查目前預設與執行日誌，而不是只憑模式名稱推測。

逐一驗證單一應用程式的連線路徑

先選一個容易重複測試的應用程式，確認它使用系統設定還是獨立代理設定。若要手動填寫代理，請使用本機監聽位址與相應的協定連接埠，而不是遠端伺服器位址。SOCKS 入口是否會將網域交給代理解析，也取決於應用程式支援的選項；本機解析與遠端解析可能命中不同規則。操作前記錄原始設定，測試結束後再還原，以免留下不易察覺的覆寫設定。

驗證時同時觀察應用程式結果與用戶端日誌：應用程式連線失敗且日誌完全沒有目標記錄，優先檢查接入；有記錄但出站選錯，檢查路由；使用預期的代理出站仍連線失敗，再檢查協定與遠端。日誌詳細程度不足時，可暫時提高層級後重現一次。不要只憑頁面能否開啟判斷問題所在，也不要把快取頁面當成新的網路連線結果。

Android 應用程式分流與桌面例外

Android 的 VPN 接入可搭配應用程式清單使用。清單可能表示「只代理選取的應用程式」，也可能表示「略過選取的應用程式」，兩者意思相反，設定前務必閱讀目前選項的說明。加入清單後重新建立連線，並讓待測應用程式重新建立連線。被清單排除的應用程式不會因切換全域路由而自動納入，因為流量根本沒有進入用戶端處理路徑。

桌面環境也有系統代理例外清單、瀏覽器獨立設定與應用程式自身的網路選項。無法連線到本機管理頁面時，先檢查流量是否被送往不適合的代理路徑；某個應用程式始終直連時，則檢查它是否略過系統設定。不要用不斷切換全域與繞過模式來取代接入分析。完整比較請參閱系統代理與路由模式筆記；確認接入正常後，再進入下一章設定規則。

路由分流：順序、條件與出站標籤

先確認實際由誰執行規則

路由規則由目前執行的核心負責處理，圖形介面則用來產生或管理設定。修改前先確認使用中的核心、啟用的路由預設與伺服器設定類型。有些自訂設定會自行定義路由，不一定採用用戶端的一般規則頁面。修改後完全沒有變化時，應先確認編輯的內容是否確實套用到執行設定，而不是反覆調整一套未被使用的預設。

規則通常依順序比對，第一條命中的規則會決定出站。將精確的業務網域放在廣泛分類前，將區域網路例外放在一般代理規則前，可減少規則互相覆蓋。同一條規則中不同條件的組合方式也要確認：以常見的 field 規則為例，不同類型的多個條件通常必須同時符合，同類清單則提供多個候選值。不要把同時包含網域與連接埠的規則誤解為兩條獨立規則。

理解 domainStrategy 與標籤

domainStrategy 會影響路由匹配時的網域解析方式。AsIs 不會為位址匹配主動解析網域；IPIfNonMatch 會在網域未匹配後嘗試解析，以繼續比對位址條件；IPOnDemand 則可能在遇到相關位址規則時提前解析。它不是代理協定開關，也不等同於用戶端所有 DNS 的轉送策略。選擇時應考量規則內容與解析成本。

outboundTag 會引用實際存在的出站標籤。direct、proxy、block 只是常見名稱，必須有相應的出站定義才有作用。以下範例僅展示路由片段，假設執行設定中已定義 direct 與 proxy，且具備相應的規則資料檔。不要將片段單獨存成完整設定檔，也不要在未核對標籤前直接覆蓋用戶端產生的內容。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

規則資料與精確網域

geosite 用來引用網域集合，geoip 用來引用位址集合；集合名稱與可用內容取決於實際安裝的資料檔。這些資料不是透過網路即時查詢得出的絕對結論，更新後分類也可能改變。某個網站可能使用多個關聯網域，只匹配首頁網域未必涵蓋登入、資源與 API 請求；應依日誌逐一確認，避免直接擴大到整個無關分類。

撰寫精確例外時，要分清完整網域與後綴匹配。例如 full:example.com 只適用於該完整名稱，domain:example.com 通常也會涵蓋其子網域。範例網域僅用來說明語法，實際規則請填入目標業務網域。不要以模糊關鍵字匹配取代明確範圍，否則網域中剛好含有相同字串的其他服務也可能被納入，排查時不易察覺。

透過日誌理解規則命中

驗證規則時一次只修改一項，儲存後依用戶端要求重新載入，再建立新的連線。記錄目標是網域還是位址、命中了哪條條件，以及最後使用哪個出站。若目標只剩位址，網域規則可能缺少足夠資訊；若較前面的廣泛規則已命中，後面的精確條件就不會執行。排查時若暫時移動規則，請記錄原本位置，測試完再還原。

分流後若部分資源無法載入，先暫時將該服務交給單一可用出站測試，再逐步縮小關聯網域範圍。這能分辨規則涵蓋不足與遠端服務本身不可用。不要一開始就加入大量下載的規則集；每多一層集合，追查路徑就更複雜。穩定的路由應能說明每條規則的用途、順序與撤銷方式。用途不明的項目應先停用觀察，而不是長期保留成未知依賴。

TUN 模式：虛擬網卡、DNS 與回環

先確認一般接入方式可用

TUN 透過虛擬網路介面承接系統流量，適合無法直接設定代理或不遵循系統代理的應用程式。它改變的是接入路徑，後續仍需路由規則與可用出站。啟用前先透過一般代理確認同一台伺服器可以連上目標，否則啟用後若出現問題，就無法分辨是遠端連線還是本機網卡所致。TUN 不是修復錯誤伺服器資料的工具，也不保證所有應用程式的網路行為完全一致。

圖形用戶端的 TUN 功能可能依賴不同核心、輔助元件與權限機制，相關欄位不一定與一般 Xray 路由設定相同。不要將其他實作的整段設定貼到目前用戶端。先閱讀目前的 TUN 設定頁，了解自動路由、DNS 接管、略過網段及網路堆疊等選項各自的用途；沒有明確需求時保留合理的預設值，避免一次更改所有選項。

權限與系統路由

首次啟用時可能需要系統管理員授權，或安裝虛擬網卡相關元件。授權後檢查核心日誌、網卡是否建立，以及系統路由是否如預期生效。只看到虛擬網卡名稱，不代表流量已進入核心；同樣地，開關顯示已啟用也不代表建立程序成功。若啟用失敗，保留錯誤訊息，先檢查權限與元件狀態，再決定是否重試，不要連續建立多個用途不明的介面。

自動路由會影響系統選擇網路出口的方式，因此要特別處理用戶端連往遠端伺服器的流量。若這些流量再次被攔截並送回同一個代理入口，可能形成回環，造成反覆重新連線或整體網路無法使用。用戶端通常提供相應的略過機制，建議優先使用既有設計。手動新增網段或程序例外前，先確認實際出口網卡與遠端位址，避免略過範圍過大。

DNS 接管需要另外驗證

TUN 常見問題之一是位址可直連，但網域無法存取。此時應檢查 DNS 請求送往何處、用戶端能否連上上游解析服務，以及解析結果能否用於後續路由。應用程式可能使用系統 DNS，也可能自行建立加密解析連線；用戶端設定某個 DNS 上游，不代表會自動接管所有應用程式的解析行為。應以實際請求路徑為準，不能只因設定頁顯示伺服器位址就認定已完成。

部分實作提供 FakeDNS，會將網域映射到保留位址範圍，再於後續連線中還原網域關係。這需要 DNS 與流量接管相互配合，不適合直接當成所有情境的預設方案。若應用程式快取舊結果、略過接管路徑或使用獨立解析，都可能造成映射資訊不一致。若沒有明確需求，先採用較簡單的解析方式，待一般連線穩定後再單獨測試這類功能。

區域網路、雙堆疊與應用程式範圍

測試項目應涵蓋網頁、區域網路服務、休眠後喚醒與網路切換。無法連接印表機、檔案分享或路由器管理頁時，先檢查本機網段是否被錯誤送往代理。企業網路可能使用非典型的內部網段或專用 DNS，不能只依照家用網路的經驗設定略過規則。若要保留內部解析，應一併考量解析路徑與存取路徑；只放行位址未必能解決網域問題。

IPv4 與 IPv6 也要分別確認。若只接管其中一種位址族，應用程式可能優先使用另一種，導致連線路徑不如預期；若解析結果包含無法連線的位址族，也可能要等候很久才連線成功。排查時觀察實際目標位址與系統連線結果，不要第一時間就停用整個位址族。Android 也應檢查 VPN 永遠開啟、封鎖未經 VPN 連線等系統選項，這些設定會改變停止用戶端後的行為。

若只有特定應用程式在 TUN 下異常，先檢查該應用程式的連線特性：是否使用 UDP、是否綁定網卡、是否有獨立代理，以及是否需要區域網路探索。逐項驗證比盲目降低 MTU 更有依據。涉及路由器與旁路由時，閘道與回程路徑會進一步影響接管範圍，可參閱路由器部署筆記；不要將桌面 TUN 設定直接套用到閘道環境。

日常維護：更新、備份與分層排查

分開管理不同更新項目

用戶端程式、代理核心、路由資料與訂閱內容是不同的更新項目。用戶端更新可能改變介面與設定產生方式，核心更新可能改變功能及參數支援，規則資料更新會影響分類結果，訂閱更新則會變更伺服器資料。更新後遇到異常，先確認剛更新的是哪一層。一次更新所有內容雖然省事，卻會讓問題缺少可比較的範圍。

更新前使用用戶端的備份功能儲存必要資料，並記錄目前的接入方式、路由預設、DNS 設定與已驗證可用的伺服器。備份可能包含敏感連線資訊，應存放在受控位置，避免直接放入公開同步資料夾。升級後先用原本的最小情境驗證，再測試 TUN 與特殊規則。不要只確認程式能開啟，就刪除舊備份或立刻繼續調整設定。

依接入、核心與遠端分層排查

完全無法連線時，先暫停接管功能，確認基本網路是否正常。若基本網路也無法使用，請檢查無線連線、閘道與系統網路狀態；基本網路正常但代理失敗時，再確認本機監聽與核心日誌。瀏覽器顯示本機連線遭拒，多半應先檢查監聽位址、連接埠與程序狀態，而不是修改遠端協定。若日誌出現設定解析錯誤，直接撤銷最近一次設定變更會更有效。

有目標記錄但遠端連線失敗時，請分辨是名稱解析失敗、連線逾時、連線遭拒，還是安全交握失敗。解析失敗時檢查解析路徑；逾時時檢查位址、連接埠與可達性；遭拒通常表示目標連接埠沒有接受連線；交握問題則繼續核對系統時間、伺服器名稱、傳輸方式與身分參數。不要關閉憑證驗證來掩蓋錯誤，應查明驗證未通過的原因。

速度測試時保持條件一致

速度慢不一定是協定問題。先固定同一台裝置、同一個網路、同一個目標，以及同一時段的測試方式，再比較不同伺服器。下載目標本身、無線訊號、電信業者路由與本機背景工作都會影響結果。單次連線測試只能提供有限資訊，無法證明持續傳輸能力。使用不同類型的服務交叉驗證，比在清單中反覆進行同一種測試更貼近實際使用情況。

若網頁瀏覽正常，但大型檔案傳輸異常，請檢查目標服務限制、連線重複使用與網路穩定性；若只有一個應用程式速度慢，檢查其獨立代理與解析路徑；若所有應用程式都慢，再比較基本網路與代理路徑。TUN 情境也要留意是否有其他 VPN 或安全軟體正在接管流量。分層排查方法請參閱速度慢故障排查筆記，沒有證據時不要反覆更換所有設定。

日誌只保留排查所需資訊

平時使用適中的日誌層級，重現問題時再暫時提高詳細程度。記錄發生時間、操作步驟、接入模式與完整錯誤訊息，通常比擷取整個伺服器清單更有幫助。分享前先檢查位址、身分欄位、訂閱入口與個人使用的網域等資訊。問題處理完畢後恢復日常層級，避免持續產生大量檔案，也不要將長期存取記錄當成一般備份任意傳送。

結束程式與裝置遷移也是維護的一部分

結束用戶端前，依使用方式停止系統代理或 TUN，並確認網路已恢復。若程式異常結束後瀏覽器無法連線，請檢查系統是否仍指向已停止的本機監聽；TUN 環境則檢查路由與 DNS 是否恢復。避免在多個應用程式之間來回切換接管功能，卻未清除舊狀態。需要重新安裝時先備份，只有確認資料已損壞才考慮重建設定，不要把重裝當成所有問題的通用解法。

遷移到新裝置後，先還原必要資料，不要立刻恢復所有自動啟動與背景執行選項。訂閱更新、核心啟動、應用程式接入、路由命中及結束後的系統恢復都應逐項測試，最後再啟用自動化。長期維護的目標是保留一條明確可用的復原路徑，而不是不斷增加設定。常見問題可從常見問題分類頁開始查找；複雜問題則應提供最小重現步驟以便繼續定位。

進階指南：最小化實驗與易維護設定

從明確的問題著手擴充

進階設定的目標不是啟用更多功能，而是解決已觀察到的問題。先清楚描述需求，例如「讓某個業務網域固定直連」、「讓某個應用程式走代理」或「網路切換後自動恢復」，再判斷屬於接入、路由、解析還是執行管理層。需求能明確分類，就能縮小變更範圍；若需求只是「整體更快」，應先補上可重複的測量方式與故障現象，再決定調整方向。

每次實驗都保留基準設定，複製路由預設或建立獨立的伺服器測試項目，不要直接覆蓋日常設定。記錄輸入條件、預期結果、觀察方式與還原步驟。例如新增完整網域規則後，用新連線驗證其出站，並確認其他網域沒有被擴大匹配。實驗成功不代表適合長期啟用，還要確認重新啟動、更新訂閱與網路變更後，行為是否一致。

分別評估協定、安全層與傳輸方式

研究 VLESS、VMess 或 Trojan 時，應著重了解它們與目前伺服器及核心的相容條件，不要只憑名稱判斷效能高低。協定負責通訊約定，TLS 或其他安全機制提供相應的連線保護，而傳輸方式也會受伺服器部署及中間網路條件影響。某種組合在一個環境可用，不代表換到另一條線路後仍有相同表現；只有伺服器端支援時，用戶端參數才有作用。

調整傳輸欄位時，請確保連線兩端設定一致。路徑、服務名稱、伺服器名稱與身分參數各有用途，不能任意用同一個字串取代。分享連結若缺少欄位，應向資料來源確認，不要從其他節點複製。連線問題發生在安全交握前或之後，排查方向也不同。了解日誌所處的階段，比收集一份沒有說明用途的「通用參數大全」更實用。

讓 DNS 與路由形成完整流程

進階 DNS 設定應先釐清三件事：由誰發出查詢、由誰執行查詢，以及查詢結果交給哪條連線使用。網域規則可能不需解析就能決定出站；位址規則可能要先取得解析結果；應用程式自行解析也可能繞過用戶端。分別記錄這些路徑，才能知道某個上游解析設定會影響哪個環節。不要只為了讓設定頁看起來整齊，就強迫所有查詢都使用不適合內部網路的同一個上游。

需要分流 DNS 時，也要同時驗證解析服務本身的連線路徑，以及回傳位址後續是否可達。查詢成功不代表回傳結果適用於目前網路，位址能連線也不代表網域分類符合預期。實驗時選少量明確目標，分別記錄網域、回傳位址與出站；不要一開始就加入大量規則集、多個上游與複雜快取策略，否則每次重現都可能受不同快取狀態影響。

了解產生的設定檔，釐清內容來源

熟悉圖形介面操作後，可查看用戶端產生的設定檔，追蹤入站標籤、路由條件與出站定義之間的引用關係。重點不是背下所有欄位，而是辨認哪些內容來自伺服器資料、哪些來自全域設定、哪些來自路由預設。執行中的檔案可能會重新產生，因此需要保留的修改應回到相應管理介面處理。若確實要使用自訂設定，應明確了解它接管了哪些功能，以及哪些圖形介面選項將不再生效。

分階段驗收，不要一次做完所有設定

建議先建立穩定連線，再設定可解釋的分流，接著處理特殊應用程式與 TUN，最後研究多核心與複雜解析。每個階段都應有明確的完成條件：連線階段要能重現成功與失敗；分流階段要能說明目標使用哪個出站；接管階段要能正常恢復系統網路；維護階段則要能從備份重建最小環境。上一階段未通過驗收前，不應繼續疊加下一層設定。

切換不同核心時，尤其要重新驗證協定、路由資料與 DNS 行為，不能只因程式成功啟動就認定設定等同。保留一套日常使用的核心與預設，另一套僅用於明確的功能測試，可減少切換帶來的不確定性。若要重新依照操作流程設定，請返回使用指南；需要安裝項目時，前往用戶端下載頁面；術語與異常問題則分別查閱術語手冊與常見問題。最後留下的設定應該易於理解、驗證與還原。