本文適合已持有服務商提供之 WireGuard 設定的使用者。先區分本機 Interface 與遠端 Peer，再依照 Add Server 的填寫順序核對地址、連接埠、金鑰及通道參數，最後分別檢查 AllowedIPs、Global Routing 與 MTU。閱讀後即可判斷各欄位應填在哪一側，以及「已開啟連線但請求失敗」時應從哪個環節排查。
一、先辨識設定中的 Interface 與 Peer
Shadowrocket（小火箭）的 WireGuard 類型會使用 WireGuard 協定建立通道。此協定透過 UDP 傳輸，雙方以金鑰識別身分；並非輸入帳號與密碼的連線方式。本文以使用者已有的合法設定為前提，參數應取自同一份分配給目前裝置的設定，不可混用不同裝置或不同 Peer 的欄位。
常見設定檔分為 [Interface] 和 [Peer] 兩個區段。前者描述本機通道介面，後者描述遠端。依序前往 Home → 右上角「+」→ Add Server → Type → WireGuard 後，應按欄位用途填入，而不是照設定檔的行號逐行複製；表單分組與選填欄位的位置可能因介面調整而異。
| 設定歸屬 | 常見欄位 | 填寫前確認 |
|---|---|---|
[Interface] | PrivateKey、Address、MTU | 描述目前用戶端，而非伺服器的私鑰與公網地址。 |
[Peer] | PublicKey、Endpoint、AllowedIPs | 描述遠端身分、連線目的地，以及允許交由該 Peer 處理的地址範圍。 |
[Peer] 選填項目 | PresharedKey、PersistentKeepalive | 僅在原始設定有提供，或實際網路環境需要時填寫。 |
| DNS 設定 | DNS | 屬於名稱解析設定，不是 Peer 公鑰，也不是 Endpoint 連接埠。 |
二、從 Add Server 開始填寫地址與金鑰
新增時先確認遠端地址與連接埠，再核對兩側金鑰，最後檢查本機地址及進階參數。以下依填寫順序整理；若介面將 WireGuard 專屬選項放在獨立區段，仍應依相同欄位用途對應填寫。
-
選擇類型
前往 Home →「+」→ Add Server → Type → WireGuard。先確認 Type，再填寫參數，以免在其他協定的表單中尋找同名欄位。
-
拆分 Endpoint
將原始設定中的 Endpoint 拆成 Address 的遠端主機與 Port 的連接埠。例如
vpn.example.com:51820僅供格式說明：主機是vpn.example.com，連接埠是51820，實際填寫時請使用自己的設定值。 -
核對金鑰
PrivateKey 填入本機 Interface 私鑰；PublicKey 填入遠端 Peer 公鑰。若原始設定有 PresharedKey，則填入對應欄位；不可將用戶端自己的公鑰當成遠端公鑰。
-
填寫通道參數
將 Interface 的 Address 填入本機通道地址欄位，並依表單支援的格式保留地址類型與前綴資訊，再核對 AllowedIPs、MTU 及選填的 PersistentKeepalive。
-
儲存並驗證
儲存後返回 Home，選取剛新增的設定，再檢查 Global Routing。首次連線時，依系統提示確認 VPN 設定授權，接著以明確會透過該設定傳送的請求進行測試。
Address 需依情境判讀。Add Server 的一般地址欄位通常指遠端伺服器，而 WireGuard Interface 的 Address 指本機通道地址，例如 10.66.0.2/32。轉填時務必確認欄位所屬區段，不可將內網通道地址填入遠端伺服器欄位。IPv6 Endpoint 在原始設定中常寫成 [2001:db8::10]:51820，方括號用來區隔地址與連接埠，不代表它是本機介面地址。
PrivateKey、PublicKey 和 PresharedKey 都是編碼後的金鑰值，不能以一般密碼取代。WireGuard 金鑰為 32 位元組，常見的 Base64 文字長度為 44 個字元；長度相符僅能協助發現字元遺漏，無法證明金鑰配對正確。複製時尤其要注意結尾的 =、隱藏換行及前後空白。
三、AllowedIPs 與 Global Routing 各自控制什麼
AllowedIPs 是 WireGuard Peer 的地址前綴集合：傳送時會用來判斷目標地址應交由哪個 Peer 處理；接收時也會限制該 Peer 可使用的來源地址。它不是網站網域清單，不能填入 example.com，也不能將整行 DOMAIN-SUFFIX 規則貼入。
Shadowrocket 的規則層與 WireGuard 的 Peer 層是兩套不同的判斷機制。Global Routing 選擇 Proxy、Direct、Config 或 Scene 等模式時，會決定請求如何進入策略處理；請求交由 WireGuard 後，還必須符合 Peer 的地址範圍與遠端轉送條件。不能只修改 AllowedIPs，就認定應用程式的所有流量都會進入該通道。
| 設定 | 說明 | 適用範圍 |
|---|---|---|
0.0.0.0/0 | 涵蓋所有 IPv4 地址。 | 不包含 IPv6，也不能取代 Global Routing 的選擇。 |
::/0 | 涵蓋所有 IPv6 地址。 | 遠端與本機設定仍須具備相應的 IPv6 能力。 |
10.20.0.0/16 | 僅涵蓋指定的 IPv4 網段。 | 用於受限網段時，不應預期所有公網目標都能透過該 Peer 連線。 |
DOMAIN-SUFFIX、IP-CIDR、FINAL | 屬於 Config 中的規則關鍵字。 | 用來控制請求的策略選擇，應放在規則設定中，不可放入 AllowedIPs。 |
結論：分開檢查兩層範圍
公網請求失敗時，先確認該請求實際選用了 WireGuard，再檢查 AllowedIPs 是否涵蓋目標地址類型與網段。只有其中一層設定正確，仍不足以建立可用的資料傳輸路徑。
在 Config 模式下，應檢查目前啟用設定的規則順序及最終套用的策略；Direct 模式不適合用來驗證 WireGuard 出口。Scene 則應依目前場景的具體設定判斷。若要排除規則因素，可先記下原設定，再暫時選用 Proxy 並指定待測的 WireGuard；驗證完成後還原原模式。
四、MTU、UDP 連接埠與 Keepalive 的設定範圍
MTU 用來限制通道介面可傳送的 IP 封包大小，單位為位元組。通道封裝會占用外層封包空間，因此不能直接將接入網路的 MTU 視為通道可用值。MTU 過大時，可能出現小型請求正常、較大回應停滯的情況；但 DNS、遠端轉送或網路封包遺失也可能造成類似現象，不能只憑網頁無法開啟就下結論。
- MTU：優先沿用服務商針對目前路徑提供的數值。外層路徑 MTU 為 1500 時，WireGuard 在外層 IPv4 下通常以約 60 位元組估算額外負擔，在外層 IPv6 下則約為 80 位元組；1420 是常見的起始值，並非適用於所有網路的答案。
- Port：必須與 Endpoint 一致。伺服器使用其他 UDP 連接埠時，不可因範例寫著 51820 就改成 51820；網頁或 TCP 測試成功，也無法證明同一地址的 UDP 通道正常。
- PersistentKeepalive：用於定期傳送保活資料，協助維持 NAT 對應。原始設定為 25 時，通常表示 25 秒，而非 25 毫秒；0 通常代表停用定期保活。
- PresharedKey：是雙方額外共用的金鑰，兩端必須一致。若原始設定未提供，請勿自行產生一組只填在用戶端，否則會造成金鑰不符。
結論：每次只變更一個參數
確認握手與路由正常後，若只有大型回應異常，可先記下原 MTU，再暫時將 1420 降至 1380 進行對照測試。若未改善，請還原原值並繼續檢查網路路徑。這是診斷步驟，不保證能提升速度。
五、從連線授權到網頁存取的排查順序
Home 的連線開關開啟，表示用戶端開始處理連線，不代表 WireGuard 已完成握手，也不代表 DNS 與遠端轉送都正常。WireGuard 通常會按需進行握手，因此驗證時應送出一筆確實交由該設定處理的請求，再配合可查看的記錄、統計資料或服務商端狀態判斷。
- 確認授權與選取項目：檢查系統 VPN 設定授權是否已完成，以及 Home 目前選取的是否為目標 WireGuard，而非其他已儲存的設定。
- 確認請求路徑：核對 Global Routing；使用 Config 時，檢查目標請求是否符合預期策略。排查期間可記錄 Settings → On Demand 的狀態，避免自動連線規則影響手動中斷、重新連線的觀察。
- 確認 Endpoint 可連線：若遠端使用網域名稱，先檢查該網域能否解析，再確認目前網路是否允許所填的 UDP 連接埠。切換 Wi-Fi 與行動網路有助於區分接入網路因素，但測試時應維持相同設定。
- 確認身分配對：檢查本機 PrivateKey 是否對應伺服器登錄的用戶端公鑰，以及遠端 PublicKey 是否取自目前的 Peer。若參數看似正確卻未能成功握手，應請原設定提供者核對登錄關係。
- 確認資料傳輸與解析：若已完成握手但請求沒有回應，請接著檢查 AllowedIPs、遠端轉送及存取權限；只有網域名稱存取異常時，再檢查 DNS 路徑，避免一開始就修改 MTU 或金鑰。
六、轉填 WireGuard 參數時的常見問題
可以互換 PrivateKey 和 PublicKey 試試看嗎？
不可以。請回到原始設定確認：Interface 的 PrivateKey 對應本機私鑰，Peer 的 PublicKey 對應遠端公鑰。若取得的是伺服器設定而非用戶端設定，應先取得分配給目前裝置的用戶端參數，切勿直接對調兩段設定。
AllowedIPs 已設為完整範圍，為什麼仍有請求直連？
先在 Home 查看 Global Routing。使用 Config 時，請求是否進入 WireGuard 由規則決定；使用 Direct 時，即使 AllowedIPs 設為完整範圍，也不會因此改走通道。請檢查目前規則套用的策略，再確認 IPv4 與 IPv6 範圍是否分別涵蓋。
原始設定中的 DNS 應該填入 Address 嗎？
不應混在一起填。Address 代表遠端地址或本機通道地址，需依欄位分組判斷；DNS 則是解析伺服器。請檢查目前 Config 中的 DNS 設定及其可連線路徑。若 DNS 位於通道內網，也須確認請求能透過 WireGuard 抵達該地址。
鎖定螢幕再解鎖後，連線總是等很久，調整 MTU 有用嗎？
先判斷是否為閒置後 NAT 對應失效。核對原始設定中的 PersistentKeepalive，並在再次送出請求時觀察握手是否恢復。MTU 處理的是封包大小，無法維持 NAT 對應；若切換網路後仍持續失敗，再檢查 Endpoint 與 UDP 通道。
記錄排查結果時，建議只記下網路類型、Global Routing 模式、目標地址類型、MTU 及失敗階段。如此可對照「未握手」、「已握手但沒有資料」及「只有網域名稱存取失敗」三類問題，避免同時反覆修改金鑰、路由與解析設定，失去可比較的測試條件。