代理協定與核心參考

用戶端、核心與伺服器的分工

圖形化用戶端負責顯示伺服器清單、讀取分享連結、管理訂閱與儲存設定。核心負責建立入站監聽、執行路由規則、連線至遠端並轉送流量。遠端服務則依約定的協定接受連線。v2rayN 顯示某個編輯選項，不代表目前選用的核心一定支援；用戶端能匯入連結，也不代表伺服器會接受其中所有參數。排查相容性時，必須同時確認用戶端如何解讀欄位、核心實際產生的設定，以及伺服器允許哪些組合，不能只看介面上的協定名稱。

本機應用程式通常先連線至系統代理或虛擬網路介面，再由核心轉送至遠端。瀏覽器無法連線，可能是本機入口、名稱解析、路由選擇、遠端連線或目標網站任一環節出了問題。協定只是其中一環。若把所有連線失敗都歸因於 VMess 或 VLESS，就可能忽略連接埠被占用、系統代理未生效或分流規則誤判等更直接的原因。首次測試時，請固定一個應用程式與一個目標，確認要求已進入用戶端，再觀察錯誤發生在哪一層；不要同時切換節點、修改 DNS 和調整路由。

代理協定、傳輸方式與安全層

VMess、VLESS、Trojan 與 Shadowsocks 定義代理雙方如何識別使用者、指定目標位址及封裝資料。TCP、WebSocket、gRPC 等屬於承載或傳輸方式；TLS 和 REALITY 則涉及外層安全機制。VLESS 與 REALITY 不能當成同一層級的協定直接比較，因為兩者可以用在同一條連線上。同樣地，看到 WebSocket 不代表使用 VMess，看到 TLS 也不表示一定使用 Trojan。選擇時應比較完整組合，而不是把不同層級的名稱放在同一張速度排行榜上。

連線位址、伺服器名稱與應用程式目標

連線位址決定用戶端先連到哪裡；伺服器名稱通常用於安全握手與身分驗證；應用程式目標則是瀏覽器原本要造訪的網站。三者有時會使用相同網域，但用途不同。修改連線位址時，不應順手覆寫伺服器名稱；調整 WebSocket 的 Host，也不等於變更應用程式目標。伺服器若使用反向代理，路徑、Host 與伺服器名稱可能都會影響轉送。少了其中一項，常見情況是入口可連線，要求卻未送到正確服務，而非單純的帳戶錯誤。

實際檢查時，先按層記錄現有設定：使用哪種協定、底層傳輸方式為何、是否啟用外層安全機制，以及認證欄位的來源。不了解的開關先保留原值，並保存原始匯入內容。分享連結中的簡寫欄位不一定與介面上的中文名稱完全對應，不能只因名稱相近就互換。最可靠的依據是伺服器提供的完整參數，以及核心文件對各欄位的說明。以下章節會沿用這套分層方式，分別討論設計取捨與用戶端檢查順序。

VMess：結合認證與資料保護

VMess 屬於 Project V 的協定體系，將使用者認證、要求資訊與資料保護納入協定設計。常見設定以 UUID 識別使用者，並包含相應的加密選項。較新的實作採用 AEAD 認證方式；舊教學中的額外識別碼與舊式認證參數，不能直接當成通用建議值。匯入後應讓用戶端依目前格式產生設定，而不是為了照抄舊截圖而改回舊欄位。裝置時間也應保持準確；若認證流程涉及時間條件，時鐘明顯偏差可能造成網路可達、認證卻失敗。

VMess 是否適用，主要取決於現有服務與用戶端的支援情況。若已有穩定的 VMess 服務，不必只因另一個協定名稱較新就更換。需要確認的是傳輸方式、使用者識別、加密設定與外層安全是否一致。VMess 可搭配不同傳輸方式，實際連線耗用也會隨組合而異。採用多層封裝的 VMess 連線，不能和另一條直連傳輸的連線直接比較，再把差異全歸因於協定本身。比較時至少要固定伺服器、目標、網路與測試方式。

