當你問開發者什麼是 WireGuard，幾乎一定會聽到：「它是一個 VPN。」這說法雖然正確，但只是答案的一半，而且是較不有趣的那一半。

真正有趣的工程設計在於這個協議本身。事實上，你可以將它當作一個函式庫使用——作為任何透過 UDP 傳輸資料的應用程式的即插即用加密層，而完全不需要運行 VPN。我們剛剛開源了一個 .NET 函式庫，正是做這件事的。

在介紹這個函式庫的功能之前，值得誠實說明為什麼我們需要更好的選擇。標準答案是「我需要加密傳輸」時會用 TLS over TCP，這對許多問題來說運作良好。但 TCP 有結構性的成本，當涉及延遲、移動性或丟包鏈路時，這些成本會變成用戶明顯感受到的問題。特別有三點經常在客服支援中出現。

TCP 保證有序傳送。當單一封包在傳輸中遺失時，後續所有封包都必須排隊等待遺失封包重傳——即使這些後來的封包已經抵達。對於遙測串流、遊戲狀態更新或感測器讀取，你幾乎不會在意順序，你只想要最新的數值。TCP 卻給你嚴格順序的陳舊資料。這種現象很常見：串流偶爾短暫「卡住」然後追趕進度，音訊或視訊抖動，或是延遲突然飆升，應用程式因等待封包而「掛起」。這都是因為單一封包讓整個管線暫停。底層網路很快恢復，卻因 TCP 的順序保證而讓問題顯現。

TCP 連線綁定在四元組：來源 IP、來源埠、目的 IP、目的埠。當行動裝置從 Wi-Fi 轉到行動網路時，IP 地址改變，所有開啟的 TCP 連線都會被拆除，TLS 會話也隨之中斷。應用程式必須承擔重新連線、重新協商 TLS 以及重建應用層狀態的成本。

對於會移動的裝置——手機、車輛、現場設備——這不是邊緣案例，而是常態。RST 封包到達，錯誤向上傳播，某處開始重試循環。如果你曾經好奇為什麼行動應用在切換網路後有時會多花幾秒恢復，這通常就是原因。

TCP 的擁塞控制將封包遺失視為網路擁塞的訊號，並相應減少傳送速率。在真正丟包的鏈路（如行動物聯網、衛星上行、工業無線電）上，這會形成有害的反饋迴路：鏈路因干擾丟包，堆疊減速，吞吐量崩潰，儘管唯一問題只是瞬間的噪音爆發。

物聯網儀表板另一端的使用者看到的是陳舊的讀數——不是因為裝置停止傳送，而是擁塞控制因干擾而節流了傳輸。

這些不是罕見的失效模式，而是遊戲、語音、視訊會議、物聯網監控以及任何在行動基礎設施上運行的應用中，重要且常見的抱怨來源。曾在這些領域出貨的開發者立刻能認出這三點。

傳統對「我需要對 UDP 流量加密」的回應是「放到 VPN 裡」。這確實可行，但操作負擔重。VPN 是整個網路抽象——有自己的路由、地址空間和操作面。它把兩個不同的問題綁在一起：封包路由與加密。大多數使用情境只需要後者。

DTLS（TLS-over-UDP）存在且是合理選項，但繼承了 TLS 的複雜性：憑證鏈、PKI 基礎設施、密碼套件協商和多輪握手。這對只有 256 KB RAM 的嵌入式裝置，或只想加密資料通道而不想建立憑證機構的團隊來說，是一個沉重的操作負擔。

WireGuard 協議是根本不同的設計點。它是無狀態的——無需事先建立連線，無需追蹤會話，也無需憑證機構。兩把金鑰、一個簡潔握手，你就能加密。且與 TLS 不同，WireGuard 的密碼學選擇是固定的：Noise_IKpsk2 用於密鑰交換，ChaCha20-Poly1305 用於認證加密。沒有配置錯誤的空間。

