Shadowrocket 協定參數
與連線類型選擇

Shadowsocks：精簡代理與加密方式

設計背景與限制

Shadowsocks 著重於提供較精簡的加密代理通道。用戶端依約定封裝目標位址與業務資料，再由伺服器驗證並轉送請求。它不是完整的虛擬區域網路方案，也不會因為被選為 Type 就自動設定 App 路由。對使用者而言，重點不在記住協定歷史，而是了解同名協定仍可能採用不同的加密方式與格式：伺服器接受哪種方式，用戶端就必須選擇相同方式，不能把名稱相似當成相容。

較早期的串流加密方式與後來的 AEAD 方式，在資料格式及認證能力上有所不同。AEAD 結合加密與完整性驗證，可偵測遭到竄改的資料；但這不表示所有名稱含 AEAD 的項目都能互通。部分較新的方式也對金鑰長度與編碼格式有特定要求。實際填寫時請以現有伺服器設定為準；若用戶端清單沒有提供某種方式，不能以名稱相似的選項替代。

Address、Port、Method 與 Password

在 Add Server 中選擇 Shadowsocks 後，先檢查 Address 與 Port。Address 是提供代理服務的主機名稱或 IP，不是訂閱連結，也不是要造訪的網站；Port 則是該服務監聽的連接埠。主機名稱不可包含整段網頁路徑，IPv6 位址也應依欄位要求填寫。若資料來自 QR Code 或訂閱，請優先保留自動解析結果，再逐項與原始資料核對，避免手動拆分時漏掉連接埠或附加參數。

Method 決定雙方如何處理金鑰與密文，Password 則必須逐字元一致。有些方式會以一般密碼衍生金鑰，另一些方式則要求特定格式的金鑰資料，因此不能簡單認為「密碼越長越相容」。複製時請留意尾端換行、全形符號與隱藏空白；不要將伺服器管理頁面顯示的編碼字串再次自行編碼。若認證失敗，先核對 Method 與 Password 是否配對，不要立即修改 DNS。

UDP、附加傳輸與 iOS 表現

Shadowsocks 的 TCP 與 UDP 路徑需要分別驗證。網頁可以開啟，不代表遊戲或通話的資料封包也能送達。用戶端設定、伺服器轉送能力及中間網路都可能限制 UDP；目標 App 本身也可能使用不同連接埠。若伺服器資料包含附加傳輸參數，請確認目前用戶端確實提供相應選項，並完整照填。基礎協定名稱相同，不代表附加傳輸也有相同的相容性。

在 iPhone 上，較精簡的資料封裝有機會減少部分處理負擔，但實際速度仍會受到加密方式、裝置效能及網路路徑影響。大量持續下載時，運算負擔較容易顯現；偶爾開啟訊息時，連線建立與無線喚醒反而可能更重要。不能只因協定結構簡潔，就斷定一定更省電；也不應把單次測速的高峰值當成長期傳輸速度。

排錯可分成三個方向：連線入口持續逾時，先確認主機、連接埠和目前網路；連線建立後立即失敗，檢查 Method 與 Password；網頁正常但部分 App 失敗，檢查 UDP、規則命中與名稱解析。若修改的是從 Subscribe 取得的項目，請先複製並保留原值，避免後續更新覆蓋修正。依序核對通常比嘗試一連串無關的開關更有效。

WireGuard：金鑰、位址與路由前綴

為什麼欄位與一般代理不同

WireGuard 用於 IP 封包通道，設計採用固定的現代密碼元件及較精簡的交握機制。它不使用使用者名稱與密碼表單辨識對端，而是透過金鑰建立身分關係，並將允許通過對端的位址範圍與路由相連。因此在 Shadowrocket 查看 WireGuard 項目時，應分別了解金鑰、通道位址、Endpoint 和 AllowedIPs，不能套用一般代理「位址加密碼」的填寫方式。

PrivateKey 是本端私鑰，PublicKey 通常指對端公鑰。兩者雖然都是編碼字串，卻代表不同身分與方向。不可將私鑰填入對端公鑰欄位，也不能因字串長度相近就互換。PresharedKey 是額外的選用共享資料，只有雙方約定使用時才應填寫；自行新增一段值不會提高可用性，反而可能導致雙方交握條件不一致。

Endpoint 與通道位址

Endpoint 是對端實際接收 UDP 通訊的主機和連接埠；通道 Address 則是本端在通道內使用的位址。兩者位於不同層次：外部公開位址可連線，不代表內部位址配置正確；內部位址正確，也無法彌補入口連接埠無法連線的問題。將現有設定拆分填入介面時，請保留位址前綴長度，並確認 IPv4 與 IPv6 是否依資料分別設定，不要自行用本機區域網路位址取代。

