Shadowrocket 協定技術參考

01 · 協定選用：先分清連線的不同層

可選範圍取決於既有服務

在 Shadowrocket 的 Add Server 中選擇類型，是指定用戶端應採用哪種通訊格式，並不會讓遠端自動改用該協定。同一個 Address 與 Port 不一定能接收多種協定；只有伺服器明確提供相應入口，切換類型才有意義。開始前，請先整理服務說明中的協定名稱、地址、連接埠、驗證資料與傳輸設定。若透過 Subscribe 匯入，請先保留匯入結果，不要只因某個名稱看起來熟悉，就把已辨識的類型改成其他選項。

協定主要規範用戶端與伺服器如何交換驗證資訊和代理請求；傳輸方式決定這些訊息透過什麼通道傳送；TLS 則可為通道提供加密與伺服器身分驗證。三者常出現在同一份連線資料中，但作用各不相同。例如 VLESS 與 WebSocket 並非互斥的協定選項：前者描述代理層，後者可能負責外層傳輸。拆分這些層次，才能理解為何 UUID 正確，連線仍可能因路徑或憑證問題而失敗。

將一條連線拆解成可逐項核對的設定

這些項目之間有先後依賴。地址解析失敗時，修改驗證欄位通常無濟於事；伺服器已完成 TLS 交握後才拒絕驗證，繼續調整 DNS 也無法解決密碼錯誤。記錄中最先出現、且直接與故障相關的訊息，通常比最後一則籠統的逾時提示更有參考價值。記下錯誤發生在解析、建立通道、身分驗證或存取目標哪個階段，就能大幅縮小排查範圍。

速度與耗電沒有固定排名

在 iOS 上，實際體驗同時受無線訊號、往返延遲、封包遺失、伺服器負載與目標網站影響。協定額外開銷只是其中一項。交握步驟較少的設計，可能在短連線較多時較容易看出差異；傳輸大型檔案時，鏈路容量與壅塞控制通常更重要。不要把一次 Connectivity Test 的結果當成整條存取路徑的傳輸量結論，也不要據此推斷所有目標的存取表現。

耗電也不能只看協定名稱判斷。加密運算會消耗資源，但頻繁重新連線、無線模組持續運作、過於密集的保持連線封包與反覆重傳，也可能是主要耗電來源。比較時應固定裝置、網路、螢幕亮度與工作內容，分別觀察首次開啟、持續傳輸和待機階段。若未控制這些條件，就不適合斷言某種協定一定更省電或更快。

還要區分「支援某種協定」與「支援該協定的所有組合」。特定外層傳輸、驗證擴充或特殊欄位是否可用，應以目前 Shadowrocket 的實際介面及既有服務說明為準。資料中若出現用戶端沒有對應欄位的選項，不要隨意填入備註或其他輸入框。請先確認該選項是否屬於另一層設定，再決定是否向原服務提供者詢問。

02 · Shadowsocks：共用金鑰與加密方法

設計目標與連線模型

Shadowsocks 是以加密代理連線為核心設計，通常使用共用金鑰保護通訊。用戶端接收應用程式的請求，依約定格式將目標資訊與資料交給遠端，再由遠端連線至目標。它與完整的 IP 層通道並非同一概念：協定主要處理代理轉送，不會只憑伺服器地址就自動涵蓋所有系統路由、內部地址配置或對等端關係。這種設計讓參數較集中，但仍須由用戶端的路由策略決定哪些請求會進入代理。

理解 Shadowsocks 時，最重要的是把加密方法視為協定相容性的一部分，而不是可以任意調整的強度滑桿。用戶端與伺服器必須採用一致的方法、金鑰規則與訊息格式。資料中看似只差幾個字元的方法名稱，可能代表不同設計，不能只因名稱相近就互換。較新的方法系列可能也對金鑰資料的編碼或長度有特定要求，不能假設任何一般文字密碼都符合條件。

Address、Port、Password 與加密方法的對應關係

