Shadowrocket 協定手冊

01 / Model

協定分層與選用前提

協定名稱不等於完整連線方案

在 Add Server 中選擇 Type，首先是指定用戶端應以哪種格式與伺服器通訊，而不是替同一條連線切換效能等級。伺服器提供 Shadowsocks 時，不能只把用戶端改成 VLESS，就取得另一種協定的能力。雙方必須在協定、連接埠、認證資料及外層傳輸上保持一致。匯入訂閱通常會一併帶入這些資訊，但匯入成功只表示內容可供解析，不代表遠端設定仍有效，也不代表目前網路能連上對應連接埠。

理解一條連線，可依序拆解為目標請求、代理協定、承載傳輸及實際網路路徑。目標請求指出要連線的網域與連接埠；代理協定負責傳遞請求及驗證身分，部分協定也提供加密；承載傳輸決定資料如何透過 TCP、UDP、TLS 或其他封裝傳送；實際路徑則包含無線連線、電信網路、伺服器接入，以及伺服器到目標的後半段路徑。某一層出現異常，不能直接歸因於協定名稱；排查時應沿著這條鏈逐層縮小範圍。

認證、加密與路由是不同問題

密碼、UUID 與金鑰都可能用來驗證身分，但意義並不相同。UUID 不是網域，WireGuard 的 Public Key 也不能當成密碼欄位的替代文字。加密用來保護傳輸內容，認證則用來識別通訊對象或使用者；兩者可能由同一機制完成，也可能分屬不同層。TLS 憑證驗證是核對伺服器身分的一環，不能因帳號密碼正確就略過。欄位名稱相似時，仍應依服務端提供的協定說明確認對應關係。

Global Routing 則是另一個判斷面向：Config 依目前設定分流，Proxy 將可代理的流量交由代理策略處理，Direct 則直接連線。這些設定不會將伺服器的協定類型轉換成另一種協定。選對 Type 後，還要確認請求確實套用預期策略；否則，連線成功可能只是 DIRECT 生效，連線失敗也可能只是規則選到了無法使用的目標。相關術語可參閱術語表，避免把模式切換誤當成協定調校。

依實際支援能力選擇

選用的起點是服務端實際提供哪些功能，而不是協定清單中看起來較新的名稱。先記下可用類型、是否支援 UDP、認證方式及所需傳輸，再確認目前用戶端是否提供對應欄位。同一種協定也可能有不同功能組合，不能靠隨意填寫其他欄位來補上缺少的設定。若訂閱與手動說明不一致，請向你的服務商確認目前有效的參數；不清楚的擴充欄位應維持原狀，避免一次修改多個條件，失去可重現的基準。

Shadowrocket 是 Apple 平台的付費商業 App，取得方式與系統需求請以 App Store 頁面標示為準。若要確認購買管道，請參閱App Store 正版核驗說明。一次買斷用戶端 ≠ 線路方案：購買 App 不會取得伺服器位址、認證資料或訂閱。這也界定了本頁所說的選用方式——在既有條件下選對連線方式，並以實際結果判斷是否適合目前網路，而非宣稱某種協定在任何環境都更快。

02 / Shadowsocks

Shadowsocks：共享金鑰與輕量封裝

設計取向與適用範圍

Shadowsocks 的設計目標，是以相對精簡的方式傳送代理請求，常見部署會使用共享密碼與指定的加密方法。用戶端取得目標位址後，會依協定封裝並傳送至伺服器，再由伺服器建立後續連線。它並非以完整虛擬網路為主要概念，因此通常適合從「特定請求如何轉送」來理解，而不是視為一張遠端網路卡。協定實作與加密方法會影響具體細節，不能把所有標示為 Shadowsocks 的設定都當成完全相同。

現代部署常見 AEAD 加密方法，可同時處理機密性與完整性驗證。較新的協定變體也可能進一步限制金鑰格式、工作階段組成或重放防護。重點不是記住哪個名稱比較長，而是確認用戶端選用的方法與伺服器完全一致。共享密碼也不一定是任意可讀的短語：某些方法要求金鑰符合指定長度與編碼。不能將舊設定中的密碼直接移植到另一種方法，再期待伺服器自動相容。

