V2Ray 協定選擇
與核心相容性參考

01 / 連線模型

協定、傳輸與安全層的差異

連線由多組參數共同決定

在 v2rayN 中開啟伺服器編輯視窗時，協定類型只是連線設定的一部分。位址與連接埠決定連到哪裡，使用者識別碼或密碼負責驗證，傳輸設定則決定資料如何承載，TLS 或 REALITY 再處理相應的安全交握。路由規則決定哪些請求使用這條連線。分清各個層次，才能理解為什麼兩個項目雖然都標示 VLESS，卻不能直接互換其他欄位。

應用程式的請求通常先進入用戶端的本機入站，再由核心依路由選擇出站。出站連線會連至遠端伺服器，遠端再連往目標位址。圖形介面負責整理參數，實際建立連線的是核心；系統代理或虛擬網路介面則負責將應用程式請求送入入站。因此，「用戶端已啟動」、「本機代理連接埠正在監聽」、「遠端交握成功」和「目標網頁可存取」是不同階段，不能只靠一個連線圖示確認全部狀態。

位址、伺服器名稱與請求主機名稱

伺服器位址可以是網域名稱，也可以是服務提供者指定的位址。TLS 伺服器名稱通常用於驗證憑證名稱，也會參與伺服器名稱指示；HTTP 相關傳輸可能另有 Host 或請求主機欄位。這些欄位有時相同，有時會依伺服器部署方式而異。正確做法是逐項依照伺服器提供的設定填寫，而不是把編輯視窗中的所有網域欄位都換成伺服器位址，更不要照抄他人截圖中的無關名稱。

傳輸類型並非可任意切換的速度檔位。原始 TCP、WebSocket、gRPC 等傳輸方式都需要伺服器提供相應入口；路徑、服務名稱與中間反向代理的轉送規則也必須互相吻合。WebSocket 路徑不等於網站上的任意目錄，gRPC 服務名稱也不是備註。如果遠端只接受一種傳輸方式，在本機切換選項通常只會導致交握失敗，不會自動協商出另一種可用連線。

先保存原始參數，再逐項修改

匯入完整連線後，建議先保留原始項目，複製一份用於測試，並在備註中標明修改內容。每次只調整一類設定，例如只更改路由規則，或只檢查伺服器名稱。如果同時修改核心、傳輸與 DNS，即使連線恢復，也很難判斷真正原因；下次遇到問題時又得重新猜測。訂閱更新可能會覆蓋編輯結果，長期需要保留的本機調整，應放在獨立管理的項目或設定中。

閱讀記錄檔也應採用相同的分層方式。名稱解析失敗，先檢查位址解析；連線遭拒，先檢查遠端連接埠與服務狀態；憑證名稱不符，先確認系統時間與伺服器名稱；交握完成後仍無法存取，再檢查目標解析與路由。看似相同的介面提示，可能來自完全不同的階段。將記錄檔中的第一個有效錯誤與當下操作時間對照，比反覆切換所有選項更容易縮小問題範圍。

02 / 驗證與加密界線

VMess 與 VLESS 的設計取捨

VMess：協定本身包含驗證與加密機制

VMess 是 Project V 生態系中較早發展的代理協定，設計上將使用者驗證與資料保護納入協定本身。用戶端除了要知道遠端位址，也必須持有相符的使用者識別碼，並依照雙方支援的方式組織請求。現代部署通常採用 AEAD 驗證機制；舊版項目中仍可能保留額外識別碼數量等歷史欄位。遇到這類欄位，不要只憑名稱猜測用途，更不要為了「相容」而隨意填入數值。

VMess 的驗證流程與時間條件有關，因此系統時間明顯不準可能導致交握失敗。疑難排解時，請在作業系統中啟用自動時間同步，確認時區與實際時間來源一致，再重新連線。修改用戶端備註、重新啟動瀏覽器或切換路由，都無法解決驗證時間問題。若舊訂閱持續要求過時參數，應優先向服務提供者確認目前可用的格式，而非長期依賴舊版用戶端繼續解析。

