OpenWrt 與 pfSense，自架路由器的防火牆與 QoS 差異

OpenWrt 的防火牆抽象核心是「區域（Zone）」與「轉發（Forwarding）」這兩個概念。你把某個網路介面歸到某個 zone（例如 lan、wan），然後在 zone 與 zone 之間定義是否允許轉發、是否開啟 NAT、是否開放 INPUT。這套模型對於家庭場景非常直覺：內網 → 外網允許、外網 → 內網拒絕，一行設定就搞定。它的好處是設定檔短、維護簡單；缺點是當你需要更細緻的例外規則（例如「只允許某個 IP 在特定時段連到某個服務」），就得靠 Traffic Rules 的優先順序去疊，規則一多就會變得難以追蹤。

值得一提的是 OpenWrt 對「區域」的處理其實是雙面刃。它的直覺性來自「介面 → 區域」的對應，但當你的網路拓撲開始出現 DMZ、VLAN 分段、IoT 隔離時，zone 的數量會快速膨脹，而 zone 之間的轉發矩陣（forwarding matrix）是以「區對區」為單位，並沒有原生的「規則物件」可以重複引用。你得靠 config rule 手工一條一條補，或者在 /etc/nftables.d/ 底下塞自訂的 nft 檔。這對熟悉 Linux 的人不是問題，但對「只想在網頁上點一點」的人來說，會在某個臨界點之後感受到明顯的摩擦力。

另外，OpenWrt 本身不內建 IDS/IPS。雖然套件庫裡有 snort、suricata 之類的東西可以裝，但一來套件版本不一定新、二來要自己處理 ruleset 更新與效能調校，三來在低階 ARM 設備上跑 IPS 基本上是自虐。它比較適合「以靜態規則為主的邊界防護」，而不是「深度封包檢測」的場合。當然，OpenWrt 也有 banip 這類輕量級的封鎖工具，可以訂閱公開的黑名單，對於擋掉一些無腦掃描已經足夠。

pfSense 的防火牆體系：PF、pfSense 的規則模型

pfSense 的防火牆核心是 PF，而 pfSense 在 PF 之上建立的規則模型，可以說是它最「企業級」的部分。它的規則有幾個關鍵概念：介面（Interface）、方向（Direction，in/out）、動作（Pass/Block/Reject）、位址族、協定，以及最重要的「浮動規則（Floating）」與「別名（Alias）」。

Alias 是 pfSense 相對 OpenWrt 的一大優勢。你可以把一組 IP、一段網段、一個通訊埠、甚至一個 URL table（透過 pfBlockerNG 之類的套件定期更新）包成一個具名物件，然後在幾十條規則裡重複引用它。當你有一天要新增一台 NAS 時，只要把它加進「NAS_HOSTS」這個 alias，所有相關規則就自動生效，不必逐條修改。這種「以物件為中心」的設計，是大型規則集能維持可讀性的關鍵，也是 OpenWrt 的 zone/rule 模型相對吃力的地方。

浮動規則是另一個分水嶺。它允許你定義不綁定特定介面的規則，並用「快速（Quick）」旗標決定是否在命中後就停止評估後續規則。這讓你可以很優雅地寫出「不管從哪個介面進來，只要是來自這個黑名單就一律阻擋」這種一刀切的策略，再用更細的規則去補例外。pfSense 也支援規則排程（Rule Schedule，依時間啟用）、狀態逾時（State Timeout）微調，以及「預設封鎖、明確放行」的嚴格模型。

進階防禦方面，pfSense 的套件生態是它真正拉開差距的地方。Suricata 與 Snort 都以套件形式提供，並且有相對完整的 GUI 整合（規則集管理、警報檢視、介面綁定），不用自己手刻設定檔。pfBlockerNG-devel 更是社群的招牌之一，能同時做 IP 黑名單、DNSBL（擋廣告與惡意網域）、GeoIP 地理封鎖。這套組合拳讓 pfSense 在「邊界威脅攔阻」這個維度上，明顯比「原生只有 nftables 規則」的 OpenWrt 更完整。當然，代價是效能與記憶體消耗，以及你得花時間去理解這些套件之間的交互作用。

進階防火牆功能與威脅防禦

