Shadowrocket
協定選擇與參數說明

01 / 先區分協定、傳輸與規則

類型必須與伺服器端一致

在 Add Server 選擇類型，本質上是在選擇用戶端與伺服器之間的通訊格式。Shadowsocks、VMess、VLESS、Trojan 等名稱代表不同的驗證與資料組織方式，不是可以任意替換的速度檔位。現有資訊若標示 VLESS，就不能只因另一種協定看起來較簡單而改選 Trojan。伺服器必須支援相同的協定、憑證與傳輸組合，連線才有成立的條件。

理解設定時，可將連線拆成四層：最底層是裝置到伺服器的網路連通性，其上是 TCP、UDP 或以它們為基礎的傳輸，再上層是協定驗證與選用的 TLS，最後才是請求抵達目標服務。Config 中的規則負責決定哪些請求採用哪種策略，不會修正伺服器密碼。分清這幾個層次，才能避免驗證錯誤時反覆修改 DNS，或規則路由錯誤時不停更換協定。

分別確認位址、身分與傳輸

伺服器位址用來找到連線入口，連接埠則用來指定入口上的服務。位址可以是網域名稱，也可以是 IP；填寫網域名稱時還會多一道解析程序。驗證欄位用來確認連線者是否獲准使用此入口，可能是 Password、UUID 或金鑰。傳輸欄位則描述請求如何送達伺服器端，例如 WebSocket 的 Path、HTTP Host 或其他服務名稱。即使位址與憑證正確，傳輸路徑不符仍可能導致交握中斷。

匯入訂閱時通常會一併寫入這些欄位，因此首次排查應保留匯入後的原始值，再逐項與自己已有的資訊比對。不要先清除看不懂的選項，也不要把其他項目的參數拼進目前項目。某個介面沒有顯示額外傳輸選項，可能代表該組合不需要，也可能與目前類型有關；應以目前的應用程式介面和現有設定為準，不要照抄無關範例。

速度與耗電應在相同條件下比較

在 iOS 上，協定處理會耗用處理器資源，但無線訊號、重傳、螢幕亮度與背景活動往往同樣重要。交握時間較短的協定不保證大檔案傳輸更快；能迅速跑滿頻寬的協定，也未必適合長時間低流量待機。短連線較容易顯現交握與解析成本，持續下載則更容易看出頻寬、壅塞控制與伺服器負載的影響。評估前應先說明測試的是哪種工作情境。

選擇協定不會改變伺服器所在網路的基本條件。同一協定在不同入口可能呈現完全不同的延遲與吞吐量；不同協定若共用壅塞的出口，也可能一起變慢。比較時固定裝置、網路、目標資源與測試時段，暫停其他高流量工作，並記錄連線是否成功、首次請求的等待時間及持續傳輸穩定度。不要把單次測試結果當成永久排名。

02 / Shadowsocks：配對加密方法與密碼

以代理轉送為核心的連線設計

Shadowsocks 的設計目標，是以相對簡潔的方式承載代理流量，並在用戶端與伺服器之間加入驗證和加密處理。通常不必理解完整的虛擬網路拓撲，只要依伺服器位址、連接埠、加密方法與密碼建立設定。欄位較少，代表比較容易核對，但不表示任意組合都有效；加密方法本身就是協定相容性的一環。

傳統設定常會在加密方法名稱中標示演算法、運作方式或金鑰長度。選擇時必須與伺服器端完全一致，不能依手機型號挑選看起來較快的名稱。不同方法的密碼處理方式與封包格式可能不同；用戶端能儲存項目，不代表伺服器端會接受。若協定變體要求不同格式的憑證，更應沿用現有設定，不要直接以一般密碼取代。

逐項檢查四個核心欄位

伺服器位址應填寫實際入口，不要把整段分享連結貼到位址欄。連接埠填寫伺服器端提供的數字，複製時避免帶入空格、冒號或說明文字。Password 須保留大小寫與符號，也要留意通訊軟體複製時可能加入換行。Method 對應加密方法，應逐字確認。若資訊來源只提供分享連結，建議先依教學匯入再檢查解析結果，通常比手動拆解更不容易漏掉編碼字元。

