DNS over HTTPS：它是什麼以及如何保護您的查詢

最後更新： 十月22，2026
作者： 像素化
  • DoH 使用 HTTPS 對 DNS 查詢進行加密，從而提高隱私性和安全性，防止竊聽和篡改。
  • 它不等同於 VPN：它保護網域名稱搜索，但不能保護所有流量或您的 IP 位址。
  • 它的部署具有性能優勢，但也與家長控制、監控和審查有衝突。

資料中心中的伺服器，代表 DNS 伺服器所在的架構。

當你輸入網址時，後台有一個元件在運行，確保你訪問的是正確的網站：網域名稱系統 (DNS)。 DNS將易於記憶的網域轉換成電腦可以理解的 IP 位址。這確實很方便，但多年來它一直存在一個重大漏洞：這些查詢以未加密的方式傳輸。這就是為什麼 DNS over HTTPS（也稱為 DoH）如此受歡迎的原因——它增加了一層額外的保護，使你的網路服務提供者更難追蹤你訪問的網域名稱。

首先要澄清一點：DoH 可以提升 DNS 查詢的隱私性，但它並非 VPN，也不會將您的整個連線變成一條秘密隧道。本文將深入探討 DoH 的本質、其流行原因、如何在 Chrome、Edge 和 Firefox 中啟用它、它的優缺點、它與 DNS over TLS 和 VPN 的區別，以及它在技術和實際應用中的局限性。

什麼是 DNS？為什麼傳統系統無法滿足需求？

DNS 伺服器是幾乎無人關注的元件之一，但它卻是網頁瀏覽的基礎。其作用是將網域名稱與對應伺服器的 IP 位址關聯起來。當您造訪網站時，您的電腦無法識別字母：它需要 IP 位址才能知道要連接到哪台伺服器。許多路由器都預先安裝了由網路服務供應商配置好的 DNS 伺服器，這使得存取過程非常便捷，但也給控制該基礎架構的人員留下了明顯的痕跡。

根本問題在於傳統的DNS查詢以明文形式發送，沒有任何保護措施。這使得竊聽、中間人攻擊和篡改回應成為可能。網路服務供應商可以獲知您查詢的網域名稱以及查詢時間；共享網路上的攻擊者可以嘗試攔截請求並傳回詐騙回應。這種技術被稱為DNS劫持，最終可能導致您造訪虛假頁面、垃圾廣告或旨在竊取資料的網站。歷史上，政府和網路服務供應商也曾利用這些漏洞實施審查、封鎖網域名稱或投放額外廣告。

  • 被動聽話： 有人觀察你的查詢記錄，推斷你經常使用哪些服務或網站。
  • 中間人攻擊： 通訊被攔截，回應被修改以冒充伺服器。
  • 屏蔽和過濾： 它阻止某些網域的解析，以控制對內容的存取。

DNS over HTTPS：對查詢進行加密，使其不被所有人看到。

用木塊拼成「加密」一詞，說明透過 HTTPS 對 DNS 查詢進行加密。

DNS over HTTPS（簡稱 DoH）是利用 HTTPS 協定以加密形式傳輸 DNS 查詢和回應的解決方案。它不會發送明文 DNS 請求，而是將其封裝在安全連接中，通常使用 443 連接埠（安全網站使用的連接埠）。這樣可以保護查詢和回應，防止外部人員輕易讀取它們。

要實現這一點，被查詢的 DNS 伺服器也必須支援基於網域的 DNS (DoH )。僅僅在瀏覽器中啟用一個選項是不夠的：所選的解析器必須符合此標準。該規範一直在不斷發展，目前仍被視為一項新興技術，儘管自 2018 年以來，Google和 Mozilla 基金會等公司一直在對其進行測試和整合。除了提高隱私性之外，測試表明 DoH 還可以降低延遲並加快查詢速度，因為它並非總是需要解析整個域，而只需解析所需的最小部分即可。

DoH的優勢：更高的隱私性、更少的操控性和更好的效能

最明顯的優勢在於安全性。由於 DNS 查詢經過加密傳輸，因此很難被窺探或竄改。這增加了中間人攻擊的難度，降低了在公共 Wi-Fi 網路上的風險，並防止當地業者清楚地看到您正在要求哪些網域。由於 DoH 流量使用 443 端口，因此它與其他 HTTPS 連接混雜在一起，難以與普通的網路存取區分開來。