Trojan：依賴 TLS 的代理認證

Trojan 將代理要求放在 TLS 連線中，再透過協定本身的認證資訊識別使用者。它不像 UUID 那樣採用統一的帳戶識別方式，用戶端通常需要設定密碼。使用時仍須區分遠端位址與伺服器名稱，並確認憑證與名稱相符。TLS 連線建立成功，不代表代理認證也已通過；反過來說，密碼正確也無法修正憑證名稱錯誤。應分別理解這兩個階段的記錄。不要把停用憑證驗證當成一般安裝步驟，否則用戶端確認遠端身分的能力會降低。

Trojan 常被認為設定欄位較集中，但實際維護難度仍取決於憑證、網域與服務部署。連線重用、傳輸擴充或外部轉送安排都可能增加額外條件。用戶端支援 Trojan，不代表也支援所有名稱相近的擴充組合。遷移設定時，應先確認伺服器採用哪種實作與傳輸方式，再檢查用戶端是否完整保留密碼和伺服器名稱。密碼可能包含需要進行 URL 編碼的字元，手動組合分享連結時尤其容易在這裡出錯。

Shadowsocks：加密方法與密鑰必須相符

Shadowsocks 通常以精簡的設定描述代理連線，關鍵資訊包括伺服器位址、連接埠、加密方法與密碼。簡稱 SS 只代表協定家族，不能取代具體的方法名稱。傳統 AEAD 方法與新版 Shadowsocks 2022 方法，在密鑰要求及實作支援上有所不同；後者不能直接套用任意長度的一般密碼。用戶端能識別 SS 連結，不代表其核心支援連結指定的所有方法。若匯入成功但連線報錯，請先核對方法名稱與密鑰格式，不要反覆更換伺服器位址。

這三類協定各自處理認證與轉送，不能只用欄位數量判斷安全性或資源耗用。設定較短不一定更省電，層次較多也不一定比較慢。對於既有服務，優先採用參數完整且用戶端明確支援的組合；若需維護多部裝置，則應優先考慮各裝置能否使用同一種設定格式。若要進一步比較四種代理協定，請閱讀VMess、VLESS、Trojan、Shadowsocks 選型說明，並參考下一章了解 VLESS 的安全界線。

VLESS 不等於完整的加密連線

VLESS 的設計方向是精簡代理協定本身，並將部分職責交由外層機制處理。使用者識別通常仍採用 UUID，但其運作方式不能照搬 VMess 的加密選項。常見 VLESS 設定中的 encryption: none 表示協定這一層不另行選擇資料加密方法，不代表整條連線一定沒有保護。要確認完整連線是否受保護，還需檢查傳輸設定中的 TLS 或 REALITY。反之，若設定確實沒有外層安全機制，就不能因為協定名稱是 VLESS，便認定連線已加密。

因此，討論 VLESS 時應說明完整組合，例如 VLESS 搭配 TLS 或 REALITY，並交代承載方式。不同組合的伺服器需求、握手欄位與核心支援範圍都不相同。選項中的 flow 也不是通用的加速開關，而是代表特定流控方式，必須符合伺服器與傳輸條件。任意填入 xtls-rprx-vision，不會讓不支援該組合的服務因此取得相應能力。若原始連結沒有這個欄位，就不應只憑教學截圖自行補上。

REALITY 的用戶端驗證資料

REALITY 是安全傳輸機制，不是取代 VLESS 的另一種使用者帳戶協定。常見的 Xray 用戶端設定中，需要確認伺服器名稱、公鑰類驗證資料、短識別碼與指紋設定等內容。介面名稱會隨用戶端與核心設定模型而異，分享連結也可能採用縮寫。檢查時應以匯入後欄位的實際意義為準，而非只看標籤。用戶端用於驗證遠端的資料，與伺服器保存的私鑰資料用途不同；伺服器私鑰不應複製到一般用戶端設定中。