逐項核對欄位，不憑印象填寫

在 Add Server 中，先確認 Address 與 Port 指向服務端實際監聽的位置，再核對 Method 和 Password。Address 可以是網域或位址，但解析結果必須連得到正確服務；Port 是服務端的監聽連接埠，不是瀏覽網頁時使用的預設連接埠。Method 並非本機的安全強度滑桿，而是雙方協定的一部分。Password 的大小寫、結尾空格，以及複製時夾帶的換行，都可能造成認證失敗。修改前應保留原始設定，再逐項對照來源。

如果既有設定包含額外傳輸參數，應將它們視為連線方案的一部分。協定本身與額外封裝不可混為一談：增加外層可能改變交握流程、網域需求與網路適應性，也會增加排查項目。只有服務端明確要求，且目前用戶端支援對應選項時，才進行設定。若手動建立的設定無法連線，但同一來源匯入的設定可以使用，應優先比較兩者欄位差異，不要先切換加密方法或刪除不熟悉的選項。

速度、耗電與常見故障情況

在 iPhone 上，封裝層較少通常有助於縮小問題範圍，但不等於耗電一定較低。加密運算只是耗電來源之一，螢幕、無線訊號、重傳與背景活動可能占去更多電力。現代裝置執行部分加密演算法的效率不錯，但實際傳輸量仍受伺服器負載與網路壅塞影響。若日常用途以瀏覽網頁和短連線為主，可觀察第一個請求是否迅速完成；若以持續傳輸為主，則應留意穩定傳輸階段的速度與溫度變化。

TCP 請求正常，但 UDP 服務異常時，應分別核對用戶端設定、服務端支援情況及目前網路是否能連通 UDP；不能用網頁開啟成功來證明所有傳輸都正常。若網域無法連線，但直接使用目標位址有回應，也要考慮 DNS 的位置與解析結果差異。若連線建立後才卡住，請記錄問題發生於傳送請求、接收回應或持續傳輸階段，並在相同網路下再次測試。區分這些現象，通常比不斷更換 Method 更有助於診斷。

03 / VMess · VLESS

VMess 與 VLESS：分開理解認證與傳輸

兩種設計的職責差異

VMess 將使用者身分識別、請求封裝及相關安全機制整合在協定中，常見設定會以 UUID 作為使用者識別碼。在代理協定發展較早的階段，它著重於可識別的使用者與連線處理方式，後續也出現不同的認證格式。使用者應確認伺服器實際採用的組合，而不是根據舊教學猜測相容參數。訂閱中的額外欄位可能與舊版相容性或特定實作有關，應優先保留來源提供的值。

VLESS 的協定職責則較精簡，基礎協定本身不負責內容加密，必須搭配適當的安全傳輸使用。它仍需要認證資訊，但「有 UUID」不代表內容已經加密。要確認保護機制來自何處，還需檢查外層是否使用 TLS 或服務端指定的其他安全機制。不能因介面中有同名認證欄位，就認為 VMess 與 VLESS 可以互換；兩者的交握與封裝方式不同，伺服器必須支援所選類型。

建立參數對應關係

UUID 應完整複製，不要加上引號、說明文字或多餘分隔符號。伺服器位址與 TLS 的 Server Name 可能不同：前者決定連線目的地，後者用於 TLS 交握中的名稱資訊與憑證驗證。若來源明確提供不同值，請填入各自對應的欄位；若未說明，不應自行以其他可連線的網域取代。也應檢查系統時間，時間錯誤可能影響憑證效期判斷，也可能干擾依賴時間條件的認證流程。

傳輸選項決定協定請求如何承載。使用 WebSocket 時，Path 是服務端用來區分入口的路徑，Host 可能參與外層請求路由；這些欄位不是備註欄，斜線、大小寫與路徑前綴都可能影響結果。部分部署會透過反向代理，將同一位址上的不同服務分開；若連接埠可連但路徑不符，遠端可能回傳網頁內容，而非協定交握。此時繼續調整 UUID 通常無法解決問題，應先檢查傳輸與入口欄位。