VMess 安全選項必須符合核心能力與伺服器要求。初次設定時，通常選擇自動比手動強制使用特定演算法更合適；處理器是否支援硬體加速，也會影響不同演算法的實際負載。協定本身具備資料保護，不代表外層永遠不需要 TLS：某些部署會依賴 TLS 入口與反向代理來組織服務。是否需要外層安全層，仍須依完整部署方式判斷。

VLESS：精簡協定層，將安全交由外層處理

VLESS 的設計重點是精簡代理協定層，保留使用者識別等必要資訊，並由外層方案提供傳輸安全。常見設定中的加密欄位為 none，表示 VLESS 協定層不提供相應的資料加密，不能據此推論整條連線沒有保護。判斷連線安全性時，還必須確認外層是否啟用 TLS 或 REALITY，以及驗證與憑證相關參數是否正確。

反過來說，看到使用者識別碼，也不能將它視為加密層的替代品。如果部署原本要求 TLS，本機為了排錯而關閉安全層，伺服器通常不會接受；即使另有可接受明文的入口，也不能因此認定兩種連線的安全性相同。選用 VLESS 的前提是理解伺服器提供的完整組合，而不是單純追求「欄位較少」，或把它當成可任意替換 VMess 的選項。

VLESS 設定中的 flow 代表特定流量控制方式，與一般路由分流不同。部分 flow 必須搭配特定核心、傳輸與安全層使用，不能把某條連線的值複製到所有 VLESS 項目。用戶端提供輸入欄位，只表示介面可以收集這項資料；是否支援、是否接受該組合，仍由目前使用的核心與伺服器共同決定。

選擇協定應以遠端支援為優先

已有可用的 VMess 服務時，不必為了追求新名稱就直接改成 VLESS。兩者的伺服器驗證流程不同，只在本機修改協定類型並不能完成移轉。正確的移轉方式是先由伺服器提供相應入口，再匯入新的連線資料，確認可存取目標與所需的 UDP 應用程式，最後再決定是否取代舊項目。保留一份已知可用的設定，也有助於分辨服務端變動與本機環境變動。

如果伺服器同時提供兩種完整設定，可以在同一台裝置、同一個網路、相近的時間內比較連線表現。先維持路由、目標位址與測試內容一致，再觀察連線是否穩定、持續傳輸是否正常，以及裝置從休眠中恢復後能否重新連線。不要只憑一次測速就將結果歸因於協定；出口線路、伺服器負載、傳輸封裝與本機 DNS，都可能比協定層差異更顯著。

03 / 不同安全模型

Trojan、Shadowsocks 與 REALITY

Trojan：以 TLS 建立代理連線

Trojan 的常見部署以 TLS 連線為基礎，在受保護的通道內完成密碼驗證與代理請求。它的設定方式通常比多層封裝的組合直觀，但不代表只填入密碼就足夠。伺服器位址、連接埠、伺服器名稱與憑證驗證仍是重要參數。如果憑證所屬網域與填入的名稱不符，用戶端應拒絕連線，而不是把驗證失敗當成可以忽略的一般警告。

Trojan 的交握表現會受 TLS 協商、遠端回應與網路品質影響，不能因為採用 TLS，就認定建立連線一定比較慢。在某些情況下，工作階段恢復可降低重複交握的成本，但實際效果取決於實作方式與連線生命週期。選用時應留意遠端憑證維護、密碼輪替與用戶端支援情形。憑證錯誤的詳細排查方式，請參閱TLS 交握與憑證錯誤排查。

Shadowsocks：加密方法決定相容範圍

Shadowsocks 常簡稱為 SS，核心概念是使用預先共享的金鑰建立加密代理通道。隨著協定演進，不同加密方法在驗證、金鑰處理與資料組織上各有差異。舊版方法、AEAD 方法與較新的方法系列，不能只因為「都是 SS」就認定彼此相容。匯入時必須保留正確的方法名稱與密碼格式；尤其不要把需要特定長度金鑰的設定當成一般口令欄位處理。

