V2Ray 協定與
核心技術指南

01 / CONFIGURATION LAYERS

協定、傳輸與安全層

節點名稱不等於完整設定

用戶端清單中的每個節點，都是一組彼此配合的參數，而不只是單一協定名稱。協定定義如何驗證身分及傳遞代理要求；傳輸負責將資料送至伺服器；安全層則負責連線身分驗證與保護。位址、連接埠、使用者識別碼是連線條件；路徑、要求標頭、伺服器名稱則可能屬於不同層級。選擇時，第一步應先讀取完整參數，而非只看縮寫就判斷速度或相容性。可用的組合由伺服器端決定，用戶端只能在支援範圍內正確還原設定。

以 VLESS 為例，同一協定可以搭配不同的傳輸與安全設定。使用一般 TCP 傳輸的設定，不能直接改成 WebSocket 後繼續連線，因為伺服器端也必須設定相應的監聽方式與路徑處理。啟用 TLS 也不是替任何節點加個開關就能完成：伺服器必須提供對應的交握程序，憑證名稱必須相符，用戶端也必須信任簽發鏈。協定相同但其他欄位不同，實際連線流程仍可能完全不同。

分清位址、伺服器名稱與要求目標

伺服器位址告訴用戶端要連線至哪台設備，可以是網域名稱，也可以是 IP 位址。TLS 的伺服器名稱通常用於傳送 SNI，並參與憑證名稱驗證；WebSocket 的 Host 則是應用層要求欄位。三者可能相同，也可能依部署方式明確設定為不同值。別因為看起來都是網域名稱就直接互相複製。疑難排解時，先確認位址解析，再確認連接埠是否可連線，接著檢查交握與驗證，最後才檢查目標網站的連線；依此順序處理，可避免把解析問題誤判為協定問題。

接入模式與出站協定是兩回事

系統代理是提供系統或應用程式使用的本機代理入口，只有遵循相關設定的程式才會使用。TUN 透過虛擬網路介面接收流量，涵蓋範圍通常較廣，但仍受路由、權限與排除項目影響。兩者都不會自動變更遠端協定。節點匯入成功但某些程式仍無法連線時，應先確認程式是否真的經過用戶端，再查看出站記錄；直接把 VLESS 換成 VMess，無法解決應用程式繞過系統代理的問題。

路由與 DNS 又是另外兩個層級。路由負責為流量選擇直連、代理或封鎖等出站方式；DNS 則負責網域解析及相關策略。某個網站採用直連，不代表節點驗證失敗；網域無法解析，也不能直接說是 TLS 設定錯誤。回報問題時，建議一併記下用戶端、核心、協定、傳輸、安全層與接入模式。分享記錄前，請移除訂閱網址、使用者識別碼與驗證欄位，只保留錯誤類別與發生順序即可。

匯入畫面顯示成功，通常只代表文字已解析並加入清單，不表示伺服器已接受連線。實際驗證至少要經過啟動核心、建立工作階段及存取目標這三個步驟。完整操作流程請見v2rayN 設定教學；本頁後續章節會分別說明各層的選擇限制。

02 / VMESS & VLESS

VMess 與 VLESS 的設計取捨

VMess：協定內含驗證與加密機制

VMess 是 Project V 生態系中較早發展的代理協定，設計上將使用者驗證、要求資訊保護與資料加密納入協定本身。用戶端必須使用正確的使用者識別碼，並依伺服器端要求選擇相關安全設定。現代設定通常採用以 AEAD 為基礎的驗證方式。舊資料提到的額外識別欄位屬於歷史相容背景，不應照著舊教學填入任意數值。伺服器端如何設定，用戶端就應如何配合；新增設定時，優先採用維護者明確提供的現代參數。

協定內建保護，不代表外層 TLS 毫無用處。外層連線與代理協定處理的問題並不完全相同，部署方式也可能採用 WebSocket 或其他承載方式。評估 VMess 節點時，應檢視整條連線流程：本機接入、協定封裝、外層傳輸與遠端出站都會消耗資源。不能只看協定名稱估算負載，更不能因為多一層加密就斷言日常使用一定會明顯變慢。

