WireGuard 密鑰不相符，指至少一條 peer 記錄沒有保存由對端目前私鑰派生的公鑰，或雙方可選 PSK 並不相同。只有沉默不能判斷哪方錯誤。你要從可信本機觀察建立雙向公鑰映射，比較預期的 peer 記錄，找出過時關係後才輪換或更換資料。

完整 VPN 指南涵蓋更廣的工作階段；本文只處理 WireGuard 靜態身份與可選 PSK 一致性。

關鍵要點

每端保留自己的私鑰，並把對端公鑰設定為 peer 身份。［1］

只比較公鑰或受控指紋，絕不交換私鑰來「核對」。

端點錯誤、UDP 阻擋、路由或 AllowedIPs 問題均可貌似密鑰故障。

目前握手證明該 peer 在當時使用的靜態密鑰映射相符。

PSK 不符屬於另一項秘密狀態核對，不能顯示原值作目測比較。

WireGuard 密鑰如何映射？

每個 WireGuard 介面都有靜態私鑰，其派生公鑰作為介面身份。peer 設定保存遠端介面公鑰。握手時，每端使用自己的私鑰和已設定的遠端公鑰；協議不會傳送可協商用戶名稱來自動修正錯誤映射。［1］

白皮書把 peer 與公鑰及允許 IP 位址關聯。［2］同一介面因此同時有本機身份、每個遠端的預期身份，以及分配予各 peer 的位址前綴。公鑰配對正確時，錯誤位址映射仍可造成沒有數據。

可選 PSK 會加強公鑰密碼層。wg 手冊定義私鑰、peer 公鑰、PSK、端點、允許 IP、保活與運行狀態欄位。［3］雙方 PSK 必須相同，但它屬於秘密；安全流程只能比較受控來源或本機計算的受控指紋，不能貼入聊天、支援個案、螢幕截圖或指令輸出。

A 端資料	預期關係	B 端資料
A 目前私鑰	派生	A 實測公鑰
A 為 B 設定的 peer 公鑰	必須相等	B 實測公鑰
B 為 A 設定的 peer 公鑰	必須相等	A 實測公鑰
A 為 B 設定的 PSK	必須來自同一秘密代次	B 為 A 設定的 PSK
A 為 B 設定的 `AllowedIPs`	把目的映射至 B	不是密鑰比較

甚麼證據支持 WireGuard 密鑰不相符？

一端輪換密鑰後，新匯入設定從未握手，是有力背景；peer 公鑰與預期遠端在本機派生的公鑰不相等，則是直接證據。受控換鑰後握手立即停止，也可收窄變更時段。

反覆發起而沒有回應並非密鑰專屬症狀。UDP 可被阻擋，端點可能錯誤，NAT 狀態可逾時，服務可能沒有監聽，或 peer 已離線。伺服器回應與握手失敗指南說明為何可達性與驗證要分開。

確切 peer 有新鮮握手時，它在當時使用的靜態密鑰與可選 PSK 已一致。後續沒有數據，應先使用握手後沒有數據的計數流程，而不是猜測換鑰。

七步密鑰核對

步驟 1：讀取密鑰前標記兩個端點

為端點使用清晰標籤，例如 laptop-2026 及 gateway-east，記錄管理員、預期介面、peer 設定、端點與客戶端位址，但不要複製完整設定。很多「不符」其實是在比較舊裝置記錄與同名新裝置。

固定失敗嘗試的時間，以及兩端預期 peer 的最近握手值。如多個 peer 共用同一閘道，應按公鑰及獲分配的位址前綴識別記錄，而不是按清單位置。盤點期間不要重新命名、刪除或重新產生任何東西。密鑰一旦改變，便會毀掉判斷「設定分發、運行中的程序還是 peer 記錄過時」所需的證據。

步驟 2：在本機派生兩端公開身份

在 A 端使用可信 WireGuard 工具，派生或顯示目前活動介面私鑰對應的公鑰，只把公開結果寫入工作表；再在 B 端本機重複。

