Shadowrocket
協定詳解與選擇

設計背景與主要取捨

Shadowsocks 是為加密代理連線而設計，常見設定包含伺服器位址、連接埠、加密方法與密碼。它不像完整的虛擬網路通道那樣要求使用者設定介面位址與整套路由，而是由用戶端將相應請求轉送至遠端。欄位簡潔有助於人工核對，但不代表所有方法都能互換；不同協定世代、加密方法與擴充選項都可能改變相容條件。收到一筆設定時，應先確認完整方法名稱，而不只是記住 Shadowsocks 這個總稱。

常見的 AEAD 方法在提供機密性的同時，也會驗證訊息以偵測資料是否遭到竄改。較新的協定設計可能調整工作階段、防重播機制及金鑰格式，因此不能將任意文字密碼填入所有方法。特別是要求特定長度編碼金鑰的方法，憑據必須符合該方法的格式。此處不會只憑名稱判斷哪種方法一定更快或更安全；實際可選範圍首先受遠端實作與目前 App 支援情況限制，再由裝置和網路測試結果決定。

Address、Port、Method 與 Password

Address 填入網域或 IP 位址，Port 填入服務監聽的連接埠，兩者應取自同一份有效資訊。網域格式不要加上網頁路徑，也不要將完整訂閱連結貼進伺服器位址欄。Method 必須與遠端設定完全一致，Password 則應原樣保留，尤其要留意複製時的前後空格、換行與全形符號。若訂閱中有名稱相同的項目，不要只憑顯示名稱認定它們相同；可分別核對位址、連接埠和方法，避免修改到另一筆已失效的項目。

部分既有設定還包含外掛或額外傳輸參數，但這些並非所有 Shadowsocks 連線都必須填寫。只有遠端明確使用相應功能，且目前 App 能設定對應參數時才需要填入。不要照著他人的截圖任意加入 TLS、路徑或 Host，以為層數越多就越可靠。若匯入後出現未知欄位或資訊缺漏，應向原始資訊提供者確認相容格式，不要以不斷猜測參數取代核對。

TCP、UDP 與行動裝置上的表現

網頁瀏覽通常主要使用 TCP，也可能涉及以 UDP 為基礎的應用程式協定。Shadowsocks 項目能處理哪些流量，取決於用戶端、遠端與中間網路是否共同支援相應轉送。一個網頁能開啟，不足以證明 UDP 鏈路正常；反過來，某個即時 App 無法使用，也不能直接證明密碼錯誤。應先用一般網頁確認基本連線，再用確實需要 UDP 的目標單獨測試，並檢查遠端相關連接埠與網路政策。

在 iOS 上，連線結構較直接時，日常短請求可能較容易穩定處理，但延遲與傳輸量仍取決於實際路徑。持續傳輸時，加密處理、無線訊號與伺服器傳送能力都會影響耗電；少量存取時，建立連線與喚醒無線網路可能更為關鍵。若網路不佳而反覆逾時，換用加密方法未必有幫助。先區分「尚未建立連線」與「連線後傳輸緩慢」，再決定要檢查入口可連線性或持續傳輸條件。

適用情境與排錯範圍

如果既有伺服器只提供 Shadowsocks，正確做法就是依原始資訊完整匯入，不必為了協定名稱而更換。若同一伺服器提供多種相容選項，可將欄位較少的選項作為比較基準，方便定位基本問題。發生故障時，先檢查 DNS、連接埠、Method 和 Password，再確認 UDP 與附加選項；若切換網路後恢復，應繼續檢查網路條件，而非反覆重設憑據。規則分流也須分開核對，避免把已符合 DIRECT 規則的請求誤當成 Shadowsocks 測試結果。

以 TLS 為基礎的設計取捨

Trojan 將代理工作階段建立在 TLS 連線中，並透過相應的密碼驗證識別使用者。理解時應將外層 TLS 與內部驗證分開：TLS 負責建立安全通道並驗證相應的伺服器身分，密碼則負責協定層的存取驗證。TLS 握手成功不代表密碼一定正確；密碼正確也無法補救憑證名稱不符。相較於只核對一種加密方法的設定，Trojan 更需要確認網域、憑證與入口之間的對應關係。

這種設計運用成熟的 TLS 生態系，但也必須符合憑證有效期限、名稱驗證與握手協商等要求。它不等同一般網頁連線，也不能把任何支援 HTTPS 的位址當成 Trojan 伺服器。只有遠端實際提供相應服務並設定好驗證資訊，用戶端才可能完成整個工作階段。使用者需要的是一份完整且既有的伺服器資訊，而不是根據網站位址和常見連接埠自行拼湊設定。

Address、Password 與 SNI 各自的用途

Address 是建立網路連線的入口，Port 是服務連接埠，Password 應與遠端驗證設定一致。SNI 會在 TLS 握手時傳送目標名稱，伺服器可能據此選擇憑證與處理路徑。即使連至 IP 位址，仍可能需要指定網域形式的 SNI；反之，Address 已是網域，也不代表可以忽略原設定要求。若既有資訊明確列出 SNI，就應保留，不要直接以目前顯示的伺服器名稱取代。