此外，還有性能方面的考量。 DoH可以透過改變網域解析方式並更有效地利用快取來降低延遲並加快 DNS 通訊速度。例如，某些 API 的 GET 方法經過最佳化，可以更有效率地進行快取。實際上，這可以帶來略微更快的瀏覽速度，雖然它並非萬能靈藥，而且這種提升並非總是顯而易見。此外，由於 DoH 是在瀏覽器中實現的，因此用戶無需等待網路服務供應商啟動它。

缺點與爭議：加密技術何時讓生活變得複雜

並非所有人都對基於網域的加密 (DoH) 持正面態度。這種加密方式在保護用戶的同時，也增加了網路監控的難度。許多家長控製程式依賴檢查 DNS 查詢來確定孩子試圖造訪哪些網站；而 DoH 使得這項任務變得更加複雜，甚至可能根本無法完成。企業網路管理員也面臨類似的情況，他們無法了解哪些網域正在被查詢，也無法像以前那樣輕鬆地執行某些規則。

網路服務供應商也失去了監控存取和應機構要求屏蔽特定網域的能力。這引發了一場合理的爭論：有些人認為這是隱私的勝利，而有些人則認為這是一個控制和管理問題。以DoT為例，它也因使用自身易於識別的連接埠而受到批評，這使得即使不知道具體請求內容，也能識別出DNS查詢。 DoH透過偽裝在HTTPS流量中來避免這種明顯的訊號，但作為代價，網路管理員用於管理通訊的工具也相應減少。

如何在 Chrome、Edge 和 Firefox 中啟用 DoH

雙手在筆記型電腦上打字，螢幕上顯示網路安全圖形，代表瀏覽器中的衛生部設定。

在現代瀏覽器中啟用網域名稱系統 (DNS) 通常很簡單，尤其是在基於 Chromium 或 Firefox 的瀏覽器中。雖然有些瀏覽器的高級設定選單中可能隱藏著此選項，但實際上它一直都存在。在進行任何變更之前，請務必了解瀏覽器僅保護自身的 DNS 查詢：如果裝置上的其他應用程式未在系統層級進行配置，則它們可能仍使用不同的 DNS 系統。

  使用不同顯示卡運行《生化危機：安魂曲》的性能

Google Chrome

在 Chrome 瀏覽器中，快捷方法是輸入 chrome://flags/#dns-over-https 在地址欄中。 這樣就能直接進入 Chrome 的實驗性功能或功能頁面。你會看到一個名為「安全 DNS 查詢」的選項已選取；點擊標有「預設」的下拉式選單，然後選擇「啟用」。之後，你需要重啟瀏覽器才能使變更生效。

微軟邊緣

在基於 Chromium 的 Edge 瀏覽器中，該過程幾乎完全相同。 開啟瀏覽器並輸入 edge://flags/#dns-over-https 在搜索欄中進入 Edge 瀏覽器的「設定」頁面，即可看到「安全 DNS 查詢」選項。將“預設值”變更為“啟用”，並在提示時重新啟動瀏覽器。

Mozilla Firefox瀏覽器

在 Firefox 中，無需進入「實驗性功能」設定。點選右上角的選單按鈕，然後選擇「選項」。在「一般」部分，捲動到最底部，點選「網路設定」。在彈出的視窗中，勾選「啟用 HTTPS 上的 DNS」旁的核取方塊。之後，您可以選擇 Cloudflare 和 NextDNS 等服務供應商，透過 HTTPS 進行加密。

DNS over TLS (DoT)：另一種加密路徑

DNS over TLS（簡稱 DoT）是另一種保護 DNS 查詢的方式。它不使用 HTTPS，而是透過 TCP 連線和標準連接埠 853 使用 TLS 加密。 TLS與 HTTPS 的安全基礎相同，因此其原理類似：建立一個加密隧道，只有連接雙方才能解密和處理資訊。這使得中間人攻擊更加困難，並防止第三方讀取或篡改查詢。