有些部署還會提供額外外掛或傳輸相關設定。這些不是裝飾選項，而是連線路徑的一部分；若伺服器端要求額外封裝，用戶端缺少對應參數就無法使用相同格式通訊。反之，一般入口也不應自行加入額外封裝。若無法確認，請向自己的服務商確認欄位用途，不要在網路上找「通用值」覆蓋現有資訊，更不要以關閉檢查取代相容性確認。

TCP 正常不代表 UDP 正常

Shadowsocks 可轉送 TCP 與 UDP 流量，但兩者能否使用仍取決於伺服器、網路路徑與用戶端項目設定。網頁能開啟，只能表示當時使用的請求路徑成功，不能證明需要 UDP 的應用也正常。若網頁可用但即時應用失敗，應先確認該應用實際使用的傳輸方式，再檢查伺服器是否支援，而不是立刻更換加密方法。

UDP 封包有大小限制，額外封裝會壓縮可用的酬載空間。小封包正常、大封包或持續流量異常時，應考慮路徑 MTU、封包遺失與分片問題。此時反覆修改 Password 通常沒有幫助，因為驗證問題不會只在特定封包大小下穩定發生。請記錄是所有目標都異常，還是只有特定工作異常，並以同一伺服器上的簡單請求作為對照，縮小問題範圍。

觀察 iOS 上的處理負載

在硬體與實作相容性良好的情況下，現代驗證加密方法能有效處理大量流量，但實際表現仍受伺服器處理能力與網路頻寬限制。持續高吞吐時，裝置可能因加密、收發資料與無線活動而產生更多熱量；待機時則應確認是否確實有流量。不能只因協定欄位少，就推論它一定最省電，也不能把裝置發熱全歸因於某種演算法。

排查時先保留一份原始項目，逐項確認位址、連接埠、Method 與 Password，再分別使用 Connectivity Test 和實際目標請求進行驗證。若所有請求都失敗，優先檢查入口與憑證；若只有特定應用異常，再檢查 UDP、DNS 與規則路徑。也可搭配閱讀協定類型概覽，了解相關協定的整體定位；實際填寫仍須依據現有伺服器參數。

03 / VMess 與 VLESS：身分欄位之外還有傳輸設定

外觀相似不代表協定相同

VMess 與 VLESS 都常使用 UUID 作為身分欄位，也都可能搭配不同傳輸方式，因此乍看之下容易混淆。VMess 將使用者驗證與協定內的資料保護機制整合；VLESS 則著重精簡協定本身的處理，將可靠的資料保護交由相容的安全傳輸組合負責。兩者的封包與驗證流程並不相同，不能因 UUID 格式相同，就認為只更改類型也能連線。

UUID 是用來識別使用者身分的值，不是伺服器網域或顯示名稱。複製時應保留完整內容，尤其不要漏字或混入不可見空格。有些設定還包含與驗證方式或相容性相關的欄位，不能只依舊教學照填。VMess 的部分舊有參數並非目前所有設定都需要；若現有資訊與介面不一致，應先確認設定來源與目前支援的組合，不要自行補填數值。

傳輸方式決定伺服器如何接收連線

同一協定可以透過不同傳輸方式運作。直接使用 TCP 的組合通常不包含 WebSocket 路徑；使用 WebSocket 時，Path 和 Host 可能決定請求轉送至哪個後端；採用其他傳輸方式時，則可能出現不同的服務識別欄位。這些欄位負責調整傳輸方式，不是取代 UUID 的另一組密碼。只填位址與 UUID、漏掉傳輸欄位，是匯入內容不完整時常見的失敗原因。

Path 須保留開頭的斜線、大小寫及現有查詢字串，不要把它當成給使用者看的備註。Host 與伺服器位址可能不同：前者可能參與應用層路由，後者用來建立網路連線。若同時啟用 TLS，還可能需要填寫用於安全交握的 Server Name 或 SNI。三者有時相同，但用途不同；應依設定分別填寫，不要為了看起來一致就全部改成伺服器 IP。

VLESS 精簡不代表可以省略安全層

