Shadowrocket 協定參考

01 / Connection Model

連線模型：先區分四層參數

選擇協定的首要原則是與服務端設定一致，而不是從名稱推測效能。Shadowrocket 中的一筆連線通常會描述伺服器位址、身分驗證、傳輸方式及安全設定；規則則決定哪些要求交由這筆連線處理。任何一層不相符，都可能導致連線逾時。開始修改前，請先保留目前可用的設定，並確認資訊來自自己已有的服務商或自行管理的伺服器，避免憑印象補填欄位。

協定、傳輸與 TLS 並非同一項

Shadowsocks、VMess、VLESS 和 Trojan 採用不同的協定機制；TCP、UDP、WebSocket 則涉及資料承載方式；TLS 負責特定連線層的加密與身分驗證。一筆設定可以同時包含協定名稱、WebSocket 和 TLS，並非要從三者中擇一。請依照取得的連線資料逐層對應；啟用 TLS 不代表可以忽略協定認證，填入 UUID 也不表示傳輸層設定必然正確。

位址與名稱也各有用途。Server 通常決定用戶端要連往何處，Port 指定要連線的服務連接埠，SNI 則是在 TLS 交握時提供伺服器名稱。WebSocket 的 Host 是 HTTP 要求資訊，Path 指向伺服器指定的路徑。這些欄位有時剛好相同，有時則刻意不同，並非可以互換的備用輸入欄位。連線資料未要求的欄位，請保留匯入值或預設值，不要一律填成伺服器位址。

Global Routing 決定流量是否進入連線

Global Routing 的 Config 會依目前設定檔比對規則，Proxy 會將納入用戶端處理範圍的流量交由代理策略處理，Direct 則用於直接連線。這三種模式改變的是路由選擇，不會變更服務端協定。若切換至 Proxy 後可以連線，切回 Config 卻失敗，應先檢查規則及實際命中的策略，而非立即重建伺服器設定。反之，在 Direct 下連線成功，也不能證明代理連線已建立。

DNS 是貫穿各層的前置條件。用戶端可能要先解析伺服器網域名稱，目標網站也可能有獨立的解析流程。伺服器網域名稱解析失敗時，認證尚未開始；目標網域解析錯誤時，連線設定本身仍可能正常。因此，應區分「找不到伺服器」與「透過伺服器連線至特定目標失敗」，保留錯誤涉及的網域及發生階段，不要把所有解析問題都歸因於協定不相容。

iPhone 與 iPad 上的實際表現也會受到無線訊號、網路切換、背景工作及伺服器負載影響。低延遲只表示特定測試的往返耗時較短，不代表大型檔案的傳輸量更高；一次快速載入也無法證明待機時更省電。比較協定時，請使用同一部裝置、相同網路、相近時段及相同目標，並記錄是否啟用額外傳輸層，否則結果難以重現。

本頁說明欄位用途及驗證順序，不取代服務端設定說明。匯入後若出現文中未列出的擴充選項，請先確認目前的服務端是否需要，再進行修改。不同傳輸組合可使用的欄位並不相同，請以 App 內實際顯示的項目為準。儲存時一次只調整一組相關參數，並記下原值，才能在下次測試時判斷變化來自哪一層。

02 / Shadowsocks

Shadowsocks：配對加密方法與密碼

Shadowsocks 的設計目標是透過較少的協定互動完成代理轉送，並結合加密與資料傳輸。它不是完整的裝置組網協定，也不會以憑證名稱識別使用者。對用戶端使用者而言，最基本的設定是位址、連接埠、加密方法與密碼都必須對應服務端。同名的伺服器設定不一定共用這些值；尤其服務端更換連接埠或認證資料後，舊設定可能仍在，但已無法使用。

Method 決定密碼如何參與連線

Method 並非可任意調整的效能選項。不同方法會規定金鑰衍生、資料封裝及完整性驗證方式，用戶端與服務端必須相容。現代的認證加密方法可以同時保護資料並偵測竄改，但不代表任何一種方法都適用於所有服務端。請逐字核對提供的加密方法，不要因為名稱屬於相同演算法系列就擅自替換，也不要以「名稱較長應該更安全」為由自行選擇。