VLESS：減少協定本身負責的資料加密

VLESS 的設計方向是簡化代理協定結構，將資料安全更多交由搭配的安全層負責。常見用戶端設定中的加密欄位為 none，表示 VLESS 本身不提供相應的資料加密，不代表整條連線沒有受到保護。安全性仍須檢查是否正確啟用 TLS 或 REALITY、是否驗證伺服器身分，以及本機與遠端的信任界線。若誤將此欄位改成其他協定使用的加密方式，通常只會導致設定不被接受。

VLESS 與 Xray 生態系中的流量控制、安全層功能經常一起出現，但不能把這些功能視為所有 VLESS 實作的預設能力。例如 Vision 流量控制需要核心支援，且連線組合必須相符；只有 VLESS 基本欄位的分享連結，不會自動具備這項能力。伺服器端未要求流量控制時，不要為了追求所謂的效能提升而自行新增。設定不是越多越好，正確還原伺服器端提供的參數才是首要條件。

時間、使用者識別碼與遷移限制

VMess 對時間同步有實際要求，裝置時間明顯不準可能影響驗證。疑難排解時，應檢查系統日期、時間與自動同步狀態，而不是反覆產生使用者識別碼。VLESS 不能視為解決所有時間問題的替代方案，因為外層憑證驗證仍會受系統時間影響。兩種協定的使用者識別碼看起來都可能是 UUID，但格式相同不代表協定可以互換；只修改用戶端的下拉選項，並不會連帶改變伺服器端設定。

從既有 VMess 方案遷移至 VLESS，需要伺服器端提供新的入口或明確的變更說明，同時確認傳輸、安全層與流量控制需求。遷移前保留原本可用的設定，使用獨立群組測試新入口，確認目標應用程式與 UDP 情境都正常後，再進行替換。不要在唯一可用的節點上連續覆寫多個欄位，否則發生問題時很難判斷是哪一步造成影響。若想集中比較驗證與保護方式，可繼續閱讀VMess 和 VLESS 的差異。

匯入後應逐項檢查協定類型、使用者識別碼、位址、連接埠、傳輸、安全層與流量控制，而不是只比較節點備註。備註由分享者填寫，不具技術約束力。發生設定解析錯誤時，先處理欄位與核心相容性；驗證失敗時，檢查伺服器端帳號與參數；只有在連線穩定建立後，才值得討論吞吐量與回應速度。

03 / TROJAN & SHADOWSOCKS

Trojan 與 Shadowsocks 的設定限制

Trojan：常以 TLS 作為連線基礎

Trojan 的設計結合密碼驗證與 TLS 連線，用戶端常見欄位包括位址、連接埠、密碼與伺服器名稱。它與使用 UUID 的協定在驗證方式上不同，但同樣要求用戶端與伺服器端的設定完整相符。密碼正確不代表一定能連線：憑證名稱、簽發鏈、系統時間或外層傳輸出問題，都可能讓連線在進入驗證前就中斷。疑難排解時，應先判斷錯誤發生在 TLS 交握階段，還是協定驗證階段。

在可信任的網路環境及正確驗證條件下，TLS 可為連線提供加密與伺服器身分驗證。選用 Trojan 時，不應預設略過憑證驗證，也不應把未知憑證錯誤一概歸咎於用戶端限制。網域憑證與實際連線的伺服器位址可以不同，但伺服器名稱必須符合部署要求。使用 IP 位址連線時尤其要核對名稱欄位，不能期待用戶端自動猜出憑證所屬的網域。

Shadowsocks：加密方式也是協定相容條件

Shadowsocks 在用戶端中常簡稱為 SS，主要參數為伺服器、連接埠、密碼與加密方式。其設計著重於簡潔的加密代理通道，但「支援 SS」並不代表完整相容。傳統 AEAD 方法與後續擴充方案，在金鑰要求、實作支援及連結解析上可能有所不同。設定中的方法名稱必須完全相符，不能因為用戶端中的另一個選項看起來比較新就自行替換。

