Shadowrocket WireGuard 設定教學：PrivateKey、PublicKey、Endpoint 與 MTU 說明

1. WireGuard 設定中的本機與遠端

在 Shadowrocket（小火箭）中，WireGuard 是連線協定，不是訂閱格式，也不是分流規則。本文以服務商提供的用戶端設定為例：[Interface] 描述本機隧道介面，[Peer] 描述遠端對等端。請先確認檔案是供用戶端使用，再填入各欄位；不可直接將伺服器設定當作用戶端設定。

訂閱連結或獨立設定都應向你的服務商取得。如果匯入訂閱後已產生完整的 WireGuard 項目，先核對該項目即可，不必再手動建立同名項目。訂閱更新可能會重新寫入參數；需要測試修改時，請保留原項目，並將測試副本與由訂閱管理的項目區分開來。

設定填寫正確，與實際請求經由該連線傳送，是兩回事。Home 中選取的項目、Global Routing 的模式，以及 Config 中符合的規則，都會影響請求路徑。請先核對連線參數，再確認流量是否指向該項目，避免將規則直連誤判為 WireGuard 失效。

2. PrivateKey、PublicKey 與 PresharedKey 的對應關係

PrivateKey 是本機身分的私密部分；用戶端設定中 [Peer] 的 PublicKey 則用來識別遠端。兩者代表不同身分，不可互換，也不可將本機由 PrivateKey 衍生的 PublicKey 填入遠端 PublicKey 欄位。伺服器必須登錄與本機 PrivateKey 對應的公鑰，雙方設定才有可能相符。

WireGuard 金鑰是以 Base64 編碼的 32 位元組值，常見文字長度為 44 個字元，末尾可能包含 =。長度符合只能用來檢查格式，無法證明金鑰與伺服器相符。複製時請移除前後空白，避免混入換行、引號或說明文字，也不要刪除末尾的填充字元。

3. Endpoint 與 Address：伺服器入口不等於隧道位址

Endpoint 包含遠端主機與連接埠。例如 192.0.2.1:51820 中，主機是 192.0.2.1，連接埠是 51820。如果 Shadowrocket 編輯頁將位址與 Port 分成兩個欄位，請分別填寫；不要把含連接埠的完整內容填入只接受主機名稱的位址欄。IPv6 Endpoint 組合表示時須加上方括號，例如 [2001:db8::1]:51820。

Address 是隧道內部使用的本機位址，通常以含前綴長度的格式提供，例如 10.66.0.2/32。若服務商同時提供 IPv4 與 IPv6，請依其指派結果填寫。不要將 Endpoint 的公網位址填入 Address，也不要從其他裝置複製相同的隧道身分並同時使用，以免造成身分或位址衝突。

表格中的位址僅用來說明欄位，不能當作可用設定。尤其 192.0.2.1 與 2001:db8::1 都是文件範例位址。要能實際連線，還須確認連接埠已開放、遠端支援 UDP、金鑰相符，且本機網路允許相關通訊。

4. 在 Home 新增 WireGuard 項目的核對步驟

手動新增適用於已取得獨立參數的情況。以下路徑以英文介面名稱為例，欄位排列可能因裝置版面而異；若服務商提供的項目在編輯頁找不到對應欄位，不要硬塞進其他欄位，應先確認該設定的匯入方式與支援範圍。

1. 保留原始設定

   保存服務商提供的原始參數，並記下 Home 目前選取的項目與 Global Routing 模式。測試期間每次只修改一項，方便還原。

2. 選擇協定

   前往 Home → 右上角「+」→ Type → WireGuard。先確認 Type，再填寫位址、Port 與金鑰，以免沿用其他協定表單的欄位意義。

3. 對應欄位

   將 Endpoint 拆分為遠端主機與 Port；PrivateKey 對應本機私鑰，PublicKey 對應遠端公鑰。Address、DNS、MTU 請依原始設定及編輯頁支援的欄位填寫。

4. 儲存並選取

   儲存後返回 Home，選取剛新增的項目，再啟用連線。首次設定 VPN 時，請依系統提示授權；系統顯示 VPN 已連線，不代表遠端交握與業務請求都已成功。

