Shadowrocket 協定選擇與參數參考

01 / SELECTION

協定選擇：先確認伺服器端，再比較傳輸條件

分開理解協定、傳輸、安全性與路由

在 Shadowrocket 中選擇協定類型，代表指定用戶端與伺服器通訊時使用的格式，並非選擇可任意互換的速度等級。伺服器提供 Shadowsocks，就必須選用對應的 Shadowsocks 類型與驗證資料；伺服器提供 Trojan，也不能只把類型改成 VLESS 繼續使用。位址和連接埠相同，只能表示連線目的地相同，無法證明伺服器接受相同的交握、驗證或資料封裝。選擇類型時，首要依據始終是既有資料明確標示的協定。

可用的連線通常涉及四層資訊。第一層是位址與連接埠，決定資料傳送到哪裡；第二層是協定與身分驗證，決定伺服器是否接受請求；第三層是傳輸與安全性參數，例如 TLS、WebSocket 或 UDP；第四層才是本機路由，決定哪些請求會經由該連線。某些協定會整合其中數層，另一些則可採用不同組合。排查時應逐層檢查，否則容易把 DNS 錯誤當成密碼錯誤，或把規則未命中誤認為協定不相容。

速度與耗電量沒有固定排名

實際速度會受到接入網路、往返延遲、封包遺失、伺服器負載、出口頻寬及目標服務等因素影響。增加一層封裝通常會增加資料量與處理負擔，但不代表在所有環境中都更慢：如果某種傳輸方式更適合目前的網路，減少重傳所帶來的效益可能高於封裝成本。反過來說，同一協定在不同伺服器上的差異，也可能遠大於同一伺服器上兩種協定的差異。因此，本頁不會依協定名稱排列固定的速度快慢。

在 iPhone 與 iPad 上觀察耗電量，也要一併考量使用方式。持續大量傳輸會同時使用無線網路、加解密與應用程式的處理能力；零星請求則容易受到連線建立次數、背景維持連線和網路喚醒影響。頻繁自動測速、過短的更新間隔與反覆連線失敗，都可能掩蓋協定本身的差異。比較時應固定裝置、網路、伺服器與目標，並將螢幕亮度和其他背景工作納入考量，不能只因一次電量下降就歸因於某個協定。

建立可重複的比較方法

先保存一份已知可用的設定作為基準，再逐項調整。以同一目標分別觀察首次開啟、重複存取、持續傳輸和休眠後恢復，不要每輪測試都同時更換 DNS、協定與伺服器。Connectivity Test 可用來觀察連線狀態，但測試結果不代表所有服務都能正常使用。瀏覽網頁、播放影片和即時語音對傳輸的要求各不相同，應測試實際需要使用的服務，而非只比較單一數值。

如果既有資料只提供一種協定，正確做法是完整匯入這組資料並進行驗證，而不是只看名稱就改選另一種類型。若確實需要切換，應先取得伺服器端為新協定準備的完整參數。訂閱解析後清單空白，與協定選擇是不同層面的問題，可先查看匯入訂閱後清單空白的自我檢查說明。本頁後續章節假設至少已有一筆可編輯的伺服器記錄；介面是否顯示相關欄位，請以目前 App 中的實際選項為準。

03 / VMESS · VLESS

VMess 與 VLESS：身分欄位相似，不代表協定相同

設計取捨與類型界線

VMess 將身分驗證與資料處理整合為專用的代理協定，設定通常包含 UUID，以及與安全性、傳輸相關的參數。VLESS 採用較精簡的協定層設計，本身不提供內容加密，理解完整連線時必須搭配安全傳輸方案。兩者都可能使用 UUID，也都可能搭配不同的外層傳輸，因此只看連結中的身分欄位無法判斷協定類型。應以原始訂閱或伺服器端明確標示為準，不能把同一個 UUID 當成跨協定通用的連線憑證。