如果把鏡頭拉遠一點，pfSense 在「企業級高可用」上的能力也值得提一筆：CARP（Common Address Redundancy Protocol）可以讓兩台 pfSense 以主備模式共用一組虛擬 IP，達到閘道器層級的容錯切換。OpenWrt 雖然可以透過 VRRP（keepalived）做到類似效果，但那是額外安裝、額外設定的東西，不像 pfSense 是內建且有官方文件與 GUI 支援。

反過來說，OpenWrt 在「規則的透明性」上有它的迷人之處。因為整個防火牆最終就是一組 nftables 規則，你可以用 nft list ruleset 一覽無遺，要與其他 Linux 工具（例如 tc、conntrack）搭配也毫無隔閡。對於喜歡「看到全貌、自己掌握每一個 byte」的人來說，這種透明感是 pfSense 的抽象層給不了的。pfSense 雖然也能透過 shell 下 pfctl -sr 看規則，但你得先穿過好幾層 PHP 產生的設定，追蹤起來反而更費神。

QoS 與流量整形：SQM/CAKE 對比 ALTQ 與 FQ-CoDel

如果說防火牆決定「誰能進來」，那 QoS 決定的是「進來的東西排隊排得公不公平」。這一塊可以說是 OpenWrt 最被低估、卻也最好用的一項武器，而 pfSense 在這方面的表現則常常被誤解。我們先從 OpenWrt 的 SQM 說起。

OpenWrt 的 SQM 與 CAKE

OpenWrt 的 SQM（Smart Queue Management） 套件，是它對抗「緩衝區膨脹（bufferbloat）」的招牌功能。它的核心邏輯很簡單也很聰明：在 WAN 介面上掛一個佇列管理演算法，把「上傳」與「下載」的流量各自整形，並且刻意把可用頻寬設得比實際線路稍低（例如 95%），讓排程器永遠有餘裕去決定「下一個該送誰的封包」，而不是把封包一股腦塞進 ISP 的緩衝區裡排隊。

SQM 背後可以選用的演算法有 fq_codel、cake、piece_of_cake 等，其中 CAKE（Common Applications Kept Enhanced）是目前最受推崇的選擇。CAKE 的厲害之處在於它把「公平佇列（Fair Queueing）」、「AQL（避免過度緩衝）」與「頻寬整形」整合在一起，並且內建了針對「主機」與「流量」的隔離能力（per-host isolation、per-flow isolation），甚至還支援 DSCP 標記的尊重與重映射。實務上，只要線路不是極度擁擠，開啟 SQM + CAKE 之後，視訊會議的延遲抖動、遊戲的 ping 尖峰、大檔案下載時的「整條線卡住」現象，都會有非常明顯的改善。

操作上也非常友善：LuCI 裡的 SQM 頁面只要填上「下載頻寬」「上傳頻寬」，選好佇列演算法與腳本，按下儲存套用即可。它甚至有「Speedtest 建議值」可以參考（雖然未必精準，但當起點很夠用）。對一般家庭使用者來說，這是 OpenWrt 相對 pfSense 最直接的「爽感」來源之一。

限制當然也有。SQM 的整形是綁在介面上的，當你的線路是多 WAN 或需要依來源做差異化排程時，它的設定就會開始變得笨重。此外，CAKE 是相對吃 CPU 的演算法，在低階 ARM 路由器上開啟高流量整形時，CPU 使用率會明顯上升，甚至成為瓶頸。這也是為什麼很多玩家會選擇 x86 小主機跑 OpenWrt，就是為了讓 SQM 有足夠的運算餘裕。

pfSense 的流量整形器與 Limiters

pfSense 的 QoS 能力其實相當完整，只是它的「入門曲線」比 OpenWrt 陡上不少。它主要提供兩套機制：Traffic Shaper（流量整形器）與 Limiters（限速器）。

Traffic Shaper 的設計思維是「先定義介面上的佇列（Queue），再定義規則把流量導進對應的佇列」。傳統上它建立在 ALTQ 框架之上，讓你可以用「多層佇列（Hierarchical Queue）」的方式，把介面頻寬切成好幾塊，例如「VoIP 優先」、「一般瀏覽次之」、「P2P 最低」。它甚至內建了一個「Traffic Shaper Wizard」，會根據你選擇的連線類型（例如 Cable、DSL、Multi-WAN）自動生成一組佇列與規則，是許多人第一次接觸 pfSense QoS 的起點。不過這個精靈產生出來的規則往往是「堪用但不精準」，進階使用者通常還是會手動調整。

Limiters 則是建立在 dummynet 之上的另一套機制，概念上比較像「針對特定流量做頻寬上限或延遲模擬」。它支援 FQ-CoDel 作為排程演算法，也能做「每 IP 公平分配」之類的設定。與 Traffic Shaper 相比，Limiters 比較適合「我只要限制某類流量不要吃滿頻寬」的簡單場景，而 Traffic Shaper 則適合「我要精細分配優先級」的複雜場景。

這套設計的優點是「表達力強」：你幾乎可以針對任何流量特徵（來源/目的 IP、通訊埠、通訊協定、DSCP 標記）去指定佇列，並且可以做出非常細緻的層級結構。缺點則是「設定繁瑣」：一個不小心，佇列之間的權重、上限、優先級就會互相打架，而且 pfSense 的介面在呈現這些關係時並不特別直覺，除錯時常常需要回到 shell 用 pfctl -sq 去看實際的佇列狀態。

實際測試場景與效果差異

把兩者放在同一條 300M/100M 的家用光纖上比較，會得到相當有趣的心得。在「對抗緩衝區膨脹」這件事上，OpenWrt + SQM/CAKE 是壓倒性地簡單有效：你只要把上下傳頻寬填對，選擇 piece_of_cake，按下套用，然後打開 bufferbloat 測試網站，通常就能看到 A 到 A+ 的成績。pfSense 要做到同等效果，得先設好 Traffic Shaper 的介面佇列、再設好 Limiters 的 FQ-CoDel、再把規則導進去，中間任何一步設錯，效果就會大打折扣，而它的 GUI 並不會主動告訴你「你沒開 SQM」。

不過，在「多類別差異化排程」這件事上，pfSense 的表達力就明顯勝出。假設你是一個小型工作室，需要讓 VoIP 通話永遠優先、視訊會議次之、NAS 備份最低，同時要針對不同部門做頻寬上限，那麼 pfSense 的多層佇列 + Alias + 浮動規則，可以很精準地把這件事做出來，而且規則的意圖相對清楚。OpenWrt 雖然可以透過 tc 手動寫 HTB + fq_codel 來達成，但那就完全脫離了 SQM 的便利性，變成純手工活，維護成本很高。

另外一個常被忽略的點是「上傳方向的整形」。家用線路的下載頻寬通常遠大於上傳，而 bufferbloat 往往是在上傳方向爆掉（因為 ISP 的上行緩衝較小、較容易塞滿）。SQM 預設就會同時處理 ingress 與 egress，並且會用 IFB（Intermediate Functional Block）虛擬介面來處理下載方向的整形，這部分 OpenWrt 已經封裝得很好。pfSense 則需要你自己確認 Traffic Shaper 是否有正確掛在對應方向，否則很容易出現「下載很順、但一上傳就整條線卡住」的狀況。

效能、硬體與資源佔用

把防火牆與 QoS 的功能面談完，接下來要面對的是很現實的問題：同樣的硬體，誰跑得比較順？

OpenWrt 的優勢在於「輕」。一個乾淨的 OpenWrt 安裝在 x86 上，開機後常駐記憶體可能只有一兩百 MB，CPU 待機幾乎為零。這讓它可以在非常低階的硬體上運行，也讓 SQM 這類吃 CPU 的功能有更多餘裕。相對地，pfSense 因為是完整 FreeBSD 系統加上 PHP WebGUI 與眾多服務，開機後基本佔用就明顯較高，官方建議的 2GB RAM 並不是隨便說說。如果你打算跑 Suricata 或 pfBlockerNG，記憶體與 CPU 的門檻還會再往上跳一級。

但「輕」不等於「快」。在純封包轉發與狀態追蹤上，兩者其實都能輕鬆跑滿 1Gbps 甚至更高的線路（前提是網卡不要太爛、並且有開啟硬體加速或適當的 offload）。pfSense 因為 PF 的狀態表設計成熟，在大量連線數（例如 P2P 或大量 NAT 連線）的場景下，它的狀態管理通常比較穩定；OpenWrt 的 nftables conntrack 也不差，但在極端連線數下需要調整的核心參數比較多，初學者容易踩到「連線表滿了」的坑。

真正拉開差距的是「你要不要開進階功能」。如果你只做基本的 NAT 與防火牆，兩者效能差異不大；但如果你要開 IDS/IPS、要跑大量黑名單、要做精細 QoS，那 pfSense 天生就是為這種「重負載」場景設計的，而 OpenWrt 則會逼你必須更審慎地選擇硬體與套件。反過來說，如果你只是想要一台安靜、省電、跑 SQM 很順的小路由器，那 OpenWrt 在低功耗平台上的表現往往更討喜。