Password 也必須依原值填寫。複製時容易帶入空格、換行或外觀相近的字元；某些協定變體的金鑰有特定編碼與長度要求，不能當成一般文字密碼重新輸入。若連結匯入後顯示的密碼較長，請保留原有格式，不要轉換大小寫或手動刪除尾端符號。需要再次確認時，請透過既有資料的管理入口核對，避免將完整密碼貼到截圖或公開討論中。

常見的 AEAD 方法包括 AES-GCM 與 ChaCha20-Poly1305 系列。其運算成本與裝置硬體指令、實作方式及流量型態有關，因此不能只憑演算法名稱就斷定哪一種在 iPhone 上一定更省電。持續傳輸時，處理器效率可能影響吞吐量；零星存取時，喚醒次數與無線電活動時間可能更重要。只有在服務端同時提供相容選項時，比較演算法才有實際意義。

TCP 可用不代表 UDP 也可用

Shadowsocks 可以承載不同類型的目標流量，但 UDP 轉送是否可用，仍須服務端、用戶端設定及目前網路共同支援。網頁通常可透過 TCP 建立連線，部分即時應用則仰賴 UDP；因此「網頁開得了，另一個 App 卻仍無法使用」並不矛盾。請先確認該服務是否需要 UDP，再查看現有服務是否允許轉送，不要以網頁載入結果取代 UDP 的個別驗證。

若連線資料還包含額外的外掛程式或傳輸參數，它們也是完整連線的一部分。基礎協定名稱相同，不代表可以刪除帶有額外封裝的設定後繼續使用。同樣地，不要主動為一般設定加上未要求的 TLS、Host 或 Path。增加欄位只會帶來更多比對條件，不會自動修正位址錯誤、密碼失效或連接埠無法連線等問題。

在 iPhone 上如何判斷是否值得保留

若目前的 Shadowsocks 設定已能穩定處理日常需求，只因協定名稱看起來更複雜而更換，未必能帶來好處。可先記錄冷啟動存取、持續傳輸及鎖定螢幕後恢復這三種情況：首次存取主要觀察連線建立，持續傳輸觀察穩定吞吐量，恢復測試則觀察系統網路變化後能否重新連線。各項測試要回答的問題不同，不宜合併成單一的「速度分數」。

發生失敗時，請先確認伺服器網域名稱是否能解析、連接埠是否正確，再核對 Method 與 Password，最後檢查 UDP 或額外傳輸需求。若同一筆設定在相同網路下對所有目標都失敗，應優先檢查服務入口及認證；若只有特定目標異常，再檢查規則、目標解析及服務端至目標的路徑。逐層縮小範圍，比不斷更改加密方法更容易得到可重現的結果。

維護訂閱匯入的設定時，也要區分訂閱更新與手動修改。更新可能覆寫服務商維護的欄位，也可能新增名稱相近的項目。測試前請確認目前選取的確實是剛核對過的連線，避免修改甲設定卻測試乙設定。若要長期保留自訂設定，請先確認 App 內該類項目的更新行為，並保留原始連線資料以便還原。

03 / VMess · VLESS

VMess 與 VLESS：分別核對認證與承載

VMess 與 VLESS 常會搭配不同傳輸方式使用，但不能將兩者視為可互換的名稱。VMess 有自身的認證與資料保護機制；VLESS 則著重簡化協定本身，將安全保護交由配套的安全層處理。兩者代表不同的設計取捨，並非單純的速度升級關係。服務端使用哪種協定，用戶端就應選擇相應類型；不能只保留 UUID 就切換協定名稱。

UUID 是身分資料，不是完整設定

UUID 常用來識別連線身分，但正確的 UUID 只代表認證資料的一部分。Server、Port、傳輸類型及相關安全選項仍須相符。匯入失敗後，若只重新輸入 UUID，卻保留錯誤的 WebSocket Path，連線結果不會改變。也不要借用其他項目的 UUID 進行測試，因為不同使用者身分可能對應不同權限、有效狀態或服務入口。

VMess 的認證流程會受到時間因素影響，裝置時間明顯偏差可能造成連線失敗。排查時可在系統的日期與時間設定中確認是否啟用自動校時，並檢查時區或手動時間是否有誤。時區顯示不同本身不代表系統時間錯誤，重點是實際時間是否正確。不要反覆更改舊的認證欄位來補償時間問題，應先讓裝置與服務端的時間基準恢復正常。