DotT 具有諸多優勢，尤其與不提供任何安全措施的傳統 DNS 相比。加密技術可以防止網路犯罪分子攔截請求，並能有效抵禦某些審查措施。然而，它要求客戶端和伺服器都具備相容性。雖然有些服務提供者提供相容的伺服器，但在桌上型電腦或筆記型電腦上使用通常需要安裝額外的軟體；而從 Android 9 開始，Android 系統已經整合了 DotT 功能。 Windows 和 Linux 系統也有相應的解決方案，但它們的易用性可能不如使用者預期。

許多資料保護專家批評DoT使用單一且易於識別的端口，認為這是其許多缺點之一。雖然無法得知使用者正在造訪哪個網站，但卻可以偵測到DNS流量。對某些網路管理員來說，這很有用，因為它能讓他們掌握網路活動的全貌；而對其他管理員來說，這則訊號他們寧願隱藏。此外，DoT的普及程度遠不及傳統DNS，其伺服器端應用也有限。人們擔心，少數幾家公司會日益集中DNS查詢，從而可能形成某種國際壟斷。

衛生部與交通部：保護同一件事的兩種方式

DoH 和 DoT 的主要區別在於連接埠以及流量偽裝方式。 DoT使用其專屬端口 853，而 DoH 使用 443 端口，並與普通的 HTTPS 連接混為一談。這一看似微小的差異引發了廣泛的討論。從隱私角度來看，DNS 查詢與其他流量的不可區分性是一項優勢：如果它們不被識別，就不容易被操縱。然而，從網路管理角度來看，控制權的喪失使得安全或過濾策略的實施變得更加困難。

從本質上講，存在著兩種不同的願景。網路工程任務小組 (IETF) 是眾多網路標準的製定者，它支援 DoT（隱私保護），而Google和 Mozilla 基金會則大力推廣 DoH（隱私保護）。這兩種技術並非相互對立，而是代表了對隱私、網路可見度和中介機構角色的不同理解。選擇哪一種取決於需要保護的內容以及網路的管理者。

DoH 與 VPN：它保護的是問題本身，而不是整個旅程。

使用平板電腦和 VPN 應用程式的用戶，比較 DoH 與 VPN 的隱私保護效果。

在討論隱私問題時，DoH 和 VPN 經常被提及，但它們的功能並不相同。 DoH保護的是名稱查詢；而 VPN 保護的是資料的傳輸路徑。最簡單的理解方式是，DoH 就像把敏感問題裝進一個密封的信封裡，而 VPN 則讓整個資料傳輸過程先經過一條私密的隧道，然後再回到公共道路上。兩者都能提升隱私保護，但只有 VPN 能夠全面保護手機、平板電腦和電腦的流量。

網站載入之前，DNS 會做什麼？

在瀏覽器載入網站之前，您的裝置需要知道其位置。 DNS的工作原理類似於電話簿，將網站名稱轉換為 IP 位址。這個過程無時無刻不在發生：當您打開網頁、啟動應用程式、更新電子郵件或播放影片時。大多數情況下，這個過程悄無聲息地進行，您不會注意到，這固然方便，但也容易讓人忽略其隱私問題。傳統的 DNS 查詢沒有加密，因此您的網路服務供應商、您的雇主、您的學校、咖啡館的 Wi-Fi 或飯店網路都可以看到您的裝置正在嘗試存取哪些網域。他們雖然看不到 HTTPS 頁面的完整內容，但確實可以大致了解您的網路活動。

DNS 查詢並不會洩漏你瀏覽過的所有頁面或你在表單中輸入的所有內容，但網域清單卻可能暴露你的習慣、興趣、工作工具、健康研究或金融服務。正因如此，加密 DNS 已成為實用的隱私保護功能。它雖然不會洩露所有訊息，但其洩漏的內容遠遠超出許多人的想像。

衛生部隱瞞了什麼，又揭露了什麼？

DoH 透過 HTTPS 發送 DNS 查詢，HTTPS 是安全網站使用的加密協定。請求從您的裝置發出時是加密的，並到達支援該標準的解析器。在公共 Wi-Fi 網路上，這可以有效防止網路營運商無意中讀取您的查詢。如果您的網際網路服務供應商管理 DNS，切換到 DoH 解析器可以防止他們以通常的方式看到這些查詢。此外，如果網路篡改名稱解析結果，加密的 DNS 可以減少某些形式的竄改。

  BSD 發行版完全指南：Unix 的遺產

