Shadowrocket 協定參考

協定選擇的四個層次

先區分協定、傳輸、加密與路由

在 Shadowrocket 中選擇協定，實際上是在決定客戶端如何與既有伺服器通訊，而不是替連線挑選速度等級。完整連線至少涉及四個層次：協定規定請求與驗證格式，傳輸負責將資料送至另一端，加密保護傳輸中的資料，路由則決定哪些請求會進入這條連線。四者彼此相關，卻不能互相取代。選對協定類型後，伺服器位址、連接埠、憑證與傳輸參數仍須逐項一致；僅憑名稱相同，無法證明兩端能夠通訊。

例如，VLESS 是一種請求與驗證格式，WebSocket 是一種承載方式，TLS 負責加密連線並驗證身分，而 DOMAIN-SUFFIX 則決定某個網域是否套用代理策略。同一種協定可以搭配不同傳輸方式，同一種傳輸方式也可能承載不同協定。伺服器提供的整組參數才是設定單位，不能把一組設定的驗證資訊與另一組設定的傳輸方式拼在一起。匯入後若看到不同名稱，應先確認各名稱分別描述哪個層次。

明確界定比較目標

網頁瀏覽通常包含許多短請求，初次建立連線所需時間、網域解析與連線重用都會影響使用感受。大型檔案傳輸則更容易顯現持續吞吐量、壅塞控制與伺服器出口限制。語音及互動式 App 更重視往返延遲波動、封包遺失與 UDP 是否可用。因此，「網頁開得快」和「持續傳輸速度快」是兩種不同的結論；把單次下載結果套用到所有 App，容易造成後續排查方向錯誤。請先寫明目標，再選擇能反映該目標的測試方式。

在 iPhone 和 iPad 上，也應一併記錄使用時段與網路條件。固定位置使用 Wi-Fi 與移動中使用行動網路，可能面臨不同的位址變更、無線重傳與背景排程。協定增加的封裝、加密與保持連線機制會帶來額外負擔，但螢幕亮度、無線訊號強度和持續傳輸量也會明顯影響電量。若未控制這些因素，測試只能反映某次使用經驗，無法據此建立固定的協定耗電排名，更不能認定名稱較新的協定一定比較省電。

建立可復原的選擇流程

實際選擇首先受限於既有伺服器支援的能力。若只有一組完整設定，依照資料選擇對應類型即可，不必為了比較而改寫協定。若已有多組可用設定，先確認每組設定都能獨立連線成功，再比較相同目標的首次存取、重複存取與持續使用情況。保留原設定副本，每次只變更一個條件，並記錄當時使用的網路。如此即使調整後沒有改善，也能回到已知狀態，而不會因連續修改而失去比較基準。

最後再考量維護成本：參數較多的連線需要保存更完整的資料，憑證、網域與傳輸路徑也可能各有不同的變更週期。暫時速度較快、卻沒有明確參數來源的設定，未必適合長期使用。優先選擇資訊完整、符合目前用途且方便驗證的既有設定。協定參考的用途是說明差異與限制，不是取代伺服器設定，也不會將某種協定說成適用所有網路的唯一答案。

Shadowsocks、HTTP 與 SOCKS5

Shadowsocks：簡潔的加密代理

Shadowsocks 著重以較簡潔的協定承載代理流量，並透過約定的加密方式與金鑰資料處理兩端通訊。通常不必像複雜的傳輸組合那樣同時填寫多層路徑參數，但這不代表所有設定都能互換。不同加密方式對應不同的金鑰需求與封包處理方式，伺服器支援的項目也可能不同。選擇時應先確認既有資料中的加密方式與客戶端選項相符，再檢查伺服器、連接埠與驗證資料。

密碼與加密方式必須搭配理解。有些設定使用一般密碼文字，有些加密方式則對金鑰編碼與長度有明確要求；把編碼後的資料當成一般密碼，或只因為某個加密方式「看起來更安全」就擅自更換，都可能導致驗證失敗。使用 Subscribe 匯入時，請優先保留匯入值；手動新增時，依照資料逐項填寫，不要自行補上未提供的選項。若設定包含額外承載方式，也要另外核對相關參數，不能假設伺服器會接受預設值。