擴充參數不能單獨移植

部分 VLESS 設定也會包含 Flow 或其他安全交握參數，這些屬於特定連線組合，並非通用的加速開關。某個組合在伺服器端可用，不代表目前用戶端支援所有相關功能。請檢查 Add Server 中實際可用的欄位與來源說明；若缺少必要選項，應先確認相容性，不要把某個值塞進備註或其他名稱相似的欄位。匯入後也應開啟設定檢查，確認用戶端確實識別關鍵參數，而不只是儲存了名稱。

速度方面，額外交握與傳輸封裝可能增加第一個請求的等待時間，但連線穩定後，瓶頸可能轉移至網路與服務端。WebSocket 並非天生比其他承載方式快，VLESS 的精簡也不代表一定比 VMess 省電。弱訊號下反覆重新連線的影響，往往大於兩種協定間的運算差異。比較時應使用相同網路、相近目標與相同用途，分別記錄冷啟動和持續連線情況；不能只依一次 Connectivity Test 的結果排序。

排錯可依「位址與連接埠、外層交握、傳輸入口、認證、目標存取」逐段進行。外層憑證錯誤時，先檢查時間與 Server Name；若回傳一般網頁卻無法代理，檢查入口路徑；連線成功後特定服務仍失敗，則檢查 UDP 能力與路由。若長時間閒置後首次請求特別慢，也應記錄是否重新建立連線。欄位以外的常見狀況可參閱疑難排解，不要關閉憑證驗證來掩蓋前一層的錯誤。

04 / TLS · Proxy

Trojan、HTTP 與 SOCKS5

Trojan 透過 TLS 提供安全傳輸

Trojan 常見的設計是先建立 TLS 連線，再於受保護的通道中完成協定認證與請求轉送。它的參數表面上可能比多層組合精簡，但 TLS 仍有完整的身分驗證要求。伺服器憑證、連線位址與 Server Name 必須合理對應；密碼正確也無法彌補憑證名稱錯誤。使用者可先將問題拆分為「TLS 是否成功」與「協定認證是否成功」，比把所有失敗都歸為密碼錯誤更容易定位。

Address 可指向服務端位址，Server Name 則應符合服務端要求與憑證內容。即使直接使用位址連線，TLS 驗證時仍可能需要指定網域。憑證過期、憑證鏈不完整、裝置時間錯誤或名稱不符，都可能導致交握失敗。略過驗證會降低對通訊對象的確認，不應作為日常修復方式。若服務端採用特殊信任設定，應依照明確的管理說明處理，而不是在公共網路上臨時關閉檢查，只為換取一次連線成功。

HTTP 與 SOCKS5 的基本職責

HTTP 代理源自應用層代理需求，常見的 CONNECT 方法會要求代理建立通往目標的通道。名稱中的 HTTP 描述代理互動方式，不代表用戶端與代理之間必然使用 TLS。連線至 HTTPS 目標時，目標端的 TLS 與代理連線的保護是兩回事：目標加密不代表代理認證資訊在每種設定下都受到同等保護。應明確區分一般 HTTP 代理與透過 TLS 連線至代理的方案，並依伺服器實際能力設定。

SOCKS5 使用較通用的請求格式，可描述目標位址與連接埠，並定義認證及 UDP 關聯等機制。它本身不提供通用的內容加密保證，使用者名稱與密碼認證也不等於加密傳輸。它適用於既有的信任網路或有明確配套保護的環境；選用前應確認用戶端到伺服器之間由哪一層保護資料。至於是否支援 UDP，也不能只看協定規範允許哪些功能：伺服器實作、認證方式與目前用戶端實際支援的組合，都需要逐項確認。

不要混淆代理認證與目標認證