易用性、維護與社群生態

功能與效能之外，每天都會碰到的是「好不好維護」。這部分兩者各有擁護者。

OpenWrt 的維護哲學是「文字檔即設定」。你的所有設定幾乎都躺在 /etc/config/ 底下，備份就是複製一個資料夾，還原就是貼回去，版本控管用 Git 輕鬆搞定。它的升級路徑也相對單純（sysupgrade），但要注意「保留設定」與「跨大版本升級」之間的相容性問題，尤其是 fw3 → fw4 這種底層變動，常常需要手動檢查規則。LuCI 介面雖然完整，但它的資訊密度偏高，對新手不算特別友善，很多功能還是得靠文件與論壇。

pfSense 的維護哲學則是「設定即組態檔」。整個系統的設定集中在 config.xml，備份與還原都透過 WebGUI 的 Backup & Restore 完成，升級也有內建的更新流程（CE 版需要透過套件管理器，Plus 版則更自動化）。它的 WebGUI 設計相對成熟，許多常見任務（例如新增 VPN、設定 DHCP 保留、看流量圖表）都有清楚的向導。但它的「黑盒子感」也比較重：當你遇到 GUI 沒涵蓋的狀況時，往往得去翻 pfSense 論壇或 Reddit，而且某些行為（例如 NAT 反射、浮動規則優先順序）的邏輯需要花時間才能內化。

社群生態方面，OpenWrt 的優勢是「與 Linux 世界無縫接軌」：任何 Linux 上的網路工具、除錯技巧、核心參數調校，幾乎都能直接搬過來用。它的套件庫龐大，但品質參差不齊，很多套件是社群維護、更新頻率不一。pfSense 的優勢則是「垂直整合」：它的套件生態雖然數量較少，但核心套件（Suricata、pfBlockerNG、HAProxy、OpenVPN/WireGuard）都有專人維護與相對完整的 GUI 整合，遇到問題時也比較容易找到「針對 pfSense 場景」的解答，而不是「這是 Linux 通用做法，你自己想辦法」。這對於不想花太多時間除錯的人來說，其實是很大的加分。

選型建議：你該選哪一個？

講了這麼多，最後還是要回到「你」。以下用幾個典型場景幫你做個粗略的對應：

還有一個常被忽略的折衷方案：把兩者分工。例如用 OpenWrt 當主要路由器與 Wi-Fi 存取點、負責 SQM，然後把 pfSense 放在後面當「威脅防禦閘道」或「VPN 端點」。這種「分層防禦」的做法在進階玩家圈並不少見，既能享受 OpenWrt 的輕巧與 SQM 便利，又能利用 pfSense 的 IDS/IPS 與規則表達力。當然，這會增加拓撲複雜度與電力消耗，是否值得就看你對「單一設備搞定」的執念有多深了。

結語

OpenWrt 與 pfSense 之間的選擇，本質上不是「哪個比較好」，而是「你想用什麼樣的方式，去換取什麼樣的能力」。OpenWrt 用透明性與輕量換取了你對每一條規則、每一個封包的掌控感，並且在 QoS 這條路上用 SQM + CAKE 給出了一個「連新手都能享受」的解答；pfSense 則用抽象化與垂直整合，換取了企業級規則模型、成熟的高可用機制與完整的威脅防禦生態，代價是更高的硬體門檻與更陡的學習曲線。

如果你問我，對大多數自架路由器的玩家來說，最實際的建議會是：先從 OpenWrt 開始，把 SQM 與基本防火牆摸熟，理解自己的網路瓶頸到底在哪裡；當你某一天發現「我需要更細緻的規則分類」「我需要看誰在掃我的 Port」「我想要主備容錯」，那就是 pfSense 該登場的時候了。反過來也一樣，如果你先接觸 pfSense，卻發現自己 90% 的時間只是在調 SQM 的參數，那不妨回頭試試 OpenWrt，你會發現很多時候「簡單」本身就是一種效能。

路由器是家裡網路的心臟，但它不需要是「最強的那一顆」，而是「最適合你脈搏的那一顆」。希望這篇對比能幫你在兩者之間，找到那個讓你能安心按下「儲存並套用」的答案。

🏠 返回首頁