以 iOS 使用體驗來看，封裝層較少有助於降低額外處理，但實際速度仍受伺服器資源、連線品質與目標網站限制。現代裝置的加密效能通常不是唯一瓶頸，也不能把特定演算法名稱直接等同於耗電程度。若只有持續傳輸時裝置發熱，先比較傳輸量相近時的表現；若閒置時也明顯耗電，則檢查重新連線、網路訊號與保持連線機制，而非立刻更換加密方式。協定參數錯誤通常不會因為多等一會兒就自行恢復。

HTTP：區分代理連線與目標連線

HTTP 代理最初是為轉送網頁請求而設計，可轉送一般 HTTP 請求，也能透過 CONNECT 為目標建立通道。請區分兩段連線：裝置到代理伺服器，以及代理伺服器到目標網站。目標網站使用 HTTPS，不代表裝置到 HTTP 代理的這一段也採用 TLS。若伺服器明確提供加密的代理入口，仍須依照資料設定相應的連線方式，不能只看目標網址以 HTTPS 開頭就判定整段連線的性質。

HTTP 代理常見欄位包括位址、連接埠，以及可選填的使用者名稱與密碼。驗證方式取決於伺服器設定，空白憑證與錯誤憑證也可能得到不同結果。CONNECT 是否允許連線至特定目標連接埠，取決於伺服器策略；能瀏覽一般網頁，卻無法使用某項服務，不一定是客戶端協定實作有問題。排查時先使用已知允許的目標，再核對該服務實際使用的連接埠與傳輸類型，避免把權限限制誤認為速度不足。

SOCKS5：通用轉送不等於內建加密

SOCKS5 適用於較通用的連線轉送，定義了驗證協商、連線請求與 UDP 關聯等機制。協定本身不提供通用的連線加密保護；即使使用者名稱與密碼存在，也不表示資料已透過加密通道傳輸。它適合搭配可信任的既有網路環境或另行提供的安全承載方式。選擇之前，應先確認伺服器的存取範圍與保護方式，不能單憑欄位多寡，就將 SOCKS5 與具備加密機制的協定視為相同。

SOCKS5 的 UDP 支援必須同時滿足兩端實作、伺服器允許，以及中間網路可連通等條件。TCP 連線成功不代表 UDP 關聯也正常；網頁正常但即時服務失敗時，應另外驗證該服務的連線路徑。網域由哪一端解析，也會影響解析結果與存取行為，不能只檢查伺服器位址欄位。維護既有設定時，先保留驗證、解析與 UDP 相關設定的原始資料，再依實際需求逐項驗證，比隨機切換選項更容易找出問題。

VMess 與 VLESS 的設計取捨

VMess：一併檢查驗證與協定處理

VMess 的設計包含使用者驗證與協定層的資料處理機制，常以 UUID 識別使用者資訊。它經常與其他傳輸方式搭配，因此單一設定可能同時包含 UUID、協定安全選項、傳輸類型與外層 TLS 欄位。看到 UUID 不代表整條連線已設定完成：位址與連接埠決定連線目的地，驗證決定伺服器是否接受連線，而外層參數則決定請求如何抵達實際服務。任何一層不一致，都可能造成連線逾時或中斷。

手動檢查時，先確認 UUID 是否完整，特別留意複製時混入的空格、換行或遺漏字元。接著核對伺服器要求的安全選項，最後再檢查傳輸欄位。不同時期的設定可能包含額外參數，不要用一份資料中的值覆蓋另一份；應以目前既有服務的明確說明為準。若驗證階段與時間有關，裝置時間明顯不準也可能影響連線。請先校正時間，再確認是否需要更新憑證。

VLESS：精簡協定不代表省略安全層

VLESS 著重精簡的驗證與請求封裝，通常使用 UUID，但協定本身並不以提供通用資料加密層為設計重點。實際部署時，必須搭配所使用的安全與傳輸機制一起理解，不能把「欄位較少」解讀成無須驗證遠端身分。UUID 是驗證資料，不能取代憑證驗證；傳輸方式、TLS 設定及伺服器指定的其他參數，仍是完整連線的一部分，應一併保存。