密碼欄位也不能一概當成一般短密碼。有些方法要求特定長度與編碼格式的金鑰；若錯誤刪除末尾字元、變更大小寫或再次解碼，都會破壞驗證條件。複製分享連結時應保留完整內容；手動輸入則依伺服器端說明填寫。不要把其他協定的 UUID 填入 SS 密碼欄並期待自動轉換，也不要把連結中已編碼的驗證內容直接當成最終密碼使用。

別忽略外掛、UDP 與傳輸擴充

有些 SS 分享資訊也包含外掛參數。圖形用戶端能辨識連結，不代表執行環境已具備相應外掛，核心也不一定原生實作相同功能。本站用戶端清單請以下載頁說明為準；若服務要求外掛，應先確認是否有目前用戶端支援的替代入口。別把缺少外掛造成的錯誤誤判為密碼錯誤，也不要依照不明來源的提示安裝額外元件；請先向服務維護者確認連線方案。

UDP 是否可用，取決於協定實作、伺服器端轉送、用戶端接入模式與目標應用程式。網頁瀏覽正常，不代表語音或即時通訊也一定正常，因為後者可能使用不同類型的流量。系統代理通常無法自動接管所有程式的 UDP 流量；TUN 接入也無法補足伺服器端未開放的功能。比較 Trojan 與 SS 時，應在相同網路與相同任務下分別測試，不要用一次網頁載入結果代替所有相容性測試。

既有服務若只提供標準 Trojan 或 SS 參數，優先使用能完整呈現這些參數的用戶端設定，不必額外疊加不需要的傳輸選項。桌面端可在 v2rayN 建立獨立測試項目；Android 端可在 v2rayNG 核對加密方式與安全選項。若要使用 v2flyNG，還應確認其所附核心支援該加密方式與擴充功能，不能只因介面上有同名協定就省略驗證。

兩者都沒有固定對應的速度等級。伺服器負載、網路路徑、加密實作與連線多工方式，通常比協定名稱更能說明實際體驗。選擇設定時，應先滿足身分驗證、功能需求與維護條件，再以實際任務比較資源耗用。匯入後無法使用時，可參照說明中心中的安裝設定與疑難排解分類，確認下一步。

04 / TLS & REALITY

TLS、REALITY 與 Vision 流量控制

REALITY 不是與 VLESS 同一層級的節點協定

用戶端常在同一條節點說明中列出 VLESS、REALITY 與 Vision，容易讓人以為三者屬於同一層。實際設定中，VLESS 是代理協定，REALITY 是 Xray 生態系中的安全機制，Vision 則是特定連線組合使用的流量控制。三者需要搭配運作，但職責各不相同。選用 REALITY 不能省略協定驗證，選用 Vision 也不能取代安全層。介面中的每個欄位都應依伺服器端提供的組合填寫。

一般 TLS 的信任流程通常仰賴憑證、名稱與簽發鏈。用戶端會透過這些條件確認遠端身分，系統時間也會影響有效期限判斷。REALITY 採用不同的驗證與交握機制，用戶端會使用公鑰、短識別碼、伺服器名稱等相關參數。兩種方案的欄位不可混用：一般 TLS 的憑證設定不能直接取代 REALITY 公鑰；一般 TLS 節點也不會因為填入短識別碼就變成 REALITY 節點。

分別檢查公鑰、短識別碼與指紋

REALITY 公鑰應使用服務維護者提供的用戶端設定，不可填入任意產生的值，也不能把伺服器私鑰填進用戶端。短識別碼同樣必須符合伺服器端允許的設定。疑難排解時，先確認複製內容完整，沒有多餘空格或換行，再檢查目前核心實際支援的欄位格式。不同世代的核心可能調整欄位名稱或解析方式，應以正在執行的核心文件與用戶端匯出結果為準，不要盲目照搬舊設定片段。

伺服器名稱應使用伺服器端明確允許的值，不要任意挑選常見網站網域。指紋設定用於影響用戶端交握特徵，在某些安全組合中是必要參數，但不是速度等級。修改指紋無法修復位址無法連線、金鑰不符或使用者驗證錯誤。若伺服器端提供建議值，請先維持一致；需要測試相容性時，一次只修改一項，並記錄核心記錄中的具體失敗階段。