VLESS 的設計較精簡，不代表完整連線一定耗用較少資源，也不代表可以省略安全層。如果連線再加上 TLS、WebSocket 或其他傳輸方式，實際資料開銷與交握流程取決於整套組合。VMess 的表現同樣受伺服器設定與網路條件影響，而非只由協定名稱決定。選擇類型時，應同時記錄協定、傳輸與安全層三個面向，再比較相容性和使用情境；只抽出其中一個面向比較，容易得出與實際運作不符的結論。

UUID、傳輸類型與路徑

UUID 用於識別伺服器端允許的使用者身分。複製時須完整保留所有字元與分隔格式，不能用備註名稱取代。備註只供使用者辨識記錄，不參與協定驗證。VMess 的部分參數也與協定實作和舊有設定格式有關，不應只根據網路上的單一截圖批次修改。如果協定驗證流程會檢查時間，裝置時間明顯有誤可能導致連線失敗；應先確認系統日期與時間正常，再判斷伺服器是否拒絕該身分。

傳輸欄位決定協定資料如何承載。使用 WebSocket 時，Path 是交握請求路徑，Host 則與 HTTP 層的主機資訊有關；它們不是伺服器備註，也不能把完整網址任意拆開填入不同欄位。路徑開頭的斜線、大小寫與查詢字串是否須保留，應依伺服器資料核對。選用其他傳輸方式時，欄位組合可能不同，不應將 WebSocket 參數照搬到其他傳輸類型。介面未顯示某欄位，也不代表可以用名稱相近的欄位取代。

TLS 名稱與其他擴充參數

連線位址用於找到伺服器；TLS 的 Server Name 提供交握時使用的名稱資訊，並與憑證名稱驗證相關。兩者可能相同，也可能由伺服器資料明確指定為不同值。Host 則屬於另一層，不能只因內容看起來都是網域名稱就互相取代。如果資料還包含其他安全性擴充或特殊交握參數，應確認目前的 App 是否支援相應組合。欄位可以輸入，只表示有可供填寫的位置，並不足以證明任意組合都能與伺服器互通。

既有設定中的 Flow 等選用參數，屬於特定協定組合的設定，不是通用的加速開關。只有伺服器端明確要求，且用戶端提供相容選項時才應啟用。不要反覆嘗試各種安全性參數來取代核對原始資料，否則會同時改變交握條件，失去排查基準。對於從訂閱匯入的記錄，先保留原始結果，再建立獨立的測試副本，更容易判斷是匯入資料不完整，還是後續編輯造成連線變化。

行動網路中的比較方式

在 iPhone 或 iPad 上評估這兩類連線時，應區分首次交握與連線建立後的資料傳輸。多層交握會讓短時間請求更容易受到往返延遲影響；長時間傳輸則可能主要受頻寬與網路壅塞影響。切換網路後，舊連線失效並由 App 重新建立連線，也會造成短暫等待。如果只是某種傳輸方式恢復較慢，應記錄發生在解除鎖定後恢復、切換無線網路，還是一般連續使用期間，而不是直接歸因於 VMess 或 VLESS 的整體差異。

發生連線失敗時，依序排除位址與連接埠、協定與 UUID、外層傳輸、安全層及目標存取問題。如果連線記錄顯示請求根本沒有選到該伺服器，應先檢查 Global Routing 與目前的設定。更多常見狀況請參閱疑難排解，避免尚未確認路由就反覆修改身分欄位。

05 / HTTP · SOCKS5

HTTP 與 SOCKS5：先辨識代理入口，再確認保護範圍

兩種通用代理介面的設計出發點

HTTP 代理是為轉送 HTTP 請求而設計，處理網頁請求時可使用代理格式的請求目標；對於 HTTPS 等情境，通常會透過 CONNECT 請求建立通往目標的通道。SOCKS5 則提供較通用的代理連線協商，用於指定目標位址、連接埠與連線請求。兩者都是代理入口的協定規範，不代表入口天然具有相同的加密保護、驗證機制或 UDP 能力。既有伺服器若標示為 HTTP，就不能只因位址相同而改選 SOCKS5。