代理使用者名稱與密碼用於存取代理服務，不是目標網站帳號。若遠端要求認證，留空可能遭到拒絕；若服務端未啟用相關認證，隨意填入帳號也不會增加保護。收到認證相關錯誤時，應先確認回應來自代理還是目標網站。一般網頁可以開啟，但部分 App 失敗，也可能與 App 的請求方式、目標連接埠、UDP 需求或規則有關，不能據此推斷使用者名稱與密碼只對部分網站有效。

在 iPhone 上，這幾類協定的實際耗電情況取決於交握次數、連線重用與無線網路活動。建立 TLS 連線需要額外運算與往返，但連線建立後可承載後續請求；反覆中斷再重新連線，可能比維持適當的既有連線更耗資源。另一方面，為了持續保活而頻繁喚醒無線網路也有成本。因此不能只憑「使用 TLS」就判定耗電較高，也不能認為缺少加密的類型必然值得選用；應先符合安全與相容性條件。

排查時先確認服務端提供哪一種代理，再檢查是否需要 TLS、認證與 UDP。Trojan 的憑證錯誤應沿 TLS 流程處理；HTTP 代理的拒絕回應應檢查認證或 CONNECT 權限；SOCKS5 可建立工作階段但特定服務失敗時，則檢查命令支援與資料封包路徑。在工作網路中使用既有代理，也應遵守網路管理規定，不要任意更改認證方式或目標連接埠限制。效能測試應在允許的服務範圍內進行，避免把權限限制誤判為協定速度問題。

05 / WireGuard

WireGuard：金鑰、位址與隧道路由

從虛擬網路理解，而非只看單一請求

WireGuard 主要採用加密的第三層隧道模型，與前述以目標請求建立代理工作階段的類型不同。它使用公私鑰識別通訊雙方，透過 UDP 傳送封裝後的網路封包。其設計著重於精簡的協定範圍與明確的密碼學組合，不需要使用者在大量加密演算法間逐項協商。對用戶端使用者而言，這減少了演算法選擇，卻讓金鑰歸屬、隧道位址、對端端點與路由範圍成為設定重點；任何一項錯誤都可能影響最終連線。

Private Key 是本端的身分資料，必須妥善保密；Public Key 則用來識別對應的對端。填寫時必須分清來源設定中的「本端」與「對端」分別指誰，不能把伺服器公鑰填成本地私鑰。選用的 Preshared Key 是額外共享資料，並非取代公私鑰的一般密碼。若訂閱或設定已提供這些內容，請完整保留；分享排錯記錄時，則應移除私鑰與其他認證資料，不能只遮住伺服器名稱就以為已妥善處理。

Endpoint、Address 與 Allowed IPs

Endpoint 是用來連上對端的實際位址與 UDP 連接埠；隧道 Address 則是裝置在隧道內使用的位址，兩者屬於不同網路層。將公開伺服器位址填入隧道位址欄，或把隧道內部位址當成 Endpoint，都可能導致無法建立連線。若 Endpoint 使用網域，也需要在隧道啟動前有可用的解析路徑。若一啟用就無法解析端點，應檢查解析流程是否形成依賴循環，而不是先調整金鑰。

Allowed IPs 描述與對端相關的位址範圍；在 WireGuard 模型中，它也與路由選擇及來源位址驗證有關。它不是網站白名單，也不能任意擴大來提高連線成功率。用戶端如何將這些範圍與自身策略結合，應依目前設定核對。範圍太窄可能漏掉所需服務的位址，範圍太廣則可能讓不相關流量進入隧道；即使隧道交握成功，若伺服器未提供相應的轉送能力，仍無法連上目標。

行動網路切換與保活取捨

行動裝置在 Wi-Fi 與行動網路間切換時，外部位址與 NAT 對應可能改變。WireGuard 的設計可在收到認證封包後更新對端端點資訊，但不代表所有切換都能立即完成；新網路仍須允許 UDP，伺服器也必須收到有效流量。閒置一段時間後首次存取變慢，可能與對應逾期或重新建立通訊有關。應分別記錄持續使用、閒置後恢復與切換網路後恢復，不要把三種情況合併成單一穩定性評分。