現在，DoH 隱藏的是網域查詢，而不是整個通訊過程。它或許能阻止一些觀察者清楚地看到網域查詢，但並不會將你的整個網路連線變成加密隧道。一旦設備獲知了 IP 位址，連接的其餘部分就會按照正常路徑進行，除非有其他隱私工具更改了路徑。 DoH 不會對你連結的網站、應用程式或服務隱藏你的真實 IP 位址，也不會讓你看起來像身處其他城市或國家。如果你登入了某個帳戶，該服務仍然知道是你本人。如果瀏覽器有 cookie、已儲存的會話、廣告識別碼或可辨識的指紋，DoH 也不會刪除這些訊號。

除非在系統層級進行配置且應用程式遵循該設置，否則 DoH 並不能保護所有應用程式。例如，一個瀏覽器可能使用安全 DNS，而同一裝置上的另一個應用程式可能使用不同的 DNS 路徑。有些應用程式管理自己的網絡，並且並不總是與系統或瀏覽器設定保持一致。因此，DoH 可能會造成一種完全安全的錯覺：它提高了 DNS 查詢的隱私性，但無法像 VPN 那樣保護檔案傳輸、即時通訊、視訊通話、遊戲連線、後台同步或串流應用程式。

筆記型電腦上有安全掛鎖圖標，象徵在衛生部的支持下，您可以安全地私密地瀏覽網頁。

VPN能保護哪些內容，又無法隱藏哪些內容？

VPN 保護的是您網路存取的不同面向。它會在您的裝置和 VPN 伺服器之間建立一條加密隧道，將您的網路流量路由到該伺服器。您的網路服務供應商或本地 Wi-Fi 網路看到的是與 VPN 伺服器的加密連接，而不是您連接的每個網站和服務的清晰視圖。此外，VPN 還會更改網站和應用程式看到的公共 IP 位址：目標網站看到的不是您的家庭或行動電信商的 IP 位址，而是 VPN 伺服器的 IP 位址。這可以減少基於位置的追踪，幫助您繞過某些 ISP 的隱私設置，並使使用公共 Wi-Fi 更加安全。

功能全面的 VPN 可保護瀏覽器、串流應用程式、電子郵件用戶端、雲端備份工具、即時通訊應用程式、遊戲和後台服務。正確配置後，它還可以將 DNS 請求路由到加密隧道，因此進行 DNS 洩漏測試非常重要。話雖如此，VPN 並非萬能。如果您登入社群網路、電子郵件帳號、串流服務或線上商店，該服務仍知道您的身分。它可以隱藏您的原始 IP 位址，但無法匿名化您的登入資訊。同樣，您直接發送的任何內容也存在同樣的問題：您的姓名、電子郵件地址、付款資訊、收貨地址、照片或訊息。

Cookie 和瀏覽器指紋仍然至關重要。應用程式可以透過廣告識別碼、權限、位置存取、藍牙掃描、附近 Wi-Fi 名稱和掃描工具等方式造成類似的問題。惡意軟體是另一個棘手的難題，因為它甚至可以在資料到達 VPN 通道之前就將其捕獲。簡而言之，VPN 可以隱藏和加密大量活動，但它並不能掩蓋所有的數位指紋。

DoH 和 VPN 可以同時使用。

是的，它們可以結合使用，但理想的設定取決於裝置、瀏覽器和 VPN 應用程式如何處理 DNS。在很多情況下，最簡單的解決方案就是讓 VPN 處理 DNS。一個好的應用程式應該透過加密隧道發送 DNS 查詢，這樣你的 ISP 就不會直接收到這些查詢。這樣，你就可以在 VPN 連線中獲得 DNS 隱私保護，而無需單獨調整瀏覽器設定。

當瀏覽器使用自身的網域授權 (Domain Authority，DoH) 配置，而 VPN 嘗試在系統層級管理 DNS 時，就會出現問題。雖然可能不會發生任何故障，但確實會造成混亂：您可能認為所有查詢都通過 VPN，但實際上，瀏覽器會將部分查詢傳送到其他解析器。這時，DNS 洩漏測試就派上用場了。如果在連接 VPN 後，您看到的是 ISP 的 DNS 伺服器，則表示某些功能未如預期運作；如果看到的是與 VPN 關聯的伺服器，則設定很可能運作正常。

