V2Ray 協定與核心參考

設定分層：先看懂欄位位置

用戶端中的「伺服器類型」並不能說明整條連線。一次代理連線通常涉及應用程式入口、代理協定、底層傳輸、安全設定與路由出口。位址與連接埠用來指定連線目標，UUID 或密碼用於驗證身分，TCP 或 WebSocket 負責承載資料，TLS 或 REALITY 則屬於另一組安全協商設定。分開理解這些欄位，比死記一串組合名稱更實用，也能避免把伺服器要求的安全方式誤選為協定。

協定、傳輸與安全層的界線

VMess、VLESS、Trojan 與 Shadowsocks 是本頁討論的代理協定，定義用戶端與伺服器如何表示目標位址、驗證身分及傳送代理資料；各自的功能與安全模型並不相同。TCP、WebSocket、gRPC 等屬於傳輸方式；TLS 是常見的傳輸安全機制；REALITY 則是 Xray 生態系中的安全傳輸方案，通常搭配 VLESS 使用，但它與 VLESS 並非同一層級，不能單獨取代伺服器類型。

閱讀 VLESS 設定時，先確認伺服器類型，再核對傳輸方式，最後檢查安全層。例如伺服器要求 TCP 與 REALITY，即使 UUID 相同，用戶端也不能擅自改成 WebSocket 與一般 TLS。反過來說，兩筆 VMess 設定也可能因路徑、主機名稱或傳輸方式不同而無法互換。能否連線取決於整組參數是否一致，而非清單上的協定名稱是否相同。

位址、名稱與路徑是不同參數

伺服器位址用於建立底層連線，TLS 的伺服器名稱用於名稱驗證與協商，WebSocket 的 Host 則是應用層請求資訊。這些值有時相同，但不代表永遠綁定。只有伺服器明確提供不同值時才分別填寫，不要憑經驗複製到每個欄位。連接埠也只是伺服器的監聽入口：常見連接埠不代表已啟用 TLS，更無法證明傳輸方式設定正確。

WebSocket 路徑必須與伺服器及反向代理設定一致；開頭的斜線、大小寫與查詢字串都可能影響比對。gRPC 服務名稱也不同於一般網頁路徑。匯入後欄位空白不一定表示資料缺漏，有些協定不需要該欄位，有些用戶端則會採用預設值。判斷前先核對協定與傳輸組合，不要直接套用其他教學中的路徑。

分開排查本機入口與遠端協定

桌面應用程式連上本機 SOCKS 或 HTTP 入口後，核心才會依路由選擇直連或代理出口。本機連接埠與遠端伺服器連接埠不同，修改其中一個不會連帶改變另一個。系統代理也不是協定的一部分，只會影響有讀取系統代理設定的應用程式。某個程式未經代理連線時，應先確認它採用的連入方式，而不是立刻更換遠端協定。

Android VPN 模式會透過系統虛擬網路介面接收符合範圍的流量，再交由核心處理；它與桌面系統代理的涵蓋範圍不同。出現連線圖示，只能表示本機連入已建立，不能證明遠端驗證、網域解析與路由皆正常。依序確認「本機是否收到請求、路由選擇哪個出口、遠端能否連線」，即可將問題拆成幾個獨立檢查項目。

VMess 與 VLESS 的設計取捨

VMess 與 VLESS 常見於 Project V 相關用戶端，但設計目標不同。VMess 源自 V2Ray 早期協定體系，將身分驗證、請求組織與資料保護等功能納入協定設計；VLESS 則廣泛用於 Xray 生態系，採用較精簡的協定結構，並將更多安全傳輸交由外層機制處理。兩者沒有脫離伺服器條件的絕對優劣，選擇時應先確認伺服器提供的設定，以及目前核心是否支援完整組合。

VMess：分清現代驗證與舊設定

VMess 的 UUID 是身分參數，不是伺服器位址，也不是能任意產生後直接取代的備註。現代 VMess 設定應使用 AEAD 驗證方式；舊資料中的額外 ID 或 alterId 屬於歷史相容性背景，不能照著舊教學隨意填入非零數值。伺服器與核心對舊模式的支援程度可能不同，匯入舊訂閱後，應先確認服務提供者目前要求的設定。