VLESS 本身不提供與 TLS 相同的傳輸加密保護，因此「認證通過」不代表連線鏈路已獲得充分保護。請使用現有服務明確指定且用戶端支援的安全組合。若資料要求 TLS，就必須核對名稱驗證與憑證鏈；若包含其他專用安全參數，也應逐項依資料設定。不要因為 App 允許欄位留白，就推定該組合適合實際網路環境。

WebSocket 的 Host 與 Path 各有用途

WebSocket 常用來以指定的連線承載方式傳輸資料，建立連線的過程可能經過 HTTP 要求、TLS 或反向代理。Host 可協助入口識別要求的對象，Path 則區分服務端路徑，兩者都不是裝飾欄位。Path 通常區分大小寫，開頭的斜線與查詢部分也可能有意義；請勿擅自簡化從資料複製的內容。若收到網頁或一般 HTTP 錯誤內容，通常應先檢查入口路由，而非 UUID。

部分連線資料還會涉及特定流量控制或多工行為，通常受服務端實作、協定類型及傳輸組合共同限制，不應直接套用到其他設定。尤其不要在網路上找到某個欄位名稱後，就直接加到不同組合中，這可能使原本可用的設定失效。是否設定，應以目前的 App 是否提供該欄位，以及服務端是否明確要求為前提，而不是看欄位名稱是否聽起來先進。

如何觀察額外封裝的成本

在行動網路上，額外交握可能影響首次存取，但長連線建立後，後續流量會攤平這部分成本。傳輸經過的入口、路徑長度及服務端負載，也可能比協定標頭開銷影響更大。因此比較 VMess 和 VLESS 時，應盡可能使用相同服務入口與傳輸組合；若連伺服器位置都不同，測出的差異就不能歸因於協定本身，更不能套用到其他使用者。

建議依「類型與身分、傳輸參數、安全參數、裝置時間」的順序複查，並使用相同目標重複測試。若更新訂閱後欄位有所變動，請先確認變化是否來自資料更新，再考慮還原舊值。逾時與校時的詳細排查順序，請參閱連線失敗的三步排查；尚未找出問題階段前，不要同時修改多個層級。

04 / Trojan · TLS

Trojan 與 TLS：先完成伺服器身分驗證

Trojan 的設計是在 TLS 連線中進行代理認證與資料傳輸，利用成熟的安全傳輸機制保護通訊。設定時須同時符合兩組條件：TLS 連線必須正確建立，接著協定密碼也須獲服務端接受。密碼正確無法修復憑證名稱不符；TLS 交握成功也不代表 Trojan 認證已通過。將這兩個階段分開，是理解這類連線錯誤的關鍵。

Server、SNI 與憑證名稱的關係

Server 表示連線的網路入口，SNI 是用戶端在交握時傳送的名稱資訊，憑證則用來證明伺服器身分。部分部署的入口位址與憑證網域不同，因此既有資料會另外指定 SNI。此時請保留資料中指定的對應關係，不要為了看起來一致就把所有名稱都改成入口位址。憑證驗證會檢查預期的身分，不能只因某個位址連得上就省略驗證。

使用 IP 位址作為入口時，更要留意名稱驗證。若憑證是簽發給網域名稱，並不代表也涵蓋該 IP 位址；請依服務端提供的名稱設定連線，不要自行猜測。反過來，也不能隨意填入熟悉的網域名稱作為 SNI，因為入口未必提供該名稱的服務。名稱錯誤可能在認證前就中止連線，此時繼續修改 Password 通常沒有幫助。

憑證驗證也取決於憑證鏈、有效期限及裝置的信任狀態。系統時間明顯錯誤，可能使原本有效的憑證顯示尚未生效或已過期；伺服器未正確提供中繼憑證，也可能導致不同裝置的結果不一。排查時請記下錯誤指出的名稱及驗證階段，再請伺服器管理方核對憑證部署。不要把長期略過憑證驗證當成一般修復方式，這會削弱對伺服器身分的確認。

Password 與 ALPN 各自的用途

Password 是協定認證資料，必須與目前服務端設定完全一致。它與 TLS 憑證私鑰並非同一項資料，也不應填入 SNI、Host 或 Path。複製後請確認字元完整，但不要為了排除輸入問題而在公開紀錄中顯示原值。若需他人協助，只要說明欄位是否已核對，以及錯誤發生在哪個階段，並遮蔽完整認證資料。

