本文重點

適合已持有獲授權使用的 WireGuard 設定,並需要在 Shadowrocket(小火箭)核對欄位的使用者。先分清本機 PrivateKey 與對端 PublicKey,再填寫 Endpoint、隧道位址與 AllowedIPs,最後排除 Global Routing 規則造成的影響。本文說明參數與排查順序,不提供連線資料;示例位址僅供說明格式,無法用來建立實際連線。

一、先分清 WireGuard 設定的兩端

WireGuard 設定通常由 [Interface] 和一個或多個 [Peer] 區段組成。前者描述本機的隧道介面,後者描述允許通訊的對端。將設定移入 Shadowrocket 時,應依欄位所屬位置填寫,不要直接把設定中第一個 PublicKey 當成伺服器金鑰。

WireGuard 使用 UDP 傳輸。Endpoint 的連接埠由對端設定決定,51820 是常見範例,並非固定必用的連接埠。網頁能開啟、一般 TCP 連接埠測試有回應,都不能單獨證明目前網路允許這條 WireGuard UDP 通道。

UDP
WireGuard 傳輸協定
32 位元組
解碼後的公鑰與私鑰長度
51820
本文 Endpoint 範例連接埠,非強制值

金鑰通常以 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,連接埠欄則單獨填入數字。

設定項目用途核對方式
AllowedIPsWireGuard 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 的選用關係;應先確認這次要使用哪個對端。

  1. 整理原始設定

    分清 [Interface] 與目標 [Peer],備妥用戶端 PrivateKey、Address、對端 PublicKey、Endpoint 和 AllowedIPs。原始設定若有 PresharedKey,也一併備妥。

  2. 選擇類型

    前往 Home → 右上角「+」→ Type → WireGuard。使用容易辨識的名稱,避免與現有連線項目同名而誤選。

  3. 填寫欄位

    依本機與 Peer 的欄位歸屬填寫金鑰和位址;若 Endpoint 分成位址和連接埠兩欄,請分別輸入。保留 AllowedIPs 的 CIDR 前綴長度;若未提供 PresharedKey,請勿自行產生替代值。

  4. 儲存並選取

    儲存後返回 Home,選取剛新增的 WireGuard 項目。確認目前的 Global Routing 設定,再開啟連線;首次出現系統權限提示時,依裝置畫面操作。

  5. 測試並還原設定

    使用自己有權存取,且位於 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 和完整訂閱網址。每次只修改一個欄位並留下紀錄,比連續替換多組參數更容易找出原因。