不要把私鑰複製到暫存資料夾、shell 歷史或網上解碼器。無法安全顯示活動公鑰時，使用受支援登記介面記錄公開身份。

確認運行狀態，不要假設磁碟檔案已載入。設定檔改過後，服務仍可能運行舊密鑰；介面也可能由另一真源重建。把活動公鑰與預期記錄比較，全程不要輸出私鑰。

到此停止：任何一端無法建立可信的本機公開身份時，請獲授權管理員提供公鑰或指紋證明，不可索取私鑰。

步驟 3：雙向比較映射

讀取 A 端為 B 保存的 peer 公鑰，與 B 的本機公開身份比較；再讀取 B 為 A 保存的公鑰，與 A 的身份比較。這是兩條獨立關係，一條可以是最新，另一條仍然過時。

比較	結果	解釋
A 預期 B = B 實測	相同	A 的遠端身份記錄一致
A 預期 B ≠ B 實測	不同	A 的 peer 記錄或 B 的預期身份過時
B 預期 A = A 實測	相同	B 的遠端身份記錄一致
B 預期 A ≠ A 實測	不同	B 的 peer 記錄或 A 的預期身份過時
兩邊相同	未顯示靜態公鑰問題	檢查 PSK、端點、路徑與選路

不相符只指出一條不一致的關係，不能自動判定責任人或機器。應在登記真源確認哪一個公開身份獲授權：可能是裝置合法換鑰而伺服器記錄遺漏更新，也可能是本機有未獲授權替換，成為過時的一方。條件容許時，在受保護的管理工作階段中逐字比較完整公鑰。如支援個案或口頭核對無法安全傳遞完整公鑰，便在兩端以相同、有文件記載的演算法及編碼計算密碼學指紋，並標明所用演算法；只看一個縮短的前綴，可能出現碰撞或抄錯。

步驟 4：不公開 PSK 地處理它

先確認兩條 peer 記錄是否都應使用 PSK。一端「存在」、另一端「缺失」，本身已是不一致。如雙方都有，確認它們來自同一次受控的產生和分發。

政策容許在本機核實時，可以就地計算帶密鑰的或密碼學指紋，並只透過獲准渠道比較得出的受控識別碼。不要用快速而不加鹽的雜湊，作為公開低熵秘密的一般手段。最穩妥的營運方式往往是：透過秘密管理系統，把一個新產生的 PSK 重新部署到兩條預期記錄，全程不顯示它。

切勿把 PSK 放在會留在歷史記錄、程序清單或支援訊息中的指令行。wg 狀態顯示已設定預共享密鑰，並不證明兩端的秘密值相同。

步驟 5：輪換前排除相似故障

確認端點位址及 UDP 連接埠通往預期介面。再完美的密鑰映射，也無法回應送往舊主機的流量。以窄範圍的防火牆及封包計數確認握手發起是否到達、回應是否離開。

把預期 peer 與路由、AllowedIPs 對照。AllowedIPs 指南解釋前綴如何綁定 peer。錯誤前綴可令有效握手後沒有數據，重複或放錯的 peer 記錄亦會令你查看錯誤計數。

確認雙方運行的是預期的設定代次，重新啟動、容器、網絡命名空間或管理代理沒有載入另一個檔案。看不到遠端證據時，不能由「沒有回應」推論密鑰不符。

步驟 6：只修正已證明過時的關係

一旦登記的真源確認了獲授權的公開身份，便透過受支援的設定渠道，更新不一致的遠端 peer 記錄。不要走複製遠端私鑰的捷徑。按本地政策，把舊的公開記錄和變更單號保留足夠長的時間，以便還原和審計。

如果本機私鑰本身在未經授權下被取代，或其保密性成疑，應視為保安事故處理。在獲准環境中產生新的本機密鑰對，只把新公鑰分發給每個獲授權的 peer，撤銷舊身份，並核實沒有遺留的過時 peer。這比修正一個筆誤的範圍更大，可能需要與管理員協調。

對於 PSK 不一致，透過獲准的秘密渠道向雙方部署同一個新秘密。除非擁有人明確接受這項保安改動且協議政策容許，否則不要為了令隧道連通而暫時移除 PSK。