ALPN 用於協商 TLS 內的應用層協定。某些部署會明確要求協商結果，其他部署則採用預設行為。它不是所有連線都需要手動設定的加速開關，也不能靠任意新增協定名稱來提高相容性。若現有資料指定 ALPN，請保留其順序與內容；若資料未指定且匯入值為空，請先維持原狀，只有確認服務端需求後再調整。

交握、耗電與連線重用

TLS 首次交握需要網路往返與加密運算，但不能因此認定 Trojan 在 iPhone 上一定更耗電。持續連線可以分攤交握成本，裝置對密碼演算法的支援也會影響處理效率。實際耗電還與弱訊號下的重傳、頻繁切換網路及不斷重建連線有關。比較時請區分偶發存取與持續傳輸，不要用一次啟動耗時推斷整天的耗電表現。

若小型要求正常、大型檔案卻經常中斷，請檢查鏈路品質、逾時及可能的 MTU 問題；若所有要求都在建立階段失敗，應先檢查入口與 TLS。若只有特定網域異常，還要確認 Global Routing、規則與目標解析。協定具備安全層，不代表之後所有業務問題都與憑證有關，仍應依錯誤發生位置逐步縮小範圍。

維護時建議保留原始匯入設定，再複製一份進行受控測試。伺服器更換憑證或入口後，應優先確認既有資料是否同步更新，不要累積多筆略過驗證的設定。確認連線恢復後，請刪除不再需要的測試副本，避免誤選名稱相近的項目。購買及系統相容性資訊仍應透過App Store 正版核驗說明的對應入口確認，與協定設定無關。

05 / HTTP · SOCKS5

HTTP 與 SOCKS5：代理能力不等於加密能力

HTTP 代理與 SOCKS5 的設計目的，是讓應用程式透過中介伺服器存取目標資源，與面向裝置組網的通道有明顯差異。HTTP 代理主要處理 HTTP 要求與連線通道；SOCKS5 則提供較通用的目標位址及連線要求。選用時應先確認既有伺服器實際提供哪種服務，再確認是否搭配安全傳輸；支援代理不代表用戶端到代理伺服器的鏈路已加密。

HTTP 代理中的 CONNECT

HTTP 代理可處理一般 HTTP 要求，也能透過 CONNECT 要求建立通往目標的位元組通道。目標網站使用 HTTPS 時，網站內容通常由用戶端與目標之間的 TLS 保護；但這與用戶端到代理伺服器之間是否另有 TLS，是兩回事。代理伺服器仍會取得連線目標等資訊，因此不能只看網址列顯示 HTTPS，就判定代理入口的認證及中繼資料傳送方式。

若伺服器提供的是含 TLS 的 HTTP 代理入口，用戶端必須依該入口要求選擇相應的安全設定。將一般 HTTP 代理設定直接指向要求 TLS 的連接埠，或反過來設定，都可能在協定協商階段失敗。連接埠號碼並無通用保證，相同號碼可能用於不同服務；請依明確的伺服器資料設定，不要根據常見連接埠猜測協定類型。

是否必須填寫 Username 與 Password，取決於代理服務的認證要求。欄位留白可能表示服務不要求這組認證，也可能只是匯入資料不完整，不能逕自判斷。若出現認證相關錯誤，請先確認帳號是否屬於目前入口、字元是否完整，以及該認證方式是否受目前組合支援。不要將網站登入密碼填入代理認證欄位，兩者的身分範圍不同。

SOCKS5 的連線與 UDP 範圍

SOCKS5 可表示目標網域名稱或 IP 位址，並支援不同指令，其中 UDP 轉送通常會用到 UDP ASSOCIATE。協定規範支援此功能，不代表每部服務端都會開放，也不代表所有接入網路都能使用。實際測試時，請確認伺服器允許 UDP、用戶端設定支援目前用途，並檢查防火牆及回傳路徑。不能只憑 SOCKS5 這個名稱，就斷定即時服務一定可用。

SOCKS5 常見的認證機制不等於加密機制。即使伺服器要求使用者名稱與密碼，仍須另外評估用戶端到入口之間的傳輸保護。目標應用程式本身的 TLS 可以保護相關服務內容，卻不能取代對代理入口的信任判斷。若既有服務要求透過可信任的內部網路存取，請遵守這項範圍限制，不要將僅供內部用途的代理位址用於不符合設計條件的環境。