憑證驗證通常要求憑證鏈可信、憑證仍在有效期限內，且涵蓋預期驗證的名稱。發生錯誤時，先檢查裝置時間與名稱，再確認伺服器端是否正確部署憑證。若只是變更連線入口，應依伺服器設定說明確認相關欄位，而不是在用戶端關閉驗證。略過驗證會削弱伺服器身分檢查，既無法修復密碼錯誤，也不能保證連線至預期的服務。

握手、應用程式請求與 UDP 的範圍

TLS 握手成功只代表鏈路中的其中一段正常。接下來仍須通過 Trojan 驗證、由遠端連線至目標並傳回資料。因此，「握手成功但頁面無法載入」應繼續檢查驗證資訊與遠端存取；「握手前就逾時」則適合先檢查解析與入口可連線性。若只有特定網站無法使用，也應查看規則比對結果與 DNS 解析結果。將各階段分開檢查，可避免把所有問題都歸咎於憑證，或在密碼欄反覆修改原本正確的資訊。

Trojan 的 UDP 轉送能力需要用戶端與伺服器共同支援，實際表現也會受到承載方式影響。TCP 網頁存取正常，不足以證明即時互動流量也能正常運作；在某些承載架構中，丟包可能讓等待時間明顯增加。應以目標 App 的實際服務進行測試，不要以單一網頁結果代替。含有額外傳輸層的項目也應依原始設定核對，不能把基本 Trojan 欄位清單當成所有變體的通用清單。

iOS 上的速度與耗電判斷

TLS 握手需要網路往返與運算，遠距離路徑上的首次連線可能較容易感受到等待；後續連線能否降低成本，取決於具體工作階段與實作方式。持續傳輸時，路徑品質、壅塞狀況與遠端效能往往比首次握手更重要。就耗電而言，穩定連線與減少重試通常有幫助，但長時間維持連線也會增加無線網路活動。不能只憑「使用 TLS」就判定耗電較高，也不能保證它在所有網路環境下都比其他協定更好。

若既有伺服器提供穩定的 Trojan 設定，且憑證名稱、密碼與傳輸資訊齊全，可將其作為一種可驗證的選項。比較時應維持目標與網路不變，先確認能否可靠建立工作階段，再觀察持續傳輸與背景執行情況。若更新後無法連線，應檢查訂閱是否同步更新憑證相關名稱或入口變更；如需了解更新流程，可繼續閱讀 訂閱手動與自動更新說明，不要以猜測新參數取代設定同步。

通道協定與代理項目的差異

WireGuard 的設計目標是建立結構精簡的加密網路通道，採用固定的密碼學組合，並以公鑰識別對端。它處理的是網路層封包，因此設定中會出現介面位址、對端金鑰與路由範圍等概念，而不只是代理密碼。在 Shadowrocket 中使用相應項目時，也須配合用戶端的接管與規則機制理解；不能未經核對，就將獨立通道設定中的每個選項視為與 App 中某個欄位完全相同。

與使用者名稱或 UUID 驗證的協定不同，WireGuard 需要本端私鑰與遠端公鑰正確配對。遠端也必須識別本端相應的公鑰，並為其設定適當的位址與可達範圍。只複製 Endpoint，或只取得遠端公鑰，都不足以建立完整連線。若既有資訊來自設定檔，應先辨識 Interface 與 Peer 分別描述哪一端，再依目前 App 支援的方式匯入，並保留原始檔案供逐項比對。

金鑰、Endpoint 與位址欄位

PrivateKey 是本端的機密資訊，不應出現在公開截圖或求助內容中；Peer 中的 PublicKey 通常指遠端公鑰，兩者不能互換。有些設定還包含 PresharedKey，這是額外的共享機密，雙方也必須一致。此處不提供金鑰範例，避免格式示意被誤認為可用憑據。向他人描述問題時，只需說明欄位是否存在、匯入時是否出錯及錯誤類別，不必提供真實金鑰。

Endpoint 表示可連線至遠端的位址與 UDP 連接埠；Address 通常表示分配給本端的通道內位址，兩者在不同位址空間中扮演不同角色。DNS 設定會影響相應名稱解析，AllowedIPs 在 WireGuard 的語意中則與對端可處理的位址範圍及路由選擇有關。若遠端只允許某個內部網段，不能只靠用戶端擴大範圍至所有位址，就取得額外的轉送能力；伺服器端的路由、轉送與回程路徑仍須正常運作。

UDP、Keepalive 與行動網路

WireGuard 通常透過 UDP 傳輸，網路必須允許用戶端與 Endpoint 的相應連接埠交換資料。Wi-Fi 正常、行動網路異常，可能與 UDP 路徑、位址變更或網路映射有關，不一定是金鑰失效。觀察時先確認是否有有效握手，再檢查實際服務能否使用；握手成功不代表 DNS、目標路由與回程路徑都正確。尤其是存取內部網段時，應確認該網段是否與目前本地網路重疊。

