適合已持有獲授權使用的 WireGuard 設定,並需要在 Shadowrocket(小火箭)核對欄位的使用者。先分清本機 PrivateKey 與對端 PublicKey,再填寫 Endpoint、隧道位址與 AllowedIPs,最後排除 Global Routing 規則造成的影響。本文說明參數與排查順序,不提供連線資料;示例位址僅供說明格式,無法用來建立實際連線。
一、先分清 WireGuard 設定的兩端
WireGuard 設定通常由 [Interface] 和一個或多個 [Peer] 區段組成。前者描述本機的隧道介面,後者描述允許通訊的對端。將設定移入 Shadowrocket 時,應依欄位所屬位置填寫,不要直接把設定中第一個 PublicKey 當成伺服器金鑰。
WireGuard 使用 UDP 傳輸。Endpoint 的連接埠由對端設定決定,51820 是常見範例,並非固定必用的連接埠。網頁能開啟、一般 TCP 連接埠測試有回應,都不能單獨證明目前網路允許這條 WireGuard UDP 通道。
金鑰通常以 Base64 文字表示,32 位元組的值編碼後通常為 44 個字元,結尾帶有 =。這個長度只能協助找出明顯的複製遺漏,無法證明金鑰屬於正確的裝置或對端。請勿將 PrivateKey、PresharedKey 或含有這些內容的 QR Code 貼到公開討論區。
二、PrivateKey、PublicKey 與 PresharedKey 如何對應
| 欄位 | 應填入的內容 | 常見填寫錯誤 |
|---|---|---|
PrivateKey | 目前用戶端對應的私鑰,來自其 [Interface] 區段。 | 誤填伺服器私鑰,或重新產生金鑰後,未同步登錄用戶端公鑰。 |
PublicKey | 目標 [Peer] 的公鑰,也就是此處要連線的對端公鑰。 | 誤將本機由 PrivateKey 衍生的公鑰填在此處。 |
PresharedKey | 雙方另外約定的預共享金鑰;只有原始設定有提供時才填寫。 | 一端填了數值、另一端未設定,或與 PrivateKey 混淆。 |
Address | 分配給本機的隧道內位址,例如 10.66.0.2/32。 | 誤填 Endpoint 的公網位址,或使用了另一台裝置的隧道位址。 |
PrivateKey 用來識別本機,其對應的用戶端公鑰必須登錄在對端設定中。只在 Shadowrocket 更換 PrivateKey,但對端仍保留舊的用戶端公鑰,通常無法完成握手。PublicKey 不是密碼,也不是可任意填寫的標籤;它必須與實際對端的私鑰配對。
複製金鑰時,請保留大小寫、加號、斜線與結尾等號,並移除不慎複製進去的引號和換行。若金鑰已外洩,應更換金鑰並同步更新對端登錄資料;只刪除聊天記錄並不會讓舊金鑰失效。
三、Endpoint、AllowedIPs、DNS 與 MTU 的用途
Endpoint 是建立加密通道時要連線的外部位址,不是隧道內部位址。IPv4 範例為 192.0.2.10:51820;使用 IPv6,且位址與連接埠填在同一欄時,格式為 [2001:db8::10]:51820。若介面分別提供位址和連接埠欄位,位址欄只填主機名稱或 IP,連接埠欄則單獨填入數字。
| 設定項目 | 用途 | 核對方式 |
|---|---|---|
AllowedIPs | WireGuard Peer 的位址範圍選擇,以及接收來源的限制。 | 用戶端的出站目標必須落在相應 Peer 的範圍內;也要確認對端允許用戶端的隧道來源位址。 |
DNS | 常見設定檔提供的解析器設定,不屬於 WireGuard 握手本身。 | 確認解析器位址可透過目前連線路徑存取,並檢查 Shadowrocket 目前 Config 中的 DNS 設定。 |
MTU | 隧道介面可傳輸的 IP 封包大小上限。 | 優先保留設定提供方指定的數值;若大請求卡住、小請求正常,再單獨嘗試調整。 |
PersistentKeepalive | 閒置時定期傳送 keepalive 封包,間隔以秒為單位。 | 需要維持 NAT 對應時,可依設定方要求使用,例如 25;這無法修復錯誤的金鑰。 |
AllowedIPs 不是 Shadowrocket 的完整分流規則
0.0.0.0/0 表示涵蓋所有 IPv4 位址,::/0 表示涵蓋所有 IPv6 位址。只填前者不代表 IPv6 也一併涵蓋;只填 10.66.0.0/24 則只涵蓋這個網段。範圍應符合自身用途與對端能力,不要只為了「看起來完整」就直接擴大。
在 Shadowrocket 中,Global Routing 與目前的 Config 會先決定連線採用哪條路徑;連線交由 WireGuard 出站處理時,也必須符合該 Peer 的位址範圍限制。因此,AllowedIPs 包含某個 IP,不代表存取該 IP 時一定會自動選用這個 WireGuard 項目;規則選中該項目,也不代表缺少的 AllowedIPs 範圍會自動補上。
# 僅用於說明位址格式;不是可直接匯入的完整設定。
# 以下位址為範例,並不對應實際服務。
[Interface]
Address = 10.66.0.2/32
MTU = 1420
[Peer]
Endpoint = 192.0.2.10:51820
AllowedIPs = 0.0.0.0/0, ::/0
PersistentKeepalive = 25
1420 是常見的 MTU 參考值,並非適用所有網路的最佳值。若握手正常,但較大的回應停滯,可先記下原值,再嘗試較小的數值,例如 1380,以相同請求重新測試後再決定是否保留。不要同時修改 MTU、DNS 和金鑰,否則無法判斷是哪項變更生效。也不要假設原始檔案中的 DNS、MTU 等設定,在不同匯入方式下都會自動套用。
四、在 Shadowrocket 新增 WireGuard 的核對步驟
以下依 Home、Config、Settings 的介面結構說明手動新增順序。不同平台的欄位排列和儲存按鈕位置可能不同,請依英文欄位名稱逐項對照。若持有的設定包含多個 Peer,不要預設手動新增一個連線項目就會完整還原所有 Peer 的選用關係;應先確認這次要使用哪個對端。
-
整理原始設定
分清
[Interface]與目標[Peer],備妥用戶端 PrivateKey、Address、對端 PublicKey、Endpoint 和 AllowedIPs。原始設定若有 PresharedKey,也一併備妥。 -
選擇類型
前往 Home → 右上角「+」→ Type → WireGuard。使用容易辨識的名稱,避免與現有連線項目同名而誤選。
-
填寫欄位
依本機與 Peer 的欄位歸屬填寫金鑰和位址;若 Endpoint 分成位址和連接埠兩欄,請分別輸入。保留 AllowedIPs 的 CIDR 前綴長度;若未提供 PresharedKey,請勿自行產生替代值。
-
儲存並選取
儲存後返回 Home,選取剛新增的 WireGuard 項目。確認目前的 Global Routing 設定,再開啟連線;首次出現系統權限提示時,依裝置畫面操作。
-
測試並還原設定
使用自己有權存取,且位於 AllowedIPs 涵蓋範圍內的目標進行測試。排查完成後,還原日常使用的 Global Routing 設定;前往 Config 確認實際規則引用的策略仍指向預期的出站。
五、使用 Global Routing 區分參數錯誤與規則影響
開始診斷前,先記下 Home → Global Routing 目前的設定值。Config、Proxy、Direct、Scene 是路由模式,不是 WireGuard 的金鑰選項。Scene 會依已設定的場景行為運作;尚未確認場景內容前,不宜將它當成固定的測試路徑。
Config
建議使用依目前 Config 中的規則選擇策略。DOMAIN-SUFFIX、GEOIP、IP-CIDR 與 FINAL 等規則可能會將不同目標交給不同出站;只有命中相應策略的連線才會使用該 WireGuard 項目。
適用情境:規則核對完成後的日常分流。
Proxy
讓進入 Shadowrocket 處理範圍的連線使用選定的代理路徑,減少 Config 規則選擇造成的變因。仍須確認選定的是目標 WireGuard 項目,且目標位址位於其 AllowedIPs 範圍內。
適用情境:短時間檢查 WireGuard 出站能否存取指定測試目標。
Direct
採用直連路徑。此時網頁能開啟,只表示直連條件下可以存取,不能證明 WireGuard 設定成功,也不能用來判斷該 Peer 的出口狀態。
適用情境:比對裝置原有網路的基本連線狀態。
若指定目標在 Proxy 下可存取,切回 Config 後卻失敗,請先檢查該目標命中的規則及其策略,不要立刻更換 PrivateKey。反過來說,若 Proxy 下也無法存取,應回頭核對 Endpoint、UDP 可達性、雙方金鑰和 AllowedIPs。Settings → On Demand 用來管理依條件觸發連線的行為,不會修改 Peer 金鑰;排查自動重新連線造成的干擾時,可先記下目前狀態,再暫時關閉並手動控制連線。
六、如何排查握手失敗、網域無法連線與閒置斷線
已開啟連線,為什麼還是無法存取?
開啟連線不代表 Peer 已完成有效通訊。先確認 Home 中選取的是目標 WireGuard 項目,再核對 Endpoint 位址與 UDP 連接埠、用戶端 PrivateKey 對應的公鑰是否已登錄在對端,以及 PublicKey 是否確實來自對端。若有日誌或對端握手紀錄,請觀察發起測試後是否出現新的有效握手;不要只看連線開關。
有握手紀錄,卻收不到網頁內容?
檢查雙方的 AllowedIPs:用戶端是否涵蓋目標位址,對端是否允許本機的隧道來源位址。若目標位於對端後方的網路,還需請網路管理方核對轉送、防火牆、回程路由及必要的 NAT。握手表示金鑰與基本 UDP 通道可用,但不保證對端已具備轉送至目標網路的能力。
IP 位址可連線,網域名稱卻解析失敗?
前往 Config 檢查目前設定的 DNS 與解析器可達性,並分辨是 Endpoint 主機名稱解析失敗,還是服務網域解析失敗。測試裸 IP 時,應選擇本來就支援以 IP 存取的目標;HTTPS 網站可能因憑證或虛擬主機要求而拒絕裸 IP,不能直接將這類錯誤歸因於 DNS。
閒置一段時間後就無法連線,重新連線又恢復?
先確認是否發生 Wi-Fi 與行動網路切換,或系統休眠導致連線狀態變更。若懷疑 NAT 對應逾時,請依原始設定要求核對 PersistentKeepalive,例如 25 秒;同時查看 Settings → On Demand 是否設有相應觸發條件。Keepalive 會增加週期性通訊,無法取代網路切換後的實際測試。
提交排查資料時,可描述發生問題的時間、網路類型、目標位址類別、Global Routing 設定值及是否出現握手紀錄,但請遮蔽 PrivateKey、PresharedKey 和完整訂閱網址。每次只修改一個欄位並留下紀錄,比連續替換多組參數更容易找出原因。