VMess 驗證與時間有關，裝置時鐘明顯不準可能造成驗證失敗。若位址可連線但交握失敗，先檢查系統日期、時區與自動校時，再確認 UUID 及伺服器狀態。不過，VMess 連線失敗也不一定是時間問題；傳輸路徑、外層 TLS 或遠端連接埠錯誤，同樣會造成連線失敗。日誌顯示的錯誤階段，比單純的逾時提示更有助於縮小問題範圍。

VMess 可搭配不同傳輸方式，因此不能只看協定名稱估算資源負載。VMess 搭配 WebSocket 與 TLS，和直接承載的設定，在交握、封裝與連線重用方面可能有所差異。現有 VMess 設定若運作穩定、訂閱更新正常且符合需求，就不必只因另一個名稱較常見而更換。遷移應有明確目的，例如統一核心支援或減少不必要的傳輸層。

VLESS：標頭精簡不代表安全方案完整

VLESS 主要處理代理請求與身分資訊，本身不提供與 VMess 相同的負載加密機制。用戶端常見的 encryption 設為 none，是此協定欄位的正常值，不代表整條連線必然以明文傳輸。是否具備傳輸保護，還要檢查外層 TLS、REALITY 或部署中的其他安全措施。因此，不能只看「none」一個欄位就判斷整體安全性。

同樣地，也不能因 UUID 看起來複雜，就認為 VLESS 可以省略外層保護。身分識別與加密傳輸解決的是不同問題。一般使用者應依照伺服器提供的完整安全組合匯入設定，不要為了減少欄位而關閉安全層。若服務提供者只給出缺少安全說明的記錄，應先確認部署環境與用途，而不是直接將它當成通用的公開網路設定使用。

flow、傳輸方式與伺服器能力

VLESS 的 flow 欄位不是通用加速開關。部分 Xray 設定會使用 xtls-rprx-vision，而伺服器、用戶端核心及承載方式都必須符合相關條件。將此值複製到任意 VLESS 記錄，可能導致設定遭拒或交握失敗。尤其不要在沒有伺服器依據時，混用直接傳輸設定與 WebSocket、gRPC 欄位，最後拼出名稱看似正確、實際上卻無效的設定。

編輯器顯示某個選項，不代表目前選用的核心已實作該功能。核對 VLESS 時，建議依序檢查 UUID、傳輸方式、安全類型、伺服器名稱與 flow，再另外確認 REALITY 相關公鑰與短識別碼。參數都正確仍無法連線時，記下核心日誌中的具體錯誤，並前往說明中心，從驗證、交握與解析三個方向繼續排查。

實際選擇可以簡單處理：現有且持續維護的 VMess 服務，照原本參數繼續使用；伺服器提供 VLESS 與明確的 TLS 或 REALITY 參數時，再選擇支援該組合的 Xray 用戶端。協定遷移不是只要更改類型選單即可。兩者的驗證結構與安全設定不同，遷移時需要伺服器提供一份新的完整設定，並保留舊設定以供比對驗證。

Trojan、SS 與 REALITY

Trojan、Shadowsocks 與 REALITY 常同時出現在訂閱清單中，但它們並非同一層級的替代方案。前兩者是代理協定，REALITY 則是安全傳輸方案。比較時應列出完整組合，例如 Trojan 搭配 TLS、VLESS 搭配 REALITY，或指定 Shadowsocks 使用的加密方法。只說某筆記錄「使用 REALITY」，仍不足以判斷需要哪種用戶端與參數。

Trojan：以 TLS 為基本條件

Trojan 的設計以 TLS 安全連線為基礎，用戶端通常透過密碼驗證代理請求。設定時除了核對密碼，也要確認伺服器名稱與憑證驗證條件。伺服器位址可以是網域名稱或 IP 位址，但 TLS 使用的名稱必須符合伺服器憑證與設定要求。位址能連線但名稱不符，仍可能在建立代理請求前失敗；這種情況不是更改密碼就能解決。

遇到憑證錯誤時，不應把略過憑證驗證當成一般修復方式。關閉驗證會改變連線的安全界線，也可能掩蓋名稱填錯、裝置時間不準或伺服器憑證異常等問題。先檢查名稱、時間與憑證有效性，再聯絡服務提供者確認設定。若專用測試環境確實使用自簽憑證，也應依該環境的信任設定處理，不要把測試做法套用到日常設定。

Shadowsocks：加密方法也是協定條件