有些既有設定還會指定特定的流量處理選項。這類欄位與伺服器的處理方式及可用傳輸有關，不是通用的速度提升開關。資料未提供時，不要照抄網路上另一組設定來補填；資料明確要求，但客戶端目前的選項不相符時，也不要改選名稱相近的值。先確認 App 能力與伺服器條件，再決定是否採用這組設定，比反覆嘗試可能建立錯誤假設的組合更可靠。

WebSocket 與其他承載方式須搭配設定

WebSocket 常見的檢查項目包括請求路徑與 Host。路徑可能用於伺服器分流，其中的大小寫、前置斜線與其他組成部分都可能有意義，不要任意刪除。Host 用於相應請求的路由，不一定等同於實際建立網路連線的位址，也不一定等同於 TLS 的 Server Name。伺服器若透過不同層次區分請求，這些值就可能各有用途；將所有網域都改成同一個位址，反而可能破壞原本正確的設定組合。

若採用其他傳輸方式，也應依照該方式檢查欄位。例如，涉及服務名稱時，不能只因名稱與路徑都是文字，就將兩者互換。外層連線已建立但請求仍失敗，可能表示請求已抵達入口，卻未轉送至正確的後端。此時應一併檢查傳輸參數與伺服器分流條件，而不是重新產生 UUID。更換驗證資料無法修正錯誤的路徑，反之亦然。

如何比較 iPhone 上的實際負載

VMess 與 VLESS 的使用感受差異，不能脫離搭配的傳輸方式與伺服器來討論。TLS 交握、連線重用、額外封裝與伺服器負載，對首次存取的影響可能大於兩種協定格式本身。若一種設定使用直接連線，另一種經過額外轉送層，即使速度不同，也不能將差異全部歸因於協定名稱。比較時應盡量讓位址所處網路、目標、傳輸條件與測試時間相近，並分別記錄首次連線與後續請求。

長期使用還要觀察網路切換後能否恢復，而不只記錄剛連線時的結果。裝置從 Wi-Fi 切換至行動網路後，原有連線可能需要重新建立，實際情況同時受傳輸機制與系統排程影響。若只有切換網路時失敗，先測試關閉後重新連線是否能恢復，並記錄是否所有服務都受影響。這些結果有助於區分連線持續性問題與固定參數錯誤，避免將可重現的網路條件誤判為協定長期無法使用。

Trojan 與 TLS 參數檢查

Trojan 的外層安全連線

Trojan 將代理請求與驗證放在 TLS 連線內部，透過成熟的安全傳輸機制承載服務。對使用者而言，密碼、伺服器位址與 TLS 身分驗證必須同時成立，不能三選一。即使密碼正確，若連線所用的伺服器名稱不符、收到不受信任的憑證或選錯連接埠，仍無法建立正確連線。排錯時應依序檢查外層連線，再檢查內層驗證。

TLS 不只負責加密，也會透過憑證鏈與名稱比對協助確認遠端身分。交握階段的失敗發生在服務資料正常轉送之前，因此「網頁打不開」只是最終現象，不能據此判定密碼錯誤。先確認網路能連至入口，再檢查憑證相關條件；安全連線建立後，才需要繼續檢查內層驗證與目標請求。依照這個順序排查，可減少同時修改多個欄位造成的重複作業。

連線位址、Server Name 與 Host

伺服器位址回答的是「要連到哪裡」，Server Name 則用於 TLS 交握中的伺服器名稱指示及相關身分驗證；實際欄位名稱請以目前介面為準。既有設定可能使用一個網路位址連線，卻以另一個明確提供的網域名稱進行驗證。這種差異不能只憑外觀自行修正。若將 Server Name 改成連線位址，憑證可能不再相符；若只更改位址卻未確認伺服器入口，也可能連到完全不同的服務。

Host 用於相應的應用層請求，與 Server Name 的用途不同。只有實際採用包含此欄位的傳輸方式時，才需要依資料填寫；不要自行替不含該欄位的連線增加含義。若設定同時提供多個網域，應記錄每個值所屬的層次。最容易排查的資料，不是只寫一個「伺服器網域」，而是清楚列出連線位址、TLS 名稱與請求路由各自使用的值，以及哪些欄位維持預設。

