本文適合已取得服務商提供的 WireGuard 參數,並準備在 Shadowrocket 手動設定的使用者。先確認本機與 Peer 的金鑰,再核對 Address、Endpoint 和 MTU,最後透過 Global Routing 與連線狀況找出問題。範例地址僅供說明格式,並非可用服務;排查時不必公開 PrivateKey 或完整設定。
一、新增前先確認參數分屬哪一端
Shadowrocket(小火箭)是 Apple 平台的付費用戶端,主要供 iPhone 與 iPad 使用。唯一取得管道是 App Store,開發者為 Shadow Launch Technology Limited,應用程式 ID 為 932747118,採一次買斷制。系統需求以 App Store 頁面標示為準。買斷用戶端不等於購買連線服務;本站不提供、不銷售,也不推薦節點或訂閱。
WireGuard 透過金鑰識別通訊雙方。設定中的 [Interface] 通常描述本機,[Peer] 則描述遠端。Shadowrocket 的伺服器編輯表單並非原始設定檔編輯器,欄位可能分開顯示;填寫時應依欄位意義對應,不能把整份設定檔貼到單一欄位。
開始前,請先取得本機 PrivateKey、本機 Address、遠端 PublicKey、Endpoint,以及服務商要求的其他參數。若設定包含 PresharedKey,也請一併保留。只有 PublicKey 或伺服器地址,無法完成設定。伺服器端也必須登記與本機 PrivateKey 配對的 PublicKey,並允許使用對應的隧道地址。
二、從 Home 新增 WireGuard 類型的伺服器
先保留原始參數,再新增一筆獨立的測試記錄。以下路徑使用英文介面名稱說明;欄位排列請以目前的 App 為準。不要將 WireGuard 原始設定當成 Subscribe 連結新增,也不要假設既有訂閱中的其他協定參數可以直接轉換為 WireGuard。
-
開啟新增頁面
前往 Home → 點選右上角「+」→ Type,選擇 WireGuard。確認目前編輯的是單一伺服器記錄,而非 Subscribe 項目。
-
填寫遠端資訊
將 Endpoint 的主機名稱和連接埠填入伺服器地址與連接埠欄位。例如
vpn.example.com:51820代表主機為vpn.example.com,連接埠為51820;若表單將欄位分開,請勿在主機欄重複加上連接埠。 -
填寫本機資訊
依原始設定填入 PrivateKey 與 Address。Address 是指派給本機的隧道地址,不是 Endpoint,也不是目前 Wi-Fi 的區域網路地址。
-
核對 Peer 資訊
在對應欄位填入遠端 PublicKey。只有服務商提供的設定明確包含 PresharedKey 時,才填寫該欄;不要以 PublicKey 代替,也不要自行產生隨機值。
-
儲存並測試
依原始設定核對 MTU 等可用欄位後儲存,返回 Home 並選取剛新增的記錄。首次測試可先暫時選擇 Global Routing → Proxy,再開啟 Home 的連線開關;首次建立系統 VPN 設定時,請依系統提示確認。
三、PrivateKey、PublicKey 與 Peer 的對應關係
最常見的金鑰錯誤不是長度不符,而是把通訊雙方的金鑰填反。PrivateKey 留在本機;Peer 的 PublicKey 用來識別遠端。伺服器端設定則須記錄本機的 PublicKey。兩端的 Peer 指向相反,因此不能直接將伺服器端整段 Peer 參數照搬成本機的 Peer 參數。
本機參數
- PrivateKey
- 本機私鑰,必須與伺服器端登記的本機 PublicKey 配對。
- Address
- 本機隧道地址,例如
10.7.0.2/32;請以實際指派的地址為準。 - MTU
- 隧道介面允許的最大 IP 封包長度,請先依照原始設定。
PrivateKey 與 Address 屬於本機端,不能從遠端 Endpoint 推算。
Peer 參數
- PublicKey
- 遠端公鑰,必須與實際連線的伺服器私鑰配對。
- Endpoint
- 遠端可連線的主機與 UDP 連接埠,例如
vpn.example.com:51820。 - PresharedKey
- 選填的額外共用金鑰;若啟用,兩端必須使用相同的值。
Peer 指通訊對端,不是訂閱分組或規則策略群組。
標準 WireGuard 金鑰的 Base64 文字通常為 44 個字元,結尾包含 =。這項特徵只能協助找出遭截斷或複製錯誤的情況,不能證明金鑰配對正確。複製時請保留結尾字元,移除誤帶入的空格、換行與引號;不要將 PrivateKey = 這類欄位名稱一併填入值中。
- 更換 PrivateKey 後無法連線:更換私鑰會改變本機 PublicKey。若伺服器端未更新登記,新身分便無法依原設定通訊。
- 複製到第二台裝置後連線不穩:多台裝置同時使用相同金鑰身分,可能導致遠端學到的通訊地址反覆變動。請向服務商申請分別指派的身分與地址。
- 未填 PresharedKey 後無法連線:若遠端要求此欄,本機也必須填入完全相同的值。這不是可以任意省略的備註。
四、Address、Endpoint 與 AllowedIPs 不可混填
Address 描述隧道內的本機地址,Endpoint 則描述隧道外的遠端入口。以 10.7.0.2/32 為例,斜線後的數值是 CIDR 前綴長度,不是連接埠。請勿改成 10.7.0.2:32。若服務商同時指派 IPv4 與 IPv6,請分別填入對應欄位,不要自行產生看似相近的地址。
| 欄位 | 格式範例 | 檢查重點 |
|---|---|---|
| Address | 10.7.0.2/32 | 本機隧道地址;必須與伺服器端指派的地址一致。 |
| Endpoint | vpn.example.com:51820 | 主機名稱可正常解析,UDP 連接埠與遠端監聽連接埠一致。 |
| IPv6 Endpoint | [2001:db8::1]:51820 | 這是組合格式範例;若主機與連接埠分欄,請分別填入對應欄位。 |
| AllowedIPs | 0.0.0.0/0, ::/0 | 原始 WireGuard 設定中的 Peer 地址範圍,不是 Shadowrocket 的 Rule 文字。 |
| DNS | 10.7.0.1 | 僅供格式參考;實際地址必須能透過目前路由存取。 |
以上網域與地址僅用於說明語法,無法據此建立連線。Endpoint 不要加上 https://,也不要填入訂閱路徑。若原始 Endpoint 使用網域名稱,建立隧道前必須能解析該網域;因此「連線後使用哪個 DNS」與「連線前能否解析 Endpoint」是兩個不同問題。
在原生 WireGuard 設定中,AllowedIPs 會影響 Peer 的輸出選擇與輸入來源地址檢查。用戶端常見的 0.0.0.0/0 與 ::/0 代表涵蓋所有 IPv4、IPv6 地址範圍;伺服器端針對特定用戶端的 Peer,通常只允許指派給該用戶端的地址。兩端不可直接照抄相同範圍。在 Shadowrocket 中,業務流量是否交由該伺服器處理,還取決於 Global Routing、目前的 Config 與策略選擇,不應將 AllowedIPs 當成 App 內的分流規則。
五、MTU 與 PersistentKeepalive 的調整原則
MTU 不是頻寬數值。WireGuard 封裝會增加外層資料的額外負擔,隧道內允許的封包長度必須配合實際路徑。原始設定已指定 MTU 時,請先照填;若未指定,先維持 App 的預設處理方式。不要只因某個網頁載入緩慢,就同時修改 MTU、DNS、連接埠與金鑰,否則無法判斷是哪項變更造成影響。
- 何時考慮調整 MTU:連線建立後,小型請求正常,但較大的回應持續停滯,才值得將路徑 MTU 列入排查。這種狀況也可能由封包遺失或遠端問題造成,不能只憑一次載入失敗就下結論。
- 如何進行單一變數測試:先記錄原始值。若原值為
1420,可在服務商允許的範圍內暫時改為1380,重新連線後存取相同目標並比較結果;這兩個數值僅為測試範例,並非通用最佳值。 - 如何處理 IPv6:不要為了測試而任意降至
1280以下。IPv6 對鏈路 MTU 有最低要求;使用 IPv6 時,尤其應一併核對伺服器設定與實際路徑。 - 如何還原設定:若修改後沒有可重複驗證的改善,請還原原始值。不要將某個網路環境有效的數值直接套用到所有裝置與網路。
PersistentKeepalive 用來定期傳送保活封包,常見用途是維持 NAT 對應,並非提升頻寬。原始設定中的 PersistentKeepalive = 25 表示約每 25 秒傳送一次保活封包;這是常見設定範例,不代表 Shadowrocket 的固定預設值。只有目前介面提供對應欄位且服務商要求時,才依其設定填寫;不要把整行文字填入其他參數欄位。
六、透過 Global Routing 區分協定問題與規則問題
儲存 WireGuard 記錄只完成伺服器參數設定。Home 用於選擇與連線,Config 用於設定規則,Settings 則包含 On Demand 等選項。排查時,請先固定同一台伺服器、同一個目標與同一個網路,再比較 Global Routing 的不同選項;不要切換伺服器後,就將所有狀況歸因於規則。
Proxy
建議適用於本輪初步排查:讓進入 Shadowrocket 的一般業務流量以 Proxy 方式處理,減少 Config 規則分支的影響。仍須確認目前選取的是待測 WireGuard 記錄;此選項無法修正錯誤金鑰或無法連線的 Endpoint。
適用情況:先驗證 WireGuard 參數與遠端轉送能力
Config
依目前設定中的規則與策略處理流量。若 Proxy 下目標正常、Config 下卻異常,應檢查規則順序、符合的策略,以及策略實際選用的伺服器,不要立即重新產生金鑰。
適用情況:完成參數驗證後檢查規則分流
Direct
讓一般業務流量直接連線。目標在此狀態下可存取,只能表示直連路徑正常,不能證明 WireGuard 通道可用,也不適合用來確認 WireGuard 的出口結果。
適用情況:對照直連網路的狀況
Global Routing 也可能透過 Scene 依情境切換路由設定。初步排查時應先固定選項,避免情境條件改變測試路徑。以下是 Config 中 [Rule] 區段的語法範例,並非 WireGuard 伺服器參數;測試前請先備份目前的 Config,不要直接覆寫整份設定檔。
[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 比對地址範圍,GEOIP 依 IP 地理資料庫判斷,FINAL 則承接前面未符合的流量。範例中,存取 example.com 子網域的流量會先符合第一行;其餘流量不會一律直連,而是繼續往下比對。PROXY 最後使用哪台伺服器,仍須在 App 中核對。
七、依照狀況提供排查資訊,切勿提交私鑰
完成上述步驟後,仍須區分「無法與遠端建立有效通訊」與「已有隧道流量,但目標無法使用」。前者應優先核對金鑰、Endpoint 與 UDP 可連線性;後者再檢查 DNS、伺服器轉送、AllowedIPs 和 MTU。WireGuard 遇到無效請求時可能不會回傳可讀錯誤,因此介面沒有明確錯誤訊息,不代表所有欄位都正確。
| 觀察到的狀況 | 優先檢查項目 | 後續處理 |
|---|---|---|
| 發出請求後只有傳送量增加 | Endpoint、UDP 路徑、Peer 金鑰與 PresharedKey | 核對原始參數,並請服務商確認伺服器端是否收到請求。 |
| 連線後多數網域目標都無法使用 | DNS 可連線性、解析結果、目前路由 | 記下失敗的網域與時間,分辨是解析失敗還是無法連線目標。 |
| Proxy 正常,Config 異常 | Config 規則符合結果與策略選擇 | 檢查目標符合的規則,以及 PROXY 選用的伺服器。 |
| 閒置一段時間後請求失敗 | NAT 對應、網路切換、保活要求 | 重新連線作為對照,再向服務商核對 PersistentKeepalive。 |
| 小型請求成功,大型回應停滯 | 路徑 MTU、封包遺失、伺服器轉送 | 每次只調整一個參數,並記錄調整前後相同請求的結果。 |
聯絡自己的服務商時,可提供故障發生時間、使用 Wi-Fi 或行動網路、目前的 Global Routing、已遮蔽敏感資訊的 Endpoint、有無收發流量變化,以及單一變數測試結果。請勿提交 PrivateKey、PresharedKey、完整設定檔或含有憑證的訂閱連結。若金鑰已外洩,應申請更換身分並撤銷舊設定,而非只修改記錄名稱。
- 測試完成後,請還原原本的 Global Routing,並確認目前的 Config 與伺服器選擇。
- 若需要自動連線,請再前往 Settings → On Demand 還原設定,並分別確認 Wi-Fi 與行動網路下的行為。
- 保留必要的參數變更記錄,但不要將金鑰貼到公開筆記、截圖或公開討論中。