Address 請填入既有服務提供的主機名稱或 IP 地址，不要將整段分享連結放進地址欄位；Port 是服務端監聽該協定的連接埠，不是網頁地址中的任意數字。Password 必須完整保留原值，尤其留意複製時是否多出前後空格、換行或全形標點。加密方法請逐字核對，不能因為介面提供多個選項，就以看起來較新的名稱取代服務端設定。

常見的 AEAD 方法會結合資料保密與完整性驗證，接收端可拒絕未通過驗證的訊息。金鑰或方法不符時，可能只看到連線中斷、目標沒有回應或驗證相關錯誤，不一定會出現明確的「密碼錯誤」訊息。因此，遠端連接埠可連通，不代表參數已全部正確；還必須進一步確認用戶端能否透過該連線存取實際目標。匯入分享連結後，也應檢查類型與欄位，不能只看清單中是否出現名稱。

TCP、UDP 與額外傳輸並非同一個開關

網頁常見的 TCP 流量，與依賴 UDP 的應用程式流量，可能有不同結果。服務端、用戶端設定與中間網路都必須允許相應轉送，才能形成完整路徑。只開啟一個與 UDP 相關的選項，不會讓不支援該功能的遠端自動具備支援；反過來說，某個網頁能正常開啟，也不足以證明 UDP 路徑可用。應依實際應用需求分別驗證，不要把所有故障都歸因於伺服器完全無法連線。

部分連線資料還包含額外傳輸或封裝設定。這些設定不要與 Shadowsocks 的密碼和加密方法混為一談。只有既有服務明確提供，且目前介面有相應設定欄位時，才照原值填寫。若匯入連結缺少額外參數，手動補齊時請先記錄原始設定，再一次只修改一項；連續更換方法、連接埠和額外傳輸，會讓後續難以判斷是哪項設定造成變化。

如何在行動裝置上評估取捨

Shadowsocks 的參數層次較集中，適合用來理解「入口、金鑰、方法」之間的對應關係，但不代表它在任何網路環境都較有優勢。持續傳輸時的表現仍受伺服器出口與鏈路封包遺失影響；短時間工作則也會受到名稱解析與連線建立的影響。iPhone 從 Wi-Fi 切換到行動網路後，既有連線可能需要重新建立，恢復速度取決於整條鏈路，不能只從協定名稱推斷。

排錯時可分四步縮小範圍：先確認 Address 能否解析，再確認連接埠是否屬於目前入口，接著核對加密方法與金鑰，最後區分 TCP 與 UDP 的工作差異。若連線已建立但只有部分網域失敗，請前往本頁的驗證與分流章節檢查規則與 DNS。不要為了解決單一目標的問題，反覆修改已能成功驗證的協定參數。

03 · VMess 與 VLESS：驗證、傳輸及安全層

欄位相似不代表兩者可以互換

VMess 和 VLESS 都常使用 UUID 作為使用者識別，因此匯入後可能會看到相似的地址、連接埠與身分欄位。但兩者並非同一種通訊格式，不能只更換類型而保留其他項目不變。VMess 具有自己的驗證與資料保護機制；VLESS 的基礎設計較精簡，本身不提供等同於 VMess 的負載加密，通常需要搭配正確設定的安全傳輸。應先依既有伺服器入口決定採用哪一種。

設計上的差異不能直接換算成效能高低。VLESS 減少部分代理層職責後，外層 TLS 或其他安全機制仍有各自的成本；VMess 的實際表現也會受傳輸方式、多工與鏈路狀態影響。若一份資料只寫「VLESS」，卻沒有說明外層安全設定，資訊仍不完整。不要看到有驗證欄位，就誤以為通道已同時具備伺服器身分驗證與資料加密。

UUID、時間與驗證失敗

UUID 是結構化的識別值，應完整保留字元與分隔符號，不能填入顯示名稱、訂閱地址或其他密碼。VMess 的驗證設計與時間有關，裝置時鐘明顯不準時可能影響連線，因此驗證失敗時要檢查系統日期與時間是否正確。匯入資料中的相容性欄位，應以服務端說明及目前用戶端選項為準；不要照抄舊教學中的數字，覆蓋已正常匯入的值。