憑證錯誤時，不要略過驗證

憑證問題通常可從三個方向檢查：裝置時間是否正確、設定名稱是否符合憑證涵蓋範圍，以及伺服器是否提供完整且受信任的憑證鏈。憑證過期、憑證鏈不完整與名稱不符是不同故障，處理方式也不相同。客戶端只能檢查本機參數與時間；伺服器憑證部署問題則須由既有服務的管理者處理。反覆更改密碼無法修復憑證鏈，也不能取代確認實際故障原因。

略過憑證驗證會改變身分確認條件，不應作為日常排錯的預設步驟。若關閉驗證後連線才能建立，只能表示原本的身分驗證環節有問題，不能證明該伺服器值得信任。請保留原始設定，查明具體不符之處，再恢復正常驗證。若既有服務需要額外的信任資料，也應先確認資料來源與適用範圍，不要將從其他連線複製的憑證設定隨意套用到目前設定。

TLS 負載與長時間連線

TLS 建立連線時需要額外的往返通訊與運算，但後續請求可能重用連線，實際影響取決於 App 行為與網路條件。頻繁中斷並重新連線的小流量情境，不能直接與長時間保持連線的大流量情境相比。訊號較弱時，重試也可能增加交握負擔，讓耗電變化看起來像是協定的固定特性。測試時應區分首次連線、連續存取與閒置後恢復，觀察差異發生在哪個階段。

Trojan 設定中的 UDP 能力，也不能只因外層 TLS 正常就認定可用；應配合伺服器支援情況與實際服務檢查。若網頁正常但某項即時服務異常，可先檢查路由，再單獨驗證 UDP 路徑。憑證、網域與傳輸方式的排查方法也適用於其他採用 TLS 的協定，但不能因此互換不同協定的密碼或請求格式。共通層次可以沿用相同的判斷方式，內層協定仍須維持自身參數一致。

WireGuard 的金鑰與路由

與請求代理的比較界線

WireGuard 以 IP 層通道為設計目標，透過公開金鑰機制識別對端，並使用 UDP 傳送加密資料。它與依目標請求建立代理連線的協定，在觀察與設定層次上並不完全相同。在 Shadowrocket 的使用情境中，還須考量客戶端如何將流量交給這條連線，以及遠端如何轉送收到的資料。通道成功建立不代表目標路由、名稱解析與回程路由都已設定正確，仍須驗證實際服務。

其設計採用較明確的密碼學組合與較精簡的協定狀態，減少使用者自行組合演算法的空間。但精簡不代表所有欄位都能留白：本機位址、金鑰、遠端入口與允許的位址範圍仍各有用途。伺服器必須識別目前客戶端的公開金鑰，並提供相應的網路條件。若更換設定中的私密金鑰，卻未同步更新遠端對應資訊，通常會破壞原有的身分關係。

Private Key、Public Key 與 Endpoint

Private Key 是本機身分的機密資料，只應用於受信任的設定儲存空間；Public Key 用於識別對端，不負責相同的保密工作。填寫遠端 Public Key 時，應使用資料中明確標示的對端公鑰，而不是再次複製本機公鑰。有些設定還包含預先共用金鑰，它是額外的安全資料，不是任意的文字備註。欄位名稱都含有 Key，不代表它們可以互換，也不能透過刪除其中一項來簡化設定。

Endpoint 指的是遠端入口位址與連接埠，並不等於通道內使用的本機位址。前者用於在目前網路中找到伺服器，後者則用於通道內的資料通訊。位址前綴長度具有明確的網路意義，不能當成裝飾字元刪除。若匯入後提示欄位不完整，請回到原始資料確認，不要用裝置目前的 Wi-Fi 位址代替。實體網路位址與通道位址屬於不同層次，混用只會讓排錯更困難。

Allowed IPs、DNS 與 MTU

