開啟 3 天免費試用
註冊即可免費體驗全部高級功能。
*只限新用戶；每位用戶只可獲得一次試用。
甚麼是加密 DNS 流量？DoH、DoT 與網絡攔截警告
Marcus Reid
2026年4月6日· 更新於 2026年10月9日· 7 分鐘讀完
加密 DNS 流量保護裝置與解析器之間的查詢交換。DNS 協助將主機名稱轉成地址，DoH 和 DoT 則為這個過程加入加密傳輸。它們不會隱藏瀏覽活動的所有痕跡，亦不能消除對解析器的信任要求。［1］［2］［3］
關鍵要點
- DNS 加密保護特定連線，不代表所有活動資料都不可見。
- DoH 使用 HTTPS；DoT 使用 TLS，預設連接埠為 853。
- iOS 警告描述私隱限制，不能單憑提示斷定有特定攻擊者。
調整 DNS 時，亦應配合帳戶、裝置與網絡安全檢查清單。
加密 DNS 流量保護甚麼？
明文 DNS 可能向查詢路徑上的觀察者透露所要求的域名。加密能減少這種暴露；防範主動攻擊時，驗證解析器身份同樣重要。解析器本身仍會收到查詢，IP 地址和其他連線資料亦可能在別處可見。［2］［3］
DNS 傳輸保護與網頁本身的 HTTPS 加密屬不同層面。不能因為出現 DNS 警告，便斷言所有網頁內容或密碼都在被讀取。
DoH 與 DoT 有甚麼分別？
| 項目 | DoH | DoT |
|---|---|---|
| 規範 | RFC 8484 ［2］ | RFC 7858 ［3］ |
| 傳輸方式 | 透過 HTTPS 承載 DNS | 透過 TLS 承載 DNS |
| 常用連接埠 | HTTPS 預設連接埠 443 | 預設連接埠 853 |
| 部署時檢查 | 哪個應用程式使用哪個解析器 | 解析器、身份驗證模式與網絡政策 |
DoH 可以共用 HTTPS 基礎設施，但這並非無法被過濾的保證。DoT 的專用預設連接埠則方便獨立實施連接埠政策。兩份標準都不能證明某個協議始終較快：連線重用、具體實作和解析器位置都會影響結果。
即使 DNS 已加密，本地網絡仍可能看到解析器連線的 IP 地址、交換時間及流量大小。其後連接網站時，目的地 IP 亦可能可見；共用 IP 不足以還原確切的頁面 URL。DoH 及 DoT 不加密全部應用程式流量，因此 DNS 私隱與後續連線私隱需要分開判斷。［6］
解析器信任仍存在於哪裏？
應用程式可能詢問作業系統的解析器，亦可能直接聯絡自己的解析器。所選遞迴服務可以從快取回答、轉送請求，或查詢權威 DNS 層級。加密裝置到解析器這一段，不會自動加密之後的每次交換。說明觀察者能看到甚麼之前，要先找出加密連線在哪裏終止。［6］
圖中分開三次交換：客戶端透過 DoH 或 DoT 詢問遞迴解析器，解析器按需要取得 DNS 資料，客戶端其後透過 HTTPS 連接網站。快取答案可能省去新的上游查詢。這是協議模型，不是這部裝置的測量結果，亦不表示所有解析器都會加密上游交換。
遞迴解析器能看到提交給它的名稱，並可能把請求與可取得的客戶端資料連結。加密傳輸轉移信任邊界，不消除它。檢查營運者的保留與處理政策，以及服務有沒有把查詢轉送至其他供應商。熟悉的供應商名稱或一次成功的 TLS 連線，本身不能證明沒有保存記錄。［6］
DNSSEC 回答另一個問題：已簽署 DNS 資料能否按信任鏈通過驗證。它提供來源認證及完整性，不提供查詢保密。執行驗證的解析器可以同時使用 DNSSEC 及 DoH 或 DoT，但連線加密不代表驗證已啟用，未簽署域名亦不會因請求使用 HTTPS 就變成已簽署。兩種機制都不認證網站安全。［5］
加密 DNS 包含廣告攔截嗎？
DoH 或 DoT 沒有附帶預設攔截政策。解析器可能過濾特定名稱，亦可能不作過濾、回傳一般答案。這是加在傳輸上的服務政策。加密解析器不一定攔廣告，過濾解析器亦不一定加密客戶端連線。［2］［3］
本機過濾器只能看到到達它的查詢。瀏覽器使用獨立 DoH 供應商時，改路由器 DNS 地址未必影響該瀏覽器。反過來，本機過濾器亦可以把獲准查詢轉送到加密上游，同時保留自己在路徑中的位置。先核對真正的客戶端、過濾點及上游服務，再解釋廣告變化，不能直接把它當作加密證據。
域名過濾亦不能選擇性刪除與正常內容共用主機名稱的廣告。解析器政策可能阻擋整個名稱，但 HTTPS 頁面內容屬另一層。廣告有沒有出現、空廣告位有沒有消失，都不能判斷傳輸保護有沒有生效。
哪些證據說明使用了預期路徑？
記錄被檢查的應用程式、其解析器政策、系統解析器設定及 VPN 路由規則。分清設定偏好與觀察到的行為：應用程式可能使用另一解析器，快取答案亦可能省去新查詢。比較設定時，在同一應用程式內重複同一個無害查詢；同時換應用程式及網絡，就失去了這項對照。［6］
DNS 測試頁可以識別聯絡其測試基建的遞迴服務。但只憑解析器名稱，不能看出裝置到解析器使用了明文、DoH、DoT 還是 VPN 隧道。解析器變了，不證明其他應用程式都變了；解析器沒變，亦不證明加密失敗。要判斷傳輸，應把結果與客戶端的公開設定說明結合，並在獲授權時核對相關連線或路由證據。
| 觀察 | 可以支持的結論 | 還需檢查甚麼 |
|---|---|---|
| 一個瀏覽器顯示不同解析器 | 該測試查詢到達另一遞迴服務 | 系統及其他應用程式的涵蓋範圍 |
| 解析器名稱沒有變化 | 測試仍觀察到同一服務 | 傳輸及 VPN 路由 |
| 改設定後頁面能開啟 | 這次請求成功 | 快取、路徑及私隱政策 |
| 內部主機名稱無法解析 | 新路徑可能缺少私有 DNS 資料 | 預期分流 DNS 及擁有人設定 |
測試自己有權修改的設定前，保存原值，每次只改一個變數。所需內部名稱失效時，透過所屬工具恢復原值，並向管理員確認支援的路徑。不要只為消除警告，就用公共供應商取代機構 DNS 政策。
iOS 的加密 DNS 警告代表甚麼？
Apple 說明，DNS 解析仍可能正常運作，但查詢的名稱未經加密，因此可能被網絡內的觀察者看到。警告本身不能定位原因，亦不證明正發生惡意監察。更改設定前，先確認受影響的是哪個網絡，以及由誰管理。［4］
使用多人共用的公共 Wi-Fi時，應分清場所登入頁面與私隱設定。不要為了消除提示便安裝不明描述檔或憑證。
排查 iOS 警告的四項檢查
以下檢查按所列協議及 Apple 文件整理，未進行完整端到端裝置實測。只修改自己擁有或獲准管理的設定。
1. 記錄受影響的連線
記錄網絡名稱、提示原文，以及轉到另一條可信連線後是否仍會出現。比較結果有助分清特定網絡問題與裝置層面的設定問題。
2. 從官方支援的維護操作開始
Apple 建議檢查軟件更新和路由器安全設定、重新啟動裝置與路由器，並忽略後重新加入 Wi-Fi。只重啟自己有權管理的路由器，忽略網絡前確認能夠重新連線。這些是排查動作，並非必定有效的修復。［4］
3. 核對網絡擁有人的設定
自己的路由器應按廠商說明操作，並先保存原有設定。受管理網絡應向管理員確認 DNS 政策。不要只憑未經證實的「記憶體錯亂」說法，便關閉安全控制或重設全部網絡設定。
4. 驗證實際受保護的路徑
VPN 可以在隧道內承載 DNS，但應用程式自設解析器和路由仍須分別檢查。如果網絡政策容許，AethoVPN 可為這項對照提供加密轉送。iPhone 或 iPad 應透過官網設定精靈取得客戶端設定，需要 Pro 或 Premium。
連線前後用同一瀏覽器重複同一測試，再核對該客戶端的 DNS 及路由設定。單憑連線圖示或網絡供應商解析器名稱，都不能證明每條查詢進入隧道，亦不能證明查詢繞過隧道。這不會修復路由器，亦不保證受限網絡可用。新用戶可以用電郵註冊並開始 3 天 Pro 試用。
總結
- 分清 DNS 傳輸保護、解析器信任和網頁內容加密。
- 按實際設定比較 DoH 與 DoT，不依賴籠統的速度或隱蔽性保證。
- 結合網絡擁有人的資料和官方裝置指引排查 iOS 警告。
常見問題（FAQ）
加密 DNS 能向 ISP 隱藏所有活動嗎？
不能。它保護加密路徑上的 DNS 交換，但其他連線資料仍可能可見。解析器本身亦仍然接收你要求解析的名稱。［2］［3］
Smart DNS 能代替 DoH 或 DoT 嗎？
Smart DNS 這個名稱不能證明傳輸已加密。應檢查服務實際使用的解析器協議及設定，不要將路由功能視作 DNS 私隱保護的證據。
可以忽略 iOS 警告嗎？
連線仍能使用，不代表 Apple 所說的私隱限制已經消失。應檢查網絡情況；若這種暴露不適合目前任務，可考慮轉用可信的連線。［4］
瀏覽器內的 DoH 設定會涵蓋所有應用程式嗎？
不能直接這樣推斷。應分別檢查瀏覽器、系統和其他應用程式的設定範圍；某個應用程式選用加密解析器，不證明整部裝置都受保護。
為何 DoT 可以按連接埠被過濾？
DoT 通常使用 853 連接埠，防火牆可以獨立控制這類連線。使用其他連接埠需要客戶端與伺服器共同設定，可用性仍取決於網絡政策。［3］
加密 DNS 會自動攔廣告嗎？
不會。DoH 和 DoT 規定受保護的傳輸，不規定攔截清單。應檢查解析器獨立的過濾政策，以及應用程式查詢是否真正到達該服務。
DNSSEC 與加密 DNS 是同一回事嗎？
不是。DNSSEC 驗證已簽署 DNS 資料；DoH 或 DoT 保護傳輸連線。兩者可以配合，但不會自動啟用對方，亦不保證頁面內容安全。［5］
**免責聲明：**本文提供一般技術資訊，使用時應遵守所在網絡與裝置的管理政策。
來源:
- Cloudflare: What is DNS?
- IETF: RFC 8484 - DNS Queries over HTTPS (DoH)
- IETF: RFC 7858 - Specification for DNS over Transport Layer Security (TLS)
- Apple Support: Recommended settings for Wi-Fi routers and access points
- IETF: RFC 4033 - DNS Security Introduction and Requirements
- IETF: RFC 9076 - DNS Privacy Considerations
Sources checked 2026 年 10 月 9 日。
延伸閱讀:
