Shadowrocket WireGuard 設定教學：Private Key、Public Key、Address、DNS 與 MTU 填寫方式

一、填寫前先確認設定來源與欄位層級

Shadowrocket（小火箭）的 WireGuard 類型需要有效的對端設定，不能只靠伺服器位址建立連線。使用前須已有自己的服務商與設定，或已管理相應的 WireGuard 對端。本教學不提供、不販售也不推薦節點或訂閱。若手邊只有一般訂閱連結，請先確認其中是否確實包含 WireGuard 類型的項目，不要將訂閱 URL 填入伺服器位址欄。

常見的 WireGuard 設定分為 [Interface] 與 [Peer] 兩部分。前者描述本機身分與隧道介面，後者描述遠端身分及連線目標。Shadowrocket 會將這些資訊對應至伺服器編輯表單；欄位排列與顯示名稱請以目前介面為準。下文保留設定中的原始鍵名，方便逐項核對。

收到設定後，請先安全備份，再進行輸入。不要在公開求助內容中附上 Private Key、Preshared Key 或完整訂閱連結；這些資訊可能直接關係到連線權限。若只需確認格式，可說明欄位長度、是否包含空格及所在設定區段，無須透露密鑰內容。

二、Private Key 與 Public Key：本機私鑰和對端公鑰不可互換

[Interface] 中的 PrivateKey 是用戶端私鑰，必須與對端登記的用戶端公鑰相符。[Peer] 中的 PublicKey 則是伺服器公鑰，用來識別遠端。兩者看起來都像一串 Base64 文字，但用途不同，不能只憑外觀判斷，也不能將用戶端自己的公鑰填入對端 Public Key 欄位。

標準 WireGuard 密鑰經 Base64 編碼後通常為 44 個字元，末尾可能有 =。長度看起來正確，只表示格式可能符合要求，不代表密鑰彼此相符。貼上時請移除前後空格、引號與換行，但要保留密鑰本身的 +、/、= 等字元。

• 若重新產生用戶端私鑰，對端也必須登記由新私鑰產生的用戶端公鑰；只修改本機設定通常無法恢復連線。
• 不要從伺服器端的 [Interface] 複製 PrivateKey 到用戶端。你需要的是專門指派給該用戶端的設定。
• 若原始設定沒有 PresharedKey，請保持未設定，不要用 PrivateKey 或 PublicKey 代填。
• 不要讓兩台裝置共用同一份用戶端身分；對端可能將回應封包送往最近一次活動的端點，造成連線輪流中斷。

三、Address、Endpoint 與連接埠：分清隧道內外位址

Address 是隧道內部位址，Endpoint 則是連線至遠端時使用的外部入口，兩者不可互換。舉例來說，設定分配給用戶端 10.66.0.2/32，並指定 192.0.2.10:51820 為 Endpoint：前者代表本機在隧道中的身分，後者則指出加密 UDP 封包要送往何處。此處的 Endpoint 使用文件專用位址，僅供說明格式，無法實際連線。

/32 是 IPv4 前綴長度，不是連接埠；IPv6 單一位址設定也可能使用 /128。若介面要求單獨填寫 IPv4 位址，請勿連同連接埠或整個 Endpoint 一起貼上。只有在原始設定明確分配 IPv6 位址且網路支援時才填寫，不要自行補上位址。

在 WireGuard 中，AllowedIPs 用來描述 Peer 可承載的目的範圍及來源驗證範圍，不是另一種寫法的用戶端 Address。即使原始設定包含 0.0.0.0/0 和 ::/0，Shadowrocket 是否會選用該伺服器處理特定連線，仍須配合 Global Routing 與 Config 規則判斷，不能只憑這兩項就認定所有 App 都會使用它。

四、在 Home 新增 WireGuard 並進行基本測試

首次設定時，請先只測試單一伺服器，不要同時修改路由、DNS 與 MTU。如此一來，若發生問題，就能確認是哪個變更造成結果不同。以下入口用於新增 WireGuard 伺服器；Config 用於設定檔與規則，兩者用途不同，請勿混淆。

