設定 WireGuard 時，先分清本機身分、對端身分與外層連線位址，再確認隧道內的 Address。本文適合已取得服務商提供設定的使用者：依欄位對照完成輸入，以預設 MTU 建立基準，再分別確認 DNS、UDP 是否可連通，以及閒置後能否恢復連線，避免把所有問題都歸因於金鑰或 MTU。
先分清金鑰、隧道位址與 Endpoint
在 Shadowrocket（小火箭）中選擇 WireGuard 類型，不代表連線已可正常使用。WireGuard 透過金鑰識別通訊雙方，並以 UDP 傳送封裝後的資料；伺服器也必須登錄對應用戶端的 PublicKey，並允許使用分配的隧道位址。只完成用戶端設定，無法取代伺服器端的配對設定。
本文以 [Interface]、[Peer] 中的標準 WireGuard 欄位說明其用途。這些是設定檔中的名稱，不代表 Shadowrocket 編輯頁一定採用相同的分組或拼法。輸入時請對照 App 實際顯示的欄位，尤其不要只憑 Address 標籤，就判定它是伺服器位址還是隧道內位址。
例如，192.0.2.10:51820 可用來說明 Endpoint 的「主機位址加連接埠」格式，10.66.0.2/32 則可用來說明隧道內 IPv4 位址的格式。前者是文件範例位址，兩者都不是本文提供的連線參數；實際值必須以使用者已有的設定為準。連接埠 51820 是常見範例，並非所有 WireGuard 服務都固定使用此連接埠。
PrivateKey 與 PublicKey 的來源
PrivateKey 是目前用戶端身分的私鑰；與其配對的用戶端 PublicKey 應登錄在伺服器端。用戶端 [Peer] 中需要填入的 PublicKey，則是伺服器公鑰。這兩者最容易搞混：即使格式正確，若把自己的公鑰填入對端公鑰欄位，也無法完成預期的身分驗證。
本機身分與位址
- PrivateKey
- 取自目前用戶端設定的私鑰，務必保密。
- 用戶端 PublicKey
- 由本機 PrivateKey 對應產生，供伺服器端登錄。
- Address
- 伺服器分配的隧道內位址，例如 10.66.0.2/32。
本機私鑰、伺服器登錄的用戶端公鑰與分配位址必須彼此對應。
對端連線資訊
- PublicKey
- 對端伺服器公鑰，不是用戶端自己的公鑰。
- Endpoint
- 伺服器主機名稱或 IP 位址，以及實際 UDP 連接埠。
- PresharedKey
- 選填的預共享金鑰；只有原始設定要求時才填寫。
PresharedKey 不能以 PrivateKey 或 PublicKey 取代，也不能自行填入任意值。
WireGuard 常見的 Base64 金鑰文字為 44 個字元，末尾通常帶有 =。這只能用來檢查輸入格式，無法證明金鑰屬於正確的對端。複製時請確認沒有多餘的空格、換行或引號；不要為了湊足長度而自行增刪字元。若金鑰已外洩，應更換相關金鑰並同步更新伺服器端登錄資料，而不只是修改節點備註。
在 Home 新增 WireGuard 的檢查步驟
先保留目前可用的設定，再新增一個供檢查用的項目。以下步驟以手動輸入為主；若參數是從既有訂閱匯入，請先確認實際產生的是 WireGuard 類型。不要將 WireGuard 設定文字貼到只接受訂閱 URL 的輸入欄，也不要假設所有設定格式都能由同一個匯入入口辨識。
-
選擇類型
前往 Home → 右上角「+」→ Type → WireGuard。確認類型後再填寫參數，避免在其他協定的編輯表單中套用同名欄位。
-
填寫對端資訊
將原始設定中 Endpoint 的主機與連接埠，分別填入伺服器位址和連接埠欄位。例如 192.0.2.10:51820 表示主機為 192.0.2.10、UDP 連接埠為 51820；此處僅示範拆分方式。
-
對應身分
填入本機 PrivateKey、對端 PublicKey，以及原始設定要求的 PresharedKey。逐一確認資料來源，切勿混淆用戶端公鑰與伺服器公鑰。
-
確認位址
將分配的隧道內 Address 對應填入本機位址欄位。若原始設定同時包含 IPv4 與 IPv6，請分別確認；若介面將位址與前綴分開，請依實際欄位填寫。
-
儲存並驗證
儲存後返回 Home，選取該項目，再確認 Global Routing。首次連線時，請依系統提示完成 VPN 設定授權，之後以實際請求測試，不要只看連線開關。
訂閱管理的項目可能在下次更新時，重新套用來源設定。若要測試 MTU 或保活間隔，請先記下原值，並使用能獨立保留的測試項目；若修改內容之後消失，先確認是否發生訂閱更新，不要反覆重填金鑰。Shadowrocket 的 Home、Config、Settings 分別用於選擇連線、管理設定與調整 App 設定；修改某個節點不會自動切換目前選取的 Config。
Address、AllowedIPs 與分流規則的界線
Address 是隧道介面的本機位址，不是 DNS 位址，也不是伺服器的公網 IP。後綴 /32 代表一個 IPv4 主機位址，/128 則代表一個 IPv6 主機位址。不要任意將服務商分配的位址改成其他裝置的位址；重複使用相同身分或位址，可能造成回應封包路徑改變與間歇性中斷。
| 設定項目 | 具體用途 | 不能據此推論 |
|---|---|---|
| Address | 本機隧道位址，例如 10.66.0.2/32 | 不可作為公網伺服器位址使用 |
| Endpoint | 外層 UDP 封包傳送至的主機與連接埠 | 連接埠開放不代表身分配對成功 |
| AllowedIPs | 標準 WireGuard 的對端位址選擇與接收來源限制 | 不能直接視為 Shadowrocket 的網域分流規則 |
| Global Routing | Shadowrocket 目前的全域路由模式 | 選取 WireGuard 項目不代表所有請求都會經過它 |
在標準 WireGuard 設定中，0.0.0.0/0 和 ::/0 分別涵蓋所有 IPv4 與 IPv6 位址範圍。但將 WireGuard 作為 Shadowrocket 節點使用時，實際請求是否經過此節點，仍須確認 Global Routing、目前的 Config 與命中的策略。不要只因原始檔案包含這兩個範圍，就認定 App 內的所有流量都會使用該節點。
DOMAIN-SUFFIX依網域後綴比對，不會驗證 WireGuard 金鑰。IP-CIDR依目標 IP 網段比對，不是用來指定本機介面的 Address。GEOIP用於比對 IP 位址所屬地區，無法解決 Endpoint 的 UDP 無法連線問題。FINAL是前面的規則都未命中時使用的預設規則；其策略不一定是目前的 WireGuard 節點。
MTU：先保留基準，再處理大型封包異常
MTU 是隧道介面可承載的最大 IP 封包大小，不是網速上限。WireGuard 封裝還會增加外層 IP、UDP 與協定本身的額外負載；若底層路徑可容納的封包較小，而路徑 MTU 探測未正常運作，就可能出現小型請求成功、較大的回應卻停住的情況。若握手正常但頁面資源載入不完整，可進一步檢查 MTU，但這只是線索，不能直接據此判定原因。
保留預設值或原始設定
建議首次測試時沿用 App 預設處理方式，或原始設定明確指定的 MTU，先確認金鑰、位址與 Endpoint 都能正常運作。這樣的結果可作為後續比較的基準。
適用情況：初次輸入、連線正常，尚未發現大型封包異常
一次只降低 MTU
只有原值高於目標值時，才嘗試較小的數值，例如從 1420 調整為 1380，再以相同請求重新測試。這兩個數值僅供排查示範，並非通用最佳值；每次只調整 MTU，並記錄原值以便還原。
適用情況：小型請求成功，但大型回應或特定網路下反覆停頓
還原原值並再次確認
若降低 MTU 後問題沒有改善，請還原原值，改查 UDP 是否可連通、DNS 與伺服器端路由。較小的 MTU 可能增加封包數量，持續調低無法解決所有問題。
適用情況：調整無效，或問題實際上由其他參數造成
若隧道需要承載 IPv6，請勿任意將介面 MTU 調至 1280 以下；1280 是 IPv6 最小鏈路 MTU 的重要界線。排查期間請維持其他條件一致，例如使用同一個 Wi-Fi、測試相同目標請求，並記錄修改前後的狀況。本文數值僅用於說明測試方法，不代表任何線路的實測結果或效能保證。
DNS 與 PersistentKeepalive 各自處理什麼問題
DNS 用來將網域名稱解析為位址；WireGuard 加密握手不會自動證明網域解析正常。若 Endpoint 使用主機名稱，建立外層連線前也需要先解析該名稱。請區分「無法解析伺服器主機名稱」與「隧道建立後無法解析目標網域」這兩個階段；兩者可能使用不同的查詢路徑。
標準 WireGuard 設定中的 DNS 是供設定工具使用的輔助設定，並非 WireGuard 握手協定的一部分。將節點用於 Shadowrocket 時，不要假設原始檔案中的 DNS 行一定會完整接管 App 的解析行為；也要確認目前 Config 的 DNS 設定。若 DNS 位址只能從隧道內存取，必須先確保有正確的連線路徑。
- 網域無法連線，但已知 IP 可連線：優先檢查解析伺服器、查詢路徑與 IPv4／IPv6 回傳結果；這只是診斷線索，並非最終結論。
- Endpoint 使用網域且無法建立連線：先確認目前網路能否解析該主機名稱，再檢查 UDP 連接埠；不要先修改隧道內的 DNS。
- 閒置後第一個請求停頓：先確認 NAT 對應是否逾時，再評估 PersistentKeepalive，不要直接重新建立金鑰。
- 切換網路後恢復緩慢：分別記錄 Wi-Fi 與行動網路的狀況，確認是否只有某個網路限制 Endpoint 的 UDP 流量。
PersistentKeepalive 的單位是秒，用於閒置時傳送保活資料，以維持 NAT 或防火牆的對應狀態。25 秒是常見參考間隔，並非必須值；在標準設定中，0 代表停用週期性保活。縮短間隔會增加閒置時的網路活動，不代表連線一定更穩定，應依既有設定與網路狀況決定。
依失敗階段排查，不要同時修改多項參數
Home 顯示連線已開啟，首先只能表示系統 VPN 通道已啟動，不能單憑此點證明 WireGuard 對端已回應。延遲測試也須依測試方式判讀：單次逾時無法區分「UDP 無法連線」、「金鑰不符」或「測試目標沒有回應」。請將問題定位到建立連線、傳輸資料、解析網域或閒置後恢復等具體階段。
| 觀察到的狀況 | 優先確認 | 下一步處理 |
|---|---|---|
| 始終沒有有效回應 | Endpoint、UDP 連接埠、雙方公鑰配對、PresharedKey | 分別透過 Wi-Fi 與行動網路測試，並確認伺服器端的登錄資料 |
| 有回應，但無法連線至目標 | 隧道 Address、伺服器轉送、目前選取的節點與策略 | 確認請求確實經過該節點，再檢查伺服器端路由 |
| 只有網域無法連線 | Endpoint 解析與目標網域解析各自所處的階段 | 在相同路由條件下，比較解析結果與已知 IP 的連線狀況 |
| 小型回應正常，大型回應停住 | 路徑 MTU、IPv6 路徑與中間網路限制 | 只調整 MTU，重複相同測試並記錄結果 |
| 閒置一段時間後失效 | NAT 對應、PersistentKeepalive、網路切換 | 記錄閒置時間，依原始設定調整保活後再測試 |
若懷疑規則繞過測試節點，可前往 Home → Global Routing，暫時選擇 Proxy，並確認選取的是待測的 WireGuard 項目。這麼做可減少規則分流造成的變因，但無法修復節點本身。測試結束後，請還原原本的 Config 或其他既有模式，避免將診斷設定誤當成日常設定。
將 WireGuard 連接埠改成 443，會比較容易連線嗎？
只有對端實際監聽相應的 UDP 連接埠時才能這樣修改。UDP 443 與 TCP 443 是不同的傳輸端點；某個網頁能透過 TCP 443 開啟，不代表目前網路允許連線至同一位址的 UDP 443。請勿猜測連接埠取代確認原始設定。
同一組 WireGuard 參數可以直接複製到 iPhone 和 iPad 嗎？
不要預設兩部裝置可以同時共用相同身分與隧道位址。對端可能會依據最近收到的有效封包更新通訊端點，重複使用設定可能讓兩部裝置互相干擾。請使用既有服務商明確分配給各裝置的身分與位址；App 購買適用性與協定身分分配是兩回事。
排查完成後，請保留一份不含金鑰的變更紀錄：修改了哪個欄位、原值與新值、使用哪種網路，以及哪個請求恢復正常。若所有網路都收不到有效回應，請回頭檢查 Endpoint 與身分配對；若只有某類請求異常，再檢查 DNS、分流與 MTU。依序排查比同時修改多項參數更容易得到可重現的結論。