Persistent Keepalive 用來在有需要時維持網路對應，代價是定期傳送資料。頻率並非越高越好，也不應對所有設定一律套用固定值。裝置處於行動網路訊號不佳的環境時，小封包也可能啟動無線活動，影響待機表現；若不需要維持外部連入能力，額外保活未必有幫助。應依服務端要求與實際網路狀況決定，並在相同閒置時間下比較恢復情況，而不是只觀察剛啟用後的短暫耗電變化。

交握正常但部分頁面卡住時，應考慮路由、DNS 與 MTU。隧道封裝會占用額外位元組，若路徑無法妥善處理較大的封包，可能出現小型請求正常、大型回應停滯的情況。調整 MTU 時應保留基準並逐步驗證，避免憑經驗填入極端數值而降低傳輸量。WireGuard 適合已有完整隧道參數、需要位址層連線的情境；若手上只有其他協定的伺服器資訊，不能只靠自行產生的一組金鑰就轉成 WireGuard 服務。

06 / Hysteria2

Hysteria2：QUIC 與丟包網路

QUIC 改變了哪一層

Hysteria2 以 QUIC 建構代理傳輸；QUIC 通常運行於 UDP 之上，並結合安全交握、資料流管理與壅塞控制。要理解它的用途，應從網路條件出發：往返時間較長、網路有丟包或可用頻寬變動時，傳輸層如何復原與調整傳送節奏，會明顯影響使用體驗。它不是單純把 TCP 資料改用 UDP 傳送就會自動變快，也無法突破實體頻寬限制；服務端連線品質、無線網路狀況與目標回應速度仍然是上限。

在以單一 TCP 連線承載多種服務的設計中，底層資料遺失可能影響後續資料的交付。QUIC 的資料流機制可減少不同資料流因可靠傳輸順序而互相阻塞的情況，但單一可靠資料流內的資料仍須依要求復原，壅塞控制也仍會影響共用連線。應用程式自身依賴可靠傳輸時，封裝後還可能存在多層回饋。因此，不能將「基於 QUIC」理解為丟包不再有代價，更不能只根據協定說明預測某次網頁載入時間。

認證、憑證與頻寬參數

手動核對時，先確認 Address、Port、認證字串與 TLS 的 Server Name。Hysteria2 服務端必須實際提供對應協定，名稱相似的其他設定不能直接互換。憑證驗證依然重要，名稱錯誤、憑證過期或裝置時間異常都可能影響連線建立。若來源提供混淆等額外參數，應確認雙方都已啟用且內容一致；這類欄位不是密碼的備用欄位，遺漏或不相符會在認證前就造成通訊異常。

部分設定允許指定上行與下行頻寬，用於特定壅塞控制行為。這些數值是傳輸調度的輸入，並非解除限速後的目標保證。填入遠高於實際網路的數字，可能導致持續壅塞、丟包與重傳，甚至影響其他 App 的使用體驗。不同壅塞控制方式對指定數值的使用方法不盡相同，應依來源說明與用戶端實際選項理解。初次測試應採用保守且易於解釋的設定，再透過持續觀察判斷是否有調整的必要。

UDP 可連通是前提，不是保證

部分網路會限制 UDP、造成品質波動，或以不同於 TCP 的方式處理 UDP。在同一地點，一般網頁可直接瀏覽，不代表 QUIC 路徑也能正常使用；連接埠沒有明顯錯誤，也不代表協定交握已完成。若 Hysteria2 只在某個 Wi-Fi 網路下失敗，應先用既有且可用的其他類型比較連線路徑，再確認服務端是否收到請求。不要同時修改認證、Server Name 與頻寬參數，否則無法分辨問題來自網路限制還是欄位錯誤。

在 iPhone 上，高傳輸量會讓無線網路與處理器維持活躍，耗電可能增加；但較快完成相同任務，也可能縮短裝置維持活躍的時間。因此，除了比較傳輸期間的溫度，也應比較完成任務後的總耗電與恢復閒置的速度。高丟包環境中，較積極的傳送策略可能提升傳輸量，也可能增加耗電。結論只能適用於受測裝置、網路與任務，不能推論成「Hysteria2 一定比較耗電」或「QUIC 總是比較省電」。