何時 DoH 就足夠了，何時建議使用 VPN？

如果您主要關注的是瀏覽器中 DNS 查詢的基本隱私，那麼 DoH 就足夠了。在受信任的家庭網路中，啟用安全 DNS 可以減少明文洩露，而無需您更改位置或保護所有應用程式。在有 DNS 過濾或篡改風險的網路中，它也很有用，因為透過 HTTPS 傳輸資料會大大增加被檢查或修改的難度。但這並不意味著它能繞過所有限製或完全防審查，但它比未加密的 DNS 有了顯著的改進。此外，它非常輕量級：您無需選擇 VPN 伺服器或大幅更改路由，通常也不會感覺到速度有明顯變化。

當您需要裝置級保護，而不僅僅是DNS查詢時，VPN是最明智的選擇。這包括機場、飯店、學校、共享辦公空間、咖啡館和租賃住宿等場所。在共享網路中，您無法得知誰控制著路由器、還有哪些設備連接，或者是否有人試圖攔截流量。如果您不希望您的網路服務供應商 (ISP) 建立您的瀏覽習慣檔案，VPN也能提供協助：即使HTTPS保護了頁面內容，網路元資料仍然可以揭示有用的模式。旅行是另一個明顯的例子：VPN可以讓您的連線更加穩定，保護您在陌生網路中的安全，並讓網站看到VPN伺服器的位置，而不是您臨時的本地連線。

Google 公共 DNS DoH API 的技術細節

Google 公共 DNS 提供兩種不同的 DoH API。一種是為 RFC 8484 設計的，接受 GET 和 POST 請求，地址為 https://dns.google/dns-query；另一種是 JSON API，僅支援 GET 請求，地址為 https://dns.google/resolve。此外，還有一個 Web 介面 https://dns.google/，可在瀏覽器中顯示 JSON 結果，但它並未實現完整的 API。請勿將此介面與 API URL 或 https://dns.google/query 混淆。該服務不支援不安全的 HTTP URL，Google 的公共 DNS64 服務也支援 DoH，但僅支援 IPv6。 Google 的安全傳輸文件包含 curl 範例以及關於 TLS、DoT 和 DoH 的詳細資訊。

  記憶體全面指南：類型、功能及選擇方法

可用的 HTTP 方法

GET 方法可以降低延遲，因為它快取效率更高。 RFC 8484 GET 請求必須包含一個 `?dns=` 參數，其中包含 Base64Url 編碼的 DNS 訊息，而且它是 JSON API 唯一支援的方法。 POST 方法也僅在 RFC 8484 中可用，它使用二進位 DNS 訊息，請求和回應體中都包含 `application/dns-message`。 HEAD 方法目前不受支持，會回傳 400 Bad Request 錯誤。其他方法會傳回 501 Not Implemented 錯誤。

狀態碼和錯誤

API 會傳回幾個值得了解的 HTTP 狀態碼。 200 OK 表示 HTTP 解析和與 DNS 解析器的通訊成功；回應體可以是二進位 DNS 回應或 JSON，取決於端點、Accept 標頭和 GET 參數。注意：HTTP 錯誤也可能是 DNS 解析失敗，因此建議檢查 DNS 回應狀態碼，例如 JSON 的「Status」字段，以尋找 SERVFAIL、FORMERR、REFUSED 或 NOTIMP 等錯誤。

  • 301 永久遷移： 用戶端必須在 Location 中指定的 URL 處重試請求。如果原始請求是 POST 請求，則只有當新 URL 指定了 DNS 參數時，才應使用 GET 請求重試；否則，必須使用 POST 請求重試。也可能出現 302、307 和 308 狀態碼，DoH 用戶端必須處理所有這四個狀態碼。永久的 301 和 308 狀態碼可以無限期快取。收到 307 或 308 狀態碼的 POST 請求必須始終使用 POST 請求重試。
  • 400 錯誤請求： 解析 GET 參數或無效 DNS 請求訊息時出現問題。大多數無效 DNS 訊息會收到帶有 FORMERR 的 200 OK 回應，但對於缺少問題部分、包含指示回應的二維碼或包含無意義程式碼組合的不可讀訊息，則會發生 HTTP 錯誤。
  • 413 有效載荷過大： POST RFC 8484 請求的正文超過了 512 位元組的最大訊息大小。
  • 414 URI 過長： GET 查詢標頭過大或 dns 參數超過 512 位元組。
  • 415 不支援的媒體類型： POST 請求體缺少內容類型標頭 application/dns-message。
  • 429 請求過多： 在給定時間內發送的請求過多。用戶端必須等待 Retry-After 標頭中指定的時間。
  • 500 內部伺服器錯誤: 衛生部服務內部錯誤。
  • 501 未實施： 目前僅實現了 GET 和 POST 請求；其餘請求均傳回此錯誤。
  • 502錯誤的網關： DoH 服務無法與 Google 公用 DNS 解析器通訊。嘗試使用其他位址可能可行，但更有效的備用方案是嘗試其他 DoH 服務，或切換到使用 UDP 或 TCP 協定的傳統 DNS 服務，位址為 8.8.8.8。

