Shadowrocket WireGuard 設定教學：PrivateKey、Endpoint 與 AllowedIPs

一、加入前先分清 Interface 與 Peer

Shadowrocket（小火箭）的 WireGuard 設定不能只靠一個伺服器位址完成。常見的 WireGuard 設定分為 [Interface] 與 [Peer]：前者描述本機的金鑰與隧道位址，後者描述通訊對端的公鑰、入口及允許的位址範圍。若把兩邊的金鑰填反，即使位址和連接埠正確，也無法完成正常驗證。

本文以使用者已備妥服務商提供或自行建立的設定為前提。開始前應取得完整且彼此相符的參數；只有 Endpoint，沒有本機 PrivateKey 或對端 PublicKey，無法組成可用設定。Shadowrocket 是閉源商業應用，客戶端買斷不等於線路方案；購買客戶端不會自動產生可用的 WireGuard 對端。

二、在 Home 加入 WireGuard 並保留原始參數

手動加入請從 Home → 右上角「+」→ Type → WireGuard 開始。選好協定後再填寫，避免將 WireGuard 參數填進其他協定的表單。以下以 WireGuard 設定檔的標準欄位名稱說明對應方式；應用程式表單可能會將 Endpoint 拆成位址與連接埠，實際欄位請以目前應用程式內顯示為準。

1. 整理設定

   保留一份原始設定，分別標出 Interface 的 PrivateKey、Address，以及 Peer 的 PublicKey、Endpoint、AllowedIPs。若有 PresharedKey，也一併記下，但不要放進公開筆記或截圖。

2. 選擇協定

   前往 Home →「+」→ Type → WireGuard。先確認 Type，再輸入參數；不要把整份設定檔文字貼進伺服器位址欄。

3. 填寫入口

   將 Endpoint 的主機與連接埠分別填入。例如 192.0.2.10:51820 代表主機 192.0.2.10、連接埠 51820；此文件中的範例位址不可作為實際入口使用。

4. 填寫身分

   填入本機 PrivateKey、對端 PublicKey 和已指派的 Address，再依原始設定處理 AllowedIPs 與選用參數。金鑰內容不要附帶引號、欄位名稱或換行。

5. 儲存並測試

   儲存後返回 Home，選取該設定並確認 Global Routing，再開啟連線。首次出現系統 VPN 設定授權提示時，確認是此應用程式後依系統指示操作。使用已知可存取的目標發出請求，並檢查連線結果。

三、PrivateKey 與 PublicKey：長度正確不代表配對正確

PrivateKey 用於驗證本機身分，其對應的本機 PublicKey 必須登記在遠端的 Peer 設定中。Shadowrocket 內填寫的 Peer PublicKey 則應取自遠端。雙方不是互換私鑰，而是各自保管私鑰，並使用對方的公鑰辨識通訊對端。

上述長度只能用來檢查明顯的複製錯誤，無法證明金鑰有效或屬於同一連線。結尾的 = 可能是 Base64 填充，不應任意刪除；聊天排版帶入的空格、引號和換行則不屬於金鑰。也不要憑外觀相似的字元手動補齊缺漏內容。

• 誤填本機公鑰：若 Peer PublicKey 填成本機公鑰，請從原始設定重新取得遠端公鑰，不要反覆重建連線。
• 只更換本機私鑰：新的 PrivateKey 會對應新的本機 PublicKey，遠端也必須同步登記，否則身分將不相符。
• 遺漏預先共用金鑰：原始設定啟用 PresharedKey 時，不能只填寫雙方的公私鑰；此值不一致同樣會使驗證失敗。
• 多台裝置共用身分：不同裝置同時使用同一組身分時，遠端可能依收到的驗證資料更新端點，造成連線互相干擾。請由設定管理方指派獨立的 Peer 與隧道位址。

四、Endpoint、Address 與 AllowedIPs 各自控制什麼

Endpoint 是建立通訊時連線的外層入口，Address 則是本機在隧道內使用的位址，兩者不可互換。例如遠端公網入口使用連接埠 51820，不代表本機 Address 也要包含該連接埠。WireGuard 使用 UDP；若入口只允許 TCP，即使填入相同的連接埠號碼，也無法取代 UDP 連通性。