這裡尤其要區分目標網站使用 HTTPS，與用戶端至代理入口使用 TLS。HTTPS 通常會保護到目標網站的內容，但若用戶端與 HTTP 代理之間未使用 TLS，代理協商資訊及部分驗證資訊的保護範圍，就與加密的代理入口不同。目標網站使用安全連線，不代表外層代理鏈路的每個部分都具備相同的安全特性。判斷保護範圍時，應逐段檢視連線，而不是只看瀏覽器網址列或伺服器備註中的某個詞。

位址、連接埠與驗證模式

HTTP 與 SOCKS5 的基本資料通常包含伺服器位址、連接埠，以及可能需要的 Username 和 Password。是否需要驗證由伺服器端決定，不能假設留白就能連線，也不能把其他協定的 UUID 填入使用者名稱，期待它自動相容。驗證失敗與網路無法連線可能呈現相似狀況，應結合連線錯誤和既有資料判斷。手動輸入時也要留意某些帳號含有網域或其他前綴，是否保留應以伺服器提供的完整格式為準。

如果代理入口要求 TLS，應選擇對應的安全性設定，並核對憑證名稱。連接埠數字本身無法證明入口使用明文或加密，也不能證明它接受 CONNECT。部分伺服器會限制可存取的目標、目標連接埠或驗證方式；即使用戶端成功連上入口，後續請求仍可能遭拒。遇到特定目標連接埠無法使用時，應先確認授權範圍與伺服器政策，而不是反覆修改本機 DNS，或誤以為所有 HTTP 代理都只能存取網頁。

DNS 解析與 UDP 支援條件

SOCKS5 的目標位址可以網域名稱表示，但實際請求是否將網域名稱交由代理端解析，仍取決於用戶端的處理方式、DNS 策略，以及目標資訊是否已轉換成 IP。不能只因選用 SOCKS5，就認定所有 DNS 請求都在遠端完成。HTTP 代理也可能在請求中取得目標主機名稱，但 App 產生的其他 DNS 查詢則須另行檢查。排查網域名稱問題時，應觀察實際連線目標與 DNS 結果，而不只是檢查伺服器類型。

SOCKS5 規範包含 UDP ASSOCIATE，不代表每個伺服器、每種接入網路和每種用戶端組合都能完成 UDP 轉送。相關協商通常還涉及控制連線與轉送位址，網路端可能會限制其中一部分。如果 TCP 服務可用、UDP 服務卻失敗，應分別確認伺服器端是否啟用、回傳位址是否可達，以及規則是否選到同一筆記錄。不能將單一網頁測試的結果直接套用到語音、遊戲或其他 UDP 服務。

適用情境與行動裝置使用評估

這兩類入口常見於既有組織代理、已授權的網路存取，或明確提供通用代理協定的環境。使用者應依管理單位提供的類型與安全要求設定，不要因為參數較少就認為更適合長期使用。對 iPhone 和 iPad 而言，連線穩定性仍會受到網路切換、驗證有效期限與伺服器限制影響。代理持續顯示驗證失敗時，應先檢查憑證狀態與授權範圍，不要以頻繁重新連線取代確認。

如果服務需要持續低延遲或 UDP，應先確認入口確實具備相應能力；如果只需存取特定授權資源，則更應重視目標路由與驗證範圍。選擇協定應配合既有連線條件，無法創造伺服器端未提供的能力。儲存記錄時，可在備註中標明用途與網路條件，但不要填入密碼；如此切換不同入口時，既能辨識使用情境，也不會在清單截圖中洩露驗證資訊。

07 / HYSTERIA2

Hysteria2：基於 QUIC 的傳輸須先確認 UDP 條件

設計目標與網路前提

Hysteria2 以 QUIC 為基礎安排代理傳輸，著重於複雜網路環境中的資料傳送與壅塞處理。QUIC 運作於 UDP 之上，並結合 TLS 完成安全交握。它可以在單一連線中安排多個資料流，各資料流的處理方式與單一 TCP 位元組串流不同，但多個資料流共用連線，仍會受到整體頻寬、壅塞情況與伺服器資源限制。多流特性不代表某個請求完全不受其他流量影響，也不能只憑協定名稱推測實際傳輸量。