討論 VLESS 時，須區分「協定本身不負責某部分加密」與「整條連線沒有保護」。實際安全性取決於搭配的安全傳輸與驗證機制。不能只看協定名稱就判定安全性，也不能因介面某個欄位標示不加密，就任意關閉 TLS。若伺服器端要求特定安全組合，應完整保留相關設定；若缺少說明，請先補齊資訊再連線。

有些項目會出現 Flow 等附加選項，這些選項對應特定運作方式，並非通用的效能加速開關。填錯可能在驗證後中斷連線，也可能不被伺服器端接受。正確做法是以現有分享資訊為準，並確認 Shadowrocket 目前的介面支援該組合。若介面沒有相應功能，不能把欄位塞進備註來實現；應確認伺服器端是否另有相容入口。

交握、裝置時間與行動網路切換

涉及時間驗證的流程可能受到裝置時鐘誤差影響。若入口可連通但驗證持續失敗，可檢查系統日期與時間是否正確，但不要把時鐘問題當成所有故障的通用解釋。使用 TLS 與額外傳輸的組合時，首次請求可能包含多階段交握；建立持續傳輸後，這些固定成本會被分攤，因此網頁首次開啟體驗與大檔案速度可能呈現不同結果。

在 iOS 的 Wi-Fi 與行動網路之間切換時，既有連線可能需要重新建立。應觀察連線恢復後的新請求能否成功，不必要求每個既有下載都不中斷。比較 VMess 與 VLESS 時，應盡量固定傳輸方式與伺服器條件，否則差異可能主要來自 WebSocket、TLS 或入口負載。進一步檢查 VLESS 時，建議先保存原項目，每次只修改一個確定需要修正的欄位。

04 / Trojan：理解 TLS 內的密碼驗證

TLS 負責安全通道，密碼負責使用權限

Trojan 的設計方式是透過成熟的 TLS 通道承載代理協定，再於通道內完成相應的身分驗證與請求轉送。理解時應分開判斷兩件事：首先，用戶端須確認連線的是可信任的 TLS 服務；其次，該服務須確認用戶端提供的密碼有效。憑證正確只能表示安全交握符合檢查條件，不代表代理密碼已獲接受，兩者不能互相取代。

因此，有些錯誤看似都發生在「連線至伺服器」階段，實際原因卻不同。伺服器位址或連接埠錯誤，可能連 TCP 都無法建立；Server Name 不符可能導致憑證驗證失敗；Password 錯誤則可能在 TLS 建立後遭拒。診斷時應依失敗階段檢查對應欄位，不要把所有連線中斷都歸因於密碼錯誤，也不要用關閉憑證檢查來掩蓋網域設定問題。

連線位址與憑證名稱可以不同

Address 決定用戶端將網路連線送往何處；Server Name 或 SNI 則用於 TLS 交握時表示伺服器名稱。透過 IP 連線時，伺服器憑證仍可能是為網域簽發，因此現有設定可能要求另外填寫名稱。憑證也涉及有效期限、簽發鏈與名稱涵蓋範圍；即使瀏覽器能開啟某個網站，也不能直接證明代理入口使用相同的連接埠、憑證與路由設定。

伺服器同時承載多項服務時，SNI 也可能影響它選用哪張憑證或哪個後端。任意改成常見網站網域通常無法解決問題，反而可能讓請求進入無關服務。正確值應以使用者現有設定為準。若原本正常、後來突然出現憑證錯誤，應檢查裝置時間、伺服器憑證狀態與入口變更，保留錯誤資訊後向自己的服務商確認。

額外傳輸設定仍須完整相符

Trojan 項目不一定只有最基本欄位。有些伺服器部署除了 TLS 外，還要求符合特定傳輸方式與路徑；使用者應依現有資訊核對，不要把其他 Trojan 項目的欄位合併進來。若透過訂閱匯入，先確認應用程式辨識出的類型與傳輸設定是否完整；手動輸入時，則應分別記錄位址、連接埠、密碼、安全層名稱及所有明確要求的附加欄位。