Shadowsocks 常簡稱為 SS，是以輕量代理與加密傳輸為核心的獨立協定體系。用戶端通常需要位址、連接埠、密碼與加密方法。加密方法不是可自由選擇的本機偏好，必須與伺服器一致。舊式串流加密方法、常見 AEAD 方法與較新的協定變體，支援範圍各不相同；用戶端選單中名稱相似，不代表彼此相容。

密碼格式也可能因加密方法而異。有些方法接受一般文字密碼，有些新方法則要求特定長度的編碼金鑰；直接輸入文字密碼，可能在本機解析階段就出錯。如果匯入訂閱後只看到位址與密碼，卻沒有保留加密方法、外掛或其他參數，應視為不完整設定。是否需要外掛，須依伺服器說明與核心支援狀況判斷，不能自行刪除後就假設功能不變。

SS 的優點常在於設定簡單、封裝層較少，但這不代表它在所有裝置上都更省電或有更高傳輸量。實際表現仍受加密實作、處理器效能、傳輸品質與應用程式請求模式影響。需要 UDP 的服務也應確認伺服器與本機入口都支援 UDP 轉送；只成功瀏覽一次網頁，無法驗證這項功能，更不能據此推論所有應用程式都能正常運作。

REALITY：核對公鑰、短識別碼與名稱

REALITY 的驗證方式與一般憑證部署不同。使用者常會接觸伺服器名稱、公鑰、短識別碼與用戶端指紋等欄位。公鑰必須與伺服器設定相符，不能從一般憑證內容中隨意擷取；短識別碼也應完整保留，不要因為看起來像備註就刪除。短識別碼是否可以留空取決於伺服器，不應拿其他設定的值來補。

用戶端指紋用於描述交握特徵相關設定，不是裝置身分驗證密碼。應使用目前核心支援且符合部署需求的值；任意更換不代表能提升效能。伺服器名稱也不能任意挑選網頁網域，應使用伺服器允許的名稱。連線失敗時，依序檢查名稱、公鑰、短識別碼、指紋、時間與 flow，通常比反覆更換連接埠更有效。

最後仍應以伺服器能力為選擇依據。需要標準憑證驗證流程時，可評估維護明確的 Trojan 設定；已有 SS 服務時，先確認加密方法相容；使用 REALITY 時，優先選擇明確支援該組合的 Xray 核心。三者無法只改協定名稱就完成遷移，訂閱中的完整參數才是用戶端建立連線的依據。

連線速度與資源負載

「連線快」至少包含三種不同指標：首次請求成功建立所需時間、持續下載的傳輸量，以及網頁上多個小型請求完成的時間。協定標頭較短，可能略微減少處理工作，但不代表跨網路的往返次數會更少；持續傳輸量較高，也不一定能加快首次開啟網頁。選擇前先確認主要用途是短請求、長連線、影片傳輸，還是頻繁休眠後喚醒，避免用單一測試結果代表所有情境。

拆解交握連線流程

冷啟動請求可能依序經過網域解析、底層連線、安全協商、代理驗證與目標網站連線。部分傳輸方式還會增加額外的應用層連線程序。每個階段的耗時都會影響首次回應，因此伺服器距離、解析狀態與封包遺失情況，往往比協定固定標頭的差異更明顯。若網域解析一直逾時，改用另一種驗證協定也無法直接消除這段等待。

WebSocket 與 gRPC 等傳輸方式適用於特定部署架構，但也會帶來額外封裝與連線管理行為。直接承載的連線結構通常較簡單，但必須符合伺服器入口條件。不要為了追求「少一層」而擅自刪除傳輸設定；這只會讓請求無法到達正確服務，而非得到更快的等效連線。比較時應使用伺服器實際提供且可用的組合。

CPU、記憶體與傳輸量的關係

加密運算、使用者空間資料轉送、緩衝區複製與規則比對都會消耗資源。裝置是否支援相關硬體加速、核心是否採用高效率實作，以及應用程式是否同時建立大量連線，都會影響結果。低階裝置可能先遇到 CPU 效能瓶頸，桌面裝置則可能主要受遠端頻寬限制。只憑協定名稱排出固定資源排名，會掩蓋真正的瓶頸，也不利於找出可調整的設定。