由誰解析網域名稱，須視實際設定而定

代理要求可能帶有網域名稱，也可能使用用戶端已解析的位址，實際行為取決於應用程式、規則及 DNS 設定。因此遇到內部網域或分區解析問題時，不要只更換 HTTP 與 SOCKS5 類型。請先確認網域名稱應在哪種網路環境解析、解析結果是否適用於服務端，再核對實際要求路徑。入口可連線但內部網站無法使用，可能是解析或存取權限問題，而非認證失敗。

在 iPhone 與 iPad 上，這兩種協定的速度表現也不能脫離環境判斷。簡單的交握可能降低部分短連線成本，但主要體驗仍取決於目標距離、代理伺服器效能與網路品質。適用情境是已有明確可用的代理服務、認證與安全條件已知，且業務類型符合服務能力；不能只因設定欄位較少，就將它們當成所有連線的替代方案。

驗證時請先選擇一個允許存取的固定目標，檢查認證與 TCP 轉送，再測試其他需要的服務。若只有內部資源無法使用，請向現有服務管理方確認權限、目標解析及存取範圍。保存診斷資訊時，只記錄狀態與目標類型，不要附上完整帳號或內部位址清單。選擇協定決定用戶端如何與入口通訊，不會自動取得原本不存在的資源存取權限。

06 / WireGuard

WireGuard：一併理解金鑰、位址與路由

WireGuard 用於加密 IP 通道，設計重點是以精簡的密碼套件及對等端模型進行通訊。它與逐一連線至目標的代理協定不同，因此設定中除了伺服器入口，還會包含本機通道位址、金鑰及路由範圍。選用 WireGuard 並非將某個 Password 換成另一種寫法，而是需要一組由服務端配置、彼此對應的通道參數。

Private Key 與 Public Key 的配置方向

用戶端的 Private Key 用於證明本端身分；服務端對應設定中會保存用戶端的 Public Key。用戶端設定中的對端 Public Key 則用來識別伺服器。若將這兩種公鑰的位置對調，即使位址與連接埠正確，也無法完成預期交握。Private Key 是敏感認證資料，不應出現在公開截圖、記錄附件或求助內容中；重新建立前，請先確認是否需要同步修改服務端設定。

部分設定還會提供 Preshared Key，在既有金鑰交換之外再加入一項共享密鑰。只有服務端要求且已設定相同值時才填寫，不要自行產生新值並期待伺服器接受。若服務端沒有此項要求，維持資料原狀即可。金鑰長度、編碼與字元都有特定結構，不能手動刪改，也不能將外觀相似的金鑰視為可替換的密碼。

Address、Endpoint 與 Allowed IPs

Address 是配置給本端的通道位址，Endpoint 則是用來聯絡對端的網路位址與連接埠。前者位於通道內部，後者用於外部連線，兩者不可互填。多部裝置通常需要各自的身分與位址配置；若將同一組用戶端金鑰複製到多部裝置，服務端觀察到的端點可能不斷變動，導致裝置彼此干擾。請使用既有服務為各裝置配置的資料。

在 WireGuard 模型中，Allowed IPs 會參與對等端路由選擇，也會限制該對等端可接受的來源位址範圍。它不是網站網域清單，更不能使用 DOMAIN-SUFFIX 語法填寫。Shadowrocket 的 Global Routing 與設定規則位於另一層；填入範圍廣泛的通道路由，不代表所有服務都必然經過該通道。應分別驗證 App 如何將要求交給連線項目，以及通道如何處理 IP 封包。

DNS 選項用來指定相應的解析行為，但是否套用至某類查詢，還取決於用戶端整體的 DNS 設定。連線成功後只能存取 IP、無法使用名稱時，請檢查 DNS 是否可連線及相關規則，不要立即重建金鑰。若通道內有私人位址網段，也應檢查是否與目前 Wi-Fi 區域網路衝突；位址重疊可能使要求送往錯誤介面，看起來像目標伺服器沒有回應。

MTU 與 Persistent Keepalive 的取捨

WireGuard 通常透過 UDP 傳送通道資料。額外封裝會占用封包空間；若 MTU 不符合實際路徑，可能出現小型要求正常、大量傳輸卻停滯的情形。MTU 不是越大越快，也不是越小越穩定；調整時應有明確症狀並能重複測試。優先採用服務端提供或已驗證的設定，記下原值後再小幅調整，避免同時變更 DNS、路由及 MTU。