SS 欄位相對精簡，適合用來了解加密方法與用戶端相容性。不過，如果服務資料還包含外掛參數，就會多出一項獨立的相容條件。某個核心支援基本 SS 協定，不代表圖形用戶端會啟動所有外掛，也不代表訂閱轉換能保留外掛選項。匯入成功但交握失敗時，應先查看原始資料是否包含未保留下來的額外需求，再確認目前用戶端是否支援。

REALITY：安全層方案，並非獨立的代理類型

REALITY 常與 VLESS 一起使用，但它不會取代 VLESS 的所有代理功能。可以將 VLESS 視為定義代理請求的層，將 REALITY 視為特定的安全交握方案。用戶端通常需要伺服器名稱、公鑰、短識別碼等資料，部分實作也提供指紋相關選項。這些值取決於伺服器設定，不能從目標網站憑證或另一條連線推導得出。

用戶端保存伺服器提供的公鑰，伺服器則持有對應的私鑰；兩者用途不可混淆。訂閱已提供公鑰時，應原樣保留，不要在本機重新產生一把，再期待遠端接受。短識別碼也必須符合伺服器允許的值，留白是否有效則視具體設定而定。伺服器名稱同樣應採用服務提供者指定的值，不要看到網址列中的網域名稱就自行替換。

REALITY 的支援範圍應依核心實作判斷，不能因為 v2rayN 和 v2flyNG 都屬於相關生態系，就認定兩者提供完全相同的選項。涉及 REALITY、特定 flow 與相應傳輸組合時，應優先核對 Xray 的實作要求，再確認圖形用戶端是否能完整產生這些欄位。如果介面缺少必要參數，一再匯入同一個連結也無法補足底層能力。

這三種名稱並非可以直接排名的同類選項。比較時應列出完整連線組合，再評估維護成本、裝置負擔與遠端可用性。如果參數來源不完整，先取得明確資料比尋找所謂的通用最佳值更重要；用戶端不會依缺少的欄位自動還原伺服器的設定。

04 / 實作與設定

V2Fly、Xray 與用戶端的關係

核心負責建立連線，用戶端負責整理設定

Project V 是理解這個生態系的背景。V2Fly 延續 V2Ray 相關核心的維護與發展，Xray 則以相關技術基礎發展出自己的功能路線。兩者共享部分概念，也各自有不同的實作與欄位。核心不是圖形介面的另一個名稱：同一個用戶端可能可以呼叫不同核心，而某個核心支援的底層選項，也不一定都會顯示為介面中的開關。

v2rayN 是優先推薦的桌面用戶端，支援 Windows、macOS 與 Linux；各平台的安裝方式請參閱用戶端下載頁。它負責管理伺服器清單、訂閱群組、系統代理與設定產生等操作。可選用的核心與功能入口，取決於用戶端實際提供的版本與設定；不要假設每個安裝套件都包含相同元件，更不要只靠修改檔名，把不相容的程式偽裝成另一種核心。

Android 優先推薦 v2rayNG，使用 Xray 核心；v2flyNG 使用 V2Fly 核心，可作為相關設定的替代選擇。兩款應用的操作概念可能相似，但設定欄位與預設行為仍可能不同。選擇應用程式時，應先確認現有服務的需求，再考慮介面使用習慣。涉及 REALITY 等特定功能時，應依相應的實作方式核對，不要只憑應用程式名稱相近就判斷相容性。

設定結構相似，不代表欄位可以照搬

兩類核心的常見設定都包含入站、出站、路由與 DNS 等概念，部分基本結構看起來非常接近。但傳輸名稱、欄位支援範圍、流量控制方式與新功能的支援程度，並不保證一致。某段 JSON 通過語法檢查，只能證明括號、字串等格式正確，不能證明目前的核心能理解所有欄位；有些錯誤要等到啟動或建立連線時才會出現。