UUID 正確不代表所有驗證條件都已符合。伺服器可能已停用某位使用者、限制特定入口，或更新連線資料。訂閱更新後仍無法連線時，請比較新舊記錄的協定類型、連接埠與傳輸項目，不要只比對名稱。名稱相同的兩條連線可能指向不同設定；名稱不同也可能只是同一入口換了備註。判斷依據始終應是實際欄位。

WebSocket、Host、路徑與 SNI

WebSocket 為代理資料提供一種外層傳輸方式，其路徑必須符合伺服器的路由設定。路徑通常包含開頭的斜線，大小寫及其他字元也可能影響比對。Host 可用於 HTTP 請求的虛擬主機選擇；SNI 則在 TLS 交握時用來宣告伺服器名稱。兩者位於不同層次，即使某份資料中的值相同，也不能因此認定它們永遠都必須相同。

使用 IP 作為 Address 時，服務說明可能仍要求填寫網域形式的 SNI，因為連線地址與憑證身分並非同一回事。正確做法是使用已提供且能通過驗證的名稱，而不是關閉驗證來繞過錯誤。若外層傳輸尚未成功，代理層的 UUID 甚至可能還沒機會交由服務端檢查，這也是需要先區分 TLS 錯誤、路徑錯誤與驗證錯誤的原因。

依工作需求檢查，不按名稱排名

在行動網路中，額外封裝會增加交握與封包開銷，也可能改變連線恢復方式；實際影響仍須依工作長度觀察。短連線較多的網頁、長時間保持的工作階段和持續下載，關注重點並不相同。若某組合在 Wi-Fi 下正常、在行動網路下失敗，請先確認相同入口的地址解析、外層傳輸與連接埠可達性，再分析協定本身。Config 的整體用法可參閱功能說明，避免將路由選擇問題誤判為協定相容性問題。

04 · Trojan：TLS 身分驗證與密碼驗證

通道安全與使用者驗證各自負責什麼

Trojan 採用以 TLS 為基礎的連線設計，在受保護的通道中處理代理請求與使用者驗證。理解時，應將伺服器身分與使用者身分分開：TLS 憑證協助用戶端確認連線到哪一部伺服器；Password 則讓伺服器判斷使用者是否有存取權限。密碼正確但憑證驗證失敗，仍不應視為連線正常；憑證驗證通過但密碼不符，也無法使用代理。

這種分工表示 TLS 不是用來「嘗試加速」的可選裝飾。一般 Trojan 連線不能為了排錯而任意關閉 TLS，同時期待遠端仍能辨識原有協定。若既有資料還包含特殊傳輸設定，應完整核對相應組合，不要假設所有 Trojan 連線都只有三個欄位。基礎協定與額外承載方式必須相互吻合，任何一層出錯都可能讓最終請求無法完成。

Address、Port、Password 與 SNI 的填寫範圍

Address 決定網路連線的目的地，可以填入服務提供的網域，也可以使用說明中明確指定的 IP。Port 必須是該 Trojan 入口的連接埠；看到 TLS 不代表連接埠一定是某個固定值。Password 請完整照原始資料填寫，並留意複製工具是否帶入看不見的換行。SNI 應使用服務說明指定的伺服器名稱；它可能與 Address 相同，也可能在 Address 為 IP 時另用提供的網域。

憑證驗證會涉及名稱比對、有效期限、信任鏈與裝置時間等條件。SNI 不是隨便填入網域就能取得有效憑證，而是向遠端宣告預期名稱，並讓後續驗證依此進行。若憑證名稱不符，請先檢查輸入是否有誤、服務資料是否過期，以及伺服器憑證設定；若裝置日期不正確，則先修正系統時間。關閉驗證會改變連線的安全性，不應作為長期解決方式。

如何依連線失敗的順序判讀問題

如果 Address 無法解析，問題發生在連到伺服器之前；如果遠端拒絕連線，先檢查連接埠與監聽狀態；如果出現 TLS 名稱或信任錯誤，應優先檢查身分驗證層。只有 TLS 通道建立後，服務端才有機會繼續處理 Trojan 驗證與目標轉送。依此順序檢查，可避免在憑證尚未通過時反覆更改 Password，也能減少沒有方向的參數組合測試。