短識別碼通常有十六進位格式與長度限制，是否允許空值則由伺服器決定。伺服器名稱必須符合伺服器允許的範圍，不能任意換成熟悉的網域。指紋設定會影響握手表現，也受核心實作支援範圍限制；它不是通用的裝置身分更換工具。若原始設定可以連線，手動重建卻失敗，請逐項比較這些欄位，再檢查複製過程是否帶入空格、全形字元或遺漏查詢參數。先還原原值，比同時嘗試多種所謂的最佳化組合更容易找出原因。

相容性問題的判斷順序

若儲存設定後核心立即結束，優先檢查欄位是否不受支援、參數結構是否錯誤或組合是否合法。若核心正常啟動，但遠端握手失敗，再檢查位址、連接埠、伺服器名稱與驗證資料。若握手成功但應用程式仍無法連線，則進一步檢查路由、DNS 與目標連線。依此順序檢查，可區分本機設定解析問題與網路握手問題。用戶端記錄中出現某個安全層名稱，只能表示目前正在處理相關階段；不能僅憑這一行就確認使用者認證與應用程式資料轉送都已完成。

建立新的桌面設定時，主要參考路徑是搭配支援相應功能核心的 v2rayN；Android 使用 v2rayNG 時，也同樣需要確認實際核心具備所需能力。不要把面向 Xray 的 VLESS 與 REALITY 設定直接交給另一個核心家族，並期待完全相容。若已有可用設定，應先確認匯入工具沒有遺漏欄位，再考慮更換用戶端。核心支援範圍請見第五章；分享連結保留欄位的方法請見第六章。兩者共同決定這類組合能否正確移轉至其他裝置。

連線建立時間、回應時間與傳輸量

連線效能至少涉及三種不同問題：建立新連線需要多久、送出要求後多久收到回應，以及持續傳輸時能維持多大的傳輸量。這些表現受不同因素影響。名稱解析、TCP 建立連線、安全握手與代理認證會影響首次回應；往返時間、封包遺失、壅塞控制與伺服器負載則會影響持續傳輸。某種協定減少了應用層欄位，不代表它在較差的網路環境下仍然更快。單看一次測速結果，無法區分協定實作、伺服器位置與網路狀態各自造成的影響。

Tcping 這類測試通常只能反映某個 TCP 入口的連線狀況，不會完整執行代理認證與目標網站連線。實際連線測試則較接近應用程式透過代理造訪測試網址的過程，但結果仍會受到測試目標與用戶端實作影響。兩項結果並非同一種指標。入口可連線但實際連線失敗，可能是認證、安全握手、目標存取或 DNS 問題，不能立刻判定線路中斷。操作方式請參考首次連線與實際連線測試指南，固定測試目標並重複觀察。

封裝、連線重用與資源耗用

WebSocket、gRPC 等傳輸方式各有不同的握手與封裝機制，也能配合既有的服務部署方式。額外封裝通常需要處理更多結構，但實際耗用是否明顯，取決於要求大小、連線維持時間與實作效率。對短時間要求而言，建立連線的過程可能比持續處理資料更重要；對長時間下載而言，網路傳輸量與封包遺失通常更關鍵。因此不能據此排出適用於所有網路的固定順序，也不應把設定欄位較少等同於處理成本較低。

連線重用可以降低反覆建立連線的成本，但不一定能改善所有工作情境。多個要求共用底層連線時，會一同受到該連線狀態影響；若網路不穩，或某個資料流占用較多資源，其他要求也可能受波及。是否啟用應視核心支援、伺服器能力與工作類型而定，先記錄預設表現再進行比較。CPU 使用量也與加密方法、硬體指令、流量大小及記錄等級有關。單看某個程序短時間使用量上升，不能直接推論該協定不適合這部裝置。