在 WireGuard 中，Allowed IPs 與對端可接收的目標範圍及來源檢查有關。客戶端實際提供哪些選項、如何搭配自身路由，請以目前介面與既有設定為準。它不應被當成 Shadowrocket 規則清單的另一種寫法而隨意修改。只允許通道連至特定內部網段，不代表選取後就自然具備完整的網際網路存取能力；還要確認遠端轉送、出口與回程路由是否支援相應目標。

DNS 負責將名稱解析成位址，通道路由則決定取得位址後如何連線，兩者須分開檢查。已知位址可連線但網域失敗時，可先檢查解析路徑；網域能解析卻無法連線時，再檢查目標範圍與遠端轉送。MTU 會影響封裝後封包的大小，設定過大時可能出現小請求正常、大型回應停滯的情況。但不要因此隨意填入通用數值；應先保留原值，確認症狀後，再依伺服器建議進行單一變數測試。

行動網路中的保持連線與恢復

持續保持連線可在特定環境中維持網路映射，但頻率並非越高越好。它可能有助於某些需要在閒置後仍能接收連入資料的情境，也會增加週期性通訊與無線喚醒。是否需要以及如何設定，應配合伺服器角色、網路映射逾時時間與實際服務需求，而不是為了讓介面看起來持續活動。若只是主動發起一般存取，不要把縮短保持連線間隔當成提升所有服務速度的通用技巧。

WireGuard 的對端識別機制可在相應條件下因應入口位址變更，但裝置切換網路後能否恢復，仍受系統、伺服器與目前 UDP 連通性影響，無法保證全程不會中斷。測試應涵蓋閒置後的首次存取與切換網路後的實際請求，並確認目標確實經由該通道傳送。分享診斷紀錄時，請隱藏 Private Key、預先共用金鑰與內部網路細節，只保留必要現象、欄位名稱與錯誤類別，避免為了方便排錯而分享完整設定。

Hysteria2 的網路適用條件

從封包遺失與壅塞了解設計

Hysteria2 以 QUIC 建立代理通訊。QUIC 運行於 UDP 之上，並結合安全交握、串流管理與壅塞控制等機制。其設計重點之一，是因應不同品質的網路路徑調整傳輸行為，但這不代表能消除實體網路的限制：無線訊號不佳、伺服器出口資源不足，或中間網路不允許相應 UDP 流量時，仍可能發生連線失敗或吞吐量下降。先確認承載條件成立，才有必要繼續評估它在目前網路中的表現。

QUIC 的多串流機制可減少部分因傳輸層依序交付而造成的串流間互相阻塞，但頻寬、壅塞與共用伺服器資源仍是共同限制。不要將它理解成任何請求都不必等待，也不能因此保證遊戲或語音延遲會降低。互動服務對排隊與封包遺失較敏感，持續傳輸則更重視吞吐量穩定性；同一組設定可能改善其中一項，卻未改善另一項，測試時必須分別記錄。

驗證、名稱與混淆參數

設定時先檢查伺服器位址、連接埠與驗證資料，再檢查 TLS 名稱與憑證驗證。驗證文字必須完整保留，不要因為看起來像備註就截短。與其他採用 TLS 的連線一樣，實際連線位址與用於身分驗證的名稱可能各有用途，應依既有資料填寫。若客戶端尚未成功建立安全連線，先檢查外層是否連通及名稱是否相符，不要直接判定驗證資料已失效。

有些服務會提供額外的混淆設定，只有伺服器明確使用相同機制與參數時才應啟用。混淆不能取代身分驗證，也不是單獨提升速度的開關。客戶端與伺服器一方啟用、另一方關閉，或密碼不一致，都可能導致資料在進入正常協定處理前就無法識別。匯入後請保留整組值；手動修改前先儲存副本，不要從另一組設定複製看似相似的選項來補足目前資料。

頻寬參數是條件，不是速度保證

若既有設定包含上行與下行頻寬欄位，應先確認方向與單位，並了解這些數值可能影響壅塞控制行為。設定值遠高於目前線路能力，不會增加可用頻寬，反而可能造成排隊、封包遺失或與其他服務爭用資源。行動網路的可用能力會隨地點與時段變動，因此固定估值不一定適用。先保留伺服器建議值或客戶端合理預設值，再透過持續測試判斷是否需要調整。

