· 協定解說 · 約 10 分鐘

Shadowrocket WireGuard 設定教學：Private Key、Peer Public Key、Address 與 MTU 說明

整理服務商提供的 WireGuard 設定，說明 Shadowrocket 中 Private Key、Peer Public Key、Preshared Key、Address、DNS 與 MTU 的用途，以及常見設定錯誤。

本文重點

本文適合已有 WireGuard 服務與設定，準備在 Shadowrocket 中核對參數的使用者。先區分本機與遠端身分，再確認 Address、Endpoint、DNS 和 MTU，最後分別測試連線、規則與網頁存取。本文著重說明各項參數由誰提供、填錯會影響哪個環節，不提供可直接連線的服務設定。

先分清 Interface 與 Peer

Shadowrocket（小火箭）中的 WireGuard 參數應取自使用者既有服務的完整設定。標準 WireGuard 文字設定通常以 [Interface] 描述本機介面，以 [Peer] 描述遠端。手動填寫時，這兩部分必須對應同一個 WireGuard 項目；不可混用另一台裝置的私鑰、本機目前的 Address，以及不同伺服器的公鑰。

WireGuard 使用 UDP 傳輸隧道通訊。伺服器位址和連接埠決定封包要送往哪裡，金鑰則用來驗證通訊雙方。因此，「位址可解析」、「連接埠填寫正確」和「身分驗證成功」是不同的檢查項目。

2 個部分
標準設定分為 Interface 與 Peer
32 位元組
WireGuard 原始私鑰與公鑰各自的長度
UDP
Endpoint 使用的傳輸協定

Private Key、Public Key 與 Preshared Key

[Interface] 中的 PrivateKey 是本機私鑰，對應介面中的 Private Key。由此可推導出本機公鑰，遠端必須登錄這個本機公鑰。本機私鑰不是登入密碼，也不是遠端公鑰；更換私鑰後，若遠端未同步更新對應資料，原有設定便無法繼續正常通訊。

設定欄位欄位用途常見錯誤
Interface.PrivateKey本機持有的私鑰，對應 Private Key。誤填伺服器公鑰，或複製時混入空格、引號。
Peer.PublicKey遠端公鑰，對應 Public Key。誤填本機公鑰，導致遠端身分不符。
Peer.PresharedKey雙方另行約定的共享金鑰，對應 Preshared Key。只有一端設定，或兩端內容不一致。

Public Key 應填對端公鑰，不是「由本機 Private Key 推導出的公鑰」。若服務設定同時列出用戶端公鑰與伺服器公鑰，請先確認欄位所屬部分：[Peer] 底下的 PublicKey 才是此處要核對的遠端身分。

Preshared Key 是選填參數，但「選填」不代表可以單方面刪除。原始設定若有此項，就應照原樣保留；若沒有，請勿自行產生後填入。含有 +、/、= 的 Base64 文字必須完整複製，不要進行 URL 編碼，也不要把結尾的 = 當成多餘標點刪除。

Address 與 Endpoint 屬於不同層級

Address 是分配給本機、位於隧道內的位址，通常會附上 CIDR 前綴長度。例如 10.66.0.2/32 表示一個 IPv4 介面位址；雙堆疊設定也可能提供類似 fd00:66::2/128 的 IPv6 位址。這些僅為格式示例，不能取代服務端實際分配的值。Address 不是遠端伺服器位址，也不是裝置目前連線的 Wi-Fi 區域網路位址。

標準設定也可能包含 AllowedIPs。此欄位描述與 WireGuard 對端關聯的位址範圍，並參與 WireGuard 的路由與來源位址檢查；它不是 Address，也不能直接視為 Shadowrocket 的全域分流規則。編輯頁是否提供對應選項，請以實際顯示的欄位為準。看到 0.0.0.0/0，不代表 Shadowrocket 的所有請求一定會經過該項目。

DNS 與 MTU：分開檢查名稱解析和封包大小

DNS 用來將網域名稱解析為位址，無法修復金鑰錯誤。標準 WireGuard 檔案中的 DNS 是用戶端工具採用的設定慣例，不是 WireGuard 交握封包中的驗證參數。在 Shadowrocket 中，也要一併確認目前生效的 Config 與 Settings DNS 設定；不能只因原始檔案寫有 DNS 位址，就認定執行時一定會使用。

參數檢查重點可觀察到的狀況
DNS解析器是否可連線、是否只能透過隧道存取，以及 Endpoint 網域名稱能否先完成解析。網域解析發生錯誤，但已知目標的連線測試可能仍有回應。
MTU先沿用原始設定；檢查隧道封裝後的封包是否超出實際路徑可承受的大小。小型請求成功，但大型回應或上傳停滯，部分網頁長時間載入。
PersistentKeepalive原始設定是否要求定期傳送保活封包，以及目前網路是否有 NAT 對應逾時問題。閒置一段時間後首次存取失敗，重新連線後短暫恢復。

MTU 的單位是位元組。1420 是常見參考值，並非適用於所有網路的固定最佳值。若原始設定已指定 MTU，請先依原值測試；只有反覆出現「大型請求停滯、小型請求正常」等狀況時，才一次只調整此項。例如將 1420 暫時降至 1380，重新測試同一頁面或同一項上傳，並記錄結果。若沒有改善，請恢復原值，不要同時修改 DNS 與規則。

原始設定中的 PersistentKeepalive = 25 表示保活間隔為 25 秒，不是逾時時間或重試次數。是否需要保活取決於網路與服務設定；保活無法取代正確的金鑰、Endpoint 或可用的 UDP 路徑。