影響 Android 實際耗電的因素

行動裝置的耗電不只來自加密運算，也包括無線網路介面的啟用時間、背景喚醒、連線重試與應用程式流量。訊號微弱時反覆重新連線，可能比正常資料處理更耗電。若啟用全裝置流量接管，原本不走代理的應用程式也可能進入處理流程；流量涵蓋範圍擴大後，不能再把電量差異全歸因於協定。系統的背景限制也可能中斷用戶端，導致重新連線與再次認證，表現為待機耗電增加、通知延遲，或解鎖後短時間內大量重新連線。

要進行有意義的比較，應固定裝置、網路類型、應用程式組合與使用時間，並區分前景傳輸和背景待機。先停止重複測速與高頻記錄，確認沒有持續重試，再比較不同設定。檢視系統電池統計時，也要一併查看螢幕、行動網路與目標應用程式的活動情況。若只更換協定，卻同時改變伺服器、傳輸方式與代理涵蓋範圍，結果只能反映兩套完整方案的差異，不能代表協定本身的耗電情況。比較 v2rayNG 與 v2flyNG 時也應遵循相同原則。

實際使用時，應先修正錯誤設定、無效重試與不必要的全流量接管，再考慮微調傳輸方式。日常瀏覽網頁與使用通訊應用程式時，參數正確且連線穩定的既有設定，通常比頻繁切換更容易評估。處理大型檔案時，則應另外觀察持續傳輸量與中斷後的恢復情況。若沒有可重現的測試條件，保留現有可用方案，比只憑單次截圖更換協定合理；若要排查特定錯誤，可參考常見問題，依故障階段逐項檢查。

Project V 生態中的分工

Project V 是理解此生態的起點，V2Ray 的設定模型與協定設計為後續工具奠定基礎。V2Fly 持續維護 V2Ray 相關實作；Xray 則從相關程式碼與技術基礎發展為獨立演進的核心專案。兩者保留不少相似概念，包括入站、出站、路由與 DNS，但功能集合和欄位模型會各自演進。不能把 Xray 簡化為 V2Fly 的版本升級，也不能視為兩者是可任意互換的同一套程式。實際相容範圍仍須逐項確認功能。

用戶端屬於另一個層次。v2rayN 為桌面使用者提供圖形化管理介面，實際協定處理由所使用的核心負責；v2rayNG 常見的使用方式以 Xray 能力為主；v2flyNG 則是 Android 上採用 V2Fly 核心的另一種選擇。選擇用戶端首先取決於平台與所需功能，而非單純的介面偏好。桌面版可優先從 v2rayN 開始；Android 需要 Xray 特有功能時，先確認 v2rayNG 是否符合需求；既有 V2Fly 設定則可檢查 v2flyNG 的相容情況。

共用的設定架構與各自的功能

inbounds 描述本機如何接收流量，outbounds 描述如何建立對外連線，routing 則決定要求要交由哪個出站處理。概念相近，不代表底下所有欄位都一致。傳輸設定、安全機制、流控選項與 DNS 行為尤其需要仔細確認。不能只因外層 JSON 看起來熟悉，就把 REALITY 等 Xray 連線功能直接移植到 V2Fly。部分欄位可能無法在另一種核心中解析，也可能有名稱相似但行為不同的設定。

路由資料資源也不是抽象地「裝上就會相同」。網域分類標籤與 IP 分類標籤取決於實際載入的資源內容；檔案遺失或標籤無法使用時，規則可能導致啟動失敗或無法達到預期。移轉時除了檢查 JSON，也要確認執行環境中的資源與路徑。相對路徑通常取決於用戶端啟動核心時的工作目錄，不能直接沿用另一部電腦上的絕對路徑。若資源由圖形化用戶端管理，應優先使用其提供的更新與設定入口，避免覆寫後無法確認實際載入的是哪一份資源。

