Shadowrocket
協定類型與參數參考

設計背景與適用範圍

Shadowsocks 著重以相對精簡的協定完成加密代理轉送：用戶端向伺服器提供目標資訊，再由伺服器建立到目標的連線。它主要依靠雙方約定的密碼與加密方法，不以網站憑證作為基本驗證條件。了解這點有助於分辨欄位：一般 Shadowsocks 設定中的 Password 與 Method 缺一不可，不能直接套用另一種協定的密碼，也不能只因連接埠相同，就認定兩種服務可以互換。

不同加密方法的封包格式與金鑰要求可能不同。較新的方法與較早的方法不只是「強弱」之別，也可能使用不同的金鑰編碼、長度及實作相容條件。伺服器端提供哪種方法，用戶端就應選擇相同方法；若清單沒有對應選項，應確認資訊是否適用於目前的用戶端，而不是找名稱相近的選項代替。匯入後仍要檢查方法名稱，尤其留意訂閱轉換過程是否遺漏該欄位。

逐一核對位址、連接埠、密碼與方法

Server 填寫伺服器網域或 IP 位址，Port 填寫實際監聽的連接埠。位址通常不包含網頁路徑，連接埠也不應填入位址欄位。Password 必須完整保留提供的內容，複製時留意空格、換行與全形字元。Method 表示特定加密方式，不是可任意選擇的偏好。若位址可以解析但連線持續失敗，應同時核對連接埠與方法；網域能開啟網頁，不代表代理連接埠正常。

有些設定還附帶額外傳輸參數，但並非所有 Shadowsocks 服務都需要這些參數。只有在現有資訊明確提供時才啟用，並確保名稱與參數相符。不要因為其他設定中有某個選項，就照樣加到目前的連線；額外封裝會改變伺服器端預期的資料格式。若匯入項目與手動填寫結果不同，可以逐欄比較，但應先保留匯入項目作為參照，避免修正時遺失原始資訊。

TCP 成功不代表 UDP 可用

瀏覽網頁大多可透過 TCP 完成，但即時通訊、部分網域解析與使用 QUIC 的 App 可能會用到 UDP。Shadowsocks 的 TCP 與 UDP 轉送須分別符合條件：伺服器端支援相應功能、網路允許相關資料通過，而且用戶端設定未停用該功能。網頁正常但即時服務失敗時，應檢查這個分支。不要只憑一次網頁載入，就認定目前連線適用於所有 App；也不要只因一個 App 失敗，就認定整條連線失效。

在 iPhone 和 iPad 上，精簡轉送通常代表需要檢查的封裝層較少，但不表示一定更快或更省電。裝置晶片處理演算法的效率、長連線數量與網路重傳，都可能改變實際結果。同一設定在 Wi-Fi 正常、行動網路逾時時，應先比較入口連接埠與網路可達性；若只有高負載時明顯變慢，則應一併觀察伺服器負載與持續傳輸量，不能單憑協定名稱下結論。

排錯可依序確認「資訊是否完整、入口是否可達、驗證是否一致、特定服務是否支援」四個面向。先查看訂閱是否更新成功，再核對目前選取的項目，避免修改一個項目卻測試另一個。驗證錯誤應回頭檢查密碼與方法；逾時優先檢查位址、連接埠與目前網路；只有部分請求異常時，再檢查規則與 UDP。這樣可以保留明確的因果關係，不必在多個設定間反覆嘗試。

若現有伺服器只提供 Shadowsocks，優先使用完整相符的設定即可，不必為了協定名稱更換類型。若使用者同時有多種可用設定，再以相同目標與相近時間比較網頁首次載入、持續傳輸與背景待機表現。記錄改善發生在哪個環節，比替協定貼上「輕量」或「高速」標籤更有用，也更方便日後在網路條件改變時重新判斷。

分清憑證身分與使用者密碼