適合嘗試的前提是已有 Hysteria2 服務、目前網路的 UDP 品質可接受，而且服務確實受高延遲或丟包影響。若網路本身穩定，且用途以短請求為主，改善可能不如持續傳輸明顯。進一步原理可參閱Hysteria2 與 QUIC 技術筆記。測試時若遇到間歇停頓，請記錄當時的網路類型、是否剛切換網路，以及是否剛從閒置狀態恢復，再檢查丟包、壅塞與伺服器負載，避免把所有問題都歸因於頻寬設定不足。

07 / Measurement

iOS 上的速度與耗電測試

先定義要完成的任務

「速度快」至少包含首次回應、持續傳輸量與互動穩定性三個面向。首次回應影響開啟新頁面的等待時間，持續傳輸量影響大型資料傳輸，互動穩定性則關係到即時服務與短請求是否反覆停頓。Connectivity Test 的結果只反映其測試方式涵蓋的部分連線路徑，不代表所有目標、UDP 服務或長時間使用情況。開始比較前，先寫明測試任務，例如連續瀏覽同一組頁面，或傳輸同一份既有測試資料，避免每次操作不同，卻直接比較主觀感受。

要隔離協定差異，理想狀況是使用位置、資源與後半段路徑相近的伺服器。若兩筆設定使用不同伺服器，觀察到的差異只能視為兩套連線方案的差異，不能嚴格歸因於協定。即使位址相同，服務端也可能為不同入口配置不同資源。若手上沒有這些控制條件，仍可實際比較後做出選擇，但結論應表述為「這筆設定在目前網路較適合」，而不是宣稱某種協定具有普遍的效能優勢。

建立可重複的測量流程

使用相同裝置、網路、位置與相近測試時段，並暫停明顯影響結果的背景傳輸。先測試基礎網路是否正常，再啟用一筆設定完成任務，接著切換另一筆設定重複測試。可交替測試順序，以降低網路隨時間變化造成的偏差。每種條件重複數次並記錄結果範圍，不要只保留最快的一次。冷連線與熱連線應分開記錄：前者包含解析與交握，後者可能受連線重用與快取影響，不能混在同一欄取平均。

Wi-Fi 與行動網路應分別記錄，移動中訊號變化尤其容易干擾判斷。測試時不要一邊移動一邊調整參數；若必須驗證切換網路後的恢復情況，應將它列為獨立任務，記錄切換前後請求恢復所需時間及是否需要手動重新連線。遇到偶發失敗時，應保留原有條件重測，而不是立刻更換多個欄位。連續多次穩定完成任務的方案，通常比偶爾出現漂亮峰值、卻經常停頓的方案更適合日常使用。

耗電比較須區分使用中與待機

電池百分比是較粗略的讀數，幾分鐘內細微的變化不足以證明協定差異。螢幕亮度、溫度、訊號強度與背景 App 都可能蓋過協定本身的耗電差異。比較使用中的耗電時，應固定螢幕與任務，觀察完成相同工作量的整體表現；比較待機時，則固定閒置時間與網路環境，確認是否有持續流量或頻繁恢復連線。不要把一次長時間播放影片的任務，和另一筆設定的純待機狀況放在一起，再據此判斷哪個比較省電。

系統電池用量統計與 Shadowrocket 的 Data 可作為觀察參考，但統計方式不同。流量位元組數不能直接換算成耗電量，系統對延伸功能與 App 活動的歸類，也未必能精確反映單一協定的額外耗電。若發現異常，先檢查是否大量重試、定期請求、保活或反覆斷線，再查看 On Demand 的觸發條件。合理設定自動連線有助於符合使用需求，但規則更複雜不代表更省電，觸發結果仍須實際驗證。