圖形用戶端通常會先讀取訂閱，再儲存內部伺服器設定，最後產生供核心使用的設定檔。相容性問題可能發生在任何一步：連結解析器不認得某個參數、內部設定沒有保存擴充欄位，或核心拒絕產生的結果。排查時先確認編輯視窗中的欄位，再查看啟動錯誤；不要把所有問題都歸咎於遠端服務。設定檔的各個區段可搭配閱讀JSON 結構解析文章。

切換核心前後的驗證順序

切換前記錄目前的協定、傳輸、安全層、flow、DNS 與路由設定，並保留已知可用的項目。切換後先執行用戶端提供的設定檢查或嘗試啟動，確認沒有未知欄位、缺少元件或連接埠占用，再測試遠端連線。若只以瀏覽器能否開啟網頁作為判斷依據，本機流量接管失敗與遠端協定不相容很容易混為一談。

一般連線移轉時，也應檢查預設值是否改變。例如網域比對策略、嗅探行為、UDP 轉送與連線多工，可能不會出現在伺服器編輯頁，卻會影響實際請求。不要為了模仿舊環境而開啟所有進階選項；先保留最低限度的必要設定，確認基本連線正常後，再逐項恢復確實需要的規則。移轉後能否穩定運作，通常取決於界線是否清楚，而非開關數量多寡。

更新核心與更新訂閱，解決的是不同問題。前者改變本機實作能力，後者更新遠端連線資料；更新後連線恢復，不代表兩者可以互相取代。若出現回歸問題，應註明最後變更的是用戶端、核心還是訂閱，並保留錯誤發生時間。提供疑難排解資料前，請移除設定中的驗證資料與訂閱網址，只保留必要欄位名稱與錯誤類型。

05 / 效能觀察

連線速度、資源使用與耗電

分開觀察連線建立與持續傳輸

「速度」至少包括建立連線所需時間、首次回應、持續傳輸速率與長時間穩定性。網域解析、連往遠端的網路往返、安全交握，以及遠端連往目標的過程，都會影響首次回應；持續傳輸則更受網路頻寬、壅塞控制、伺服器負載與裝置處理能力影響。某個方案開啟短頁面較快，不代表傳輸大型檔案一定比較快，也不代表背景維持連線時更省電。

精簡協定層可以減少部分處理工作，但無法消除網路距離與封包遺失。WebSocket、gRPC 等承載方式增加了相應的封裝，也可能配合既有服務基礎設施；額外封裝是否成為瓶頸，必須在目標環境中觀察。不能只憑層數就斷定某個組合效能較差，更不能把部署在線路不同的伺服器所得結果，當成協定間的嚴格比較。

加密演算法的資源負載取決於處理器、系統函式庫與核心實作。支援相關硬體加速的裝置，可能以較低負載完成某種加密；換一台裝置，結果就可能不同。高速持續傳輸時，處理器負載可能更加明顯；一般瀏覽網頁時，主要等待的則可能是網路回應。比較時也要觀察裝置發熱與任務完成情形，避免把正常的短暫負載誤判為用戶端異常。

連線多工不代表所有工作都會更快

連線多工會嘗試讓多個邏輯請求共用底層連線，可能減少重複建立連線的成本，也可能讓多個請求一同受到單一連線壅塞或中斷影響。實際效益取決於工作類型、傳輸方式與實作。少量短請求與持續大量傳輸，適合的設定可能不同。啟用後若部分應用程式卡住，應先關閉多工進行比較，而不是繼續疊加更多進階選項。

UDP 工作需要另外測試。網頁可以正常使用，只能證明相關 TCP 或 HTTP 請求成功，不能代表語音、即時互動或其他 UDP 應用已獲得正確轉送。用戶端、協定實作、伺服器與路由都可能造成限制。有些網路對 UDP 的處理也與 TCP 不同，因此應使用實際需要的應用程式測試，而不要以一次網頁測速取代所有相容性檢查。

行動裝置耗電更常受流量接管方式與重新連線影響