Trojan 將代理工作階段置於 TLS 連線內，先透過 TLS 建立受保護的通道，再於通道中提交協定驗證與目標資訊。這裡涉及兩種不同身分：憑證用來驗證連線對象是否為指定伺服器，Password 則用來證明用戶端具有存取權限。密碼正確無法彌補憑證名稱錯誤，憑證有效也不代表伺服器已接受密碼。排錯時應依交握順序檢查，而不是把所有失敗都歸因於密碼錯誤。

這種組合將較多安全職責交由 TLS 處理，因此伺服器名稱、憑證有效期限與裝置信任條件格外重要。這不代表使用者需要手動填入每種 TLS 選項；現有訂閱通常已提供必要設定。應先保留匯入結果，再依錯誤訊息找出缺少的欄位。若沒有完整參數就任意嘗試不同名稱，可能會連到另一個服務入口，讓問題更難判斷。

Server、Server Name 與憑證鏈

Server 是網路連線實際要連到的位址，Server Name 則是 TLS 交握與名稱驗證使用的重要資訊。以網域連線時，兩者通常相同；以 IP 連線時，則可能仍須保留原有網域作為 Server Name。憑證驗證也涉及有效期限與信任鏈，因此名稱正確只是必要條件之一。若憑證已過期或中繼憑證設定錯誤，應修正伺服器端，而非一再更換用戶端密碼。

裝置時間不準、網路認證頁面與錯誤的網域解析，都可能造成看似相近的 TLS 問題。公共 Wi-Fi 尚未完成網頁登入時，連線可能被導向認證入口；若解析到錯誤位址，也可能連上不屬於該服務的憑證。遇到這類問題，應先確認網路本身可正常使用，再檢查網域解析結果與 Server Name。尚未確認連線對象前，不要提交更多憑證或擴大信任範圍。

驗證、傳輸與業務支援的界線

Trojan 的 Password 應完整保留大小寫與符號，不要直接將訂閱網址中的整段文字填入。若現有資訊另外指定傳輸方式，也必須與伺服器端一致；不能因為一般 Trojan 常見於某種承載方式，就刪除設定中明確要求的附加欄位。匯入後可先檢查類型、位址、連接埠、密碼與 TLS 名稱，再查看其他傳輸參數。依此順序可先排除最常見的結構錯誤。

UDP 是否能正常使用，仍取決於伺服器端支援、用戶端設定與實際網路條件。即使協定能轉送某類資料，也不代表所有 App 的表現都相同。即時服務對延遲與抖動更敏感，長時間下載則更容易受到伺服器出口頻寬影響。若一般網頁正常但某個即時 App 異常，應單獨驗證該項服務；不要用網頁成功取代實際業務測試，也不要盲目調大逾時參數來掩蓋問題。

在 iOS 上觀察連線重複使用與重新連線

TLS 交握需要交換資料並進行運算，首次連線的成本與後續穩定傳輸並不相同。在頻繁建立短連線的情境中，交握次數可能影響回應速度與耗電；長連線持續運作時，這部分成本會分攤，連線品質往往更重要。伺服器端與用戶端是否使用相關重複使用機制，也會改變觀察結果。因此測試時應分別記錄首次開啟與連續瀏覽，不要將已建立工作階段後的速度當成初次連線表現。

從 Wi-Fi 切換到行動網路，可能改變裝置位址與可達路徑，既有 TCP 連線通常需要重新建立。切換後若長時間未恢復，應先停止目前工作，確認新網路正常，再測試重新連線所需時間；不要立刻清除設定。背景連線反覆失敗會增加重試次數與無線電活躍時間，造成耗電上升。此時應查明失敗原因，而不是先認定耗電來自加密運算。

若使用者已有穩定可用的 Trojan 設定，日常使用時更重要的是保留正確的憑證驗證與驗證參數，並在訂閱更新後確認未遭意外覆寫。若要與其他協定比較，應選擇相近的網路路徑、相同目標與相同測試時段，並明確記錄比較的是整套服務的表現。協定層的說明有助於定位問題，但不能取代對伺服器端運作狀態與業務目標可達性的確認。