PersistentKeepalive 用於在必要時維持網路映射，但數值越小不代表越穩定。頻繁傳送封包可能增加無線網路活動與耗電，不需要時開啟也未必有幫助。是否設定及如何設定，應依既有部署需求與實際閒置後斷線情況決定，不要在所有情境套用同一數值。也應分別觀察行動裝置在鎖定螢幕、切換網路與重新喚醒後的表現，不能用螢幕常亮時的一次成功測試取代背景穩定度判斷。

MTU 與適用範圍

MTU 表示相關介面可承載的封包大小。若封裝後的封包超出路徑承載能力，且必要的回應無法正常傳回，可能出現握手正常、小型請求成功但大型回應停滯的情況。不過這只是排查方向之一，不應一遇到速度慢就先改 MTU。應先確認路徑、DNS 與路由，再依遠端說明進行有限調整並記錄原值；任意調得過小會增加分段與封包數，調得過大則可能無法解決原有問題。

若需求是存取明確管理的內部網段，而且管理員提供完整的 WireGuard 設定，其位址與對端架構便於處理這類需求。若目標是一般代理服務，也應確認遠端確實提供相應轉送，而非只建立通往內部網路的通道。速度與耗電仍取決於無線網路狀況、封包大小、Keepalive 與流量。最終應確認握手、路由、DNS 與目標回應都正常，而不是只看設定中是否出現某個通道名稱。

依可驗證條件縮小選擇範圍

日常瀏覽網頁與使用 App，應優先採用參數完整且能穩定建立工作階段的既有設定，再比較首次回應與持續傳輸表現。存取內部網段時，可著重核對 WireGuard 的位址、路由與對端權限；需要 UDP 的服務則須確認協定、遠端與目前網路都支援相應轉送。不穩定網路下可測試既有的 Hysteria2 等選項，但不能以此取代入口可連線性檢查。所有選擇都應以遠端已提供的功能為界，而不是依協定名稱追求一種通用答案。

在重視耗電的情境中，應觀察實際使用期間的閒置連線、背景重試與網路切換。On Demand 控制何時觸發連線，規則則控制流量的去向；兩者都與協定選擇有關，但並非同一問題。只有在需要的請求進入適當路徑，且連線能穩定維持時，比較協定成本才有意義。若持續發生失敗重試，應先找出原因；單純改用欄位較少的協定，仍可能遇到相同的網路問題。

先確認請求確實經過測試項目

在 Config 中，規則的先後順序會決定請求如何比對。以下僅示範 Shadowrocket 的 .conf 規則片段，並非完整設定：網域後綴交由 PROXY，列出的私有網段交由 DIRECT，其餘流量則由 FINAL 指定最終策略。實際使用前，請確認目前設定中引用的策略可用，並了解 FINAL 的影響。不要為了測試一個網域就覆蓋整份原始設定；請先儲存原設定，再進行範圍最小的驗證。

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

若相同請求在 Direct 下正常、Proxy 下失敗，可繼續檢查遠端連線，但這不能作為整體網路狀況的最終判斷；兩種路徑可能使用不同的解析結果與目標入口。若在 Config 下異常、Proxy 下正常，應優先檢查規則與 DNS 關聯。如需了解 Home、Config、Data 與 Settings 的位置，可參閱介面英文對照，避免進入錯誤頁面尋找不存在的協定選項。

依故障階段建立最精簡的排錯紀錄

第一步確認訂閱是否成功取得、項目是否完整，再檢查位址能否解析及連接埠是否可連線；第二步核對 Type、驗證資訊與傳輸方式；第三步核對 TLS 與名稱；第四步才檢查目標存取與服務能力。若清單本身是空的，代表尚未進入協定連線階段，應先處理訂閱取得或解析問題。若已成功握手但沒有目標回應，應繼續檢查伺服器至目標的路徑、目標限制與回傳資料，而不是反覆匯入同一筆訂閱重試。

紀錄應包含裝置使用的網路類型、故障時的 Global Routing、所選協定、訂閱是否剛更新，以及可重現的錯誤階段。可保留錯誤類別與已去識別化的欄位名稱，但不要附上真實密碼、金鑰或完整訂閱連結。每輪只修改一個明確不符的欄位，並記錄原值；確認無效後還原，再檢查下一層。比較不同網路時應保持伺服器項目不變；比較不同項目時則保持網路與目標不變，才能減少變數干擾。

何時停止調整並回到基本檢查

若所有協定在同一個網路下都無法使用，應先檢查裝置網路、DNS 與系統授權；若只有一個項目失敗，應優先核對其驗證資訊與遠端狀態；若只有特定目標失敗，則應檢查規則與目標本身。不要把所有故障都當成協定選擇問題。其他常見疑問可參閱常見問答；首次建立連線則依快速上手重新核對授權與開關。App 取得、購買與相容性資訊統一於下載核驗頁說明；價格與系統需求請以 App Store 頁面標示為準。