Android 的耗電情形並非只由協定名稱決定。虛擬網路介面接管的資料範圍、背景應用程式活動、無線網路訊號、心跳與重新連線頻率，都會影響耗電。在行動網路與 Wi-Fi 之間切換時，舊連線可能需要重新建立；如果背景持續有請求，重試也會延長無線模組的活動時間。把額外耗電全歸因於 TLS 或 REALITY，通常缺乏充分證據。

系統電池最佳化也有取捨。限制背景活動過多，可能讓用戶端遭到暫停，回到前景後又不斷重連；完全放寬背景限制，則可能讓其他應用程式的持續流量照常通過。應先查看應用程式的電池使用紀錄，再確認斷線時間是否與螢幕熄滅或網路切換有關。只為了排除一次斷線就關閉所有系統最佳化，不利於找出真正原因，也可能影響其他應用程式的耗電情形。

可重現的比較方式，是保留兩份設定，在同一台裝置、同一個網路與相同工作內容下交替測試，並避免一邊充電一邊比較裝置發熱。分別記錄首次連線是否成功、持續工作有無停頓、螢幕熄滅後能否恢復，以及系統電池紀錄。多次觀察都一致的趨勢才值得採用；出口不同或測試時間不同的單次峰值，不適合用來建立協定排行榜。

06 / 資料交換

訂閱格式、分享連結與移轉

訂閱是設定的提供方式，不是協定本身

訂閱網址通常會回傳一組連線資料，再由用戶端識別內容、解析項目並加入群組。回傳內容可能是分享連結集合、編碼文字，或某種結構化設定。同一個網址也可能依請求條件回傳不同內容。因此，「瀏覽器能開啟訂閱」只表示取得了回應，不能證明回應格式符合目前用戶端的需求，更不能證明目前核心支援其中所有協定。

分享連結也各有格式約定。VMess 連結常見的是編碼後的結構化內容，VLESS、Trojan 與 SS 則常以 URI 格式攜帶驗證資訊及查詢參數；不同服務提供者也可能使用擴充欄位。連結中的部分字元需要百分比編碼，備註與查詢參數也可能包含非拉丁文字。複製時漏掉結尾、把換行符混入網址，或遭通訊軟體截斷，都可能導致匯入失敗。

Base64 是資料編碼方式，不是加密保護。即使訂閱或分享內容無法直接辨識，仍可能包含可直接使用的驗證資料。不要把完整訂閱網址貼到公開討論區，也不要隨意交給來歷不明的資料轉換服務。排查格式時，可以先在本機確認內容類型，並移除驗證欄位；只隱藏備註、卻保留完整連線資料，並不能降低外洩風險。

匯入成功後，接著確認欄位是否完整

匯入後應開啟項目，逐一核對協定、位址、連接埠、使用者驗證、傳輸類型、路徑與安全設定。REALITY 等組合還須核對相關公鑰與短識別碼；VLESS 則要檢查所需的 flow。清單中出現一筆資料，只代表解析器建立了項目，不代表所有擴充參數都已保留。即使備註正確，關鍵欄位若是空白，連線仍不完整。

在不同用戶端之間移轉時，建議使用雙方明確支援的分享格式，先匯入少量項目測試，再移轉其他群組。直接複製應用程式資料夾，可能一併帶入平台路徑、本機連接埠與專屬設定，不能視為通用移轉方式。桌面作業系統的系統代理設定也不會自動轉換成 Android 的網路流量接管設定；連線資料可以移轉，本機流量接管與權限仍須重新檢查。

訂閱更新通常會依遠端資料重新產生或合併項目，手動修改是否保留取決於用戶端的管理方式。若要長期調整備註、路由關聯或連線欄位，應先了解更新時的覆寫規則。將測試用設定存放在獨立群組，並為原始訂閱取清楚的名稱，可避免下次更新後誤以為伺服器突然改變了所有設定。

清單為空時，分別檢查回應與解析

更新失敗時，先確認網址是否完整、是否已失效，以及目前網路能否取得回應。如果請求已有回應，再確認內容是連線資料、登入頁面還是一般錯誤文字。請求成功與解析成功是兩回事；反覆編碼網頁內容，不會讓它變成有效訂閱。如需更詳細的檢查順序，請參閱訂閱更新失敗與清單空白自我檢查清單。