判斷需要更新哪一層

介面無法辨識連結欄位時，通常應檢查用戶端的匯入能力；設定產生正常，但核心回報不支援選項時，應檢查核心能力；核心正常執行，卻找不到規則標籤時，應檢查資源檔案。這是三種不同問題。只更新圖形介面，不一定會更換核心；更換核心，也不一定能修正用戶端遺失欄位的問題。更新前請保留原始訂閱與可用設定；更新後先用一筆已知可用的設定驗證，再還原複雜規則。避免在同一次操作中同時更換核心家族、改寫訂閱並匯入整套新規則。

開放原始碼代表程式碼可供查閱，並可依相應授權使用，不代表兩個專案會永遠採用相同的設定格式。選擇時應考慮所需功能、用戶端支援與維護方式，而非認定某個家族適用所有情境。若要了解設定檔各部分的用途，可繼續閱讀Xray 設定檔結構解析；若要更換裝置安裝套件，請回到下載頁，依作業系統與處理器選擇，不要混淆核心概念與安裝套件架構。

單筆分享連結與連結集合

分享連結用來描述一筆伺服器設定，常見前綴包括 vmess://、vless://、trojan:// 和 ss://。這些連結的內部格式並不完全相同。常見的 VMess 分享格式會將 JSON 內容編碼；VLESS 與 Trojan 通常透過 URL 的使用者資訊、位址和查詢參數描述設定。Shadowsocks 也有不同時期的格式。用戶端匯入時，必須先辨識協定前綴，再依相應規則解析，不能把一種連結的解碼方式直接套用到另一種。

訂閱網址是取得一組設定的入口，本身不是某個伺服器位址。常見訂閱回傳多行分享連結，或回傳以 base64 編碼的連結集合。base64 是編碼方式，不是加密，也不是代理協定；成功解碼只表示取得文字，還要確認文字格式是否受用戶端支援。換行、字元編碼與 URL 編碼都可能影響解析。複製訂閱時，請使用服務提供者給的完整網址，避免混入頁面標題、說明文字、不可見空格，或郵件工具自動加入的換行。

原生 JSON 與用戶端管理的設定

Xray 原生 JSON 可描述整套執行行為，包括多個入站、出站、路由與 DNS。它不是一組分享連結的另一種呈現方式。單筆分享連結通常只包含遠端連線所需的主要欄位，不會涵蓋完整的本機監聽與複雜分流邏輯。因此，把原生設定轉成連結時，可能會遺失全域行為；匯入連結後產生的設定，則會疊加用戶端本身的預設入站與路由。兩種結果可能都能連線，但實際處理的流量範圍、DNS 路徑與規則優先順序並不相同。

用戶端自己的設定檔也可能包含群組、顯示名稱、視窗狀態與測速偏好，這些都不是核心通用格式。移轉前應先確定要保留的是遠端參數，還是整套用戶端環境。若只想將一部伺服器移至另一部裝置，使用該用戶端可辨識的分享格式通常更直接；若要保留複雜規則，則需另外記錄路由與 DNS，不能期待分享連結會自動包含這些設定。匯入完整自訂設定時，也要確認用戶端是否仍會接管系統代理與連接埠設定，避免誤以為介面上的所有開關都能覆蓋自訂內容。

格式轉換與更新的限制

轉換只能重新排列已有資訊，無法補上缺失的伺服器名稱、公鑰類資料、短識別碼或傳輸路徑。轉換工具輸出合法 JSON，不代表欄位語意正確，更不代表目標核心支援該組合。較新的傳輸欄位可能被舊解析器直接忽略；匯入後，介面仍可能顯示正常的伺服器項目。遇到這種情況，應比對原始參數與匯入後的詳細設定，而不是以「清單中看得到名稱」就認定相容性問題已解決。