記憶體占用也不等於協定負載。規則資料庫、網域解析快取、連線數量、用戶端介面與日誌快取都可能占用記憶體。用戶端長時間執行後占用量高於剛啟動時，不能直接判定為協定洩漏。觀察時應區分用戶端與核心程序，在相同工作負載下確認占用是否持續增加且未回落，再決定是否需要回報問題。

依實際用途驗證連線重用與保活

連線重用可以減少重複建立連線的成本，但也會讓多種業務共用部分傳輸狀態。底層封包遺失、伺服器實作與連線關閉策略都可能影響結果。已採用成熟多路傳輸的組合，額外啟用某個重用選項不一定有幫助。若部分網站卡住，或大檔案正常但小型請求異常，可在複製的設定中關閉額外重用，確認問題是否因此消失。

保活設定也有取捨。較積極的保活可能減少閒置後重新連線的次數，卻也會增加喚醒行動網路無線模組的機會；較保守的設定或許能減少背景活動，但首次請求就需要重新建立連線。長時間接上電源的桌面裝置與待機中的 Android 裝置，不宜套用相同的「效能最佳化」設定。預設值通常是最適合開始測試的基準，只有觀察到具體問題時才調整。

可重複的對照測試方式

先關閉背景下載並維持相同路由，確認兩組設定使用同一個服務出口；接著分別進行一次冷啟動連線與一段持續傳輸，重複測試幾輪，不要只看單次結果。記錄失敗率、首次回應時間、持續傳輸是否穩定，以及裝置是否明顯發熱。用戶端的延遲測試可能只涵蓋特定測試位址或部分交握流程，不能直接代表完整網頁與 UDP 服務的使用體驗。

若兩組設定使用不同伺服器，只能得出「這兩組設定在目前條件下表現不同」，不能據此證明某種協定一定較快。若要單獨比較協定影響，伺服器位置、頻寬與負載應盡量一致。無法控制條件時，優先考量相容性、維護成本與長期可用性，比根據單次測試的細微差異反覆切換更實際。

V2Fly 與 Xray 核心系列

Project V 是理解此生態系的背景。V2Ray 最初建立可組合的入站、出站、路由與傳輸架構；V2Fly 延續 V2Ray 相關核心的發展，Xray 則從這項技術基礎分支演進，並加入自身的協定與傳輸功能。兩者共用部分術語與設定概念，但已不是可以無條件互換的兩個檔名。選擇核心時，應確認具體功能，而非只憑共同來源判斷相容性。

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

v2rayN 負責桌面上的伺服器管理、訂閱更新、設定編輯與核心控制，實際資料處理由選用的核心負責。v2rayNG 是 Android 上常見的 Xray 用戶端，v2flyNG 則提供 V2Fly 核心的另一種選擇。用戶端介面是否有某個按鈕，與核心是否支援相關協定是兩回事；外觀相似的記錄，在不同核心下也可能產生不同設定。

桌面版建議使用 v2rayN，可在同一介面管理訂閱群組、日誌與系統代理。若要使用其核心類型設定，應先確認目標協定需要哪種實作，再切換核心。Android 裝置則應依應用程式採用的核心系列選擇用戶端，不要把桌面版切換核心的操作方式直接套用到 Android 選單。實際選項位置請以目前安裝版本的介面為準。

欄位相同不代表設定完全相容

兩種核心都可能辨識位址、連接埠、使用者與路由規則等基本概念，但支援的傳輸名稱、協定擴充、設定結構與預設行為可能不同。REALITY 與 Vision 等功能，應確認是否在 Xray 的支援範圍內；不能因 V2Fly 能讀取 VLESS 類型，就推斷它能處理所有 Xray 的 VLESS 組合。反向遷移時，同樣要檢查來源設定使用的專屬功能。

訂閱由用戶端解析後，通常會產生適用於目前核心的設定。手動貼上整份 JSON，則會略過部分轉換程序，容易把其他核心專用欄位一併帶入。啟動失敗時，先查看日誌中的未知欄位、未知協定或參數無效提示，再檢查設定來源。不要為了讓程式啟動就大量刪除報錯欄位，因為被刪除的內容可能正是連線必需的驗證或安全設定。

路由規則：同時檢查語意與資源

路由設定取決於出站標籤與規則資料庫。即使規則語法正確，若目標出站標籤不存在，或本機資料不含引用的 geosite 分類，仍可能導致啟動失敗或分流結果不符預期。以下是 Xray 路由物件的局部範例，用來說明私有位址優先直連的語意；這不是可獨立啟動的完整設定，合併前須確認已有名為 direct 的直連出站，並備妥相應規則資料。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