密碼區分大小寫，複製時若混入空格、換行或替換符號，都可能造成驗證失敗。不要把下載訂閱用的權杖當成 Trojan 密碼，也不要把項目備註當成使用者名稱。訂閱網址與伺服器憑證是不同項目：前者用來取得設定，後者用於實際連線。訂閱更新成功只表示能取得設定內容，不代表其中每台伺服器目前都能連線。

iOS 上的速度與耗電取決於使用情境

TLS 是行動系統中成熟的基礎技術，但成熟不代表沒有成本。首次建立安全通道需要交握，頻繁建立短連線時，等待時間可能更加明顯；持續傳輸時，吞吐量則更受網路、加密處理與伺服器轉送能力影響。若再疊加額外傳輸，也須考量封裝與連線管理的負載。不能簡單斷言 Trojan 永遠比其他協定快或慢。

觀察耗電應涵蓋實際使用時段。短時間下載可能瞬間耗電較高，但也可能較快完成；反覆失敗並重新連線，則可能在吞吐量低時仍持續喚醒網路。若待機耗電異常，先檢查是否有應用程式在背景發出請求、是否持續重試、是否頻繁切換網路，再確認 On Demand 的觸發條件。光看協定名稱無法判斷背景活動來源，更不能靠修改密碼解決重試問題。

有效的排查順序是：先使用目前入口建立連線，再連線至原本可存取的一般目標，最後測試實際使用的服務。若在連線階段就失敗，檢查位址、TLS 與驗證；若只有特定目標失敗，檢查 DNS、規則與目標回應。若要依操作順序排查「已開啟連線開關但網頁無法開啟」，可接著閱讀開啟連線開關後的四步排查，避免只反覆檢查 TLS。

05 / HTTP 與 SOCKS5：代理介面不等於加密通道

從應用層代理的用途理解差異

HTTP 代理源自應用層的請求轉送需求，可處理一般 HTTP 請求，也可透過 CONNECT 為目標連線建立位元組通道。SOCKS5 則以較通用的方式表示目標位址與連線指令，不要求承載的資料都是網頁協定。兩者描述的是代理介面，不能只看名稱就推斷用戶端到代理伺服器之間已有加密保護；仍須另外確認安全層。

目標網站使用 HTTPS 是另一回事。HTTPS 可保護裝置與目標之間相應的應用程式資料，但代理入口仍可能看見連線目標等資訊，而連至代理本身的驗證與傳輸也有各自的安全範圍。若選用含 TLS 的 HTTP 代理組合，應確認憑證與伺服器名稱；若現有資訊明確標示為一般代理，就不能在用戶端任意開啟 TLS，並期待伺服器端自動配合。

使用者名稱、密碼與伺服器端允許範圍

HTTP 與 SOCKS5 都可能需要使用者名稱和密碼，也可能由伺服器端的存取控制決定是否允許使用。請依現有資訊填寫，不要認為留白就一定可用。某個代理允許特定網路來源存取，不代表切換至行動網路後仍會接受連線。若切換網路後連線失敗，應一併確認伺服器端的存取範圍與憑證，不要立刻認定 Shadowrocket 項目已損壞。

伺服器位址不要包含多餘的協定前綴或路徑，除非介面明確要求輸入完整 URL。連接埠也不應從目標網站位址推測。若現有資訊來自公司或個人維護的網路環境，也應確認該代理允許存取的目標範圍與用途。有些入口僅供特定應用程式或網路區域使用；即使通過一次驗證，也不代表所有網際網路目標都能透過它轉送。

由哪一端解析網域會影響結果

請求抵達代理前，用戶端可能已將目標網域解析為 IP，也可能將網域交由代理處理。這兩種方式會影響解析位置、錯誤表現與網域規則判斷。不能因 SOCKS5 支援網域位址，就認定所有請求都必定在伺服器端解析；Shadowrocket 的 DNS 與路由設定、應用程式的請求方式及實際實作都可能造成影響。排查時應分別測試網域請求與已知位址請求。