部分服務會依 User-Agent 或請求參數選擇訂閱格式。只有在服務提供者明確說明時才調整這些設定，不要為了測試而隨意偽裝成另一種用戶端。也要確認更新是否經由現有代理進行：若更新同一批資料時還依賴尚未建立的連線，可能形成循環。先確保至少有一種可用的更新方式，再確認回傳格式，最後處理個別項目的相容性問題。

07 / 請求路徑

路由規則與 DNS 的協作界線

路由決定出站，不負責修復交握

路由分流會依網域、位址、連接埠或其他條件選擇出站。它發生在核心處理請求的過程中，不能取代遠端驗證，也無法修復憑證名稱錯誤。如果所有存取都失敗，應先確認本機流量接管與代理出站是否可用；如果只有部分網域異常，再檢查比對規則與解析結果。將連線故障與分流故障分開，才能避免無效修改。

常見路由規則會依順序比對，前面已符合的寬鬆條件，可能讓後面的精細條件無法生效。預設出站同樣重要：在常見的設定模型中，未符合規則的請求可能會走預設路徑，實際選擇應以產生的設定為準。不能只看規則清單中的名稱，還要確認規則所引用的出站標籤確實存在，而且大小寫與拼字一致。

以下是設定中的路由片段，用來說明私有位址直連的結構。這不是可獨立執行的完整用戶端設定，必須與其他區段合併，並確認已存在標記為 direct 的直連出站，以及相應的位址規則資料。若圖形用戶端已產生這些內容，就不要重複附加片段；建議優先透過路由設定介面表達相同的需求。

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

解析發生的位置，會影響規則可辨識的資訊

應用程式可能將網域名稱交給代理，也可能先在本機解析，再只提交位址。前者讓核心有機會直接依網域比對，後者則可能只剩位址資訊。系統代理、應用程式內建代理與虛擬網路介面，在保留請求資訊的方式上並不完全相同。因此，同一條網域規則在某種流量接管方式下生效、在另一種方式下沒有命中，不一定是規則文字寫錯。

AsIs 通常表示不為了路由比對而主動將網域名稱轉換為位址，但不代表整個連線過程從此不需要 DNS。其他網域策略可能在特定條件下觸發解析，以嘗試比對位址規則。改變策略會同時影響規則結果與解析成本，不能簡單理解為解析越積極就越準確。應先決定要依網域還是位址判斷，再選擇相符的處理方式。

核心 DNS、作業系統 DNS、瀏覽器的加密 DNS 與遠端目標解析，可能各自走不同路徑。更改一項設定，不一定能涵蓋所有請求。如果瀏覽器與其他應用程式的結果不同，應先確認瀏覽器是否自行解析，以及應用程式是否確實經過用戶端。DNS 伺服器能回應，不代表存取路徑正確；解析成功後，請求仍可能被路由至不符合預期的出站。

系統代理、嗅探與本機網路存取

自動設定系統代理，主要影響遵循系統設定的應用程式，不等於接管所有流量。全域代理、略過區域網路與直連等模式名稱，也可能只是用戶端提供的預設選項，應檢查實際產生的規則。使用區域網路印表機、共享資料夾或本機管理頁面時，先確認私有位址的處理方式，再考慮是否需要為內部網域新增明確規則。

流量嗅探會嘗試從請求中擷取網域等資訊，為路由提供線索，但無法保證辨識所有協定，更不能取代完整的應用層資訊。部分設定也可能影響目標位址處理，因此應依用途啟用。排查單一網站時，記錄應用程式提交的是網域還是位址、符合哪條規則，以及最後走哪個出站，比同時更換 DNS 與路由模式更容易釐清原因。

IPv6 也應納入連線路徑檢查。系統取得位址記錄後，實際連線可能會選擇不同的位址系列；如果只為其中一種路徑設定規則或提供支援，表面上就可能時好時壞。不要把停用某種位址系列當成固定解法，應先確認本機網路、伺服器與目標是否都支援所選路徑。詳細介面操作請參閱DNS 設定教學。