若網頁首次開啟正常，但大量資料傳輸時波動明顯，可比較不同網路下的結果，並觀察其他服務是否也受影響。開始傳輸後語音變得卡頓，可能是連線排隊或資源競爭，不一定是驗證或 TLS 設定有問題。減少同時進行的測試、暫停其他大量傳輸，再測試相同目標，有助於判斷目前現象是否主要由負載造成。不要反覆提高頻寬欄位的數值，試圖掩蓋尚未確認的瓶頸。

UDP 連通性與耗電限制

網路允許瀏覽網頁，不代表也允許連線至所需的 UDP 連接埠。Hysteria2 在一個網路可用、換到另一個網路卻失敗時，應優先保留設定並檢查底層連通性是否不同。反覆更改密碼可能破壞原本正確的設定，卻無法解決承載方式受到限制的問題。若另有一組完整且可用的設定，可在相同網路交叉驗證，但結論應限於該網路條件，不要推廣成適用所有情境的協定優劣。

在 iPhone 上，較高的吞吐量代表短時間內可能處理更多資料，也可能增加無線通訊與處理器負載。持續使用時間、總傳輸量與閒置後重新連線的行為，都會影響耗電結果，不能只根據畫面上的瞬時速度判斷。切換網路後也應重新確認服務是否恢復，而不只是查看連線開關。若頻繁失敗，先降低測試強度、記錄現象並還原至已知設定，再逐項確認承載方式、參數或伺服器條件。

參數檢查與規則分流

匯入成功不代表服務驗證成功

透過 Subscribe 匯入既有訂閱，只能證明客戶端能讀取並解析相關資料，不代表其中每條連線都已通過驗證或具備相同能力。匯入後應查看目標設定的類型、位址、連接埠與必要的傳輸欄位，確認與資料描述一致。名稱只是方便辨識的標籤，不能用來判斷協定類型。若標籤寫著某種協定，但實際類型不同，應核對原始資料，不要依標籤猜測並手動修改。

QR Code 與分享文字同樣是設定的承載方式，編碼、跳脫字元與欄位對應都會影響解析結果。複製時遺漏字元、連同說明文字一起選取，或讀取不完整內容，都可能造成異常。先檢查原始資料是否完整，再決定是否手動補填。訂閱更新也可能覆蓋本機修改，因此調整設定進行測試前，應保留獨立副本並記錄來源，避免把一次性的暫時修正誤以為之後更新仍會保留。

Global Routing 決定是否套用規則

Global Routing 的 Config、Proxy、Direct 分別代表依設定處理、透過代理處理與直接連線的整體模式。日常依網站分流時，應先確認使用 Config，再檢查目前啟用的設定檔。在了解影響範圍後，可使用 Proxy 協助驗證代理路徑，但它不能取代完整的規則檢查；Direct 則不能用來證明代理協定運作正常。模式、目前伺服器與目前設定是三種不同狀態，都應記錄。

規則通常由上而下檢查，前面符合的項目可能使後面的精確規則無法執行。DOMAIN 用於比對完整網域，DOMAIN-SUFFIX 用於比對相應網域及其子網域，DOMAIN-KEYWORD 依網域關鍵字比對；IP-CIDR 用於位址範圍，GEOIP 依相應的位址地理分類處理，FINAL 則在前面的規則都未符合時提供最後的處理方式。比對對象各不相同，不能只因都可寫網域或位址就互相取代；解析條件也會影響部分位址類規則的判斷。

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

這段片段展示的是規則順序，不包含伺服器資訊，也不是可直接建立連線的完整設定。將精確的 REJECT 放在範圍較廣的 DOMAIN-SUFFIX 前面，可避免請求先被後者比對到；PROXY 須配合目前可用的代理連線理解；FINAL,DIRECT 表示其他未符合規則的請求採直接連線。範例網域僅用來說明語法。若既有設定使用自訂策略名稱，請檢查對應定義，不要將不熟悉的名稱一律改成 PROXY。

以實際連線紀錄完成判斷