在 WireGuard 協定層，AllowedIPs 會參與選擇要將輸出資料送往哪個 Peer，也用於驗證該 Peer 傳來的資料所宣告的來源位址。它不是網站網域清單，不能填入 example.com，也不能直接放進 DOMAIN-SUFFIX 規則。只有 IPv4 預設範圍而沒有 IPv6 範圍時，不應因此認定 IPv6 目標也已涵蓋。

• Endpoint 使用網域名稱時，必須先能解析該網域，才有機會向遠端送出握手流量。
• Address 的前綴長度不能只憑習慣更改；/32 與 /24 代表的位址範圍不同。
• 擴大 AllowedIPs 不會賦予遠端原本不具備的轉送或存取權限，應先確認對端允許的用途。

五、Global Routing 與 WireGuard 並非同一層的設定

Shadowrocket 會先依自身的流量策略決定請求的去向，WireGuard 參數則會限制選用此連線後的通訊。Global Routing 中的 Proxy、Direct、Config、Scene 不能與 AllowedIPs 畫上等號：Proxy 用於代理路徑，Direct 用於直接連線，Config 依設定規則處理，Scene 則依已設定的情境處理。實際結果也會受選取的策略與設定影響。

首次測試時，可在了解影響範圍的前提下短暫使用 Proxy，並選取待測的 WireGuard 連線，減少規則分流對判斷的干擾；測試後再恢復原本設定。在 Config 模式下，即使 WireGuard 本身可用，若請求符合 DIRECT 規則，也不會因為 AllowedIPs 設定了預設範圍，就自動改走該 Peer。

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

這段僅用來示意規則關鍵字，不是 WireGuard 設定，也不是要求覆蓋現有的 Config。DOMAIN-SUFFIX 會比對網域後綴，GEOIP 依 IP 地理資料庫比對，IP-CIDR 會比對 IP 網段，FINAL 則接收未符合前面規則的請求。範例中的 PROXY 代表代理策略；實際使用時還要確認設定中的策略指向，不能只看規則最後的文字。

六、MTU 與 PersistentKeepalive 的調整範圍

MTU 控制隧道介面傳送的 IP 封包大小。WireGuard 封裝還需要額外的外層 IP、UDP 等開銷，因此不能直接將底層連線的 MTU 原值照搬到隧道。1420 是常見的排查參考值，但不適用於所有路徑；應優先採用既有設定提供的數值，或使用應用程式的預設處理方式。

1. 先確認基本連線。若尚未建立握手，應先檢查 Endpoint、UDP 網路與金鑰，不要把 MTU 當成首要原因。
2. 記錄可重現的狀況。例如小型請求成功，但較大的回應一再停滯，才需要進一步懷疑路徑 MTU、封包遺失或相關網路限制。這只是排查線索，不能僅憑現象就下定論。
3. 每次只修改一個數值。可在設定提供方允許的範圍內，分別以 1420、1380 進行比較；每次儲存並重新連線，以相同目標和請求再次測試，並記下原值以便還原。
4. 避免一味降低數值。若降低後沒有改善，應回頭檢查 DNS、路由與對端狀態，而非持續調低數值。使用 IPv6 時，也須符合其鏈路 MTU 限制。

PersistentKeepalive 用於定期傳送保活資料，協助維持 NAT 對應。25 秒是常見設定範例，並非協定要求必須啟用；0 代表關閉定期保活。若閒置一段時間後回程通訊中斷，可將其納入排查，但它無法修正錯誤的公鑰、無法連線的連接埠或未獲允許的目標網段。

• 設定檔使用的單位是秒，請勿將 25 秒誤填為毫秒。
• 並非所有網路都需要相同的保活頻率，應依設定提供方的要求與實際測試結果決定。
• 切換行動網路後應重新測試；保活無法保證網路位址變更期間所有請求都不中斷。

七、依據現象排查，不要反覆重建設定

每輪排查只變更一個項目，並記錄測試網路、Global Routing 模式、存取目標與結果。Home 顯示的延遲或連線結果，只能反映對應測試項目的狀況；不同測試方式涵蓋的環節各不相同，不能用單一延遲數值證明金鑰、DNS、AllowedIPs 與所有業務請求都正常。