Persistent Keepalive 用於在有需要時維持網路位址轉譯設備中的對應狀態。它可能改善某些閒置後的連線可達性，但定期傳送資料也會增加行動裝置的網路活動。並非所有用戶端情境都需要主動設定，間隔較短也不代表一定更可靠。請依現有服務要求及實際閒置斷線情況判斷，不要將它視為通用的省電或提速設定。

WireGuard 的精簡設計有助於降低部分處理成本，但行動裝置耗電仍取決於流量、重傳及保活機制。Wi-Fi 與行動網路切換後，端點變化也可能與網路策略有關。排查時請依序核對金鑰方向、Endpoint、通道位址、路由範圍及 DNS；只有出現與封包大小相關的症狀時，才優先測試 MTU。若主要需求是存取既有私人網路，請先確認服務端允許的網段，不要一味追求涵蓋範圍越廣越好。

07 / Hysteria2

Hysteria2：UDP 路徑與頻寬設定

Hysteria2 建立於 QUIC 等機制之上，針對延遲、封包遺失及頻寬變化等網路條件設計傳輸策略。它與主要仰賴 TCP 的連線有不同取捨，但不能因此推論「任何網路都更快」。首先，目前的接入網路必須能連線至服務端所需的 UDP 入口；其次，認證、安全及頻寬相關設定必須相符。入口無法連線時，調整 App 內的速度預期並無幫助。

先確認 UDP 入口，再檢查認證

Server 和 Port 應指向既有資料指定的實際入口。部分網路允許一般網頁連線，卻會限制其他 UDP 流量，因此網頁可直接連線不代表 Hysteria2 入口也可連線。若同一筆設定在 Wi-Fi 可用、行動網路卻不可用，請保留認證設定，先比較網路路徑。不要每次切換網路就重新產生密碼，否則會混淆網路與認證問題。

認證資訊必須依目前服務端要求填寫；若同時提供額外的混淆設定，混淆與登入認證仍屬不同層級。混淆類型、相關密碼及是否啟用都必須成組相符，不能只開啟用戶端選項。缺少任何必要項目，都可能讓連線在更早階段失敗。匯入後若看到兩個用途不同的密碼欄位，不要為了方便管理而將它們改成相同內容。

TLS 名稱與憑證驗證原則與前文相同。伺服器入口使用某個位址，不代表憑證也涵蓋該位址；請保留服務端指定的 SNI。QUIC 使用 UDP，不代表可以忽略 TLS 身分驗證，也不表示所有交握失敗都是網路封包遺失。仍須分別排除時間、名稱、憑證鏈及認證錯誤；錯誤發生階段比籠統描述「逾時」更有診斷價值。

頻寬欄位不代表實測保證值

Hysteria2 的頻寬相關設定可能影響傳送行為及壅塞控制選擇，具體效果取決於服務端及 App 提供的選項。請區分上行與下行，並確認輸入單位。直接填入電信業者宣稱的接取頻寬、無線連線速率或單次測速峰值，並不代表實際路徑能持續達到該速度。填入遠高於實際鏈路的數值，可能造成更多封包遺失、重傳及抖動，反而影響互動要求。

上行頻寬尤其容易被忽略。下載時仍須傳送確認與控制資訊；若上行頻寬被背景工作占滿，即使下行容量充足，使用體驗仍可能變差。請在網路較空閒時測試，並留意是否同時進行背景同步。若服務明確支援自動處理或提供建議值，請優先依其要求設定，不要把手動指定頻寬當成所有情境都必須完成的最佳化步驟。

分別觀察吞吐量、延遲與耗電

較積極的傳輸策略可能有助於部分不穩定鏈路維持吞吐量，但持續傳送封包、封包遺失復原及使用者空間處理也會消耗資源。在 iPhone 上，較快完成下載有時能縮短無線電活動時間；若網路持續遺失封包，額外重傳則可能增加發熱與耗電。這些影響方向不同，不能只憑協定名稱下結論。請同時記錄任務完成時間、互動穩定性及裝置狀態。

