2026 年 VPN 路由器設定：WireGuard 與 OpenVPN 效能比較
這些場景的共同點是「需要覆蓋多台裝置」或「需要長期穩定在線」，而這正是路由器端 VPN 的強項。
二、WireGuard 與 OpenVPN 的架構與設計哲學
要理解兩者的效能差距，不能只看跑分，得先知道它們在設計上做了什麼選擇。這兩個協定幾乎是光譜的兩端：一邊極簡、一邊極繁。
2-1 WireGuard：把複雜度從程式碼移到協議
WireGuard 的設計哲學可以用一句話概括：用嚴格的協議規範，換取極簡的實作。
它刻意不提供密碼套件協商。傳統 VPN 會在握手階段讓雙方「討論」要用哪種加密演算法、哪種雜湊、哪種金鑰交換，這個協商過程本身就是攻擊面和效能負擔的來源。WireGuard 直接寫死了一套現代密碼學組合：Curve25519 做金鑰交換、ChaCha20-Poly1305 做認證加密、BLAKE2s 做雜湊、HKDF 做金鑰衍生。沒有協商，就沒有降級攻擊，也沒有演算法挑選的相容性地獄。
第二個特點是它被設計成核心模組。在 Linux 上，WireGuard 直接跑在核心空間，封包的加解密不需要在使用者空間與核心空間之間來回搬移。這個差異在高吞吐量時非常關鍵，因為每一次 context switch 都代表額外的 CPU 週期與記憶體頻寬消耗。
第三個特點是它沒有「伺服器」與「用戶端」的概念，只有對等節點（peer）。每個 peer 用一組金鑰識別，路由規則直接綁定金鑰。這種設計讓設定檔變得非常短，一個典型的 peer 區塊可能只有五行。
代價是什麼？WireGuard 只支援 UDP，不支援 TCP 封裝；它沒有內建的混淆機制，封包特徵相對固定；它只能處理 IPv4 與 IPv6 單播流量，不支援多播與廣播。這些限制在大多數場景下無關緊要，但在某些受限網路環境中會成為硬傷。
2-2 OpenVPN：用彈性換取相容性
OpenVPN 走的是完全相反的路。它誕生於 2001 年，那是一個防火牆與 NAT 設備對「非標準協定」極不友善的年代，因此它最核心的設計目標就是「在任何網路環境下都能穿過去」。
為此，OpenVPN 使用 TLS 作為控制通道，資料通道則可以選擇多種加密套件。它同時支援 UDP 與 TCP，甚至可以把整條隧道包在 TCP 443 裡面，讓它看起來像一般的 HTTPS 流量。它也支援使用者名稱密碼、憑證、雙因素等多種認證方式，並能與 LDAP、RADIUS 等企業目錄服務整合。
這種彈性帶來的代價是複雜度。OpenVPN 的程式碼量是 WireGuard 的數十倍，使用者空間的實作方式讓每個封包都得經過多次系統呼叫。在早期單核心、低時脈的路由器上，這直接反映在吞吐量上：同一台機器跑 WireGuard 可能有 300 Mbps，跑 OpenVPN 卻只剩 30 Mbps 不到。
不過這個局面在近年出現變化。OpenVPN 2.6 開始引入 DCO（Data Channel Offload，資料通道卸載），把最耗資源的加解密與封包轉發搬到核心模組處理，使用者空間只負責控制通道。2.7 版本進一步擴大了 DCO 的覆蓋範圍與平台支援。在支援 DCO 的環境下，OpenVPN 的吞吐量可以拉近到 WireGuard 的七成到九成，這個差距已經遠小於多數人印象中的樣子。
2-3 架構差異如何直接反映在效能上
把架構差異對應到效能指標，大致可以得到幾個結論：
理解了這些底層差異，接下來看實測數字就比較不會被誤導。
三、2026 年實測效能比較
先說在前面：任何跑分都高度依賴硬體與設定。以下數據是基於 2026 年常見路由器平台的整理，目的在於呈現「量級差異」與「影響變數」，而不是給你一個可以拿去告廠商的絕對值。
3-1 測試環境與測試方法
要得到有意義的比較，測試環境必須控制幾個變數：兩端都跑在相同的實體鏈路上，避免 ISP 頻寬成為瓶頸；測試工具統一使用 iperf3，並且分別測試單執行緒與多執行緒；加密套件要固定，例如 OpenVPN 固定使用 AES-256-GCM，WireGuard 則固定使用預設的 ChaCha20-Poly1305；每個項目至少跑三次取中位數，避免快取與熱降頻干擾。
另外要注意的是「誰是瓶頸」。如果你用一台 x86 迷你主機當伺服器、一台 ARM 路由器當用戶端，那瓶頸幾乎一定在路由器端。反過來也一樣。測試時最好兩端都記錄 CPU 使用率，才能判斷效能是被加密運算限制，還是被網路介面限制。
3-2 吞吐量實測結果
以下整理 2026 年幾個主流平台的典型表現。數值單位為 Mbps，測試條件為單一 TCP 串流、無其他負載。
路由器平台
WireGuard
OpenVPN（使用者空間）
OpenVPN（啟用 DCO）
入門 ARM 雙核 1.2 GHz（256 MB RAM）
約 120–180
約 25–40
多數不支援或極不穩定
中階 ARM 四核 1.5 GHz（512 MB RAM）
約 350–500
約 80–130
約 250–380
高階 ARM 四核 2.0 GHz（1 GB RAM，具加密加速）
約 700–950
約 150–230
約 550–800
x86 迷你主機（四核 N 系列，2.5GbE）
約 1800–2500
約 400–700
約 1500–2200
幾個值得注意的觀察：第一，WireGuard 在高階 ARM 平台上已經能輕鬆吃滿 1 Gbps 等級的家用頻寬，這意味著對大多數人來說，「VPN 拖慢網速」這件事在 WireGuard 上已經不成立。第二，OpenVPN 在沒有 DCO 的情況下，即使是高階 ARM 平台也很難突破 250 Mbps，這是使用者空間實作的結構性限制。第三，DCO 確實有效，能讓 OpenVPN 拉近到 WireGuard 的七成到八成水準，但前提是你的核心版本、OpenVPN 版本、以及路由器韌體都支援。
還有一點容易被忽略：這些數字是「單一連線」的表現。如果你的使用情境是很多裝置同時連線，多核心的調度效率就變得關鍵。WireGuard 在這方面通常比較線性，OpenVPN 則容易在某個核心上先飽和。
3-3 延遲、抖動與連線建立時間
吞吐量之外，延遲相關指標對使用體驗的影響其實更大，尤其是在視訊通話、遠端桌面、線上遊戲這些場景。
在延遲方面，兩者的「額外延遲」差距通常在 1 到 3 毫秒之間，WireGuard 略優。這個差距在絕對值上很小，但在抖動（jitter）上，WireGuard 的表現通常更穩定，因為它的封包處理路徑更短、變數更少。
真正的差距出現在連線建立時間。在相同硬體上，WireGuard 從送出第一個封包到通道可用，通常在數十毫秒等級；OpenVPN 的 TLS 握手加上認證，通常需要 300 毫秒到 2 秒不等，取決於認證方式與硬體效能。如果你的使用情境是「常常斷線重連」，例如行動裝置在不同基地台之間移動，這個差距會被放大成很有感的體驗落差。
漫遊能力也是重點。WireGuard 因為用金鑰而非 IP 識別 peer，當你的外部 IP 改變時，只要對方收到帶有新來源位址的有效封包，通道就會自動更新。OpenVPN 通常需要偵測到連線中斷後重新協商，中間會有明顯的空窗。
3-4 CPU 使用率與功耗
在路由器這種 24 小時開機的設備上，CPU 使用率不只影響效能，也直接影響發熱與耗電。
跑滿相同吞吐量時，WireGuard 的 CPU 使用率通常只有 OpenVPN 的三分之一到二分之一。這在沒有主動散熱的路由器上差別很大：長時間高負載下，OpenVPN 更容易觸發降頻，反過來又讓效能進一步下滑，形成惡性循環。
DCO 對 CPU 使用率的改善非常明顯，因為它消除了使用者空間與核心空間之間的封包搬移。不過要注意的是，啟用 DCO 後 OpenVPN 的 CPU 分佈會改變，原本集中在單一使用者空間程序上的負載會分散到核心執行緒，整體使用率下降但分佈更廣。
功耗方面，以一台典型的高階 ARM 路由器來說，純待機可能在 6 到 8 瓦，跑滿 WireGuard 大約 10 到 12 瓦，跑滿 OpenVPN 使用者空間版本可能到 13 到 16 瓦。長期下來電費差距不大，但對被動散熱機種的穩定性影響不小。
3-5 影響效能的關鍵變數
如果你實測出來的數字跟上面差很多，問題通常出在以下幾處：
四、路由器硬體選型與韌體準備
選對硬體，比事後任何調校都有效。這一節談 2026 年值得考慮的平台，以及韌體層面該注意的事。
4-1 2026 年值得考慮的路由器平台
目前市場上大致可以分成三條路線。
第一條是聯發科 Filogic 系列。這個平台這幾年在 OpenWrt 社群裡的支援度非常好，四核心 ARM Cortex-A53 搭配完整的加密指令集，跑 WireGuard 輕鬆破 800 Mbps。WiFi 7 機種如 Filogic 860、880 已經有成熟的開源支援，是自架 VPN 路由器的高性價比選擇。
第二條是高通 Networking Pro 系列。效能強勁，但在 OpenWrt 的支援上通常落後聯發科一個世代，購買前務必確認目標型號的韌體成熟度。
第三條是 x86 迷你主機。如果你追求極致效能與未來擴充性，一台搭載 N 系列或 i3 等級處理器的迷你主機，搭配多網埠，可以輕鬆處理數 Gbps 的 VPN 吞吐量。缺點是價格較高、體積較大、功耗也高一些，而且通常需要外接無線基地台。
選購時請特別注意三個規格：處理器是否具備加密指令集、記憶體是否至少 512 MB（跑 OpenVPN 建議 1 GB）、儲存空間是否足夠放韌體與套件。另外，網埠規格也很重要，如果你的 ISP 頻寬超過 1 Gbps，2.5GbE 埠就是必要的。
4-2 OpenWrt 版本與核心模組
截至 2026 年，OpenWrt 的主流穩定分支已經推進到以 Linux 6.12 為基礎的版本，WireGuard 早已是主線核心的一部分，不需要額外安裝核心模組，只要安裝使用者空間工具與 LuCI 介面即可。
OpenVPN 的部分要稍微注意。如果你打算使用 DCO，必須確認三件事：OpenVPN 版本是否為支援 DCO 的版本（2.6 以後，建議直接用 2.7 或更新的穩定版）、核心是否包含 ovpn-dco 模組、以及該模組是否已在你的平台上驗證可用。並非所有 ARM 平台都有現成的預編譯模組，有些需要自行編譯，這對不熟悉交叉編譯的使用者是個門檻。
建議的做法是：先確認你的路由器型號在 OpenWrt 韌體選擇頁面上的支援狀態，再看該版本套件庫裡有沒有 ovpn-dco 相關套件。如果沒有，就老老實實用使用者空間版本，或者改用 WireGuard。
4-3 記憶體、儲存與散熱
記憶體部分，WireGuard 相當節省，256 MB 就能跑得不錯。OpenVPN 加上 TLS 與憑證處理，建議至少 512 MB，若要跑多條隧道或搭配其他服務，1 GB 比較保險。
儲存空間的考量常常被忽略。OpenWrt 預設的 overlay 空間在很多消費級機種上只有幾十 MB，安裝幾個套件就滿了。如果你打算寫記錄檔、跑統計工具、或是安裝 DCO 核心模組，建議選擇有較大 flash 或支援 USB 儲存的機種，並把 overlay 擴展出去。
散熱是長期穩定性的關鍵。路由器通常放在弱電箱或櫃子裡，通風不良的情況下跑滿載很容易累積熱量。實務上的做法包括：加裝小型散熱風扇、墊高機身增加底部對流、避免與其他發熱設備堆疊。有些使用者會直接改裝散熱片，效果相當明顯。
五、WireGuard 伺服器與用戶端設定實作
接下來進入實作。以下以 OpenWrt 搭配 LuCI 與命令列混合說明，觀念適用於大多數 Linux 環境。
5-1 金鑰產生與 peer 設定
WireGuard 的每個節點都需要一組私鑰與對應的公鑰。產生方式很簡單，在路由器上執行命令列工具產生私鑰，再從私鑰推導公鑰。私鑰檔案權限必須設為只有 root 可讀，這是基本的安全要求。
設定檔的結構很單純：每個介面（interface）代表本機的一個身分，包含私鑰、監聽埠、以及自己的內網位址；每個 peer 區塊代表一個遠端節點，包含對方的公鑰、允許的來源位址範圍（AllowedIPs）、以及端點位址（Endpoint，伺服器端通常留空）。
這裡最容易搞混的是 AllowedIPs 的語意。它同時扮演兩個角色：對外，它決定「哪些目的地位址的流量會經過這個 peer」；對內，它是一條存取控制規則，決定「來自這個 peer 的封包，來源位址必須落在哪個範圍內，否則丟棄」。理解這一點，後面設定路由時就不會一頭霧水。
如果伺服器要接受多個用戶端，就為每個用戶端產生獨立的金鑰對，並在伺服器上為每個用戶端建立一個 peer 區塊，各自指定不同的內網位址（例如 10.6.0.2、10.6.0.3 依此類推）。網段規劃建議用 /24，避免與既有的內網網段衝突。
5-2 路由、防火牆與 NAT 規則
WireGuard 介面建立後，還需要處理三件事才能正常運作。
第一是轉發。核心的 IP 轉發功能必須開啟，否則封包進來後不會被轉送到其他介面。這個設定在 OpenWrt 裡通常是預設開啟的，但如果你使用精簡版韌體，記得檢查。
第二是防火牆區域。你需要在防火牆設定中建立一個新的區域，綁定 WireGuard 介面。如果是伺服器端要接受外部連線，這個區域的 input 政策需要允許；如果要讓 VPN 用戶端能存取內網，則要允許 forward 到 LAN 區域。同時，對 LAN 區域的 forward 設定也要允許回到這個新區域，否則回應封包會被擋下。
第三是 NAT。如果你的目的是讓 VPN 用戶端透過路由器出海（也就是把路由器當成出口節點），就需要對 WAN 介面做來源位址轉譯（masquerading）。這樣用戶端的流量會以路由器的對外 IP 送出，回應也能正確回來。反之，如果只是站對站互通，就不需要 NAT，直接靠路由表即可。
另外，監聽埠需要在 WAN 區域的 input 規則中放行。WireGuard 預設使用 UDP，建議改到非常見的高號埠，可以減少被自動掃描碰到的機率。這不是安全機制，只是降低噪音。
5-3 MTU 調校
MTU 是 WireGuard 在路由器上最常被設定錯誤的參數，也是效能問題的頭號嫌疑犯。
原理是這樣：WireGuard 的封包會在原有的 IP 封包之外再包一層。這層額外負擔包含外層 IPv4 標頭（20 位元組）、UDP 標頭（8 位元組）、以及 WireGuard 自己的標頭（16 位元組），合計 44 位元組。如果你的實體介面 MTU 是標準的 1500，那麼隧道內的可用 MTU 上限就是 1456。但實際上還要考慮封包填充與對端設定，實務上建議值通常抓 1420。
如果你的對外連線是 PPPoE（很多光纖到府是這種架構），實體 MTU 已經只有 1492，那隧道 MTU 就要再往下扣，落在 1412 附近比較安全。
設定太大會怎樣？封包會被路由器丟棄，或是需要進行分段重組，導致速度驟降、連線不穩、某些網站打不開。設定太小則每個封包能承載的資料變少，有效吞吐量下降。所以「能通」不等於「設對了」，一定要實際測。
測試方法很簡單：用 ping 指令搭配「不要分段」的旗標，從隧道另一端 ping 一個已知位址，逐步調整封包大小，找出不會被丟棄的最大值，再加上標頭大小就是最佳 MTU。這個動作值得花十幾分鐘做一次，很多莫名其妙的問題會當場消失。
此外，建議在防火牆上啟用 MSS clamping（TCP MSS 調整）。它會自動改寫 TCP 握手時的 MSS 選項，讓對端不會送出超過隧道能承載的封包。這對「大部分網站正常、少數網站卡住」這類症狀特別有效。
5-4 效能調校：多核心與 offload
硬體層級的調校主要圍繞幾個方向。
啟用軟體流量卸載。現代核心支援將封包轉發路徑從網路堆疊中「短路」，繞過部分防火牆規則檢查，大幅提升轉發效率。這對 VPN 吞吐量有直接幫助，但要注意某些進階功能（例如流量塑形、複雜的連線追蹤規則）在啟用後可能失效。
硬體 NAT 卸載。部分 SoC 提供硬體層級的 NAT 加速。這個功能對純轉發很有用，但通常與 VPN 介面不相容，因為 VPN 的封包需要經過加密處理。實務上多數情況下應該針對 VPN 介面停用硬體卸載，避免奇怪的連線問題。
中斷親和性。在有多個網路埠的平台上，把不同介面的中斷分配到不同核心，可以避免單核過載。如果你在跑多條隧道，這一點尤其重要。相關的設定通常可以透過修改系統參數或使用 irqbalance 之類的工具達成。
調整核心網路參數。例如增加 UDP 接收緩衝區、調整 backlog 佇列長度、開啟多佇列接收等。這些調整對高吞吐量情境有幫助，但過度調大反而會增加延遲，建議循序漸進。
六、OpenVPN 設定實作與效能調校
如果你選擇 OpenVPN，重點會放在認證體系的建立與調校參數的取捨。
6-1 憑證體系與 TLS 設定
OpenVPN 的認證核心是 X.509 憑證體系。你需要一個憑證頒發機構（CA），用它簽發伺服器憑證與每個用戶端的憑證。這個 CA 的私鑰是整個體系最敏感的資產，必須離線保存或放在安全的地方，絕對不要放在路由器上。
實務流程通常是：在一台安全的機器上建立 CA，簽發伺服器憑證與用戶端憑證，把伺服器憑證、CA 憑證、以及對應的金鑰放到路由器上。每個用戶端拿到自己的憑證、金鑰、以及 CA 憑證。吊銷用戶端時，把該憑證加入吊銷清單（CRL），並設定 OpenVPN 定期檢查。
除了憑證，建議再啟用 tls-crypt 或更新版本的 tls-crypt-v2。它的作用是為控制通道加上一層預共享金鑰的加密與認證，可以防止未授權的連線嘗試消耗伺服器資源，也能讓流量特徵不那麼明顯。這比舊的 tls-auth 更完整，因為 tls-auth 只做認證不做加密。
6-2 密碼套件與資料通道選擇
資料通道的加密選擇直接影響效能與安全性。
在支援硬體加速的平台上，AES-256-GCM 通常是最佳解，因為 GCM 同時提供加密與認證，且能利用處理器的 AES 指令集。如果你的平台沒有 AES 加速（例如較舊的 ARM 處理器、或某些 MIPS 平台），ChaCha20-Poly1305 在軟體實作下的表現往往更好。OpenVPN 2.6 以後已經原生支援 ChaCha20-Poly1305，不再需要外掛。
請避免使用 CBC 模式的舊式套件，例如 AES-256-CBC。它的效能較差，而且需要額外的 HMAC 來提供完整性保護，等於做兩次工。更重要的是，CBC 搭配不當的填充與 MAC 順序曾經導致過實際的安全弱點。
控制通道與資料通道可以分開設定。控制通道的流量很小，用較強的套件沒問題；資料通道才是效能關鍵，應該選擇有硬體加速支援的組合。
6-3 DCO 資料通道卸載
如果你決定使用 DCO，設定上會有幾個明顯差異。
首先，DCO 把資料通道移到核心，因此使用者空間的 OpenVPN 程序不再處理實際的封包。這意味著某些依賴使用者空間處理的功能會受限，例如部分外掛、某些流量腳本、以及某些進階的日誌選項。使用前務必確認你的設定檔沒有用到這些功能。
其次，DCO 要求客戶端與伺服器版本相容。如果一端用 DCO 另一端用傳統模式，通常還是能連，但效能優勢就只在有 DCO 的那一端體現。實務上，建議伺服器端優先啟用 DCO，因為伺服器通常是效能瓶頸所在。
第三，DCO 目前主要支援 UDP 模式。如果你的環境必須使用 TCP 封裝，那就享受不到 DCO 的好處。
最後要提醒，DCO 在不同核心版本上的成熟度差異不小。在部署到正式環境前，建議先在測試機上跑一段時間，確認穩定性與相容性。
6-4 OpenVPN 的實用調校參數
以下是幾個在路由器環境中特別值得調整的參數。
七、安全性、隱私與長期維護
效能之外，安全性與維護成本同樣該納入考量。
7-1 密碼學原語比較
WireGuard 使用的組合（Curve25519、ChaCha20-Poly1305、BLAKE2s）在 2026 年依然是相當穩健的選擇，而且因為沒有協商機制，不會出現設定錯誤導致降級的情況。它的攻擊面小，程式碼量少，也因此更容易被完整稽核。
OpenVPN 的安全性高度取決於你的設定。用對了（AES-GCM 或 ChaCha20-Poly1305、tls-crypt、現代 TLS 版本），安全性同樣優秀；但因為選項多、設定複雜，實務上設定錯誤的比例明顯較高。這也是為什麼很多安全專家會說「OpenVPN 不是不安全，是很容易被設定成不安全」。
從稽核角度來看，WireGuard 因為實作精簡，長年來接受過多輪獨立審查，發現的問題相對少。OpenVPN 歷史較長，累積修補的漏洞也較多，但這不代表現在不安全，只是代表它的歷史足跡更複雜。
7-2 金鑰輪替與前向保密
WireGuard 內建了自動的會期金鑰輪替機制，大約每兩分鐘就會重新協商一次資料金鑰。即使某一組會期金鑰被破解，也無法用來解密其他時段的流量，前向保密是預設開啟的。
OpenVPN 的前向保密取決於你選擇的 TLS 密碼套件與資料通道設定。使用支援 ECDHE 的 TLS 套件與 AEAD 資料通道，可以達到前向保密。但這需要明確設定，預設值不一定是最安全的選項。
長期維護上，兩個協定都需要定期更新金鑰。WireGuard 的靜態金鑰（peer 的長期金鑰）建議定期更換，尤其是在裝置遺失或被汰換時務必立即移除對應 peer。OpenVPN 則需要定期檢查憑證效期、更新 CRL、並在成員異動時確實吊銷憑證。若沒有自動化，這件事很容易被遺忘，這也是自架環境常見的風險來源。
7-3 記錄、洩漏與 DNS
自架 VPN 的一大優勢是你能完全掌控記錄。建議的原則是「盡量不留」：只保留必要的錯誤層級記錄，並設定檔案輪替與保存期限。完整連線記錄在自架環境中通常沒有必要，反而增加隱私風險。
DNS 洩漏是常見的設定疏漏。VPN 通道建立後，用戶端的 DNS 查詢必須一起走隧道，否則會用本地 ISP 的 DNS 解析，導致部分網站的存取行為暴露。常見做法是在隧道設定中直接推送 DNS 伺服器位址，並在路由器上擋掉非隧道的 DNS 查詢。若你的路由器本身跑了 DNS 解析服務，記得調整監聽介面與轉發規則，確保查詢走對出口。
IPv6 洩漏同樣要注意。如果你的內網有 IPv6，而 VPN 通道只處理 IPv4，用戶端的 IPv6 流量可能會直接從本地出海。解決方式有兩個：一是把 IPv6 一起納入隧道（WireGuard 原生支援，OpenVPN 需額外設定），二是乾脆在用戶端停用 IPv6。選擇哪一種取決於你對 IPv6 的需求。
八、常見問題與排錯
以下整理實務上最常遇到的幾類問題。
8-1 速度上不去？
先確認瓶頸在哪。用 iperf3 分開測試「不走 VPN」與「走 VPN」的吞吐量，如果兩者相同，代表你的 ISP 頻寬才是限制，VPN 沒問題。如果有明顯落差，接著檢查路由器 CPU 使用率：跑滿載時某一核是否 100%？如果是，代表加密運算是瓶頸，換協定或換硬體是唯一解。
再檢查 MTU。這是「速度上得去但某些網站怪怪的」最常見的原因。
最後檢查加密套件。OpenVPN 若用了沒有硬體加速的套件，效能會差好幾倍。確認你用的套件在該平台上能吃到硬體加速。
8-2 連線不穩、斷線、封包遺失
穩定性問題的來源通常有三類。第一是網路本身的品質：行動網路、公共 WiFi、或是 ISP 線路不穩，這類問題通常表現為間歇性延遲尖峰。第二是保活設定：NAT 設備會在一定時間沒有流量後清除連線追蹤記錄，導致通道看似存在但實際上已失效。WireGuard 可以設定持久保活（PersistentKeepalive），建議值為 25 秒；OpenVPN 則有 keepalive 參數。第三是資源不足：記憶體不夠、連線追蹤表滿了、或是散熱不良導致降頻。
排查時建議同時在兩端抓封包，確認是單向還是雙向問題，能大幅縮短除錯時間。
8-3 無法存取內網資源
這是設定問題，通常是三個環節之一：路由表沒有把目標網段指向隧道、防火牆沒有放行對應方向的轉發、或是 NAT 設定不當導致回應封包回不去。
診斷順序建議是：先在路由器上確認路由表正確，再檢查防火牆的 forward 鏈，最後檢查來源位址轉譯。另外別忘了，目標主機本身可能也有防火牆，如果你的內網主機只允許同網段存取，來自 VPN 網段的連線就會被它自己擋掉。
九、結論：2026 年該怎麼選？
講了這麼多，最後給出比較直接的建議。
如果你的路由器是這幾年買的 ARM 四核心機種，而且跑的是 OpenWrt，請毫不猶豫選 WireGuard。它的效能、資源佔用、設定複雜度、以及連線恢復速度，在這個硬體層級上幾乎全面勝出。設定檔短、維護成本低，對於「平時順順用、偶爾需要連回家」的多數使用者來說，這是最省心的選擇。
如果你必須在受限網路環境中運作，例如某些場合只開放 TCP 443，或需要更強的流量混淆能力，那 OpenVPN 的彈性仍然是它的獨門優勢。WireGuard 在這種環境下幾乎沒有施力點。
如果你需要與既有企業基礎設施整合，例如 LDAP、RADIUS、或是複雜的憑證政策，OpenVPN 的成熟度和工具鏈依然較完整。雖然 WireGuard 可以搭配其他工具補足部分功能，但配置起來會複雜許多。
如果你的硬體效能較弱（例如雙核入門機種），WireGuard 省下的記憶體與 CPU 會讓整台路由器更穩定，這也是明顯的選擇依據。
如果你什麼都不想放棄，其實也可以兩者並存：用 WireGuard 作為日常主要通道，另外保留一條 OpenVPN 設定作為備援，遇到特殊網路環境或特殊需求時切換使用。這種做法在路由器上並不困難，只要注意兩者的網段規劃不要衝突即可。
最後提醒一句：無論選哪一個協定，真正決定成敗的往往不是協定本身，而是 MTU 有沒有設對、防火牆規則有沒有寫好、金鑰有沒有妥善管理、以及韌體有沒有定期更新。協定只是工具，把基本功做扎實，你的路由器就能成為整個家庭網路中最可靠的那一環。
希望這篇整理對正在規劃自架 VPN 的你有所幫助。如果你的路由器型號比較冷門，或是在 DCO 編譯上卡關，歡迎在論壇的 3C 科技教學版繼續討論，把你的設定與實測數據貼出來，大家一起研究往往比單打獨鬥快得多。