使用前最重要的條件是 UDP 路徑可用。有些網路可以正常瀏覽網頁，卻限制 UDP 入口或採取不同的處理方式；此時，基於 TCP 的記錄正常，並不能證明 Hysteria2 入口也應該正常。發生故障時，先核對網域解析、連接埠與 UDP 可達性，再檢查驗證和 TLS。如果底層路徑不通，調整頻寬參數或新增保活通常無法補足缺少的網路條件。

驗證、TLS 與混淆參數

既有的 Hysteria2 資料通常包含伺服器位址、連接埠、驗證資訊與 TLS 相關設定。驗證欄位須依伺服器要求完整保留，不能直接拿其他協定的密碼嘗試。TLS 名稱與憑證驗證原則和前文相同：連線目標、Server Name 與憑證涵蓋的名稱必須正確對應。即使底層使用 UDP，憑證時間、名稱與信任鏈仍然重要，不能將所有交握失敗都歸因於 UDP 受到限制。

如果伺服器啟用了混淆，用戶端也須設定對應類型與密碼等參數。混淆、驗證與 TLS 屬於不同層，各自負責不同功能，不能因其中一項設定正確就忽略其他兩項。未啟用混淆的入口，也不應自行新增不明參數。匯入後若可用記錄與手動重建的記錄結果不同，應優先逐項比較欄位，特別留意簡略資料中容易省略的選用設定。

頻寬欄位不是測速結果

有些設定包含上傳與下載頻寬欄位，這些數值可能會影響特定壅塞控制模式的運作。欄位中的數值不是用戶端即時測得的速度，也不代表伺服器承諾持續提供相應傳輸量。伺服器政策與協商方式可能影響這些數值是否生效，不能藉由填入很大的數值增加實際頻寬。輸入時也要確認 App 欄位使用的單位，不要混淆每秒位元組與每秒位元，也不要把自己的下載能力誤填到上傳欄位。

如果設定值明顯高於實際接入能力，在相關模式下可能造成排隊、封包遺失與連線不穩；設定過低則可能限制可用的傳輸能力。應依實際網路條件與伺服器說明設定，並保留原始設定作為基準。測試時同時觀察下載是否持續、互動請求是否延遲，以及其他 App 是否受到排隊影響。短時間內曾達到較高速度，不足以證明參數設定合理，更不能取代較長時間的穩定性觀察。

在 iPhone 與 iPad 上觀察資源使用情況

QUIC 的協定處理、加密與資料收發都會占用裝置資源。實際耗電表現會受到實作方式、流量、封包遺失與無線訊號強度影響，沒有適用於所有裝置的固定結論。大量傳輸測試時，App 處理和無線傳輸會同時運作；裝置溫度升高，不能單獨證明設定錯誤。更有參考價值的是相同服務量下的持續表現、背景是否反覆重新連線，以及弱訊號或解除鎖定後恢復時是否明顯異常。

如果只有特定無線網路無法連線，可改用另一個已獲授權的接入網路，確認路徑是否不同；如果所有網路都失敗，再檢查原始驗證資料、TLS 與伺服器狀態。如果可以建立連線，但大量傳輸時停頓，應檢查路徑上的封包遺失、封包大小、頻寬設定與遠端資源，而非立即改用另一種協定。只有伺服器端實際提供新協定，切換才有意義。記錄故障發生階段與簡短錯誤資訊，比只寫「無法使用」更有助於後續判斷。

完成測試後，停止反覆測速與不必要的持續傳輸，還原日常設定後再觀察耗電量。如果問題只在更新訂閱後出現，應先比較記錄中的參數變化，區分伺服器端調整與本機網路變化。設定來自既有訂閱時，手動修改也可能在後續更新時被覆寫；因此應確認測試副本與訂閱記錄的管理方式，避免更新後同一問題再次發生。