這條規則只會處理已能依 IP 條件比對的請求；AsIs 不會為了套用 IP 規則而主動解析所有網域，因此無法單獨取代完整的區域網路網域與解析方案。實際規則應依本機服務的存取方式補齊。規則資料庫的來源、更新方式與引用語法，可接著閱讀geoip.dat 與 geosite.dat 規則資料庫說明，避免把資料庫缺漏誤判為協定不相容。

升級與切換時的還原界線

核心升級可能修正問題、增加功能，也可能加嚴舊設定的驗證。升級前先備份用戶端設定與重要自訂項目；升級後先用一筆已知可用的記錄確認基本連線，再檢查訂閱、路由與特殊傳輸。切換核心前應先停止目前連線，避免新舊程序狀態與設定混在一起。日誌能確認新核心是否真正啟動，比只看介面上的名稱更可靠。

開源授權也不應一概而論。V2Fly 核心專案通常採用 MIT 授權，Xray 核心專案則採用 MPL 2.0；用戶端、相依元件與附帶資料可能各有不同授權，應以對應發行版本的聲明為準。對一般使用者而言，開源代表可以查閱實作與授權，並不能取代設定核對、憑證驗證，以及對服務提供者的獨立判斷。

訂閱格式與參數相容性

訂閱是一種設定發佈方式，不是代理協定。訂閱網址可能傳回分享連結清單、Base64 編碼文字，或特定用戶端使用的結構化設定。用戶端必須先解析外層格式，再將每筆記錄轉換成自己的伺服器模型，最後產生核心設定。因此，「能開啟訂閱網址」、「成功匯入清單」與「伺服器能連線」是三個不同階段；其中任何一項成功，都不能取代後續檢查。

分享連結能包含多少設定資訊

常見分享連結會以協定前綴區分類型，但不同協定與歷史版本的欄位編碼方式不完全相同。VMess 連結常使用編碼後的結構化內容；VLESS 與 Trojan 連結通常以位址搭配查詢參數表示傳輸及安全設定；SS 也有不同編碼形式。備註通常只供介面顯示，不參與驗證；查詢參數中的路徑、名稱與安全欄位則可能直接影響連線能否建立。

匯入工具可能辨識協定前綴，卻不支援連結中的某個擴充欄位。介面顯示出伺服器，不代表 flow、公鑰、短識別碼、服務名稱或外掛參數都完整保留。匯入後應開啟編輯介面，依序檢查協定、安全與傳輸設定。複雜的記錄尤其要留意欄位被清空、套用舊的預設值，或用戶端忽略未知內容等情況。

Base64 是編碼，不是存取保護

將連結清單編碼為 Base64 雖便於傳送文字，但不會讓其中的帳戶資訊受到保密。訂閱網址本身也可能含有具存取權限的權杖，轉傳網址通常等同交出更新權限。不要把完整訂閱網址、QR Code 或伺服器詳細資料貼到公開日誌。求助時只要提供協定類型、錯誤階段，以及已遮蔽敏感值的欄位名稱，通常就能先完成大部分相容性判斷。

訂閱更新後清單變空，可能是伺服器傳回登入頁面、錯誤訊息或不支援的格式，不一定代表所有節點都遭到刪除。先確認網址有效且訂閱格式正確，再檢查更新是否必須透過既有代理。如果目前代理剛好失效，而更新又依賴它，就可能形成循環。更完整的檢查順序請參閱訂閱更新失敗與解析結果為空的自我檢查清單，不要反覆刪除群組再重新匯入。

如何在不同用戶端之間遷移

遷移至 v2rayN、v2rayNG 或 v2flyNG 時，優先使用目標用戶端支援的原始訂閱，不要先經過多種轉換工具。每增加一次格式轉換，都可能遺失目標格式無法表示的欄位。若訂閱提供者提供多種輸出格式，應選擇明確適用於目前用戶端與核心的版本；某種其他設定格式可以下載，不代表這三款用戶端一定能直接讀取。