也可能通道與驗證都已完成，但目標網站仍無法開啟。此時應檢查目標網域解析、遠端連線至目標的狀況，以及本機請求是否確實選用了這條連線。若只有一個網站失敗，不要立刻認定整個 Trojan 入口故障。可改用另一個允許存取的目標進行比對，並參照請求記錄確認錯誤發生階段，不要只看 Home 中的連線開關狀態。

行動網路表現與使用建議

TLS 建立連線需要交握，在往返延遲高或頻繁重新建立連線時，成本較容易顯現。持續工作階段建立後，實際傳輸則更受鏈路容量、壅塞與目標回應速度影響。不能因為採用 TLS 就認定一定較慢，也不能因為某次測試耗時較短，就認為後續工作始終穩定。iOS 的無線網路切換、休眠與重新喚醒都可能改變既有連線狀態，應另外觀察恢復過程。

已有完整 Trojan 參數的使用者，選用時應著重確認憑證能否驗證、地址與 SNI 是否明確，以及網路切換後能否恢復，而不是額外堆疊未知設定。如需逐欄位檢查，可閱讀Trojan 參數填寫說明。請保留一份已確認可用的設定，再複製一份進行測試；訂閱更新後，也要確認檢查的是目前生效的記錄，而不是舊的手動副本。

05 · HTTP 與 SOCKS5：通用代理的能力範圍

HTTP 代理與 HTTPS 網站是兩回事

HTTP 代理源自通用代理存取模型，可處理符合其規範的請求，並透過 CONNECT 等機制建立通往目標的通道。常見誤解是：目標網址使用 HTTPS，用戶端與代理伺服器之間就一定採用 TLS。實際上必須分別檢視這兩段連線。網站的 HTTPS 主要保護用戶端與目標網站之間的應用程式資料；代理入口本身是否以 TLS 保護，則取決於代理類型與入口設定，不能從目標網址推斷。

即使 CONNECT 之後的目標內容受到 HTTPS 保護，代理仍須知道要連線至哪個目標，並負責轉送。因此，目標內容加密不代表代理驗證資訊及所有連線中繼資料也受到同等保護。若既有服務提供加密的 HTTP 代理入口，請依明確說明選擇相應類型與安全選項；不要隨意將一般 HTTP 入口改成其他類型，再把交握失敗誤認為使用者名稱錯誤。

SOCKS5 的協商、驗證與 UDP

SOCKS5 是用於通用連線轉送的協定，透過協商選定驗證方式與請求操作。它能傳遞目標地址與連接埠，也定義了 UDP 關聯機制，但基礎協定本身不提供 TLS 那樣的通道加密。使用者名稱與密碼用於存取控制，不能等同於加密能力。填入憑證後，仍須了解用戶端到代理之間採用何種保護方式，以及服務端實際啟用了哪些功能。

SOCKS5 規範包含 UDP 相關功能，不代表每個服務入口和每條網路路徑都支援 UDP。服務端實作、存取策略、中間網路與用戶端目前設定都會影響結果。TCP 網頁瀏覽正常、某個 UDP 應用程式卻失敗時，請先確認服務是否允許 UDP，再核對轉送路徑。不要只因協定名稱寫著 SOCKS5，就認定故障與協定或入口能力無關。

欄位較少，也要仔細核對

這兩類連線常見欄位包括 Address、Port，以及服務要求時的使用者名稱與密碼。是否需要驗證應依既有資料設定，不能把空白使用者名稱視同隨意填寫的名稱。若憑證包含特殊字元，請優先使用可靠的匯入方式，或分別填入獨立欄位，避免手動組合分享連結時發生編碼問題。備註名稱僅供本機辨識，不能取代任何驗證欄位。

名稱解析與實際使用情境

請求可能帶有網域，也可能在本機解析後改帶 IP，這會影響名稱解析發生的位置及後續規則判斷。不能只看「HTTP」或「SOCKS5」標籤，就推斷所有網域都一定會在遠端解析。排查時應一併檢查 Shadowrocket 的 DNS 設定、目標請求形式與生效規則。如果同一目標以網域存取失敗、改用已知地址卻能連線，再進一步檢查名稱解析路徑，不要立刻更換使用者名稱或連接埠。

