DNS Over HTTPS 解析：隱私權與公共 WiFi 過濾的抉擇
DNS over HTTPS 會加密 port 443 流量中的查詢。深入了解它隱藏了哪些內容、為何能繞過 WiFi 過濾，以及網路如何保持控制權。
Published 2026年10月26日
DNS over HTTPS 會透過連接埠 443 在一般 HTTPS 流量中傳送 DNS 尋找，在裝置與解析程式之間進行加密，並已於 2018 年成為 IETF 標準。
您已在訪客 WiFi 上啟用了內容過濾，但訪客的瀏覽器仍然開啟了您以為已經封鎖的類別。防火牆正常運作、網路設定看似正確，而且另一台裝置也如預期出現封鎖頁面。兩者的差異可能在於瀏覽器詢問了哪一個解析器，而非您的過濾器是否運作。
對場地營運商與 IT 負責人來說，這就是 DoH 的核心問題。它能在查詢傳輸過程中提供保護，但瀏覽器對目的地的選擇，也可能會讓該查詢超出您網路的過濾政策範圍。
目錄
- 簡單說明何謂 DNS over HTTPS
- DoH 查詢如何從裝置傳輸至解析器
- 開啟 DoH 時，誰能看到您的查詢內容
- 為什麼 DoH 會削弱共用 WiFi 上的 DNS 過濾效能
- DoH 對速度的影響以及過濾機制的剩餘作用
- 在常見裝置上檢查與變更 DoH 設定
- 選擇並分層部署您的 DoH 控制措施
簡單說明何謂 DNS over HTTPS
DNS over HTTPS（通常簡稱為 DoH）透過加密的網頁連線傳送 DNS 查詢與回應。DNS 解析器則是裝置用來將功能變數名稱轉換為網路位址的服務。
您可以將 DNS 想像成一本電話簿。在建立連線之前，應用程式需要取得位址，儘管其快取中可能已有可用的解答。傳統 DNS 通常會以可讀的純文字形式傳送該查詢。
明信片是一個很貼切的比喻：任何經手的人都可以讀取上面的訊息。DoH 則是將問題裝在密封信封內，並使用與一般安全 Web 流量相同的運送車輛進行傳送。
比較傳輸方式，而不僅僅是加密技術
DNS over TLS（即 DoT）同樣會封裝訊息，但使用單獨標記的傳輸埠。這使得網路運營商更容易透過其目的地連接埠來識別其流量。
IETF 於 2018 年 10 月發布的 RFC 8484 定義了 DoH 的 HTTPS 交換方式，通常使用連接埠 443，這與使用連接埠 53 的傳統 DNS 不同。
傳統 DNS、DNS over TLS 與 DNS over HTTPS 比較
| 功能特性 | 傳統 DNS | DNS over TLS (DoT) | DNS over HTTPS (DoH) |
|---|---|---|---|
| 傳輸層 | UDP 或 TCP | TLS | HTTPS |
| 常用連接埠 | 53 | 853 | 443 |
| 可被區域網路讀取 | 是 | 否 | 否 |
| 可透過連接埠輕易識別 | 是 | 是 | 否，與網頁流量共用連接埠 443 |
| 可透過連接埠輕易封鎖 | 是 | 是 | 否，無法單靠連接埠進行選擇性封鎖 |
| 規範定義於 | 原始 DNS 規格 | DNS over TLS 規格 | RFC 8484 |
封鎖專用的 DNS 連接埠非常簡單。但若封鎖安全網站所使用的連接埠，也會阻斷合法的 Web 流量，因此 DoH 需要更具選擇性的控制措施。
加密並不會決定過濾的內容。解析器可以解密傳入的 DoH 請求、套用內容或威脅政策，並安全地傳回解答。關鍵問題在於誰在營運該解析器，以及它遵循的是誰的政策。
在審查控制措施時，請隨時參考此比較。適用於傳統 DNS 或 DoT 的規則，並不一定會自動適用於 DoH。
DoH 查找如何從裝置傳輸到解析器
快遞員在投遞包裹前需要地址。同樣地，瀏覽器在連接到飯店預訂頁面之前也需要目的地地址，除非該答案已經快取在本地。
此圖表追蹤從瀏覽器到解析器再返回的查找過程。
追蹤請求與回應
瀏覽器需要一個位址。它會檢查是否已有訂房網站的可用解答。快取命中可以完全避免新的查詢，因此區域網路不會看到該動作的 DNS 交換。
它會建立 DNS 詢問。如果需要新的解答，瀏覽器會準備包含網域名稱的查詢。此時，詢問仍留在裝置內部，尚未傳輸於 WiFi 之上。
它會選擇 DoH 解析器。瀏覽器會為其設定的解析器準備一個 HTTPS 請求。區域網路可以觀察到目的地位址和連線元資料，但無法直接讀取加密 DNS 訊息內部的網域。
它會建立或重用安全連線。如果需要，裝置會在傳送受保護的請求之前完成 TLS 握手。透過持久的 HTTP 連線，後續的查詢可以重用該連線；網路會看到加密的流量，包括其時間與大小。
解析器傳回解答。解析器會處理詢問，並將 DNS 回覆放在加密的 HTTP 回應中。網路可以看到從解析器傳回的流量，但看不到解答的可讀內容。
瀏覽器連線至網站。它會使用傳回的位址開始網站連線。區域網路可以觀察到該新目的地，這與讀取之前的 DNS 詢問是分開的。
若要了解更多有關快取與解析的詳細資訊，DNS 查詢的作用 一文將尋找位址的過程與網站連線本身進行了區分說明。
識別過濾點
對於需要 DNS 解析的新連線，查詢會在網頁內容載入前發生。這讓經核准的解析程式有機會在瀏覽器連線之前，拒絕已被封鎖的目的地。
獨立設定的瀏覽器可以將該決策發送到其他地方。場地的解析器隨後就不會收到需要評估的查詢。
隨附影片提供了另一種追蹤此流程的方法。
開啟 DoH 時誰可以看到您的查找紀錄
DoH 並非對所有人隱藏瀏覽紀錄。 它能在裝置與所選解析器之間保護 DNS 交換過程不被普通觀察者窺探，但該解析器仍必須讀取查詢內容才能提供解答。
這種區別在共用 WiFi 上非常重要。訪客可能合理希望防止本地端的連線攔截，而醫院或學校則需要確保其安全防護與威脅控管措施仍然有效。
DoH 改變了您在 DNS 活動中信任的對象；它並沒有消除對某人建立信任的需求。
將 DNS 能見度與瀏覽能見度分開
此表說明的是未搭配額外隱私中繼、VPN 或攔截系統的一般 DoH 使用情況。讀取 DNS 訊息與從其他網路活動推斷目的地是完全不同的功能。
在使用 DoH 時誰可以看到 DNS 查詢
| 觀察者 | 看得見網域名稱 | 看得出正在使用 DoH | 為什麼這很重要 |
|---|---|---|---|
| 相同 WiFi 上的其他裝置 | 否，無法從加密查詢中看出 | 極少能透過一般同級存取看出 | ['被動讀取 DNS 訊息已被阻擋']|
| 場地或 ISP 網路 | 否，無法在 DoH 交換內容中看出 | 通常可以，透過傳送至已知解析程式位址的流量看出 | 本機 DNS 控制無法評估傳送到其他地方的查詢 |
| 您造訪的網站 | 僅限您連線的網站 | 無法單憑網站連線看出 | 網站不會收到您無關的 DNS 查詢 |
| DoH 解析程式營運商 | 是，其收到的每一次查詢 | 是 | 直接連線會暴露這些查詢以及您的來源位址 |
| 瀏覽器或 OS 廠商 | 僅限其營運該解析程式或收到相關遙測資料時 | 軟體知道其設定的模式；廠商報告需要遙測資料 | 軟體設定不等於自動具備廠商可見性 |
解析器不一定會看到裝置進行的每一次查詢。其他應用程式可能會使用不同的解析器，而快取的解答可能不需要發出任何查詢。解析器只會看到傳送給它的請求。
同樣地，瀏覽器開發商並不會只因為提供瀏覽器就自動收到 DNS 歷史紀錄。解析器運作、軟體設定與遙測資料收集屬於不同的角色職責。
明確制定信任決策
針對受管理的 Firefox 安裝，Mozilla 的 DNS over HTTPS 政策文件 提供了解析器設定以及使用者是否能變更該設定的控制選項。這是讓瀏覽器行為與組織 DNS 管理政策保持一致的實用方法。
場所或 ISP 仍可能觀察到目的地位址、連線時間和流量大小。其他協定中繼資料也可能可能有助於識別網站，因此加密 DNS 查詢並不代表匿名瀏覽的承諾。
在批准解析器之前，請進行簡短的信任評估：
- 指名營運商。明確瞭解由哪家組織接收查詢，而非僅依賴瀏覽器的預設標籤。
- 閱讀保留條款。檢查儲存了哪些查詢與連線資訊、保留多久以及用途為何。
- 確認管轄權與存取權。瞭解營運商在何處處理資訊以及誰能取得這些資訊。
- 將可見度與責任相互配對。決定 IT 團隊需要調查哪些安全性事件，以及不應保留哪些瀏覽細節。
值得探討的問題並非抽象層面上的隱私或可管理性何者更重要，而是您所選擇的 DNS 路徑是否能在為使用者提供適當保密性的同時，又能讓組織履行其既定職責。
為什麼 DoH 會削弱共用 WiFi 上的 DNS 過濾
飯店會向房客提供櫃檯電話，以協助尋找在地服務。大多數房客會致電櫃檯，但也有房客改用工商黃頁應用程式。櫃檯可以控制自己的推薦內容，但無法控制該應用程式提供的答案。
網路 DNS 的運作方式類似。您的網路會提供解析器，但具有自行 DoH 設定的瀏覽器可能會改為詢問外部服務。
圖表顯示了繞過網路 DNS 處理機制的替代路由。
繞過行為的核心在於路由
問題不在於加密查詢永遠無法被過濾。而是您的過濾器無法對它從未收到的查詢套用政策。
在家庭景點的訪客網路中，這可能意味著成人內容阻擋機制無法套用至特定瀏覽器。在員工網路中，惡意應用程式則可能透過未核准的解析器來解析指揮與管制（C2）功能變數名稱。
後果取決於哪些控制措施依賴 DNS：
- 特定網路的策略。指派給 SSID 或 VLAN 的規則無法管轄傳送到已核准解析程式路徑之外的提問。
- 搜尋限制。基於 DNS 的安全搜尋強制執行可能會被繞過，不過帳戶層級或終端限制可能仍然有效。
- 威脅阻擋。DNS 過濾器無法拒絕看不見的查詢，即使其威脅清單中包含請求的網域。
一項 加密 DNS 部署的測量研究 報告了 Firefox 的遙測數據，其中在 2025 年期間，9.54 兆次桌面交握中有約 13.91% 使用了 DoH。該研究還描述了一個測量資料集，其中 DoH 的普及率約為 DoT 的 6.4 倍。
這些觀察結果並不能代表繞過您場所過濾機制的裝置比例。瀏覽器預設值、地區推出進度、解析器相容性以及管理員策略，都會影響 DoH 是否處於啟用狀態。
測試涵蓋範圍而非盲目假設
在員工筆記型電腦上成功封鎖，並不代表在訪客的個人手機上也有同等的涵蓋範圍。這些裝置可能會使用不同的瀏覽器、DNS 設定或隧道。
請將您的 WiFi 內容過濾器 視為具有明確流量路徑的控制項。請使用訪客隨身攜帶的裝置與應用程式來測試該路徑。
預設情況下，僅基於網路提供之解析程式的過濾已無法提供完整的涵蓋範圍。這需要配套的控制措施，並誠實記錄政策之外仍有哪些遺漏。
DoH 在速度上的代價以及過濾功能仍可發揮的作用
加密會增加處理負擔，但實際問題在於使用者是否會察覺到連線速度變慢。初始連線設定與重複查詢的成本不同，因此僅測試單次全新請求可能會產生誤導性的結果。
一項 DNS 傳輸層協定的實證比較 指出，在其無延遲的本地基準測試中，UDP 和 TLS 的回應時間小於 1 毫秒，而 HTTP/2 則穩定保持在 10 毫秒以下；下列結果保留了該研究的實驗背景，而非用來預測實際場域的效能表現。
引用研究中按協定劃分的 DNS 查找延遲
| 通訊協定 | 回報結果 | 情境 |
|---|---|---|
| UDP | 低於 1 ms | 無延遲的本機基準線 |
| TLS | 低於 1 ms | 無延遲的本機基準線 |
| HTTP/2 | 持續低於 10 ms | 連線重複使用與多工傳輸有助於減少開銷 |
| HTTP/1.1 | 大幅波動 | 歸因於管線化限制 |
| 公開 DoH 對比傳統 DNS | 每個名稱較慢 | 未觀察到整體網頁載入時間顯著增加 |
衡量整個工作階段，而不僅僅是握手過程
持久連線讓用戶端可以將設定成本分攤到後續的查詢中。多路複用則使其能夠處理多個交換，而無需為每個問題建立單獨的安全連線。
只要請求能到達過濾解析器，DNS 過濾仍可在建立新連線前拒絕特定功能變數名稱。廣告與追蹤器阻擋可能會減少後續的請求，但光靠加密本身並無法移除廣告或加速網頁載入。
追蹤揭示真實問題的維運訊號：
- 握手失敗。尋找連線建立錯誤與重試情況。
- 快取命中率。區分快取回應與全新的解析。
- 解析程式回應時間。測量訪客連線高峰期的運作表現。
- 容錯回退行為。檢查發生故障時，裝置是會停止解析，還是在未通知的情況下切換至其他路徑。
實用規則：請將瀏覽、政策執行與故障復原結合在一起進行測試，而不是作為獨立的驗收檢查。
相較於僅憑延遲假設選擇協定，選擇附近且具備高彈性的解析程式端點是更好的起點。請在真實負載下確認您網路上的結果。
檢查並變更常見裝置上的 DoH
瀏覽器設定可以解釋為什麼連線至相同 WiFi 的裝置會有不同的行為。不同版本之間的選單標籤可能會有所變更，如果找不到下列路徑，請使用「設定」搜尋功能。
檢查瀏覽器與作業系統
- Chrome：開啟「設定」>「隱私權和安全性」>「安全性」，然後查看「使用安全性 DNS」。檢查其是否跟隨目前的提供者或指定了其他服務。
- Firefox：開啟「設定」>「隱私權與安全性」，然後查看「基於 HTTPS 的 DNS」。審視保護模式（包括關閉、標準保護或最高保護）以及所選取的解析程式。
- Edge：開啟「設定」>「隱私權、搜尋和服務」>「安全性」，然後查看「使用安全性 DNS」。管理策略可能會鎖定此設定。
- Android：開啟「設定」>「網路和網際網路」，然後查看「私人 DNS」。此設定使用 DoT 而非 DoH；瀏覽器層級的安全性 DNS 需要另外檢查。
- iOS 與 macOS：檢查已安裝的設定描述檔、裝置管理設定以及 DNS 相關應用程式。加密的 DNS 描述檔運作時可能會獨立於瀏覽器之外。
驗證有效路徑
無論瀏覽器設定為何，系統 VPN 都可以透過自己的通道傳輸 DNS。此外，也請檢查應用程式是否提供獨立的加密 DNS 服務。
確認實際的瀏覽器或應用程式進行全新測試查詢時是由哪個解析器接收。 請使用瀏覽器檢測工具或解析器識別測試，並配合已核准的解析器日誌，而非僅信任設定畫面。
選擇並分層配置您的 DoH 控制措施
根據裝置所有權和政策需求進行分層控制。受管理的員工筆記型電腦可以遵循強制執行的設定；個人的訪客手機通常無法做到。對這兩類群組施加相同的限制，要麼會產生可避免的漏洞，要麼會造成不必要的連線中斷。
您可以選擇允許外部 DoH 並接受本地 DNS 可視性降低，或者限制 DoH 並承擔相容性風險，也可以結合受管理裝置的政策與選擇性的訪客網路控制。多層次防禦方法能讓您更清楚掌握哪些項目受到保護、哪些沒有。
將各項控制措施對應至其實際範圍
網路控管措施固然有用，但並不能讓每個加密解析器都能被識別。私人解析器、變更位址或 VPN 隧道，都可能打破圍繞已知常見服務清單所建立的假設。
共用與託管網路上的 DoH 控制措施
| 控制措施 | 阻擋內容 | 套用位置 | 權衡取捨 |
|---|---|---|---|
| 封鎖外連連接埠 853 | 標準連接埠的 DNS over TLS | 防火牆或閘道器 | 對透過一般 HTTPS 的 DoH 無效 |
| 強制將連接埠 53 導向網路解析器 | 明文 DNS 繞過 | 閘道器強制執行，由 DHCP 設定支援 | 完全忽略 DoH；僅靠 DHCP 無法強制合規 |
| 封鎖已知的公開 DoH 解析器位址 | 與已列出解析器的連線 | 防火牆或具備相應能力的閘道器 | 清單會過期、出現新的解析器、部分應用程式會無法運作 |
| 透過託管策略停用瀏覽器 DoH | 受涵蓋瀏覽器中的瀏覽器層級繞過 | 託管的筆記型電腦與員工裝置 | 無法涵蓋訪客 WiFi 上的個人手機 |
| 透過 MDM 強制執行網路解析器 | 裝置策略涵蓋的未授權 DNS 變更 | 已註冊的員工與企業裝置 | 需要註冊與平台支援；訪客排除在外 |
| 接受 DoH 並在終端進行過濾 | 網路端無任何處置 | 僅限託管終端 | 訪客裝置不受終端策略限制 |
封鎖解析程式的地址也可能會封鎖該地址託管的其他無關服務。請避免將防火牆的加密 DNS 類別視為永久且詳盡無遺的清單。
若您需要域名解析之外的管控能力，請評估 安全 Web 網關 並配合端點與網路原則。請仔細檢查部署要求，特別是在裝置非組織所有的情況下。
建立可測試的營運政策
請先從您需要提供的服務開始著手。員工管理網路、公共圖書館連線以及兒童活動場所，合理的做法是需要不同的限制條件與針對使用者的不同說明。
請使用此部署檢查清單：
- 列出所需的策略。識別需要內容控制或威脅過濾的 SSID、VLAN 與裝置群組，並為每個項目指定負責人。
- 將受控裝置與訪客 BYOD 分開。記錄可以在何處強制執行瀏覽器策略或 MDM，以及何處僅能使用網路控制。
- 關閉一般的 DNS 繞過途徑。在您的策略有此要求的方面，阻擋出站 DoT 並將傳統 DNS 限制為已核准的解析程式。覆蓋兩種受支援的網路位址家族。
- 套用受控瀏覽器策略。設定已核准的 DNS 路徑，並防止員工設備上出現未受支援的使用者覆寫。
- 維護訪客網路解析程式限制。定期審查被阻擋的解析程式位址、測試例外情況，並移除造成無法接受的附帶阻擋規則。
- 發布淺顯易懂的訪客通知。說明過濾了哪些類別、記錄了哪些網路資訊，以及對加密 DNS 或 VPN 使用的任何限制。
- 在每個網路上測試真實裝置。檢查允許的網站、被阻擋的類別、核准的安全測試目的地、解析程式失敗以及 VPN 行為。
上線前：封鎖頁面僅能證明特定的請求已被過濾，並不代表裝置上的每個應用程式都遵循相同的路徑。
將加密 DNS 納入驗收測試的一部分
若要使用 Shield，請將網路的 DNS 指向 Shield。我們會在我們保護的網絡上，為每台裝置回應每一次 DNS 查詢，且裝置上沒有任何可關閉的設定；因此外部解析器與隧道路徑必須納入網路的防護設計中。
在您試用 Shield 之前，我們的專家會示範您的網路如何處理 VPN 與加密 DNS。您可以利用該討論來確認哪些請求會到達受保護的 DNS 路徑、哪些控制項會強制執行該路徑，以及當裝置嘗試使用其他路徑時會發生什麼事。
在變更訪客存取權限之前，請先設定驗收標準。相較於盲目假設已啟用的過濾器能看到一切，建立經核可的解析器、具備完整記錄的例外處理流程，以及可重複執行的裝置測試，能提供更穩固的基礎。
Purple Shield 提供保護性 DNS、內容過濾、威脅防禦與廣告攔截，無須在訪客裝置上安裝代理程式。請造訪 Purple Shield 安排試用前討論，了解您的 SSID、過濾政策，以及您的網路如何處理加密 DNS 與 VPN。