隱私和效能方面的最佳實踐

DoH 應用程式開發者應限制 HTTP 標頭的使用。 Cookie 、User-Agent 和 Accept-Language 等標頭可能會洩露客戶端實作訊息，導致去匿名化。建議僅發送 DoH 所需的標頭：Host、Content-Type（用於 POST 請求）以及必要時的 Accept。 User-Agent 標頭應包含在開發或測試版本中。此外，建議使用 EDNS 填滿選項將查詢縮短到常用長度，從而增加流量分析的難度。 HTTP/2 填充雖然可行，但與 EDNS 填充不同，它不會在 DoH 伺服器回應中產生填充。

RFC 8484 中的 POST 方法僅應在對隱私要求較高的應用程式或瀏覽器模式下使用。使用 POST 會降低快取容量並可能增加延遲，因此通常不建議使用。但是，對於希望防止旨在發現用戶最近訪問過的網域的 Web 應用程式同步攻擊的應用程式來說，減少快取大小可能是明智之舉。 HTTPS 方法也具有諸多實際優勢：HTTPS API 廣泛可用且受支持，簡化了實現；HTTPS 服務使 Web 應用程式能夠存取所有類型的 DNS 記錄，從而避免了瀏覽器或作業系統 API 通常僅限於主機到地址查找的限制；使用 QUIC 透過 UDP 實現 HTTPS 的客戶端可以避免 TCP 中常見的行頭阻塞等問題。如果您遇到錯誤或想要要求新功能，請透過常用管道回報與 DoH 相關的問題。

關於 DoH 和 VPN 的常見問題

最常見的問題之一是，在使用 VPN 的情況下，是否仍有必要使用 DoH。理論上可行，但最實際的做法通常是讓 VPN 處理 DNS，並透過洩漏測試驗證查詢是否通過正確的通道。如果瀏覽器發送自己的查詢，而 VPN 發送的查詢卻來自另一個方向，那麼你可能會遇到一些意想不到的問題。

另一個常見問題是 DoH 是否能阻止您的網路服務供應商 (ISP) 看到您造訪的網站。 DoH 可以對許多觀察者隱藏 DNS 查詢，但它不會刪除所有元資料或隱藏您的 IP 位址：您的 ISP 仍然可以看到您連接的 IP 位址和其他網路資訊。為了獲得更全面的保護，您需要使用 VPN 或結合多種隱私保護措施。

此外，也值得探討 DomainHost (DoH) 在公共 Wi-Fi 環境下是否足夠安全。它可以幫助防止網路業者輕易讀取你的 DNS 查詢，但並不能保護整個連接或所有應用程式的流量。在機場、飯店和咖啡館等場所，使用 VPN 通常更為全面，尤其是在你不清楚路由器控制者是誰或是否有其他人連線的情況下。

網域名稱系統 (DoH) 和 VPN 並非直接的競爭對手，而是功能不同的工具。 DoH加密網域尋找過程，降低該環節的暴露風險；VPN 則加密裝置與伺服器之間的路徑，並變更目標使用者看到的 IP 位址。兩者都不能讓你完全隱身：帳戶、Cookie、瀏覽器指紋、應用權限、惡意軟體以及任何你直接分享的資料仍然可以識別你的身份。但這並不意味著它們毫無用處。這只是意味著它們各有其用。 DoH 保護位址尋找過程；而 VPN 則保護你資料傳輸路徑的更多環節。