在已設定的辦公室代理、測試環境，或明確提供通用代理入口的情境中，這些類型便於與既有基礎架構整合，但不能通用取代其他協定。在 iPhone 與 iPad 上，實際表現仍取決於驗證、通道保護、目標連線能力與系統網路。使用期間若要還原原本策略，請記錄修改前的 Global Routing 狀態與 Config，避免一次測試影響後續所有應用程式。常見操作問題可前往疑難排解依現象查閱。

06 · WireGuard：對等端、金鑰與通道地址

從代理請求轉向 IP 層通道

WireGuard 是為 IP 層通道設計的協定，使用公鑰識別對等端，並將網路封包封裝在 UDP 中傳送。相較於只需填入地址與密碼的代理入口，它還需要設定通道內部地址、對等端身分及允許處理的地址範圍。了解這些欄位，才能判斷資料是否完整。只知道遠端 IP 與連接埠，還不足以建立正確連線；伺服器也必須辨識用戶端公鑰，並為其設定相應地址與轉送方式。

在 Shadowrocket 中使用 WireGuard 時，也要區分 App 接管流量與特定遠端協定的封裝。iOS 顯示 VPN 相關狀態，表示用戶端取得了系統網路處理能力，並不代表目前所有對外連線都使用 WireGuard。最後仍須檢查已選取的伺服器類型、Global Routing 與 Config；也不能只憑系統 VPN 圖示，就推斷通道內部地址與遠端對等端已能正常通訊。

私鑰、公鑰與選用的共用資料

用戶端私鑰用於本機身分識別與金鑰協商，應妥善保存在自己的裝置與備份中；伺服器公鑰則用來識別遠端對等端。這兩個欄位不能對調，也不能以同一個值填滿所有金鑰欄位。用戶端公鑰由相應私鑰產生，遠端須依此公鑰識別用戶端。若更換用戶端私鑰卻未同步更新遠端設定，即使 Endpoint 沒有變更，原有授權關係也可能失效。

部分服務還會提供額外的預先共用金鑰，在既有公鑰機制上加入共用資料。它既不是用戶端私鑰，也不是伺服器公鑰，必須依資料分別填寫。不要將真實金鑰貼在公開截圖、錯誤回報或文章留言中；排錯時可以說明欄位是否存在、格式是否符合要求，但不要公開原始值。更換裝置時也要留意備份檔可能包含這些敏感資料，不能只把它當成一般規則檔。

Endpoint、地址範圍與 DNS

Endpoint 指向遠端實際可連線的地址與 UDP 連接埠；通道內部地址則是通道中的網路身分，兩者位於不同網路層。若將內部地址誤填為公開入口，或將 Endpoint 填入內部地址欄位，都會導致連線失敗。地址範圍相關設定用來表示允許處理哪些目的地址或對等端地址關係；實際作用還須配合用戶端的路由整合方式理解，不能簡單等同於 Shadowrocket 的網域規則清單。

IPv4 與 IPv6 也須分別考量。只設定其中一種地址族的路徑，不代表另一種也能以相同方式連線。如果網域優先回傳 IPv6，而通道或遠端轉送缺少相應支援，就可能有部分目標無法存取。DNS 伺服器是否可連線同樣重要：指定內部 DNS 地址後，應確認它確實能透過既有通道存取。資料中寫有 DNS，不代表解析路徑已自動正常。

保持連線、MTU 與行動網路切換

保持連線功能可在需要時維持網路映射，尤其適用於中間設備會清除閒置 UDP 狀態的環境。不過，過於頻繁的保持連線封包可能增加無線網路喚醒次數，因此不要為了追求「持續在線」就任意縮短間隔。是否需要使用及採用何種數值，應依既有服務說明與實際網路狀況決定。行動網路切換會改變用戶端對外可見的地址；WireGuard 的設計允許對等端在驗證通訊後適應地址變化，但能否恢復仍取決於新路徑能否傳送資料。