同樣地，網頁可用不代表即時通訊也可用。一般 HTTP CONNECT 的典型用途主要是 TCP；SOCKS5 雖支援 UDP ASSOCIATE，伺服器、用戶端設定與中間網路仍須符合要求。若實際工作依賴 UDP，應先確認入口明確支援此功能。不支援時，單改目標連接埠無法補足；需要伺服器端提供相容的連線方式。

適用情境與 iOS 表現

若使用者現有的是公司網路提供的 HTTP 代理，或個人環境中的 SOCKS5 入口，選擇相應類型通常比硬改成其他協定合理。重點是符合現有服務介面，而不是協定名稱聽起來更通用。若入口只適用於可信任的區域網路，應將此網路範圍視為設定的一部分；連線環境改變後，須重新評估驗證保護、網路連通性與允許存取的範圍。

協定本身處理較少，不代表整體耗電一定較低。未額外加密的連線可能減少部分運算，但目標本身的 TLS、網路重傳與應用程式請求頻率仍然存在。代理伺服器若處理緩慢，裝置可能需要更長時間維持無線活動。比較時應同時記錄成功率、請求等待時間與工作完成時間，不要只看單次延遲測試就把一般代理視為所有情境的效能解答。

若只能存取部分目標，先確認代理的存取策略與目標連接埠限制，再檢查本機規則。若身分驗證遭拒，重新確認使用者名稱、密碼與來源網路範圍；若交握成功後目標逾時，則繼續檢查解析與伺服器至目標的路徑。分層排查比不停更換協定類型有效，也能向自己的服務商清楚描述問題，而不只是說「無法使用」。

06 / WireGuard：金鑰、Peer 與位址路由

處理網路層隧道的協定

WireGuard 以網路層隧道、精簡的密碼學組合及公鑰識別對端為設計核心。相較於只填寫代理密碼的類型，通常需要理解本機介面位址、對端身分、連線入口與允許進入隧道的位址範圍。欄位較多不代表每個欄位都用於驗證；有些欄位描述身分，有些則決定網路封包如何送往正確位置，須分別理解。

Private Key 是目前用戶端的私鑰，Public Key 用來表示對應身分；Peer 的 Public Key 則指向遠端對等端。若將用戶端自己的公鑰填入遠端公鑰欄位，雙方身分關係就不成立。若設定提供 Preshared Key，它是額外的共用金鑰，不能取代公私鑰配對。真實金鑰不應放在公開截圖、文章或日誌中；向他人描述問題時，也應先移除這些內容。

Endpoint 與介面 Address 各有用途

Endpoint 是連往遠端的網路入口，通常由位址與連接埠組成。介面 Address 則是隧道內指派給本端的位址，可能附有前綴長度；它不是遠端伺服器的公網位址。匯入時應保留伺服器端指派的值，不要為了與家用區域網路看起來一致而自行更改。位址衝突、前綴錯誤或本端位址未獲伺服器端接受，都可能造成交握正常但服務無法使用。

Allowed IPs 用來將對等端與位址前綴建立關聯，也會影響哪些目標可交由該對端處理。它不是允許存取的網站清單，也不只是備註。填入完整位址範圍與只填部分網段，意義差異很大；同時還須考量 Shadowrocket 的上層策略如何將請求交給該伺服器。隧道內可路由的範圍與應用程式中的規則分流是兩層限制，不能以其中一層自動取代另一層。

交握成功後仍須驗證服務路徑

交握只表示雙方完成相應的金鑰交換，不代表位址指派、轉送與 DNS 都正確。若看得到交握但網頁無法使用，應檢查隧道位址、Allowed IPs、遠端轉送與解析設定。若完全無法交握，則優先檢查 Endpoint、公鑰配對與 UDP 連通性。區分這兩種情況，可避免路由錯誤時反覆重建金鑰，增加伺服器端與用戶端設定不一致的風險。

MTU 會影響隧道中單一封包的大小。底層網路可承載的封包大小須扣除隧道負載；設定過大時，可能出現小請求正常、大型回應停滯的情況。調整應以可重現的現象為依據，每次只改這個欄位；不要把任意較小的數字當成通用最佳化。若問題只出現在特定網路環境，也須考量底層路徑差異，不要認為整份 WireGuard 設定都已失效。