5. 固定測試條件

   先使用相同網路與相同測試請求。若 Settings → On Demand 已啟用，請記下其條件，避免自動連線影響手動測試；完成後還原原本設定。

不要只因 Home 中一次延遲測試顯示數值，就認定所有服務都可正常使用。測試結果會受到測試方式、目標與請求路徑影響；還應檢查網域解析、實際頁面載入，以及較大內容的傳輸。反過來說，某種延遲測試失敗，也不能單獨證明 PrivateKey 有誤。

5. DNS 與 AllowedIPs：分辨解析路徑和請求路徑

DNS 不是 WireGuard 加密交握本身的欄位，而是常見設定工具用來指定解析器的設定。Shadowrocket 的實際解析行為還會受到目前 Config 與相關 DNS 設定影響。因此，服務商設定中的 DNS 位址與 App 內現有的解析設定都要一起核對，不能只檢查其中一處。

如果 Endpoint 使用主機名稱，建立隧道前就必須先解析該主機名稱。若唯一可用的解析器也只能透過尚未建立的隧道連線，就可能形成依賴循環。此時應向服務商確認可用的入口解析方式，不要任意將 DNS 改成無法確認是否可連線的位址。

• 先檢查入口解析：Endpoint 使用網域名稱時，確認目前網路能否解析；位址變更後也應重新核對解析結果。
• 再檢查服務解析：隧道建立後，確認目標網域的 DNS 查詢能取得有效回應，不能只測試數字 IP。
• 分清兩層規則：AllowedIPs 屬於 WireGuard 對等端設定；DOMAIN-SUFFIX、IP-CIDR 與 FINAL 則是 Shadowrocket 的請求分流規則。
• 確認實際出口：Global Routing 使用 Config 時，請求是否經由選取的 WireGuard 項目傳送，取決於規則與策略的指向。請檢查目前啟用的 Config，不要只修改未啟用的檔案。

6. 如何選擇 MTU：優先保留原值，逐項對照測試

MTU 表示介面可承載的最大 IP 封包大小，單位為位元組。WireGuard 會在原始封包外加上傳輸封裝，因此隧道 MTU 通常小於底層鏈路 MTU。常見設定值有 1420，但並非所有網路都適用；底層鏈路、額外封裝與路徑限制都可能影響合適的數值。

常見的排查線索包括：小型請求可以完成，但較大的回應持續停滯；或切換網路後，同一份設定在大量傳輸時出現異常。這些現象可能與路徑 MTU 探測或分片有關，也可能是封包遺失或壅塞所致。請先確認金鑰、Endpoint 與 DNS，再透過只調整 MTU 的對照測試縮小範圍。

MTU 較小不代表速度更快。它或許能減少某些路徑上的大型封包問題，但也會增加傳送相同資料量所需的封包數與封裝負擔。有效的結論應來自相同網路、相同項目與相同目標下的前後比較，而不是只比較延遲測試數字。

7. 連線失敗時的分層檢查順序

先分清「系統 VPN 已啟動」、「遠端通訊可用」與「目標請求可完成」這三種狀態。WireGuard 在沒有業務流量時可能保持靜默，不能只因短時間沒有資料就判斷已斷線。反覆關閉再開啟連線，也不會自動修正錯誤的 PublicKey 或連接埠。

若裝置頻繁在 Wi-Fi 與行動網路之間切換，請分別記錄兩種網路的測試結果。選用的 PersistentKeepalive 可定期傳送保活封包，常見範例為 25 秒；但只有在服務商要求，或確實需要維持 NAT 對應，且目前設定方式支援時才應設定。它無法修正錯誤金鑰，也不是速度調整器。

向服務商回報時，請記錄網路類型、Endpoint 連接埠、發生問題的請求類型、是否只有大型內容傳輸失敗，以及調整 MTU 前後的差異。分享設定截圖或記錄檔前，請遮蔽 PrivateKey、PresharedKey、訂閱權杖及其他身分資訊。提供這些可重現的條件，比只說「無法連線」更有助於釐清問題。

• 確認參數來自同一份用戶端設定，不是拼湊不同裝置的金鑰與位址。
• 確認每次測試使用相同的已選取項目，並記錄 Global Routing 目前的模式。
• 還原沒有改善問題的修改，避免疊加多個變數後難以判斷原因。