測試大型檔案時，不要只看開始幾秒的峰值。先確認連線能否持續完成任務，再觀察下載期間的一般網頁或其他互動是否明顯受影響。若吞吐量提高但所有短要求都變慢，可能是佇列累積或鏈路已滿，應調整測試條件與頻寬預期。行動網路的可用容量會隨訊號變化，同一個固定值未必適用於所有地點。

若小型要求可用、大量傳輸卻停滯，請繼續檢查封包大小、網路封包遺失、頻寬設定及服務端資源；若完全無法建立連線，則應回頭檢查入口與安全層。若只在某個接入網路失敗，使用相同設定切換網路驗證，比連續修改參數更有意義。最後保留的應是能穩定完成實際工作、設定來源明確且結果可重現的組合，而不是某次測試中瞬間數值最高的組合。

08 / Selection · Diagnostics

選用與排查：在相同條件下驗證結果

實際選用應從既有服務支援的組合開始。若只有一個可用入口，重點是正確設定；若有多個由自己既有服務提供的選項，才適合比較協定。請優先滿足業務所需的 TCP、UDP、私人網段及安全條件，再比較連線穩定性與操作成本。不要為了少填一個欄位而放棄必要的身分驗證，也不要為了使用某個協定名稱而加入服務端不支援的封裝。

依業務需求縮小選擇範圍

日常瀏覽網頁與使用 App 時，應留意首次連線、持續可用性及網路切換後的恢復情況；持續傳輸則應觀察吞吐量及多工時的互動表現；存取既有私人網路時，則要確認位址配置、目標網段及 DNS。需要 UDP 的服務應另外驗證轉送能力。不同業務可能適用不同組合，但前提都是服務端已提供並允許使用該功能；用戶端無法自行補足缺少的能力。

透過規則確認測試要求的路徑

測試前請確認 Global Routing 選擇 Config，並確認目前啟用的是準備修改的設定檔。以下片段僅示範規則比對，不包含任何伺服器資料；PROXY 必須對應目前設定中的有效代理策略。請將特定網域放在範圍較廣的規則之前，最後以 FINAL 處理其餘流量。若希望其他要求直接連線，請依自身需求調整末尾策略，不要直接照抄。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,api.example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

規則會由上而下比對，第一個符合的項目決定後續路徑；GEOIP 判斷的是 IP 位址所屬範圍，不是依網站顯示語言推測所在地。上述保留網域僅用來說明語法，不是速度測試目標。正式驗證時，請使用自己有權存取且結果穩定的實際資源，並在連線記錄中核對命中的策略。更詳細的寫法請參閱規則關鍵字與比對範圍；只代理部分網站可參考指定網站分流說明。

依錯誤發生階段排查

第一階段是入口解析與連線：確認 Server、Port 及目前網路，再核對伺服器網域名稱是否解析為預期位址。第二階段是安全與認證：依協定檢查憑證名稱、裝置時間、密碼、UUID 或金鑰。第三階段是服務與路由：檢查規則、DNS、UDP、目標權限及大型封包傳輸。若尚未進入認證階段，不要重建身分資料；若入口已建立，也不要只盯著連接埠反覆修改。

Connectivity Test 的結果應依該測試的實際意義解讀。它可能反映特定連線或要求所需時間，不一定涵蓋實際服務的所有路徑，更不等於持續吞吐量。若測試成功但 App 無法使用，應觀察實際要求使用的網域、協定與策略；若測試失敗但部分服務正常，也要確認測試目標本身是否可連線。請交叉參考多項相關證據，不要將單次結果視為唯一結論。

比較速度時，每輪只更改一個變數，並使用相同裝置與網路，維持相近的測試時間。盡量避免背景同步、系統更新或其他裝置占用頻寬，並記錄是否為冷啟動、是否已建立連線，以及是否位於訊號較弱的區域。比較耗電則需要較長時間且可重複的固定工作；系統電池用量統計可提供線索，但不能將所有網路耗電直接歸因於特定協定。短時間發熱也應搭配傳輸量判斷。

驗證完成後，請還原日常所需的 Global Routing 與規則，刪除不再使用的測試副本，並保留原始資料與有效設定的對應關係。初次連線流程請參閱使用教學，常見使用問題請參閱新手問題快速解答。本頁用於說明選用方式與欄位用途，不取代伺服器管理，也不影響 App Store 購買範圍；系統需求仍以 App Store 頁面標示為準。