Vision 必須搭配相符的連線組合

xtls-rprx-vision 是常見的流量控制識別碼，並非所有傳輸方式都能使用的通用最佳化開關。伺服器端必須設定相應的使用者流量控制，用戶端核心也必須支援該組合。將要求特定路徑的傳輸設定直接改成 TCP，或替既有 WebSocket 設定加上 Vision，都可能造成設定不相容。遇到流量控制相關錯誤時，應先核對完整方案，不要把所有安全選項輪流開啟碰運氣。

若同一服務提供一般 TLS 與 REALITY 兩種入口，應分別建立節點進行測試，並保留各自的驗證與傳輸條件。選擇依據包括用戶端支援、服務維護方式、憑證管理條件與實際網路表現，而不是把其中一種視為適用所有情境的替代方案。一般使用者不必背熟交握細節，但應知道哪些參數必須配套使用，以及哪些錯誤無法靠略過驗證解決。

記錄中若出現交握失敗，應區分名稱不符、憑證不受信任、對端中斷連線及驗證不符等類別。先確認用戶端連線的位址與連接埠是否正確，再檢查安全層欄位；反覆更換路由規則通常無法修復交握本身。更詳細的檢查順序請見TLS 交握失敗疑難排解，文章也說明了系統時間與伺服器名稱的常見誤區。

尋求協助時，可以說明是否啟用 REALITY、是否使用 Vision、用戶端與核心類型，以及錯誤發生的階段。不要公開完整分享連結、公鑰以外的機密欄位或伺服器端設定。即使是可公開的參數也不必全部貼出；提供足以定位問題的技術背景，比貼上整份設定更有助於判斷。

05 / PERFORMANCE & BATTERY

連線速度、資源耗用與行動端耗電

分開測量建立連線與持續傳輸

「速度快」可能指首次開啟頁面的等待時間短，也可能指大型檔案持續傳輸的吞吐量高，兩者受到的因素不同。建立連線需要經過名稱解析、網路連線、安全交握與代理驗證；持續傳輸則更受可用頻寬、壅塞、伺服器轉送與處理能力影響。某種協定減少了部分封裝，不保證遠距離網路中的首次回應一定更快；同樣地，單次大型檔案下載結果也無法反映互動式應用程式的使用體驗。

比較協定時，應盡量維持伺服器位置、網路入口、測試目標與接入方式一致。不同伺服器端之間的差異往往大於協定本身的差異。不要同時更換協定、DNS、路由與傳輸，再把結果歸因於其中一項。先用相同應用程式完成幾輪短時間要求與持續傳輸，觀察問題是否穩定重現，再查看記錄與系統資源。用戶端的連線測試可作為初步檢查，但測試目標與實際服務路徑未必相同。

封裝、多工與裝置效能共同決定負載

加密運算會使用處理器資源，但現代裝置的實際成本取決於演算法實作與硬體能力，不能替 VMess、VLESS、Trojan、SS 排出固定名次。外層傳輸、連線數量、記錄層級與流量複製也會影響資源耗用。傳輸層增加的要求與封裝，可能換來部署便利或相容條件。選擇方案時，應先符合服務需求，再評估這些成本是否會在目前裝置上形成明顯瓶頸。

連線多工可減少反覆建立連線的成本，但也可能改變並行流量之間的相互影響。是否啟用，應以伺服器端與核心支援為前提，並針對實際應用測試。將所有流量集中到較少連線，不代表所有情境都會更順暢。頻繁的短要求與長時間的大量傳輸需求不同；發生波動時，應檢查是否為共用連線壅塞，而不是立刻認定協定效能不足。

Android 耗電：優先檢查喚醒頻率與流量範圍

行動裝置耗電不只來自加密。無線網路頻繁喚醒、背景應用程式持續發出要求、網路切換後重新連線，以及過於頻繁的連線檢查，都可能增加耗電。啟用 VPN 接入並涵蓋更多應用程式後，系統也可能將部分網路活動歸到代理用戶端，因此電池用量統計中的占比不能直接視為協定運算成本。先比較相同使用時段、相近網路條件與相同背景應用程式，再判斷是否異常。