在 Home 填寫並逐層驗證

Home 用來管理連線項目，Config 用來管理規則設定，Settings 用來管理 App 設定。填寫 WireGuard 參數與匯入規則設定是兩件不同的事：前者提供連線方式，後者決定哪些請求使用該連線。部分欄位的展開方式可能隨目前介面而異；對應標準設定欄位時，請依欄位用途判斷，不要依清單位置照順序貼上。

  1. 準備原始設定

    保留既有服務提供的原始設定，確認 Interface 與 Peer 是否屬於同一台裝置。先記下原本的 Global Routing 狀態，方便測試後還原。

  2. 選擇類型

    前往 Home → 右上角「+」→ Type → WireGuard。若要修改現有項目，請從 Home 開啟該項目的編輯頁，不必重複建立內容相近的項目。

  3. 對應參數

    將 Endpoint 對應至伺服器位址與 Port，將 Interface.PrivateKey 對應至 Private Key，將 Peer.PublicKey 對應至 Public Key。依原始設定和編輯頁實際欄位，逐項核對 Address、Preshared Key 與 MTU 後再儲存。

  4. 排除規則干擾

    回到 Home，選取已儲存的 WireGuard 項目，暫時將 Global Routing 設為 Proxy。開啟連線後，測試一個已知可存取的 HTTPS 網頁。這樣能先減少 Config 規則造成的干擾，但仍須檢查 DNS 與其他生效中的設定。

  5. 還原日常設定

    確認基本存取正常後，還原原本的 Global Routing，再測試同一個目標。若已啟用 Settings → On Demand，排查期間可暫時關閉自動觸發，避免手動中斷後又自動連線；測試完成後再還原原設定。

連線開關已開啟，只能表示本機連線流程已啟動，無法單獨證明遠端已完成 WireGuard 交握。延遲測試出現數值，也不能取代網頁存取驗證：測試目標、測試方式與實際請求路徑可能不同。請同時查看網域解析結果、目標存取結果及可用的連線記錄。

Global Routing 如何影響測試結果

以下僅比較 Shadowrocket 內三種分流模式，方便說明測試結果差異；Global Routing 也可能顯示 Scene，本文不將它作為隔離測試的基準。建議使用 Config，意指日常依已核對的規則處理流量，不代表任何設定檔都能直接套用。

Config

建議

依目前 Config 中的規則與策略處理請求。符合條件的第一條規則會先決定結果，因此 WireGuard 項目可用，不代表每個網域都會經由它連線。

適用情況：基本連線驗證完成後，依日常規則分流

Proxy

以代理模式處理流量，可暫時降低一般分流規則的影響。測試前請確認目前選取的連線確實是要檢查的 WireGuard 項目。

適用情況：首次填寫參數後，短時間隔離測試

Direct

以直接連線方式存取目標。此時網頁能開啟，不代表 WireGuard 參數正確；請與 Proxy 模式下存取同一目標的結果分開記錄。

適用情況：對照目前網路的直接存取狀況

返回 Config 後，若只有部分目標無法存取，請檢查規則順序與對應策略的實際選擇。DOMAIN-SUFFIX 依網域後綴比對，IP-CIDR 依 IP 網段比對，GEOIP 依 IP 地理資料庫比對，FINAL 則為未符合前述規則的請求指定最終動作。若問題只在 Config 模式下出現，不要反覆更換 Private Key 來處理規則比對問題。

常見設定問題與排查順序

填入 Private Key 後，為什麼還是連不上？

回到 Home，開啟該項目的編輯頁，依序核對 Type、Endpoint 位址、Port、Private Key 與對端 Public Key。接著確認遠端登錄的是由該私鑰推導出的本機公鑰；若設定中有 Preshared Key，兩端也必須一致。只檢查私鑰字元數並不足夠。

可以直接把伺服器 IP 填入 Address 嗎？

不能這樣替換。Address 是服務端分配、位於隧道內的本機位址；伺服器的公網位址則屬於 Endpoint。請依原始設定中的 Interface.Address 填回，並保留前綴長度；若尚未取得 Address，請先向既有服務的管理方確認。

Wi-Fi 正常，切換到行動網路後卻連不上，怎麼辦？

先在兩種網路下使用同一個項目、相同的 Global Routing 與相同測試目標，排除測試條件不同的影響。再確認 Endpoint 的 IPv4／IPv6 是否可連線，以及 UDP 路徑是否可用。若問題只在閒置一段時間後出現，請檢查原始設定中的 PersistentKeepalive；若只有大型請求失敗，再單獨測試 MTU。

訂閱更新後，手動修改的內容為什麼不見了？

訂閱管理的項目可能在更新時重新寫入參數。先確認編輯的是手動項目還是由訂閱產生的項目，記下被覆寫的欄位，並核對訂閱來源提供的設定。若需長期修正，應與既有服務提供的原始設定一致，不要每次更新後都盲目重複修改。

調低 MTU 就能解決所有載入問題嗎？

不能。先確認在 Proxy 模式下能否存取目標，再檢查名稱解析是否成功。只有反覆出現與大型封包相關的狀況，才適合繼續測試 MTU。金鑰不符、連接埠錯誤或 DNS 無法連線，都不會因降低 MTU 自動修復。

排查完成後，記錄實際使用的網路、Global Routing、測試目標、修改項目與結果。向既有服務的管理方回報時，可描述「同一目標在 Proxy 下失敗、Direct 下正常」或「小型請求成功、上傳停滯」等狀況，但請遮蔽金鑰與個人設定。明確的對照紀錄比公開整份設定更有助於找出問題。

App Store 正版核對