MTU 會影響單一封包可承載的大小。數值過大，某些路徑可能發生分片或封包遺失；數值過小則會增加封裝比例與封包數量。若出現小型請求正常、大型頁面或持續傳輸停滯的情況，可將路徑 MTU 列為排查項目，但不要把它當成所有逾時問題的萬用原因。先核對金鑰與交握，再確認內部地址、DNS 與目標轉送，最後在有明確證據時調整 MTU。設定備份與換機注意事項請參閱設定移轉說明。

07 · Hysteria2：QUIC、UDP 路徑與壅塞取捨

設計理念與相容性範圍

Hysteria2 使用以 QUIC 為基礎的傳輸，依賴 UDP 路徑，並結合驗證與 TLS 相關機制建立代理連線。其設計著重於複雜鏈路下的資料傳輸與壅塞處理，但不代表任何網路環境都能獲得更高速度。協定必須先有可用的 UDP 通道；若目前網路無法連到遠端對應連接埠，調整頻寬參數或密碼也無法突破這項基本限制。

Hysteria2 中的數字是協定名稱的一部分，不是本頁所述的 Shadowrocket App 版本。匯入時，請確認服務說明確實提供 Hysteria2，不要只因名稱相似就選擇該類型。協定世代、傳輸格式與選用設定可能有相容性限制，不能假設相同地址與驗證資料在不同類型間都通用。目前 App 是否提供某項額外選項，應以實際介面與既有服務說明為準。

入口、驗證與憑證須分別檢查

先核對遠端 Address 與 UDP 連接埠，再檢查驗證資料與 TLS 伺服器名稱。地址指向實際通訊入口；SNI 用於宣告伺服器名稱並進行憑證驗證。兩者可依服務設定採用不同表示方式，但不能任意猜測。若使用 IP 連線卻需要網域驗證，請使用服務明確提供的網域；不要把關閉憑證驗證當成補足資料不足的辦法。

部分連線資料還包含混淆或其他額外參數。這些參數不能取代驗證密碼，也不是預設必須啟用的通用開關。只有伺服器已設定相應功能，用戶端才應填入一致的資料。遺漏、拼錯或多餘啟用，都可能讓封包在進入驗證階段前就無法正確處理。排錯時應依資料逐項比對，不要同時更動驗證、安全與額外設定碰運氣。

填寫頻寬不等於設定連線的實際能力

如果目前設定提供上行、下行頻寬或壅塞相關選項，請先了解它們屬於傳輸控制資訊，不是對服務端容量的保證。某些控制模式會參考頻寬估算，其他模式則可能由實作自動判斷；實際生效條件請以相關設定說明為準。填入很大的數值不會提升無線訊號、伺服器出口或目標網站的能力，反而可能造成更多封包遺失、排隊，或干擾同一網路上的其他工作。

填寫時也要區分位元與位元組，並留意介面要求的單位。家用寬頻的標示速率不等於 iPhone 目前無線連線的穩定可用速率，更不等於行動網路的上行能力。若沒有可靠的測量結果，請優先保留既有資料建議值，或使用明確支援的自動模式，不要依據一次短暫峰值填寫。比較前後效果時，應觀察完成時間、失敗率與其他 App 是否受到明顯影響，不要只看瞬間峰值。

封包遺失、網路切換與耗電觀察

QUIC 在 UDP 上處理連線與可靠傳輸，並為不同資料流提供自己的管理機制，但無法消除實體鏈路中的封包遺失。網路品質變差時，重傳與壅塞控制仍會發揮作用；無線訊號反覆變化也可能使先前的估算失準。有些環境對 UDP 與 TCP 的處理方式不同，因此同一裝置上，TCP 類型入口可用，不代表 Hysteria2 的 UDP 路徑一定可用。

在 iOS 上，持續傳送、重傳及維持網路活動都可能影響耗電。請分別觀察持續傳輸與閒置階段，並盡量排除螢幕、背景同步及裝置溫度造成的干擾。切換 Wi-Fi 與行動網路後，也不能只根據 QUIC 的一般能力就認定工作階段一定會不中斷；伺服器、用戶端實作與新路徑條件都會影響結果。若主要用途只是短時間瀏覽，而現有其他連線已經穩定，就沒有必要只為了協定名稱更換所有設定。

