Unbound 與 AdGuard Home，自架 DNS 解析器與過濾器的差異
為什麼大家會把它們放在一起比較
原因有三個。第一，兩者都會佔用 53 埠（或至少對外提供 DNS 服務），直覺上像是「同類產品」。第二，兩者都能擋廣告——Unbound 靠 RPZ，AdGuard Home 靠 AdBlock 語法清單，功能重疊讓人以為可以二選一。第三，兩者都支援加密 DNS，名稱常常一起出現在同幾篇教學裡。
但實際上它們是上下游的關係，而非替代關係。把「解析」與「過濾」拆開來看，你會發現真正的問題不是「選哪一個」，而是「你的架構需不需要兩層」。
二、核心機制對比：遞迴查詢與轉發查詢的差別
要理解兩者的差異，最好的方式是跟著一筆查詢走一遍。假設你的筆電要連上 www.example.com，這筆查詢在兩種架構下走的路徑完全不同。
Unbound 的遞迴流程與 DNSSEC 驗證鏈
當用戶端把查詢送給 Unbound，而快取中沒有對應資料時，Unbound 會執行以下步驟：
www.example.com，根伺服器不會直接回答，而是回覆「.com 的權威伺服器是這幾台」。.com 的伺服器詢問，得到「example.com 的權威伺服器是這幾台」。example.com 的權威伺服器詢問，終於拿到 A 記錄或 AAAA 記錄。寫入快取：依記錄的 TTL 快取結果，下次同樣的查詢直接命中。
整個過程中，Unbound 只與各地的權威伺服器溝通，沒有任何第三方上游能看到你完整的查詢清單。你的 IP 會出現在各個權威伺服器的日誌裡，但單一業者看到的只是片段。這就是遞迴解析在隱私上的核心優勢。
Unbound 預設還會啟用 QNAME minimisation：在遞迴過程中只透露必要的查詢名稱片段（例如先問 .com 的 NS，而不是一次把完整網域送出去），進一步降低資訊外洩。這類細節是純轉發架構做不到的。
AdGuard Home 的上游轉發與過濾鏈
同樣一筆查詢送到 AdGuard Home，流程則是：
查本機快取：若放行且快取中有資料，直接回覆。
過濾回應：部分設定下還會檢查回應的 IP 是否落在封鎖清單中。
記錄與統計：寫入查詢日誌（可設定保留時間），更新儀表板數字。
可以看出，AdGuard Home 的價值集中在第二與第五步，其餘步驟本質上是「代理」。這不是缺點，而是設計目標不同——它的目標是可管理、可視化、可依用戶端分流的過濾層，而不是自己走完遞迴。
快取行為：兩者都有快取，但快取的東西不一樣
Unbound 快取的是 RRset（資源記錄集），而且會連同 DNSSEC 驗證狀態一起保存。它遵循原始 TTL，支援 prefetch（在 TTL 快到期前主動更新熱門記錄）與 serve-expired（上游暫時失聯時回覆過期資料），對於穩定度幫助很大。
AdGuard Home 快取的是最終答案，設定相對簡單，主要提供快取大小與 TTL 覆寫選項。它的快取偏向「減少重複轉發」，而非「維持驗證狀態」。
當兩者串接時，會形成兩層快取。這在多數情況下是好事（外層命中率高，內層負擔小），但除錯時要記得：你改了某筆記錄卻沒生效，可能不是 DNS 沒更新，而是兩層快取都還沒過期。這是實務上非常常見的誤判。
三、功能面全面對比：過濾、加密、管理介面與多用戶
接下來把幾個實際會影響使用體驗的面向攤開來看。
過濾與攔截能力：AdBlock 語法對上 RPZ
AdGuard Home 的過濾系統是它的主場。它支援 AdBlock Plus 語法（包含 ||domain^、例外規則 @@、$important 等修飾詞）、hosts 格式、純網域清單與正規表達式。內建清單目錄可以一鍵訂閱 AdGuard DNS filter、AdGuard Base filter 等常見清單，也可以手動貼上任何相容的訂閱網址。它還內建「封鎖服務」清單（例如一次封鎖 Facebook、TikTok 等整組服務），以及安全搜尋（Safe Search）強制開啟、惡意網站封鎖等選項。
更重要的是，AdGuard Home 支援以用戶端為單位的不同規則。你可以讓小孩的平板套用嚴格清單，自己的電腦只擋追蹤器，IoT 裝置則完全封鎖對外 DNS。這種粒度是 Unbound 難以做到的。
Unbound 的過濾手段是 RPZ（Response Policy Zone），概念上是把黑名單做成一個 DNS zone，載入後對命中名稱執行指定動作（NXDOMAIN、NODATA、改寫為特定 IP 等）。它效率極高、對大量網域也能撐得住，但缺點很明顯：沒有訂閱管理介面、沒有例外清單 UI、沒有每用戶端策略（除非你跑多個實例或使用 view）、而且多數現成清單是 AdBlock 語法，需要自己寫腳本轉換成 zone 檔。
結論很直接：若你重視的是「擋廣告與追蹤」這件事本身，AdGuard Home 的功能完整度遠勝 Unbound。Unbound 的 RPZ 是給已經有自動化流程的人用的。
加密 DNS：DoH、DoT、DoQ 的支援程度
AdGuard Home 在這方面幾乎是全配：作為服務端，它支援 DoH、DoT、DoQ（需要自行準備憑證，或用內建的 Let's Encrypt 整合）；作為用戶端，它的上游可以是純 DNS、DoT、DoH、DoQ、DoH3，並可設定 Bootstrap DNS 來解析上游主機名稱。這讓它在各種網路環境下的適應力很強。
Unbound 也支援作為 DoT／DoH 服務端（需編譯時啟用 TLS 支援並提供憑證），但在「上游」這一側，它的定位是遞迴解析器，因此通常是直接以明文 53 埠向權威伺服器查詢。若你想要加密到上游，實務上的做法是讓 Unbound 進入 forward 模式，把查詢轉給支援 DoT 的上游——但這樣就放棄了遞迴的隱私優勢，變成另一種折衷。
這裡有一個常被忽略的觀念：「加密」不等於「隱私」。把查詢用 DoH 包起來送到公共 DNS，只是把「誰看得到」從電信業者換成那個公共 DNS 業者，並沒有讓查詢憑空消失。真正的隱私來自遞迴——把查詢打散到眾多權威伺服器。
管理介面、日誌與可視化
AdGuard Home 的儀表板是很多人一試成主顧的原因：即時查詢數、攔截比例、Top 查詢網域、Top 用戶端、各清單的命中次數，還有可搜尋的查詢日誌（可設定保留 1 天到 90 天，或乾脆關閉）。它同時提供 HTTP API 與 Prometheus 相容的統計端點，方便接入 Grafana。這些功能讓「DNS 出了什麼事」變得容易追查。
Unbound 只提供 unbound-control stats_noreset 這類文字統計，以及可選的查詢日誌（log-queries，長期開啟會產生大量資料，一般不建議）。要可視化，得自己接 exporter 與儀表板。對熟手來說不是問題，但對家庭環境而言是額外工作量。
多用戶端、分群與家長控制
AdGuard Home 可以為每個用戶端（以 IP 或 MAC 辨識）設定不同的上游、不同的過濾清單、不同的封鎖模式，並支援家長控制的時間表（例如晚上九點後切斷某些裝置的網路）。這對家庭或小型辦公室是實用功能。
Unbound 沒有這類概念，只能靠 view 與 access-control 做粗略的分流，設定複雜且沒有圖形化管理。若你的需求包含「不同裝置要有不同規則」，答案幾乎肯定是 AdGuard Home。
四、效能與資源佔用：誰比較快？誰比較省？
效能是最容易被誇大的一環，這裡只談量級與影響因素，不給絕對數字，因為實際表現高度取決於線路、硬體與查詢型態。
查詢延遲：冷查詢與熱快取的差異
熱快取（cache hit）的情況，兩者差距極小。在區網內，無論是 Unbound 還是 AdGuard Home，回應時間通常都在 1 毫秒以內，使用者完全感受不到差異。這也是為什麼很多人在換掉公共 DNS 後覺得「變快了」——其實多半是快取命中率提升，而不是解析器本身比較神。
冷查詢（cache miss）才是真正的分水嶺。Unbound 需要從根伺服器一路問到權威伺服器，跨網路的往返次數多，回應時間可能是數十毫秒到數百毫秒。AdGuard Home 若直接轉發給鄰近的公共 DNS，通常只需一趟往返，延遲明顯較低。
但這裡有個前提：如果 AdGuard Home 的上游就是本機的 Unbound，那麼冷查詢的延遲就等於「Unbound 遞迴的時間 + 一次本機轉發」，後者幾乎可忽略。換句話說，串接架構的冷查詢會比純遞迴略慢一點點，但熱查詢完全一樣快，而換來的是完整的過濾與統計能力。
對一般家庭而言，查詢分佈極度集中在少數熱門網域（搜尋引擎、影音平台、社群網站），快取命中率往往很高，冷查詢的影響被大幅稀釋。真正該在意的反而是：上游是否穩定、快取 TTL 設定是否合理。
記憶體與 CPU 佔用
Unbound 以 C 語言撰寫，資源效率很好。一般家用環境下，常駐記憶體通常在數十 MB 的量級（實際取決於 msg-cache-size 與 rrset-cache-size 的設定），CPU 幾乎閒置。即使在樹莓派、老舊迷你電腦或 NAS 的 Docker 容器中執行，也不會有明顯負擔。
AdGuard Home 以 Go 撰寫，記憶體佔用略高，通常在一百多 MB 的量級；若訂閱了大量過濾清單、開啟長期查詢日誌，或使用大量用戶端規則，佔用會再往上。不過在現代硬體上，這仍然是非常輕量的服務。
兩者同時執行，總佔用通常仍在數百 MB 以內，對一台 1GB 記憶體的樹莓派來說完全可行。真正容易吃資源的其實是其他東西——例如容器映像、日誌輪替沒設好，或是在同機器上跑了一堆服務。
大規模或虛擬化環境的考量
如果是企業、學校或 ISP 等級的部署，Unbound 的優勢就明顯了：它支援多執行緒（num-threads）、so-reuseport、可橫向擴展成多實例並以 anycast 或負載平衡分散，且在高併發下表現穩定。這些是它在電信圈被廣泛採用的原因。
AdGuard Home 的設計初衷偏向中小規模。它在家庭與小型辦公室綽綽有餘，但在極高 QPS 下，Go runtime 與日誌寫入可能成為瓶頸。若要在大環境使用，通常會以多實例搭配外部負載平衡，或把它放在 Unbound 之後作為「使用者體驗層」。
五、部署實務：三種常見架構與設定要點
理解差異之後，來看實際上怎麼組。以下三種架構涵蓋了大多數人的需求。
架構 A：AdGuard Home 搭配公共加密上游
最簡單的做法：只裝 AdGuard Home，上游設定為 Cloudflare、Google 或 Quad9 的 DoH／DoT 位址，並設定 Bootstrap DNS 來解析上游主機名稱。
優點是五分鐘就能上線，過濾、統計、家長控制一應俱全。缺點是所有查詢仍然交給第三方上游，隱私改善有限——你只是把信任對象從電信業者換成了 DNS 業者。對於「我只想擋廣告、不在乎誰看到我的查詢」的人來說，這已經足夠。
設定時建議注意幾件事：關閉「向上游傳送 EDNS Client Subnet」（除非你確實需要地理最佳化）、設定查詢日誌的保留天數、確認 Bootstrap DNS 可用（否則上游主機名稱解析失敗會導致全部查詢掛掉）。
架構 B：Unbound 遞迴加上 AdGuard Home 過濾（推薦組合）
這是最常見、也最兼顧隱私與功能性的做法：用戶端 → AdGuard Home（過濾與統計）→ 本機 Unbound（遞迴與 DNSSEC 驗證）→ 根伺服器。
第一步，先把 Unbound 裝好並限制只能本機存取。以下是 unbound.conf 的核心片段：
server:
interface: 127.0.0.1
port: 5335
do-ip6: no
access-control: 127.0.0.0/8 allow
root-hints: "/var/lib/unbound/root.hints"
auto-trust-anchor-file: "/var/lib/unbound/root.key"
harden-glue: yes
harden-dnssec-stripped: yes
qname-minimisation: yes
cache-min-ttl: 300
cache-max-ttl: 86400
prefetch: yes
num-threads: 2
so-reuseport: yes
hide-identity: yes
hide-version: yes
接著用 unbound-checkconf 檢查語法，並確認 root.key 存在（可用 unbound-anchor 初始化或更新）。此時用 dig @127.0.0.1 -p 5335 example.com 應該要能取得答案，且具備 DNSSEC 驗證的網域會回傳 ad 旗標。
第二步，回到 AdGuard Home 的管理介面，把上游 DNS 設為 127.0.0.1:5335（純 DNS 即可，因為是本機通訊，不需要加密）。同時確認「私人反向 DNS 解析器」的設定正確指向本機，避免反向解析走錯路徑。之後用 dig @127.0.0.1 example.com 測試，確認查詢會經過 AdGuard Home 並正確回覆。
這個架構的好處是：你同時擁有 AdGuard Home 的過濾與可視化，以及 Unbound 的遞迴隱私與 DNSSEC 驗證。查詢在離開你的網路之前，就已經被過濾掉一大半；剩下真正需要解析的，才由 Unbound 以遞迴方式取得。
缺點是設定步驟較多，而且除錯時要分辨問題出在過濾規則、外層快取，還是 Unbound 的遞迴與驗證。建議在初次建置時先把 AdGuard Home 的過濾清單全部關掉，確認基本轉發正常，再逐步開啟清單，這樣比較容易定位問題。
架構 C：只用 Unbound 搭配 RPZ 黑名單
如果你追求極致的輕量與單一程序，可以只用 Unbound，並用 RPZ 載入黑名單。做法是定期抓取相容清單（例如以 AdBlock 語法為主的清單），用腳本轉換成 zone 檔格式，再透過 rpz 指令載入。
優點是資源佔用極低、沒有額外的管理負擔、解析與過濾在同一層完成。缺點是：沒有圖形介面、沒有查詢統計、沒有每用戶端策略、例外規則要手動維護，而且清單轉換腳本需要自己寫並定期執行。這種做法適合已經熟悉 shell 與排程工作、且不需要視覺化管理的人。
常見設定陷阱
不論選哪種架構，以下幾個坑幾乎人人踩過：
systemd-resolved，它會佔用 53 埠。安裝前要先停用或改設定，否則 AdGuard Home 或 Unbound 會啟動失敗。host.docker.internal，而不是 127.0.0.1。root.key 過期未更新、上游不回傳必要記錄，或中間設備攔截了 DNSSEC 相關查詢。六、安全性、隱私與合規考量
DNSSEC：誰真正在做驗證
DNSSEC 的價值在於「確認答案沒有被竄改」，而驗證必須由解析器執行。Unbound 會完整走完信任鏈，並在成功時設定 AD 位元；AdGuard Home 則只是把上游的答案轉回來，本身不做驗證。這代表在架構 A 中，你的 DNSSEC 保護程度完全取決於上游業者；在架構 B 中，則由你的 Unbound 負責驗證，控制權在自己手上。
如果你的環境位於存在 DNS 干擾或劫持的網路，DNSSEC 驗證能幫你偵測到異常（驗證失敗會回傳 SERVFAIL），而不是默默收到錯誤的 IP。這也是許多人堅持自架遞迴解析器的主要原因之一。
上游信任與查詢隱私
轉發模式下，上游能看到你所有的查詢——包括你什麼時候查了哪個網域。即使使用 DoH 加密，加密只保護「傳輸過程」，上游本身仍然看得到內容。相對地，遞迴模式下查詢會分散到眾多權威伺服器，單一業者無法拼出完整輪廓，但你的 IP 仍會出現在各權威的日誌中。
這是一個取捨，沒有絕對的贏家。實務上常見的折衷是：本機遞迴為主，遇到被干擾或解析失敗的網域時，再透過轉發特定網域到加密上游來補。Unbound 支援 forward-zone 針對特定網域轉發，正好可以用來處理這種情況。
日誌留存與法遵
AdGuard Home 預設會保留查詢日誌，這對除錯很方便，但也是隱私風險。建議依需求設定保留天數（例如 24 小時或 7 天），或直接關閉日誌只保留統計。若你服務的是公司或組織，記得把「DNS 查詢紀錄屬於個人資料」這件事納入考量，設定適當的保存期限與存取控制。
Unbound 預設不記錄每一筆查詢，只有在開啟 log-queries 時才會寫入。這一點在隱私上是優勢，但也意味著出問題時較難追查。可以折衷開啟較低詳細度的日誌，或搭配外部監控。
七、怎麼選？依使用情境給出的建議
把前面的分析整理成一張表，會更清楚。
比較項目
Unbound
AdGuard Home
核心定位
驗證型遞迴解析器
DNS 過濾與轉發前端
是否自行遞迴查詢
是（從根伺服器開始）
否（需設定上游）
DNSSEC 驗證
內建，完整驗證鏈
不執行，依賴上游
廣告與追蹤過濾
需自行轉換成 RPZ，功能有限
完整支援，清單訂閱與例外管理
圖形管理介面
無，純設定檔與 CLI
有，含儀表板與查詢日誌
加密上游（DoH／DoT）
需改用轉發模式
原生支援多種協定
加密服務端
支援 DoT／DoH（需憑證）
支援 DoH／DoT／DoQ
每用戶端策略
需以 view 手動設定
原生支援
資源佔用
極低
低至中等
設定門檻
較高
適合對象
重視隱私與驗證、熟悉命令列者
想快速上手、需要可視化管理與過濾者
如果你只想要「擋廣告、看得到統計、五分鐘上線」，選 AdGuard Home 就對了，不必勉強自己碰 Unbound。
如果你在意「查詢不要全部交給單一業者」、想要真正的 DNSSEC 驗證、而且不排斥編輯設定檔，那麼 Unbound 是必要的。此時再把 AdGuard Home 放在前面當過濾層，就是最完整的組合。
如果你的機器資源極度有限（例如老舊路由器、只有 128MB 記憶體的裝置），或你偏好極簡架構，那麼只用 Unbound 加 RPZ 會比跑兩個服務更合適。
八、常見問題一次解答
只裝 AdGuard Home 可以嗎？
可以，而且這是大多數人的起點。它會正常運作、擋廣告、提供統計。唯一要接受的是：所有查詢都會經過你設定的上游，DNSSEC 驗證也由上游決定。對一般家庭使用來說，這已經足夠。
只裝 Unbound 可以嗎？
可以，但你會失去圖形介面與便利的過濾清單管理。若你不打算擋廣告，只想要一個乾淨的遞迴解析器，Unbound 單獨使用完全沒問題，許多防火牆套件就是這樣預設的。
兩個一起裝會不會變慢？
熱快取的查詢幾乎沒有差異；冷查詢會多一次本機轉發，影響以微秒到毫秒計，實務上感受不到。真正影響速度的是上游品質與網路環境，而不是多一層本機服務。
樹莓派跑得動嗎？
可以。兩者同時執行在 1GB 記憶體的樹莓派上是很常見的配置，只要注意過濾清單數量與日誌保留設定，避免長期成長佔滿儲存空間。
為什麼裝了 Unbound 之後某些網站打不開？
常見原因有幾種：DNSSEC 驗證失敗（可能是系統時間不準或 root.key 過期）、該網域依賴的記錄類型未被正確處理、或網路環境干擾了遞迴查詢。可以先查看 Unbound 日誌，並用 dig 直接對 5335 埠測試，確認問題出在解析層還是過濾層。
Docker 部署要注意什麼？
最常見的錯誤是上游位址填 127.0.0.1。在容器內，這指向容器本身而非宿主機。若 Unbound 跑在宿主機、AdGuard Home 跑在容器，請改用宿主機的區網 IP，或設定 extra_hosts 讓容器能解析宿主機名稱。另外記得把設定檔與資料目錄掛載成 volume，否則容器重建後設定會消失。
在外網要怎麼使用自己的 DNS？
可以透過 VPN 連回家中網路，再把 DNS 指向內網伺服器；或在 AdGuard Home 上開啟 DoH／DoT 服務，搭配憑證與防火牆規則，讓外部裝置加密查詢。後者務必做好存取控制，避免變成開放式解析器而被濫用。
九、結論：解析與過濾分開，才是長期穩定的自架架構
回到最初的問題：Unbound 與 AdGuard Home 的差異在哪裡？答案其實很清楚——它們解決的是不同層次的問題。Unbound 負責「把答案正確、可驗證地找回來」，AdGuard Home 負責「決定哪些查詢該被擋下，並讓整個過程可被觀察與管理」。
把兩者視為替代品，往往會陷入「裝了 A 就覺得少了 B」的迴圈；把它們視為互補，則會得到一個兼顧隱私、過濾與可維護性的架構。對大多數自架玩家而言，架構 B（AdGuard Home 在前、Unbound 在後）是投入產出比最高的選擇：你保留了熟悉的管理介面與過濾清單，同時把解析與 DNSSEC 驗證牢牢握在自己手上。
當然，這不是唯一答案。若你的優先順序是「極簡」與「低資源」，Unbound 加 RPZ 能滿足需求；若你的優先順序是「快速上線」與「完整功能」，單獨使用 AdGuard Home 也完全合理。重點在於你知道自己選了什麼、放棄了什麼。
自架 DNS 不是裝好就結束的事。它需要定期更新清單、監控解析狀況、處理誤擋與驗證失敗，並在需求變化時調整架構。但只要基礎打得穩，它會是整個區網中最安靜、卻最有感的一項基礎建設——你看不見它，卻每天受益於它。
```
💬 想說點什麼？
歡迎到留言板分享你的想法、心得或疑問。
💬 前往留言板 →