v2rayNG 的依應用程式代理可用來限定需要接入的應用程式，但必須確認目前清單採用的是允許模式還是略過模式，以及儲存後是否需要重新啟動連線。系統電池最佳化與廠商的背景限制也應分開判斷：限制過嚴可能導致程序被結束，接著反覆重啟或失去連線；完全解除限制則可能讓原本應受限的背景工作持續執行。目標是穩定執行必要服務，而不是解除所有應用程式與系統限制。

TUN 模式還涉及虛擬介面、路由處理與 DNS 接管，其耗電與系統代理並非單純相加。若應用程式本身支援代理，系統代理可能已足以符合需求；若必須接入不遵循代理設定的程式，TUN 的額外負載可能是必要成本。比較桌面端效能時，也應留意是否同時執行其他虛擬網路軟體，以免把路由衝突或重複處理流量誤認為核心效能問題。

測試結束後，請恢復一般記錄層級，避免持續記錄大量連線內容。效能評估應以任務能否穩定完成為準，而不是單次測試的峰值。若只有某個網域明顯變慢，應檢查 DNS、分流與遠端路徑；若所有應用程式都受影響，再檢查本機負載、網路品質與伺服器狀態。協定選擇只是最佳化的一環，不能用來概括解釋所有瓶頸。

06 / CORE COMPATIBILITY

V2Fly、Xray 與用戶端的關係

圖形介面負責管理，核心負責執行

Project V 是理解 V2Ray 生態系的背景；V2Fly 與 Xray 則是相關發展路線中的核心家族。圖形用戶端負責節點管理、參數編輯、啟動程序及系統接入。v2rayN、v2rayNG、v2flyNG 並不等於某種協定；真正負責連線的是用戶端呼叫的核心。因此，介面上出現某個欄位，只能表示介面能呈現該參數，不能單憑這一點確認目前的核心能夠執行。

Xray 在自身發展過程中提供包括 REALITY 與 Vision 在內的功能；V2Fly 也有自己的維護路線與設定擴充。兩者沿用部分歷史與設定概念，但欄位並非始終完全相同。支援清單、預設行為與傳輸實作都可能隨核心版本變動。遇到特定功能時，應核對目前隨附核心的說明，不要把其中一個分支的參數表當成另一個分支永久適用的相容清單。

三款用戶端各有適用情境

桌面端建議使用 v2rayN，並依下載頁提供的作業系統架構與格式安裝至 Windows、macOS、Linux。不同桌面介面的選單位置可能有所調整，但協定參數仍須由所選核心執行。Android 端建議優先使用以 Xray 為核心的 v2rayNG；若要配合 V2Fly 方案，可評估 v2flyNG。兩款行動端用戶端名稱相近，不代表設定能力與核心擴充完全相同。

設定相似不代表直接複製就能使用

原生設定中相同的外層結構，可能掩蓋內部欄位差異。尤其需要核對傳輸名稱、DNS 選項、流量控制與安全層參數。將 Xray 設定直接交由 V2Fly 執行，或反向操作，都應先確認功能支援範圍。解析階段出現未知欄位，通常表示設定模型不相符；啟動成功後仍連線失敗，則須繼續檢查欄位是否被忽略、預設值是否變更，以及伺服器端是否接受。

切換核心前，先備份節點、訂閱群組與自訂規則。優先使用用戶端能產生的標準設定，先以一條已知可用的節點驗證，再逐步還原自訂項目。一次遷移完整的原生設定，可能連同舊路徑、舊規則檔參照及僅原核心支援的選項一併帶過去。若無法啟動，先移除非必要擴充，再從最精簡的可用連線開始恢復，而不是繼續增加相容選項。

v2rayN 中的核心類型應與節點方案相符，具體選項位置請以目前介面為準。若某項功能由用戶端自動選擇核心執行，應查看啟動記錄確認實際程序，不要只看清單備註。更新用戶端後，核心與介面之間的配合方式也可能改變。保留可用設定的備份與測試記錄，有助於分辨更新造成的行為變化與伺服器端同步調整。