建議先在相同網路、相同目標與相近時段確認基本連線，再比較多次工作的完成情況。如果只有 UDP 入口失敗，請優先蒐集連接埠可達性與路徑資訊；若所有入口都失敗，則檢查裝置網路與目標。將「傳輸無法建立」和「已建立但工作速度較慢」分開處理，才能避免用不相關的參數調整掩蓋真正原因。

08 · 從協定到實際請求：驗證、規則與排錯

先建立可重複的驗證流程

核對完協定參數後，回到 Home 選取要驗證的連線，再檢查 Global Routing。設定模式對應 Config，會依目前設定中的規則決定策略；代理模式對應 Proxy，會讓相關流量依所選代理路徑處理；直連模式對應 Direct，主要用於直接存取。三者都是路由模式，不是不同的遠端協定。Direct 模式下某個網站正常，不能證明剛才填寫的 Trojan 或 Shadowsocks 已能連線。

測試前先記錄原本的模式與目前 Config，再選一項明確工作，例如開啟同一個網頁並確認內容載入完成。Connectivity Test 可作為連線狀況的參考，但結果會受測試方法、目標與當時網路影響，不能取代實際工作測試。系統連線開關已開啟，只表示用戶端正在接管網路流量，不代表每個請求都成功經過遠端。驗證應涵蓋「選取正確記錄、請求採用預期策略、目標存取完成」三個環節。

規則順序會影響觀察結果

Config 中的規則由上而下逐條判斷，命中第一條後便決定採用的策略。PROXY 表示交由代理策略處理，DIRECT 表示直接連線，REJECT 表示拒絕請求。即使協定參數完全正確，目標若命中 DIRECT，也不會依預期經過代理；若先命中 REJECT，也不會因後面有 PROXY 就繼續嘗試。排錯時先確認實際命中的規則，不要直接修改已通過驗證的連線資料。

以下是用來說明順序的 Shadowrocket .conf 規則片段，不含伺服器資訊。例外網域放在範圍規則之前，私有地址區段採用 DIRECT，最後以 FINAL 處理前面未命中的請求。範例網域僅供說明，不代表實際服務；不要把這幾行當成適用所有環境的完整設定。

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

如果將 DOMAIN-SUFFIX 放在前面，ads.example.com 會先符合範圍規則，後續的精確拒絕規則就沒有機會生效。IP 規則是否參與判斷，也與請求中可用的地址資訊及解析方式有關；不要只看規則文字，就推斷每個網域一定會命中某個地址區段。更多規則排列方式請參閱規則順序與 FINAL 說明；首次操作仍以快速入門教學為主。

依故障層次決定下一步

每次只修改一項，並記錄修改前後的具體結果。若更新 Subscribe 後記錄有所變動，請先確認目前選取的仍是預期入口；手動副本不一定會隨訂閱更新。回報問題時可提供協定名稱、錯誤階段、網路類型與已遮蔽敏感資料的欄位結構，但應移除完整訂閱地址、Password、UUID 與私鑰等敏感資訊。記錄檔也可能包含存取目標，分享前請先檢查。

依工作需求做出最終選擇

需要連接既有通用代理環境時，先核對 HTTP 或 SOCKS5 的驗證、保護方式與所需功能；已有 Shadowsocks、VMess、VLESS 或 Trojan 入口時，重點在於加密方法、傳輸與 TLS 設定是否一致；已有 WireGuard 資料時，檢查對等端、內部地址與允許範圍；已有 Hysteria2 入口時，優先確認 UDP 路徑與控制參數。這些是排查重點，不是效能排行榜。

最後保留的連線應具備完整資料、身分驗證符合預期、常用工作能重複完成，並且在實際網路切換與待機情境下表現可接受。不要為了單次測試數字較小，就犧牲正確的憑證驗證，或反覆修改已穩定的設定。App 購買、系統相容性與重新取得方式，請返回App Store 正版下載指南；連線狀況與介面操作可繼續查閱疑難排解。本頁說明判斷依據，教學則會將這些判斷串連成可執行的首次設定步驟。