訂閱更新通常會重新產生由訂閱管理的項目，手動修改可能在下次更新時被覆蓋。需要測試時，可將設定複製成獨立項目，並保留原訂閱群組；具體複製與分組方式依用戶端介面而定。更新後出現重複名稱，不一定代表同一個端點，也可能是位址、傳輸方式或使用者參數不同。清理前先比較重要欄位，再刪除項目。若群組突然變空，先檢查回傳內容與格式，不要連續執行刪除、重建和清空所有設定。

完整排查順序如下：確認訂閱入口可連線、確認回傳文字格式符合預期、確認用戶端能辨識協定、確認重要欄位仍保留，最後再測試核心連線。格式問題與遠端認證問題應分開記錄。若想了解不同格式的結構及互轉限制，請閱讀base64 訂閱、原生 JSON 與分享連結的差異。本頁不提供線上轉換表單；請在可信任的本機工具與用戶端中處理敏感設定，避免為了轉換格式而增加資訊外洩風險。

系統代理與 TUN 的涵蓋範圍

系統代理提供應用程式使用的代理入口，只有會讀取相關設定的應用程式才會依預期使用它。有些程式採用自己的網路堆疊或獨立代理設定，因此瀏覽器能連線，不代表所有程式都走相同路徑。TUN 模式透過虛擬網路介面接收流量，涵蓋範圍較廣，但也會增加路由、權限與 DNS 等條件。它並非更換代理協定，也不會自動修正遠端參數。若協定認證失敗，啟用 TUN 只會改變流量進入用戶端的方式，無法讓伺服器接受錯誤帳戶。

在 v2rayN 中，「自動設定系統代理」與「啟用 Tun 模式」應依工作需求選擇，不要預設同時開啟所有流量接管方式。先透過系統代理測試一個會遵循系統設定的應用程式，再視需要測試 TUN，可減少變因。Windows、macOS 與 Linux 在權限、虛擬介面及系統網路設定方面各有差異，請以用戶端和作業系統的提示為準。Android 用戶端則透過系統提供的虛擬網路接管功能運作；請確認相關授權與背景執行狀態，並避免多個同類接管程式爭用同一入口。

規則順序、出站標籤與網域解析

路由規則通常依序比對，由最先符合的規則決定出站。精確規則應排在寬泛規則之前，出站標籤則必須與實際定義相符。domainStrategy 控制路由比對時如何處理網域與 IP 的關係，不等同於瀏覽器的全部 DNS 行為。IPIfNonMatch 表示網域規則未符合時，可能繼續以解析取得的 IP 嘗試比對。它不會自動建立任何地理分流規則，也不保證所有網域都會依預期分類；實際效果取決於既有規則與解析結果。

以下是可放入 Xray 原生設定 routing 欄位的 JSON 物件片段，並非完整執行設定。它會將本機迴圈位址導向名為 direct 的出站，其餘 TCP 與 UDP 流量則導向名為 proxy 的出站。使用前必須先定義這兩個出站，且代理出站需支援實際要求使用的網路類型。此範例只示範規則順序與標籤，不取代完整的區域網路例外、DNS 策略或虛擬介面防迴圈設定，也不應覆蓋用戶端自動產生的整套路由。

{
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "ip": ["127.0.0.0/8", "::1/128"],
      "outboundTag": "direct"
    },
    {
      "type": "field",
      "network": "tcp,udp",
      "outboundTag": "proxy"
    }
  ]
}

DNS、UDP 與故障判斷

網域解析可能由應用程式、作業系統或核心執行，處理路徑不同，會影響路由能取得哪些資訊。若應用程式已自行解析成 IP，核心不一定還能直接套用原始網域規則；流量嗅探也有能力與適用範圍限制，不能視為必定能還原網域的機制。設定 DNS 時，應先釐清由誰發出查詢、查詢經過哪個出站，以及由誰使用解析結果。若解析必須經過代理，而代理本身又需先解析伺服器位址，就可能形成循環依賴；因此要為遠端入口保留明確可用的解析路徑。