不要只因連線故障就反覆切換兩種核心。先確認錯誤發生在解析、啟動、交握、驗證還是目標存取階段，再判斷是否與實作支援有關。一般位址解析錯誤、系統時間不準或本機代理連接埠衝突，通常都不是更換核心的理由。需要安裝或更換用戶端時，請一律從用戶端下載頁選擇相應入口，避免把系統架構問題混入協定疑難排解。

07 / SUBSCRIPTION FORMATS

分享連結、訂閱與原生 JSON

三種格式儲存的資訊各不相同

分享連結通常描述單一連線；訂閱網址用來取得一組可更新的連線資訊；原生 JSON 則可描述核心執行設定。三者不是只換副檔名的同一份內容。分享連結方便傳送節點，但不一定包含完整的路由、DNS 與自訂出站設定；原生 JSON 的表達能力較完整，卻可能依賴特定核心與本機檔案。選擇匯入方式前，應先確認提供者交付的是哪種格式。

常見的文字訂閱會將逐行分享連結編碼為 Base64，但這只是常見格式，並非所有訂閱都採用相同定義。有些網址回傳的是設定文件或其他用戶端格式，反覆解碼也無法轉成本站用戶端所需的內容。訂閱下載成功不代表解析成功：伺服器可能回傳登入頁面、錯誤頁面或空白回應。應先查看用戶端顯示的錯誤類別，再判斷是取得失敗、內容格式不符，還是特定節點參數不受支援。

編碼轉換無法補上缺少的參數

Base64 是編碼方式，不提供機密保護。解碼後的使用者識別碼、密碼與伺服器資訊仍須保密。連結中的百分比編碼也有自己的規則，不應反覆解碼整段字串。尤其密碼、備註與路徑含有特殊字元時，多轉換一次就可能改變原意。複製時優先使用用戶端提供的分享或匯出功能，避免透過富文字編輯器插入換行、全形符號或不可見空格。

將分享連結轉換成原生設定，需要知道其協定、傳輸與安全層欄位的對應方式。來源連結若未包含某個擴充參數，轉換工具就無法可靠推斷其實際值。反過來，將複雜的原生設定壓縮成單一分享連結，也可能遺失自訂 DNS、多個出站與路由規則。轉換完成後應核對重要欄位，並實際連線驗證，不能把「轉換成功」視為完全等價的證明。

從小片段了解原生 JSON 的適用範圍

以下是核心設定中的路由片段，並非可獨立啟動的完整設定。它表示命中廣告網域分類時，會選用名稱為 block 的出站；完整設定必須已定義該出站，執行環境也必須能讀取相應規則資料。此範例用於說明欄位之間的參照關係，不應整段貼入用戶端的分享連結匯入欄位。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      }
    ]
  }
}

此處的網域策略決定路由比對時在什麼條件下嘗試解析，不等於 DNS 伺服器位址，也不會直接保證所有 DNS 要求都經過代理。規則中的出站名稱必須與完整設定相符，否則即使 JSON 語法正確，實際行為仍可能不如預期。規則資料是否存在、類別名稱是否可用，以及核心是否支援相關欄位，都屬於執行條件。欄位說明可參閱術語手冊。

訂閱更新與本機編輯應分開管理

訂閱群組中的節點可能在更新時遭到取代或重新產生。直接編輯這類節點，修改內容可能在下次更新後遺失。若要長期保留本機調整，應使用用戶端支援的獨立設定或管理方式，並記錄其與訂閱原始內容的差異。更新前別急著刪除舊群組；先確認新增節點能否連線，再處理重複項目與失效項目，發生問題時才方便復原。

訂閱網址通常帶有存取權杖，應比照帳號憑證妥善保管。不要交給來源不明的線上轉換服務，也不要在公開問題描述中貼出含權杖的完整網址。遷移時優先使用用戶端內建功能，確認目標用戶端支援該格式後再匯入。更多格式差異與失敗原因，請見訂閱格式與轉換方式。判斷相容性的關鍵始終是參數是否保留、核心是否接受，以及實際連線是否正常。

08 / SCENARIO SELECTION

依使用情境選擇並驗證