wg-client 函式庫與 .NET 內建的 UdpClient API 相容。傳送/接收模式相同，對普通 UDP 傳送迴圈加入加密只需小幅修改：

函式庫處理 WireGuard 握手、密鑰輪替和訊息封裝。呼叫端程式碼不變。封包格式是標準 WireGuard，因此相容任何符合規範的後端——Linux wg 介面、Proxylity WireGuard Listener 或其他實作。

實作約 800 行 C#，足夠一次閱讀並進行審核。唯一外部依賴是 NSec，一個管理式 NuGet 套件，提供 .NET 對 libsodium 的包裝。Noise 握手和 ChaCha20-Poly1305 傳輸基於此實作，無其他第三方程式碼。

WireGuard 設計文件中常提「無狀態」，對應用開發者來說值得精確理解其意義。

在 TLS 中，會話有生命週期：握手建立共享狀態——會話金鑰、序列號、密碼上下文——必須維持整個連線期間。若連線中斷（網路變更、伺服器重啟或逾時），狀態消失，雙方必須重新協商才能恢復加密通訊。

WireGuard 處理方式不同。會話存在且金鑰輪替，但若封包停止流動且會話過期，下一個外發訊息會靜默觸發新握手。無需錯誤處理、無需重連協調、無需撰寫應用層重試邏輯。函式庫負責傳送資料，會話需要更新時自動完成。從應用角度看，會話從未消失。

這對於傳輸間隔有睡眠、在網路間移動或連線不穩的裝置尤其重要。WireGuard 在 VPN 場景中展現的韌性，同樣適用於此，且不論負載是隧道 IP 還是其他。

WireGuard VPN 使用該協議隧道 IP 封包。內部負載是 IP 數據報——一般網際網路意義上的封包。這是 VPN 的使用案例。

WireGuard 協議僅加密位元組陣列，不檢查、驗證或解讀內容。內部負載可以是隧道 IP，也可以是 UTF-8 文字、二進位感測讀數、專有控制協議、syslog、NTP 或其他。當你將協議與 VPN 應用分離後，任意負載不再奇怪，而是理所當然的使用方式。

這意味著你可以用 WireGuard 保護資料通道，就像使用 TLS 一樣——完全不需 VPN 機制。HTTP over WireGuard 可行，我們的 syslog-over-WireGuard 範例也可行。任何目前用 TLS 保護的協議，原則上都能用 WireGuard 取代，且操作模式更簡單，無需管理 PKI。

Proxylity UDP Gateway 自產品早期即支援 WireGuard Listener。Gateway 終止 WireGuard 隧道，解封包並將內部負載路由到 Lambda、SQS、Kinesis、CloudWatch Logs 等目的地。今年稍早我們新增了 Decapsulated Delivery，將解封包步驟移至 Gateway，讓目的地收到乾淨的內部負載，無需撰寫程式碼。

wg-client 函式庫是這個架構的自然客戶端補充。物聯網裝置、工作程序或邊緣節點使用 WireGuardClient 可直接向 Proxylity WireGuard Listener 傳送加密數據報，負載在目的地乾淨解密，準備處理。無需 VPN 基礎設施，無需覆蓋網路，無需獨立金鑰管理服務。

這組合涵蓋了一個真正常見但意外缺乏服務的使用案例：嵌入式或邊緣軟體需要傳輸加密且可用 UDP，但 TLS 對環境太重，完整 VPN 基礎設施太複雜，DTLS 又太難在操作壓力下正確配置。

該函式庫以 MIT 授權開源，位於 github.com/proxylity/wg-client 。可透過 NuGet 安裝：dotnet add package Proxylity.WireGuardClient 。約 800 行程式碼，仍有少量工作待完成。歡迎貢獻、回報問題與提供回饋。

Proxylity UDP Gateway 原生接受 WireGuard 連線。搭配 wg-client 可實現端對端加密 UDP——無 VPN、無 PKI、無操作負擔。