一項服務可能同時存取頁面、靜態資源、驗證與即時通訊等多個網域。主頁開啟不代表所有請求都使用相同策略；反過來說，某個元件失敗也不能直接證明整個協定失效。驗證時請查看實際連線使用的目標與策略，區分規則未符合、連線未建立與目標回應錯誤。不要為了修復單一資源就刪除所有規則，否則不僅失去原設定的用途，也更難判斷真正有效的修改。

若要進一步了解比對對象，可查閱規則關鍵字說明；若只想讓指定網站使用代理，可參考指定網站分流設定方法。涉及 REJECT 時，也請閱讀REJECT 的適用範圍。協定決定如何建立連線，規則則決定何時使用連線；先分別驗證，再搭配使用，排錯紀錄才有明確意義。

速度、耗電與問題排查

先建立相同條件的測試紀錄

比較既有設定時，固定裝置、網路、目標與 Global Routing，暫停其他明顯的大量傳輸工作，並盡量在相近時段進行。每輪分別記錄首次連線、重複存取與持續傳輸，不要混為一談。Connectivity Test 可協助觀察連通性，但測試目標與連線方式未必符合實際服務，單一結果不能取代服務驗證。測試結束後請還原原本的路由模式，避免臨時驗證設定繼續影響日常連線。

比較耗電時，應觀察使用時間與總傳輸量相近的情況，並控制螢幕、訊號與背景活動。系統的電量頁面反映的是 App 活動與系統統計方式下的結果，並非獨立量測的協定耗電量。單次短時間測試尤其容易受到啟動、快取與無線狀態影響。若裝置持續發熱，先停止高負載測試，檢查是否正在大量傳輸或反覆重新連線；原因未明時繼續增加同時執行的工作，只會讓比較條件更不穩定。

依失敗階段逐步排查，不要隨機更換參數

完全無法建立連線時，先確認目前網路正常、入口位址與連接埠正確，再核對協定類型。使用 UDP 承載的連線，須另外確認路徑可連通；使用 TLS 的連線，則繼續檢查名稱、裝置時間與憑證條件。外層連線已建立但驗證遭拒時，再檢查密碼、UUID 或金鑰。每次只修改一個項目並保留原值，若沒有改善就立即還原，避免將原本正確的欄位也變成新問題。

若連線顯示正常但服務無法使用，先檢查實際流量是否進入預期策略，再區分名稱解析、目標連線與服務回應。已知位址可連線但網域失敗，表示應優先檢查 DNS；只有特定目標失敗，則應檢查目標本身或伺服器存取條件；只有大型回應停滯時，可進一步觀察 MTU、封包遺失與連線品質。這些都是排查線索，不能僅憑現象下定論，還需要後續驗證排除其他可能。

若只有切換網路或閒置一段時間後才失敗，請記錄發生條件、等待時間與重新連線後的變化。若手動重新連線後恢復，代表固定參數至少曾經可用，應優先觀察連線恢復、網路映射與伺服器工作階段處理，而非立刻重新填寫所有憑證。On Demand 也會依設定影響連線行為，應一併記錄，但它無法修復驗證錯誤或遠端能力不足。先在手動連線模式下取得可重複的結果，再調整隨需連線條件。

依使用情境縮小選擇範圍

一般網頁瀏覽可優先考慮既有設定中較穩定、參數清楚，且首次與重複存取表現一致的一組；需要即時通訊時，先驗證 UDP 與延遲波動；存取受控內部網段時，應注意路由範圍、位址衝突與 DNS；持續大量傳輸則應觀察吞吐量穩定性及對其他服務的影響。這些建議說明的是測試順序，不是協定排名。只有伺服器實際支援的能力，才適合納入相應情境的比較。

維護紀錄應包含協定類型、外層傳輸、使用網路、Global Routing、失敗目標類別與重現步驟。分享給既有服務的管理者前，請隱藏訂閱網址、驗證資料、私密金鑰與其他敏感資訊；截圖也只保留排查所需的區域。首次連線涉及系統權限時，請參閱新增 VPN 設定提示說明。常用欄位含義可查閱術語表，完整操作流程則請回到快速上手教學。