匯出的單筆分享連結適合少量記錄遷移，但通常不包含完整路由、DNS、應用程式範圍與介面偏好。成功匯入伺服器後，仍須在新裝置上重新檢查這些本機設定。Android 的應用程式分流範圍不會自動轉成桌面系統代理設定；桌面的自訂路由也不一定會隨單筆伺服器連結一同匯入。分開備份帳戶設定與裝置策略，遷移時更容易確認缺漏。

更新後的記錄與手動修改

訂閱群組中的記錄可能在更新時重新產生，因此直接修改訂閱節點的連接埠、名稱或安全欄位，不一定能長期保留。需要測試調整時，先複製成獨立記錄，並清楚標示來源與修改目的。如此一來，後續更新不會悄悄覆蓋測試條件，也不會讓人誤以為服務提供者已經修改參數。需要還原時刪除副本即可，不必重建整個群組。

管理多個訂閱群組時，依用途與來源區分，比只按協定分類更方便維護。同一個訂閱可以包含多種協定，參數也可能隨時間調整。每次更新後，先確認常用記錄是否仍存在、目前選取項目是否變更，再實際連線測試。發現異常時保留更新前可用的副本，有助於分辨伺服器變更、解析差異與本機核心問題。

Android 耗電與背景行為

行動裝置耗電不能只看協定名稱。Android 裝置執行代理時，耗電來源包括無線網路傳輸、CPU 處理、系統虛擬網路介面、背景應用程式請求與連線保活等。大量小型請求反覆喚醒行動網路，可能比一次持續下載更影響待機；訊號較弱時，封包重傳與搜尋網路也可能掩蓋協定間的差異。因此應先區分「大量使用時耗電」與「螢幕關閉後仍持續活動」。

v2rayNG 與 v2flyNG 的選擇範圍

需要 Xray 特有組合時，Android 端可優先考慮 v2rayNG；服務設定明確依賴 V2Fly 功能，或需要沿用相應核心時，再評估 v2flyNG。兩款用戶端不應同時啟用 VPN，因為系統對 VPN 服務有自己的使用限制。對照測試時，先停止其中一款再啟動另一款，並維持相同的應用程式範圍與路由；否則比較到的是兩種不同工作負載，而非核心差異。

首次啟動 VPN 服務時，系統授權確認只是本機流量接入程序的一部分，不代表已成功連上伺服器。連線建立後，應實際存取目標服務，確認日誌中出現有效請求與正確出口。若只有部分應用程式無法存取，先檢查應用程式代理範圍與繞過設定。將應用程式排除在 VPN 外後，其連線行為便不能再用來驗證代理伺服器是否正常；測試時要確認目前使用哪條連線路徑。

平衡背景限制與連線穩定性

系統省電策略可能限制背景服務、網路活動或自動啟動。若螢幕關閉後連線中斷，返回用戶端又立即恢復，可先查看系統是否限制該應用程式在背景執行，再依實際需求調整。不同裝置的選單名稱不盡相同，請以系統電池管理頁面為準。允許背景執行有助於維持連線，但不代表應放寬所有相關應用程式的限制；調整範圍應盡可能縮小，並保留還原方式。

若連線一直維持但裝置持續發熱，先檢查背景同步、失敗重試或異常 DNS 請求。反覆失敗的請求會造成重新連線，表面上看似代理程序耗電，實際原因卻可能是某個應用程式不斷重試。暫時縮小應用程式範圍，或改用已知正常的路由預設，有助於找出問題來源。排查期間才需要提高日誌詳細程度；長時間輸出大量日誌也會增加處理與儲存負載。

DNS、UDP 與應用程式範圍

網域解析策略會影響連線前的等待時間與請求數量。解析位址無法連線、規則將解析流量送往錯誤出口，或本機與遠端的解析結果不一致，都可能造成重複嘗試。不要為了「加快速度」就新增多個解析伺服器，卻不清楚查詢策略。先維持一套清楚可理解的解析路徑，確認一般網域、區域網路服務與代理目標都依預期處理，再逐項擴充。

即時通訊與部分互動服務可能依賴 UDP。如果協定、伺服器或接入鏈路未完整支援，應用程式可能改用其他方式，或不斷重試，進而影響體驗與耗電。網頁瀏覽正常不代表 UDP 也能正常運作。測試時應使用實際需要的服務，檢查是否頻繁中斷、長時間無法建立連線或異常重連，再搭配核心日誌判斷；不要把所有問題都歸因於 Android 背景限制。