先了解它處理的是網路層資料

WireGuard 以網路層隧道為設計基礎，與「為特定目標建立代理連線」的概念不同。設定除了遠端位址，還需要本端位址、金鑰身分，以及允許進入隧道的位址範圍。將它納入用戶端的統一連線管理，不會消除這些網路層條件。使用者應取得完整設定，而不是只憑網域與密碼手動拼湊；缺少隧道位址或對端公鑰時，通常無法建立預期的通訊關係。

WireGuard 使用公鑰識別通訊對端，本端私鑰用來證明本端身分，對端公鑰則用來指定要接受的遠端身分。兩者不能互換。本端私鑰應妥善保密，伺服器端也必須設定與該用戶端相對應的公鑰；只在手機填入一組新金鑰，伺服器不會自動識別。若設定由管理者提供，應保留雙方已約定的金鑰配對，不要任意重新產生並覆寫。

Endpoint、Address 與 Allowed IPs

Endpoint 是隧道對端的網路入口，通常由主機與 UDP 連接埠組成；Address 是本端在隧道中的位址，不是伺服器的公網位址。Allowed IPs 在 WireGuard 的基本語意中，同時涉及目標路由範圍與允許交由對端處理的位址範圍；整合至用戶端後的實際處理方式，還須參照 App 設定。了解這些用途，有助於排查「交握成功但無法存取」的情況：身分交握只代表雙方建立了工作階段，不表示每個目標都有正確路由。

若需要存取組織內網，目標網段必須符合提供的設定範圍，伺服器端也須具備轉送功能與回程路徑。若本地 Wi-Fi 網段恰好與遠端內網重疊，也可能造成路由選擇歧異。這時反覆更換金鑰通常沒有幫助，應先確認目標位址實際會經由哪條路徑傳送。IPv6 也須確認是否具備相應位址與路由條件，不能只因 IPv4 可用，就假設另一套位址空間也能使用。

Keepalive 與行動網路的取捨

WireGuard 使用 UDP。行動裝置透過網路位址轉換設備連線至遠端時，閒置的映射可能逾時。Persistent Keepalive 的用途之一，是定期傳送封包以維持相關映射，並非提高頻寬。較頻繁的保活會增加無線電活動，較少的保活則可能讓某些網路在閒置後需要較久才能恢復。應依照現有設定；只有確實遇到閒置後無法恢復時，才針對性測試，不要套用所有手機都相同的固定間隔。

切換網路後，底層出口位址可能改變。WireGuard 的機制可在符合條件時適應對端位址變化，但實際體驗仍受新網路的 UDP 可達性、位址轉換與伺服器端策略影響。Wi-Fi 正常、行動網路無法連線時，先確認 UDP 是否可達，再檢查電信網路與對端限制。具備位址更新機制不代表每次切換都不會中斷，也不能因為某次恢復很快，就推斷任何網路都能維持工作階段。

分別驗證 MTU 與 DNS

隧道封裝會占用封包空間；若路徑可承載的有效大小與 MTU 設定不符，可能出現小型請求正常、大型回應停滯的情況。不過，丟包或伺服器問題也可能造成相同現象，因此調整前應先記下原值，每次只修改一個參數，再重複相同請求。不要把網路上某個 MTU 數字當成通用答案，也不要只因網頁無法開啟，就立刻將數值調得很小，以免不必要地降低傳輸量。

DNS 決定網域如何解析成位址，路由則決定資料要送往何處；兩者在隧道情境中經常同時出現，但用途不同。若直接連線到已知內網位址成功，使用名稱卻失敗，應優先檢查內網 DNS 與其可達路徑。需要內網互通時，完整的位址規劃比協定速度測試更重要；一般網頁情境則仍須透過 Shadowrocket 確認請求是否套用預期策略。