1. 選擇類型

   前往 Home → + → Type → WireGuard。返回編輯頁後，確認類型仍為 WireGuard，再繼續填寫。

2. 填寫連線資訊

   將 Endpoint 的主機與連接埠填入相應欄位。例如，文件中的 192.0.2.10:51820 應拆開填入位址與連接埠；實際操作時請使用自己的有效參數。

3. 核對密鑰

   填入用戶端 Private Key 與對端 Public Key，再依原始設定補上本機隧道位址；只有在設定明確提供時才填入 Preshared Key。

4. 儲存並選取

   儲存伺服器後，返回 Home 選取該項目。首次連線時，請依系統提示允許新增 VPN 設定；授權只代表允許建立系統 VPN 設定，並不表示遠端已可連線。

5. 測試連線

   在 Home → Global Routing 暫時選擇 Proxy，啟動連線並存取自己有權使用的測試目標。測試完成後，請還原原本的 Global Routing 設定，再檢查日常分流情況。

Global Routing 中的 Proxy 可減少規則變因，但仍無法繞過伺服器本身的存取權限與網路限制。Direct 不適合用來確認 WireGuard 是否承載流量；使用 Config 時，則須確認測試目標確實符合會使用該伺服器的策略。系統顯示 VPN 已連線，只代表本機隧道狀態正常，不等於已完成遠端密鑰交握或成功存取服務。

五、DNS 與 MTU 怎麼設定：先沿用，再分別調整

DNS 負責網域名稱解析，無法修正密鑰錯誤。傳統 WireGuard 設定中的 DNS 通常由使用該設定的 App 解讀，並非協定交握欄位。將 WireGuard 參數手動輸入 Shadowrocket 時，不要假設原始檔案中的 DNS 會自動成為目前設定使用的解析器；也請檢查 Settings → DNS 以及目前 Config 中的 DNS 設定，並以實際啟用的設定為準。

• 若 Endpoint 使用網域名稱，建立連線前就必須能解析該名稱。若唯一可用的解析器位於尚未建立的隧道內，可能會形成解析依賴，請先核對原始設定的解析方式。
• 若以 IP 存取某個受控目標正常，但使用網域名稱時失敗，請優先檢查 DNS。不過，透過 HTTPS 直接存取 IP 可能因憑證或虛擬主機設定而失敗，不能單憑這個現象下結論。
• 若內部網域必須透過服務方指定的 DNS 解析，照搬其他網路使用的解析器，可能造成隧道已連線卻無法存取內部資源。

MTU 是介面允許傳輸的最大封包大小。WireGuard 會增加外層封裝的額外負擔，因此底層路徑可承載的大小會限制隧道內封包。設定過大時，可能出現小型請求正常、大型頁面或上傳停滯的狀況；設定過小則會增加分段與處理負擔。丟包或伺服器負載也可能造成類似現象，不能只憑「載入緩慢」就判定是 MTU 問題。

每次測試都記錄網路類型、原始 MTU、調整值及相同操作的結果。若降低後沒有持續改善，請還原原值，再檢查 UDP 是否可連線、是否丟包及伺服器端路由。不要同時更換 DNS、修改連接埠又降低 MTU，否則即使恢復存取，也無法判斷真正原因。

六、依故障狀況排查：逐層檢查密鑰與路由

排查時應先確認連線的基本條件，再檢查服務存取。確認連接埠可連線、密鑰相符、位址正確，且對端轉送與回程路徑正常後，檢查 DNS 和分流才有意義。若伺服器由自己管理，也可查看對端最近交握時間及收發計數；若由既有服務方管理，只需提供去識別化後的時間與狀況。

若在 Proxy 下測試正常，還原 Config 後卻失敗，應檢查實際符合的規則與策略，而不是重新產生 WireGuard 密鑰。例如，DOMAIN-SUFFIX,example.com,PROXY 只會符合 example.com 及其子網域；IP-CIDR 依 IP 網段符合，GEOIP 依 IP 地理資料庫符合，FINAL 則用於未符合前面規則的連線。規則會由上往下處理；目標使用哪項策略，須依目前設定確認。