步驟 7：分開驗證身份與數據路徑

發起一次獲准的連線嘗試，確認兩端預期 peer 的最近握手時間都已更新。圍繞一個小型數字位址探測記錄新鮮的 TX/RX 增量。握手證明修復後的身份映射成立；計數變化和 App 測試則分別證明後續階段。

核實端點、分配的前綴和路由仍與標示的裝置相符。修復密鑰不應悄悄授權更寬的 AllowedIPs 或另一個客戶端位址。按保留政策移除臨時診斷存取和已遮蓋的工作表。

如果公鑰兩端和 PSK 來源都相符，卻仍沒有握手，便停止重新產生密鑰，回到端點可達性、服務狀態和防火牆證據。如果握手成功但數據不通，改按計數矩陣排查。

甚麼時候託管 VPN App 比自管密鑰更簡單？

密鑰不相符是自行運行 peer 的維護成本。如果你只需要為自己的裝置提供私人連線，AethoVPN 提供了一條毋須做這類記帳的途徑：文件說明的步驟是以電郵驗證碼繼續，在 Windows、Linux 或 Android 安裝客戶端（Mac 和 iPhone 透過官網設定精靈取得設定，需 Pro 或 Premium 計劃），然後在 App 內選擇位置。這套流程不涉及匯入或核對 WireGuard 密鑰，所以你自行運行的 peer 之間出現不相符，仍要在兩端比對公鑰來解決；亦切勿把私鑰或 PSK 傳送給任何支援團隊，包括 AethoVPN 的支援團隊。可用電郵建立帳戶，比較託管方式與自行維護密鑰的分別。

總結

比較身份前，先標記確切的活動端點與 peer 記錄。
在每端本機派生或顯示公鑰，不為診斷搬移私鑰。
先比較 A 預期的 B 與 B 實測公鑰，再反方向比較。
把可選 PSK 當作獨立的秘密分發核對。
排除端點、防火牆、程式代次、路由與 AllowedIPs 相似故障。
只修正已證明過時的關係，分開驗證握手與數據。

常見問題

能否從「沒有握手」判斷哪一方錯誤？

不能。密鑰不符、端點錯誤、UDP 被阻擋、服務停止、NAT 逾時或 peer 離線都可表現為沉默，需要兩端可信觀察。

WireGuard 公鑰是否適合公開？

它不是秘密，但仍是穩定 peer 識別碼。只向預期管理員分享，不要連同完整拓撲公開。

可以直接比較雙方私鑰嗎？

不可以。每把私鑰都必須留在各自獲授權的端點或秘密管理系統；應在本機派生公鑰，再比較公鑰。

目前握手能否排除密鑰不符？

它能排除該 peer 當次握手使用的靜態身份及可選 PSK 不符，但不能證明另一 peer 或後續數據路由正確。

如何確認 PSK 相同？

確認共同秘密來源，或使用批准的就地指紋流程。「PSK 已設定」不能證明相等，原值亦不可複製到診斷資料。

WireGuard 失敗時應否重建兩端密鑰？

不應。廣泛輪換會破壞證據、擴大分發面；資料過時或洩露政策要求時才輪換。

應向支援人員提供甚麼？

提交脫敏後的端點標籤、時間、軟件版本、最近握手觀察、雙向公鑰對照或批准指紋及首個斷點；勿提交私鑰、PSK、完整設定或 dump。

免責聲明：本文只提供一般技術疑難排解資訊。只透過獲授權系統處理密鑰資料，懷疑私鑰洩露應作為安全事故處理。

來源：

WireGuard, "Protocol & Cryptography": https://www.wireguard.com/protocol/
WireGuard, "WireGuard: Next Generation Kernel Network Tunnel": https://www.wireguard.com/papers/wireguard.pdf
WireGuard Tools, "wg(8)": https://git.zx2c4.com/wireguard-tools/tree/src/man/wg.8

Sources checked 2026 年 9 月 12 日。

延伸閱讀：

WireGuard 密鑰不相符：兩端公鑰對應關係與安全診斷方法