08 / 決策與驗收

依使用情境選擇用戶端與協定

已有服務：保留完整組合，先確認相容性

已有穩定服務時，通常應先保留服務提供的完整協定組合，而不是急著更換協定。桌面端優先使用 v2rayN，並依作業系統與處理器架構選擇安裝套件；Windows 的 Desktop 與傳統 WPF 介面選擇方式，請參閱Windows 安裝與設定說明。介面形式不能用來判斷遠端協定的安全性，實際功能仍取決於呼叫的核心與產生的設定。

Android 優先考慮 v2rayNG；如果現有服務依賴 V2Fly 的特定功能，再評估 v2flyNG。首次測試時只匯入一筆資料完整的連線，確認基本存取正常後，再啟用所需的分流與流量接管範圍。如果一開始就同時移轉所有訂閱、規則與背景設定，發生問題時很難分辨是資料解析、核心相容性還是系統權限造成。

有多種連線入口：先列出需求，再逐一比較

如果伺服器同時提供 VMess、VLESS、Trojan 或 SS，應先列出必須符合的條件：裝置是否支援相應核心、是否需要 UDP、是否依賴特定傳輸入口，以及能否持續維護憑證或金鑰。確認符合需求後，再比較連線穩定性與實際使用體驗。評估 REALITY 時，應將它視為完整安全層組合的一部分，而不是在協定下拉式選單中尋找可獨立取代所有連線的選項。

多裝置使用時，更要避免追求最低共同設定的迷思。並非每台裝置都必須使用相同入口；同一項服務可以為不同用戶端提供各自相容的資料。強行將桌面端的新欄位複製到另一種核心，可能導致不相容；為了統一名稱而刪除必要參數，也可能破壞安全條件。應統一管理連線目標與路由規則的意圖，而不是要求每個編輯視窗中的內容完全相同。

行動裝置與桌面長時間運作的注意事項

桌面長時間運作時，應重點觀察系統從休眠恢復、網路切換、連接埠占用，以及應用程式是否遵循系統代理。Android 還須檢查背景限制、流量接管的應用程式範圍與電池紀錄。macOS 初次安裝遇到系統封鎖或權限提示時，請參閱安裝與網路權限處理。平台權限問題應在系統層處理，不能靠更換使用者識別碼或協定類型修復。

選擇短時間瀏覽網頁的方案時，連線建立與首次回應較值得關注；選擇持續傳輸的方案時，則應觀察工作期間是否停頓、重新連線及裝置負載。即時應用程式還要另外測試 UDP 路徑。不同工作有不同的評估重點，因此本手冊不提供脫離網路條件的固定速度排名。能夠說明原因、重複驗證的結果，比沒有測試條件的推薦標籤更適合長期參考。

發生問題時依階段排查，不要隨機修改參數

完全無法啟動時，先檢查設定驗證、執行環境與本機連接埠；能啟動但無法交握時，再檢查遠端位址、驗證、傳輸與安全層；交握成功但部分應用程式失敗時，檢查流量接管方式、UDP、DNS 與路由。如果錯誤只在訂閱更新後出現，請比對更新前後的關鍵欄位；如果只在螢幕熄滅後發生，應優先檢查背景限制與重新連線記錄。

每次排查都應固定幾項已知條件：同一台裝置、同一個網路、同一個目標或同一條連線，至少固定其中幾項，再一次只變更一個變數。記錄檔應針對一次明確操作收集，避免把很久以前的錯誤與目前成功的連線混在一起。可以分享錯誤類型與處理過的欄位結構，但不要提供完整驗證資料。這樣得到的判斷才有助於重現問題，而不只是碰巧恢復存取。

最後保留的設定應能說明四件事：選用了什麼協定組合、目前的核心為何支援它、哪些應用程式會經過用戶端，以及發生問題時要去哪裡查看線索。首次操作仍請依照快速入門流程；本頁則說明流程背後的相容界線，協助你在需要修改時做出有根據的選擇。