排錯記錄只應保留必要資訊：網路類型、協定類型、失敗時段、請求階段與處理結果。對外分享記錄前，請檢查是否包含訂閱網址、認證資料、瀏覽網域或個人網路資訊。訂閱連結通常具有存取憑證的性質，不應整條貼出。需要整理多個來源時，可參閱多個訂閱的分組與整理；先確認測試記錄對應的伺服器，再討論效能，否則重複名稱可能讓比較對象在不知不覺中改變。

08 / Decision

依使用情境選用與最終驗證

先排除不符合條件的組合

選擇順序應為可用性、安全界線、服務相容性，再考慮效能與耗電。先列出既有伺服器實際支援的類型，排除目前網路無法承載或用戶端無法設定必要欄位的組合。接著確認認證與憑證驗證完整，並檢查目標服務是否依賴 UDP、是否需要存取隧道內部位址。只有符合這些條件後，速度比較才有意義。參數清單較短不代表更可靠，方案較複雜也不代表更安全；關鍵是每一層都能清楚說明並正確驗證。

日常瀏覽網頁與使用一般 App，可優先保留已穩定使用、欄位來源明確的方案；不必只因協定名稱不同，就重建所有設定。若需要位址層隧道及特定內部網段，完整的 WireGuard 設定更符合這種用途。高丟包或高延遲環境下，已有的 Hysteria2 服務可列入實測選項。若只有 HTTP 或 SOCKS5 資訊，則必須先了解連線保護方式與服務支援範圍，不能假設名稱簡單就適用於所有敏感連線。

串連協定驗證與規則驗證

匯入完成後，先在 Home 核對選取的伺服器，再檢查 Global Routing。暫時使用 Proxy 有助於判斷部分問題是否來自分流，但不能因此略過最終的 Config 驗證。返回 Config 後，確認啟用的是預期檔案，並查看目標請求最後採用的策略。規則依序由上而下比對，第一個符合的規則會決定處理方式；若前面的廣泛規則已符合，後面的精確規則就不會繼續執行。協定可用與規則正確是兩項獨立的驗收工作。

以下僅為 Shadowrocket 文字設定中的規則片段，用來說明各自職責，並非伺服器參數，也不應直接覆寫既有完整檔案。範例網域僅供說明，PROXY、DIRECT 與 REJECT 代表不同的處理策略。IP-CIDR 可用來表示區域網路位址範圍，FINAL 則處理前面都未符合的連線。使用這些片段前，應確認既有設定中的策略含義符合實際用途；不要盲目擴大 DIRECT 範圍來掩蓋代理問題，也不要把所有本機請求都交給遠端處理。

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

DNS 也應納入最後驗證。網域規則與位址規則依賴的資訊不同，解析結果、快取以及 IPv4 / IPv6 連線能力都可能改變規則比對結果。某個網域偶爾指向不同位址，不一定是協定參數變了。先確認記錄中的請求網域或位址、實際符合的規則及套用策略，再判斷是否需要調整規則。更詳細的順序說明請參閱規則優先順序與 FINAL 後備策略，不要把協定手冊中的連線測試當成分流設定教學。

建立可復原的日常設定

最後應保留一套已驗證的基準設定：協定類型與重要參數來源明確，日常目標可正常使用，閒置或切換網路後也能依預期恢復。嘗試新方案時，請複製設定並清楚命名，不要直接覆寫唯一可用的項目。訂閱更新後應再次核對選取的設定，因為服務端可能變更位址或欄位；重複名稱也可能造成誤選。更換裝置前應備份必要設定，還原後重新確認授權、目前使用的 Config 與實際策略，不要假設所有本機狀態都會隨 App 購買紀錄一併還原。

若仍無法定位問題，請依序整理「基礎網路是否正常、端點是否可連、TLS 是否成功、認證是否通過、目標是否套用預期策略」等資訊，再參閱疑難排解。若要重新進行匯入與首次連線流程，請返回使用教學。最終選用結果應是一套可說明、可重測且可還原的設定，而非脫離網路條件的協定排名。用戶端與系統需求請以 App Store 頁面標示為準；伺服器參數則應向你的服務商確認，兩者不可混為一談。