Keepalive、漫遊與耗電範圍

WireGuard 使用 UDP；網路位址變更後，具備相應的對端端點更新機制，但實際恢復仍受行動系統排程、NAT 狀態與網路條件影響。有些設定會使用 Persistent Keepalive 協助維持對應關係。保活頻率不是越高越好：週期過短可能增加待機時的無線活動，過長則可能無法符合特定網路的對應需求。應先保留現有設定要求，再依明確問題調整。

在 iOS 上，長時間持續傳輸與長時間待機是兩種不同負載。前者著重觀察吞吐量、溫度與封包遺失復原；後者則應確認是否有持續的背景流量與保活喚醒。不能把網路層隧道結構簡潔，直接等同於任何情境都更省電。填寫欄位時，可搭配閱讀WireGuard 欄位逐項說明；若手上只有代理密碼，沒有金鑰與位址資訊，就無法據此自行建立可用的 WireGuard 項目。

07 / Hysteria2：UDP 路徑與壅塞控制

以 QUIC 為基礎的傳輸方式

Hysteria2 以 QUIC 建構代理傳輸；QUIC 運作於 UDP 之上，並結合 TLS 完成相應的安全交握。其設計著重於高延遲、封包遺失等情況下的傳輸表現，但不保證在所有網路上都更快。若所在網路限制 UDP，或 UDP 路徑品質明顯較差，協定本身的設計優勢也無法繞過底層連通性這項前提，甚至可能完全無法建立連線。

理解 QUIC 時，應區分傳輸層中的多路串流與底層鏈路資源。各串流彼此獨立，可減少某些跨串流阻塞，但仍共用無線鏈路、路徑容量與壅塞狀態；發生封包遺失時，個別串流的資料仍可能需要復原。不要將「多路」解讀為頻寬自動倍增，也不代表所有請求都不會互相影響。伺服器處理能力、目標回應與網路排隊仍會決定最終體驗。

分別保留驗證與憑證欄位

Hysteria2 項目須符合伺服器端的位址、連接埠與驗證資訊；安全層名稱與憑證檢查也應依現有設定填寫。Password 或相應驗證欄位不能取代 TLS 憑證。即使伺服器使用網域入口，也應確認 Server Name 是否符合設定要求。若使用 IP 連線，而憑證是為網域簽發，名稱欄位尤其重要；不要為了讓所有欄位一致就將它清空。

有些部署還會提供額外的混淆設定。這些參數是雙方約定的一部分，只有伺服器端明確要求時才應啟用，並須確保類型與憑證相符。隨機填入混淆密碼不會提升相容性，反而可能使封包在進入驗證階段前就無法正確解析。透過訂閱匯入後，應先檢查附加欄位是否完整，再判斷問題是否來自網路品質。

頻寬參數不是加速倍率

上行與下行頻寬欄位是提供相應傳輸策略參考，不會將線路容量提升至填入的數值。若填入遠高於實際能力的數值，傳送行為可能與鏈路承載能力不符，造成排隊、封包遺失或影響同一網路中的其他工作；填得太低則可能主動限制可用吞吐量。也要留意單位，避免混淆每秒位元組與每秒位元，造成數量級差異。

並非所有伺服器設定都以相同方式使用用戶端提供的頻寬資訊，實際壅塞控制行為須依雙方支援的設定判斷。最穩妥的起點是現有設定與伺服器端說明，而不是套用其他裝置上的所謂最佳值。若要調整，先在穩定網路中建立基準，分別觀察單項下載、上行傳送與網頁互動；不要只追求單次峰值而忽略其他請求的等待時間。

如何判斷是否適合行動網路

行動網路的可用容量與延遲可能隨訊號和基地台負載變化。某個時間點測得的頻寬，不一定適用於接下來整段使用；在電梯、交通工具或訊號微弱的區域反覆測試，也會將無線網路變化混入協定比較。建議先在固定位置、訊號穩定時確認基本連線，再觀察實際移動過程中的恢復情況，區分固定設定錯誤與網路波動造成的暫時失敗。