既有服務：先確認完整相容，再比較協定

已有可用訂閱時，選擇用戶端應先考量伺服器端提供的協定組合與裝置平台。桌面端建議使用 v2rayN，Android 端優先評估 v2rayNG；需要 V2Fly 相應功能時，再考慮 v2flyNG。不要只因另一種協定在介紹中看起來更簡潔，就自行改寫節點。保留原始訂閱，確認用戶端能匯入所有必要參數，先用一條節點完成驗證，再擴展到群組、路由與多個應用程式。

若服務提供多種入口，可將它們放入獨立測試群組，分別測試網頁瀏覽、持續傳輸與實際應用程式。固定接入模式、DNS 與目標位址，每次只比較一個變數。既有方案穩定且符合需求時，遷移的理由應是明確的相容需求、維護便利或可重現的體驗改善，而不是協定名稱的新舊。測試結果不穩定時，先檢查伺服器端路徑與網路波動，暫時不要下結論。

桌面工作與行動端背景運作的檢查重點不同

桌面瀏覽器與遵循系統代理設定的工具，可先透過系統代理接入，並確認本機監聽連接埠與程式設定一致。若要涵蓋其他流量，再評估 TUN 與權限條件。啟用 TUN 後，應確認本機網路、網域解析與其他虛擬網路軟體都能正常運作。不要把接入範圍擴大後應用程式行為的變化全歸因於遠端協定；有些應用程式可能只是第一次真正經過用戶端。

行動端更需要留意網路切換、背景常駐與流量涵蓋範圍。先使用一條穩定節點，確認鎖定螢幕後必要工作能否繼續，再觀察從 Wi-Fi 切換至行動網路後的復原情況。透過依應用程式代理排除不需要接入的背景流量，並依實際運作狀況調整電池限制。若只有某個應用程式啟動後耗電異常，應檢查該應用程式的連線行為，而不是立刻更換整套協定方案。

DNS 與分流必須納入驗證流程

連線成功後，還須確認應用程式實際使用的是否為預期出站。網域策略、路由規則順序、直連範圍與 DNS 路徑，都可能讓不同網站呈現截然不同的結果。只檢查出口 IP 不足以涵蓋所有流量，測試單一網頁也不能代表其他應用程式。檢查 DNS 行為時，應一併參照用戶端記錄、應用程式是否使用自己的解析方式，以及系統接入範圍，不要把單次測試頁面的結果套用到所有情境。

例如路由規則命中直連，但使用者預期流量走代理時，修改協定不會改變規則優先順序；應用程式若自行使用加密 DNS，用戶端的一般 DNS 設定也未必能接管該要求。相關操作請見DNS 檢測與設定步驟。調整前先保留目前設定，確認哪些流量應走哪條路徑，再驗證結果；不要同時啟用所有看起來與 DNS 有關的選項。

依失敗階段決定下一步

匯入失敗時先檢查格式與編碼；核心啟動失敗時檢查設定結構與支援範圍；交握失敗時檢查安全層；驗證失敗時檢查使用者資訊；連線建立後仍無法存取目標，才檢查路由、DNS 與遠端出站。依此順序處理可減少反覆試錯。每次只修改一項，重新啟動必要程序後再次測試，並保留簡短記錄。若錯誤類別改變，表示連線已進入不同階段，應據此調整疑難排解方向。

規劃新服務時，也應先列出用戶端支援範圍、傳輸環境、身分驗證方式與維護條件，再決定協定組合。需要管理憑證的方案，應安排名稱與憑證更新；採用 REALITY 的方案，則應明確規劃金鑰與允許參數的維護方式。任何選擇都仰賴設定持續一致，而非安裝一次後就永遠不必檢查。更新用戶端或核心後，以原本的測試任務重新驗證，比只確認能否啟動更可靠。

最後保留一套已驗證的設定作為基準，實驗參數則放在獨立項目中。需要從頭操作時，請回到快速入門；查找特定錯誤時，請使用說明中心；更換平台或安裝用戶端時，請前往下載頁。選擇協定與核心，應讓設定更容易理解、問題更容易定位，而不是增加無法說明的選項。