使用相同測試建立基準

協定比較應以實際工作需求為依據。日常瀏覽網頁先觀察首次回應與連續載入；大型檔案傳輸看穩定傳輸量與途中是否中斷；即時通訊看延遲、抖動與 UDP 業務；內網存取則優先檢查位址規劃、DNS 與回程路徑。使用者有多個設定時，先選一個能完成工作的設定作為基準，再比較其他設定。若所有設定都失敗，應先檢查目前網路與目標本身，避免在不具備測試條件時下協定結論。

有效比較應盡可能固定裝置、網路、目標、規則模式與測試時間，並暫停背景的大量資料傳輸工作，同時記錄是否為首次連線。每組重複測試幾次，以常見表現而非最佳單次結果作為參考。Connectivity Test 可協助找出明顯無法連線的項目，但結果不等於完整的網頁體驗，更不能證明 UDP、內網或長連線一定正常。將連線測試、實際存取與持續傳輸分開，才能判斷差異來自哪個環節。

使用 Global Routing 三種模式隔離變因

Config 依目前設定中的規則決定連線策略，Proxy 將適用流量送往代理路徑，Direct 則直接連線。若 Config 異常但 Proxy 正常，通常應回頭檢查規則與策略指向，而非立刻更改密碼；若兩種需要代理的模式都失敗，再檢查入口、驗證與傳輸。Direct 測試只能提供本地網路基準；若目標在直接連線時無法到達，也不能單獨證明代理協定有問題。

以下片段示範如何依網域後綴選擇策略、依位址區段直接連線，並用最終規則處理其餘請求。這是 Shadowrocket 的 .conf 規則內容範例，不是可連線的伺服器設定，也不包含驗證資訊。PROXY 必須在實際設定中對應有效策略；匯入或修改前請先備份，並確認目前 Config 確實選取了正在編輯的檔案。規則通常依序比對，前面的寬泛條件可能使後面的具體條件無法生效。

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

網域規則依賴用戶端在適當階段取得網域資訊，IP 規則則比對位址；兩者不能簡單互換。網站可能使用多個資源網域，App 也可能直接使用 IP，因此「主頁面套用預期策略」不代表所有相關請求都相同。GEOIP 結果也會受位址資料庫與目標位址變動影響。若只想讓指定網站使用代理，可繼續閱讀指定網站使用 PROXY 的規則說明，再依自身需求補上條件。

根據錯誤現象回到相應層次排查

完全逾時時，先檢查網路、位址與連接埠；明確的驗證錯誤則檢查密碼、UUID 或金鑰配對；TLS 錯誤應檢查系統時間、Server Name 與憑證；交握成功但業務失敗時，再檢查目標可達性、DNS、UDP 與路由。若只有一個網域失敗，先測試其他已知目標；若所有網域都失敗但已知 IP 可達，再集中檢查 DNS。每次只修改一組設定，驗證後記錄結果，不要同時將多種猜測寫入設定。

保留可重現的紀錄，再決定是否更換協定

排錯紀錄應包含裝置網路、目標類型、Global Routing 模式、錯誤階段與發生條件，不必公開完整訂閱網址、密碼或私鑰。分享截圖或文字前，應移除驗證資訊與個人識別資料；只保留有助於重現問題的協定類型與非敏感欄位。訂閱更新後若出現問題，可以比較類型、傳輸與名稱欄位，但要保留原項目，避免尚未確認新設定可用前，就失去可運作的基準。

最終選擇應以相容性與可重現的結果為準：能完成工作、切換網路後可恢復、持續運作時沒有異常重試，比單次測試的最高數值更有參考價值。常見匯入與連線問題可回到快速入門的故障排查；介面用語可查閱概念速查；功能行為可參考功能說明。若問題涉及伺服器端驗證、憑證或路由範圍，應向原資訊提供者確認相應設定，而非在用戶端不斷更換無關選項。