耗電對照應涵蓋實際待機情境

比較時選擇訊號強度與使用時間相近的情況，並維持相同螢幕亮度、應用程式範圍與背景同步設定。一組觀察實際使用，另一組觀察螢幕關閉後的待機狀態，並記錄系統電池統計中的應用程式活動。系統電量百分比是估算值，短時間內的細微變化不宜作為結論；更值得留意的是反覆出現的待機喚醒、持續發熱或重新連線，而不是單次測量少掉一個百分點。

若無法正常存取區域網路裝置，先確認私有位址與本地域名的路由，不要將所有流量都強制交給代理。需要依區域與用途組合規則時，可參考v2rayNG 分流設定實作指南。規則越符合實際用途，就越容易減少不必要的遠端繞行。穩定且容易理解的設定，通常比堆疊各種省電參數更適合長期維護。

情境選擇與連線驗證

選擇時應逐步縮小範圍：先確認裝置平台，再確認伺服器提供的完整協定組合，接著選擇相容的核心，最後依業務需求決定路由與接入範圍。協定不是可獨立選購的效能功能，而是用戶端與伺服器共同遵守的通訊條件。若訂閱只提供一種可維護的設定，就先完整驗證這組設定，再考慮是否需要其他組合，避免只為追求較新的名稱而增加管理成本。

桌面日常使用、Android 行動連線與既有服務

Windows、macOS 與 Linux 桌面版建議使用 v2rayN，並依處理器架構與系統套件格式前往下載頁。日常瀏覽與開發工具共用連線時，先使用明確的系統代理與本機入口設定，確認哪些程式會讀取系統設定。若程式需要明確指定 SOCKS 參數，應在該程式中設定入口，不要把「全域路由模式」誤解成會自動接管所有應用程式的網路。

Android 端應依伺服器組合選擇 v2rayNG 或 v2flyNG，再視需求設定所有應用程式或指定範圍。行動網路與 Wi-Fi 切換後，底層連線可能需要重新建立；舊連線瞬間中斷，不代表協定不穩定。若重新連線持續失敗，再檢查解析變化、遠端可達性與背景限制。經常存取本機裝置的使用者，也應將區域網路位址及相關網域列為獨立檢查項目。

已有穩定的 VMess、Trojan 或 SS 服務時，優先維護正確參數與訂閱更新；伺服器提供 VLESS 與 REALITY 時，應選擇明確支援其安全欄位與 flow 的 Xray 方案。想減輕裝置負載時，先排除不必要的轉送層、異常重試與大量背景活動，而不是只更換協定。對效能較低的裝置而言，簡單且受支援的組合通常比疊加複雜參數更容易驗證。

建立可供複查的驗證順序

第一步確認本機設定能否啟動。若核心立即結束，先處理無效欄位、連接埠占用或資料庫缺漏；此時請求尚未正常送往遠端。第二步檢查位址解析與遠端入口是否可達。第三步查看安全協商與協定驗證。完成前三步後，再排查目標網站、DNS 與分流。依階段逐一處理，可避免把本機語法錯誤誤認為伺服器不穩。

第四步驗證實際服務：開啟一般網頁、存取工作所需服務、檢查區域網路位址，並在確有需要時測試 UDP 應用程式。第五步確認閒置後能否恢復，以及網路切換後的連線狀態。每個階段都記錄使用的用戶端、核心系列、協定組合與結果，無須公開帳戶內容。若某階段失敗，保留當時的精簡日誌，比不斷更換伺服器後留下混雜記錄更方便求助。

規則順序與驗證目標

路由通常依序比對，前面的寬泛規則可能會覆蓋後面的精確條件。更換協定後若部分網站行為改變，應先確認實際產生的路由與預設出口，而非只比較編輯器中的伺服器類型。需要自訂網域與位址條件時，可閱讀Xray 自訂路由規則與比對順序；規則應依實際用途建立，不要一次匯入大量無法說明的例外。

驗收完成後，保留一筆已知可用的設定作為基準。之後更新訂閱、切換核心或升級系統，都先用這筆設定進行基本驗證，再恢復複雜分流與特殊選項。基準設定並非永遠不更新，而是讓每次變更都有可比較的起點。完成選擇後，日常操作可回到快速入門教學；本手冊則保留供查核協定界線、相容欄位與故障階段，無須每次連線前重新調整所有參數。