AllowedIPs 同時關係到哪些目標位址要交給某個對端，以及收到的資料應使用哪種來源位址。較寬的前綴涵蓋更多目標；較窄的前綴則只涵蓋指定網段，但它不是一般的網站存取允許清單。用戶端的 Global Routing、Config 規則與系統網路延伸功能，也會影響業務流量是否進入此項目，因此不能只看到涵蓋全範圍的前綴，就判定所有 App 都已使用通道。

MTU、保活與行動網路

MTU 決定通道封包大小上限。若底層路徑無法承載較大的封裝封包，可能會出現小型請求正常、大型頁面或上傳卡住的情況。調整 MTU 前，應先排除認證與路由錯誤，並保留原值逐步驗證；不要把某個網路下有效的數值當成適用於所有裝置的固定答案。若 IPv6 與 IPv4 路徑不同，也應分別測試，而不是只觀察一次網頁載入。

PersistentKeepalive 用於依指定間隔維持某些網路位址轉換對應關係，並非間隔越短就越穩定。較短的間隔可能增加背景資料傳輸與無線喚醒；較長的間隔則可能不符合某些對應關係的存續時間。應先確認是否確實發生閒置後無法恢復，再依伺服器建議調整。切換行動網路時，入口連線狀況、位址變更及 App 重試行為也都會影響恢復過程。

WireGuard 交握成功，只代表金鑰關係及部分通訊條件成立；若要存取內部服務，對端轉送、回程路由、位址配置與 DNS 也必須正常。若交握正常但沒有業務流量，請先核對 AllowedIPs、通道位址和伺服器回程路徑，再檢查規則命中情況。欄位逐項說明請參閱WireGuard 參數說明；分享問題時請隱藏私鑰與實際內部網路資訊。

依情境選擇：規則驗證與故障排查

從需求判斷，而不是只看名稱

需要一般網頁與日常 App 時，先選擇現有資料中參數完整、連線穩定的項目，不必只為了協定名稱更換伺服器。若有內部網路與位址路由需求，請檢查 WireGuard 對端與允許網段；若有組織提供的 HTTP 或 SOCKS5 入口，核對其認證與存取權限；需要使用 UDP 的 App，則另外驗證相應能力。需求無法滿足時，再判斷是設定問題、伺服器能力不足，還是網路限制。

選用 VMess、VLESS 和 Trojan 時，應保留各自所需的傳輸與 TLS 組合；Shadowsocks 應確認加密方式及資料封包支援情況；Hysteria2 則應確認 UDP 路徑與速率參數。切換 Type 不會讓任何一種協定自動相容於另一種服務。若現有訂閱包含多種類型，可保留原始項目並逐一測試；不要混用 UUID、密碼與傳輸路徑，拼出未經伺服器設定的組合。

先確認規則確實使用了該協定

協定驗證與規則驗證應分兩步進行。先透過明確的測試請求確認伺服器可用，再於 Config 下確認目標是否套用預期策略。以下是用來說明比對順序的 Shadowrocket .conf 規則片段，並非完整設定；使用前必須確認目前設定已定義可用的 PROXY 策略。範例網域僅供教學，不代表應造訪的服務。

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

規則通常依序比對，符合後便套用相應策略。DOMAIN-SUFFIX 涵蓋指定網域及其子網域；IP-CIDR 表示位址區段；no-resolve 用於避免該規則為了比對而主動解析網域，但已有的目標位址仍可能參與位址比對。GEOIP 會依位址歸屬資料庫判斷，不等於網站所屬地區。FINAL 是最後的預設規則，必須放在需要優先判斷的規則之後，否則後續規則可能無法生效。

若目標命中 REJECT，連線會在策略層遭到阻擋，變更協定無法修復；若命中 DIRECT，則應先確認是否符合預期。關於拒絕策略的用途與同網域內容範圍，請參閱REJECT 規則說明。調整規則時也應先複製設定，避免為了驗證一個目標而改變其他 App 原有的連線路徑。

依失敗階段縮小檢查範圍

若只有網域存取失敗、直接連線測試正常，請檢查名稱解析位置、回傳位址類型及 DNS 請求的路由；不要將所有問題都當成憑證驗證錯誤處理。若只在 IPv6 網路發生異常，請分別確認伺服器入口、目標位址及通道位址是否支援。恢復可用設定後，再逐項加入必要規則，才能找出確切的故障變更，而不是留下難以解釋的一堆開關。

保留可重現的結論

排查完成後，記錄實際使用的協定、外層傳輸、成功的測試任務及仍存在的限制，並刪除不再需要的測試項目。Subscribe 更新可能變更伺服器參數，系統網路狀況改變也可能使舊結論失效；出現新問題時應重新核對目前資料，不要機械式重複舊調整。設定、QR Code 和記錄都可能包含敏感資訊，分享前請逐項檢查，不要直接公開原始匯出檔。

需要重新依照操作流程設定時，請回到使用說明；需要依現象查找簡短解答時，請前往問答。本手冊旨在讓每次類型選擇都有伺服器資料作為依據、每次參數變更都有可驗證的理由，而不是以協定名稱取代對連線條件的判斷。