高吞吐量、加密處理、重傳與無線收發都可能提高裝置耗電。Hysteria2 在某些路徑上可能縮短工作完成時間，也可能在其他路徑上因持續封包遺失而增加負載，因此不能一概認定省電或耗電。若使用者已有多個相容入口，應一併記錄相同工作的完成時間、穩定度與實際電量變化；若只有一個入口，先確認欄位正確，不必為了協定名稱更換整份設定。

08 / 依情境選擇，再用規則與實測驗證

先確認現有條件，再比較設計取捨

選擇時最優先考量伺服器端實際提供的入口。若現有訂閱只包含一種協定，先確保匯入完整、驗證正確且目標可連線，不必依協定排名自行更改類型。若確實有多個可用入口，再按工作情境比較：頻繁瀏覽網頁時留意解析與首次回應；持續下載時留意吞吐量與穩定度；即時應用則留意 UDP 支援與延遲波動；存取個人內部網段時則確認位址路由是否正確。

對需要明確設定 TLS 與傳輸方式的入口，應優先確認資訊是否完整、日後是否容易核對；對網路層隧道，則要確認金鑰、位址與路由範圍都已提供；對以 UDP 為基礎的傳輸，還要確認目前網路允許且能穩定承載 UDP。選擇協定不應只看欄位多寡或名稱新舊；能正確表達現有服務，且故障時可分層排查，也是實際可用性的重要一環。

Global Routing 不會改變協定身分

Global Routing 的設定包括代理與直連，對應介面詞為 Config、Proxy、Direct。Config 依目前設定中的規則決定策略；Proxy 用來將相應流量交給代理策略；Direct 則採用直連路徑。切換這些模式會改變路由決策，不會更換伺服器協定。若目前請求根本沒有進入所選伺服器，對該請求比較協定速度便沒有意義，應先確認流量路徑。

以下片段用來說明規則順序，應放在 Shadowrocket 設定中相應的規則區域，並確認代理策略指向可用伺服器。這不是完整設定，也不包含伺服器憑證。DOMAIN-SUFFIX 先比對指定的網域後綴；GEOIP 再處理符合地區位址資料庫條件的目標；FINAL 則為其餘請求指定策略。是否需要地區規則，應依使用者本身的需求決定，不要直接照抄。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

規則通常依序比對，較具體的條件應放在適當位置；FINAL 負責處理其餘連線。IP 規則與網域規則的輸入條件不同，DNS 解析結果也可能影響判斷。某個目標走 DIRECT，不代表所選代理協定失效；某個目標走 PROXY 後失敗，也不能直接證明規則語法有誤。更多設定操作請參閱設定說明，首次連線步驟請參閱快速入門教學。

建立可重複檢驗的記錄

驗證時先在 Home 選取目標伺服器，再確認 Global Routing，開啟連線並執行 Connectivity Test，接著連線至實際使用的目標。測試工具的結果只涵蓋它執行的檢查，不代表所有協定能力、目標或規則路徑。記錄網路類型、所選項目、目標與失敗階段即可；不要公開訂閱連結、密碼或金鑰。向自己的服務商回報時，也應先移除敏感資訊。

若完全無法連線，依序檢查位址解析、連接埠與傳輸、TLS 或協定驗證；若連線已建立但部分目標失敗，再檢查 DNS、規則命中、UDP 與目標服務。測試效能時一次只改一個變數，避免同時更換伺服器、傳輸方式與路由。比較耗電也應固定觀察時間與螢幕使用方式，待裝置溫度與背景工作相對穩定後再開始，不要直接比較兩次負載不同的結果。

最後，請分開處理協定選擇與用戶端取得方式。iPhone / iPad 版於 App Store 一次性付費 $2.99；Mac（Apple 晶片與 Intel）、Windows、Android、Linux 版免費。取得與安裝相關問題請統一參閱下載指南與常見問題。本站是 Shadowrocket 官網與官方手冊，不提供、不銷售、不推薦節點或訂閱。若要了解現有項目的介面用語，可閱讀英文介面用語對照；若要確認連線步驟，可閱讀首次連線操作說明，再回到本頁核對相關協定的技術範圍。