UDP 也需要本機入口、核心、協定實作與遠端服務共同支援。網頁可正常使用，但某個即時應用程式失敗，可能是 UDP 轉送條件不符，也可能是路由未涵蓋；不能只憑協定名稱判定一定可用。測試時先確認失敗的應用程式是否進入用戶端，再確認使用的網路類型與實際命中的出站。若遠端連線穩定，但只有部分網域失敗，優先檢查規則與 DNS；若所有應用程式都無法進入核心，則先處理本機入口。更多規則語法請參考自訂路由規則與比對優先順序。

桌面版與 Android 的選擇方式

桌面版優先選用 v2rayN，再依 Windows、macOS 或 Linux 選擇相應的安裝入口。Windows 的 Desktop 與傳統 WPF 介面屬於用戶端形式差異，不是兩種代理協定；macOS 須區分 Apple Silicon 與 Intel，Linux 則須符合處理器和套件格式。這些選擇決定程式能否正確安裝與執行，不會決定遠端協定是否可用。安裝後仍須檢查核心與匯入參數。套件下載入口請以下載頁為準，不要從協定教學中的示意名稱推斷安裝檔案。

Android 首先要確認設定依賴哪一類核心功能。需要 Xray 相應功能時，以 v2rayNG 為主要選擇；若已有明確採用 V2Fly 的設定與維護流程，可評估 v2flyNG。不要只因名稱相似，就在兩款用戶端之間匯入所有應用程式設定，尤其是自訂 JSON 與路由資源。處理器架構與協定無關，現代裝置常見 arm64，但仍應以系統實際架構與安裝結果為準。選用通用套件也無法修正核心不支援的協定組合；架構與功能是兩條獨立的檢查方向。

既有穩定服務與新方案評估

已有穩定服務時，先保留目前的協定，並確認它符合所需的應用程式與網路類型。移轉理由應是明確的功能需求、裝置相容問題或維護困難，而非只是協定名稱不同。若伺服器只提供 VMess，用戶端改選 VLESS 也無法建立相容連線；只有在伺服器提供多種組合時，才能在相同目標與網路條件下比較。先確認每種組合都能正常認證，再比較首次回應、持續傳輸與背景穩定性。讓失敗的設定參與測速，只會把設定錯誤混進效能結論。

評估新方案時，可簡要記錄以下資訊：用戶端、實際核心、代理協定、傳輸方式、安全機制、流控欄位、DNS 與流量接管模式。每次只調整一個層次，並保留一筆已知可用的設定。若需長時間在背景執行，請著重檢查斷線恢復與系統背景限制；處理大量短時間要求時，請關注連線建立與重用；持續傳輸時，則要觀察傳輸量、資源耗用與中斷後的恢復情況。不同工作可能適合不同選擇，不必用單一指標概括所有情境。

依錯誤發生階段回到相應章節

匯入時就提示格式無效，請回到第六章檢查連結與訂閱格式；儲存後核心無法啟動，請回到第五章檢查支援範圍與欄位結構；入口可連線但握手失敗，請回到第二、三章檢查認證與安全設定；只有部分應用程式失敗，請回到第七章檢查流量接管、路由與 DNS；連線可用但耗電異常，請回到第四章排除持續重試與高頻測試。依此順序檢查，比不斷切換協定更容易重現問題，也能在保留敏感資訊的前提下準確描述故障。

最後可用四項條件來決定：伺服器確實提供、用戶端能完整呈現、核心明確支援，而且已在實際情境中驗證。符合這些條件後，再考慮管理習慣與資源表現。首次操作請依照快速上手完成匯入、連線與驗證；若要比較三款用戶端，請閱讀選型指南；遇到特定問題時，請查閱常見問題。本手冊用來說明這些選擇背後的技術界線，不提供不考慮伺服器條件的通用協定排名。