網誌 - 寧屏技術分享與產品更新

• 寧屏去廣告：基於DNS的智能廣告攔截方案
• 阿里雲 DNS 免費版限速：免費午餐的終結與 DNS 自主權的再思考
• 從兩次 1.1.1.1 事故看家庭 DNS 韌性建設
• DoH 與 DoT 技術對比分析
• DNS 私隱防護與用戶畫像防範策略
• 深度解析：寧屏DNS代理功能，突破網絡限制實現私隱保護
• AdGuardPrivate的更名公告
• 增加了DDNS功能
• 更好的支援ECS
• 寧屏 - 基於AdGuard Home的增強版DNS服務
• 全面支援 HTTP/3 協議
• 推出自訂用戶端名稱功能
• 廣告攔截的必要性：保護數碼時代的注意力與私隱
• 服務資源優化策略說明
• 基礎版內存上限調整
• 隨時為您提供支援服務
• 如何設定專用連結
• 全新升級——增強版廣告攔截規則
• 試用版服務詳情

寧屏去廣告：基於DNS的智能廣告攔截方案

在當今數碼化時代，廣告已成為互聯網生態的重要組成部分，但過多的廣告不僅影響用戶體驗，還可能帶來私隱洩露風險。寧屏（NullPrivate）作為一款專注於私隱保護的DNS服務，採用了與AdGuard Home類似的DNS過濾技術，為用戶提供高效的廣告攔截解決方案。

寧屏去廣告的工作原理

寧屏的廣告攔截功能基於DNS（域名系統）過濾技術，其工作流程如下：

flowchart TB
    A[用戶設備] --> B{DNS查詢請求}
    B --> C[寧屏DNS伺服器]
    C --> D[查詢域名數據庫]
    D --> E{廣告或追蹤域名?}
    E -->|是| F[返回空地址或環回地址]
    E -->|否| G[返回正確IP地址]
    F --> H[阻止廣告載入]
    G --> I[正常瀏覽網站]

DNS請求監控

當您的設備嘗試瀏覽網站時，會首先向DNS伺服器查詢域名對應的IP地址。寧屏作為您的首選DNS伺服器，會接收並分析這些查詢請求。

智能過濾機制

寧屏維護著一個龐大的廣告和追蹤域名數據庫。當檢測到用戶嘗試瀏覽的域名屬於廣告或追蹤類別時，系統會立即攔截該請求。

高效響應

對於被攔截的請求，寧屏會返回一個空地址或本地環回地址（如127.0.0.1），從而阻止廣告內容的載入。對於正常的網站瀏覽請求，寧屏則會提供正確的IP地址，確保用戶可以正常瀏覽目標網站。

技術優勢

高效性

• 網絡層面攔截：在DNS解析階段就阻止廣告載入，無需等待網頁內容下載
• 毫秒級響應：本地化的DNS響應機制，幾乎不影響網頁載入速度
• 全設備保護：一次配置，保護網絡中的所有設備

精準性

• 多層次過濾：支援精確域名匹配、通配符規則和正則表達式
• 智能分類：將過濾規則按廣告、追蹤器、惡意軟件等分類管理
• 動態更新：定期從可信源獲取最新的過濾規則

私隱保護

• 無痕瀏覽：不記錄用戶瀏覽記錄，保護瀏覽私隱
• 減少數據洩露：阻止廣告商和追蹤器收集用戶數據
• 本地處理：大部分過濾工作在本地完成，減少數據外洩風險

與AdGuard Home的相似之處

寧屏在廣告攔截方面與AdGuard Home採用了相同的核心技術原理：

1. 基於DNS的過濾機制：兩者都通過攔截DNS查詢來阻止廣告域名解析
2. 過濾規則管理：都支援自定義過濾規則和黑白名單配置
3. 網絡範圍保護：都能為整個局域網提供廣告攔截服務
4. 開源社區支援：都受益於開源社區維護的過濾規則列表

用戶體驗優化

寧屏在設計上特別注重用戶體驗，確保廣告攔截功能既高效又不會對正常使用造成干擾：

透明化管理

• 提供詳細的攔截統計資訊，讓用戶了解防護效果
• 支援靈活的白名單配置，避免誤攔截重要網站
• 實時生效的規則更新，無需重啟設備

易用性設計

• 簡化配置流程，普通用戶也能輕鬆上手
• 提供多語言支援，滿足不同用戶需求
• 兼容各種網絡環境和設備類型
• 具備安全可靠的DNS伺服器支援

私隱保護

• 嚴格的私隱保護措施，保護用戶私隱
• 不收集用戶個人身份資訊
• 確保用戶數據安全

使用建議

為了獲得最佳的廣告攔截效果，我們建議用戶：

1. 合理配置規則：根據實際需求選擇合適的過濾規則列表
2. 定期檢查更新：確保過濾規則庫保持最新狀態
3. 關注攔截統計：通過統計數據了解廣告攔截效果
4. 及時調整白名單：將誤攔截的正常網站添加到白名單中

結語

寧屏通過先進的DNS過濾技術，為用戶提供了一個高效、精準且注重私隱的廣告攔截解決方案。我們致力於在保護用戶免受廣告騷擾的同時，確保不影響正常的網絡使用體驗。選擇寧屏，讓您的網絡環境更加清爽、安全。

在數碼時代，每個人都應該擁有一個乾淨、私密的網絡空間。寧屏正是為了實現這一目標而設計，幫助用戶重新掌控自己的數碼生活。

阿里雲 DNS 免費版限速：免費午餐的終結與 DNS 自主權的再思考

2026 年 5 月 14 日，阿里雲發佈了一則低調但影響深遠的產品公告：自 6 月 24 日起，雲解析 DNS 公網權威解析免費版新增單域名日解析量限制，上限為 10 萬次，超額將觸發動態限速——延遲、丟包，或兩者兼有¹。公告措辭克制，「絕大多數免費用戶日均解析量遠低於此閾值」，似乎一切風平浪靜。

但這條公告的真正分量，不在技術參數本身，而在它所標記的一個轉折點：中國主流雲廠商的免費 DNS 服務，正從「預設夠用」轉向「需要算賬」的階段。 對於依賴免費 DNS 的獨立開發者、個人站長和中小團隊而言，這不是一次孤立的價格調整，而是整個 DNS 服務商業邏輯的重新定價。

10 萬次到底夠不夠：解析量的真實構成

官方說「絕大多數用戶不受影響」，這句話在統計意義上可能成立——如果只看中位數。但問題在於，一個正常運行的服務站點，其 DNS 解析量受多種因素疊加，10 萬次/日並非一個可以高枕無憂的閾值。

影響單域名解析量的核心變量包括：

子域名數量。 限額是「單域名」，但這裡的「單域名」指主域名及其所有子域名的解析量之和¹。一個站點如果使用 www、api、cdn、static 等多個子域名，每個子域名的解析都會被計入總額。一個中等複雜度的 Web 應用，解析量輕鬆翻幾倍。

TTL 與實際緩存行為。 理論上，遞歸解析器會按照 TTL 緩存解析結果，從而減少回源查詢。但現實是：國內運營商級遞歸解析器普遍存在不嚴格遵守 TTL 的情況，部分甚至會在 TTL 過期前提前刷新，或忽略過長的 TTL 值自行縮短。這意味著實際回源查詢次數可能遠超理論值。

爬蟲與掃描器。 搜索引擎爬蟲、安全掃描器、SEO 工具等會持續觸發 DNS 解析。這些流量不產生頁面訪問，但同樣消耗解析配額。

移動端與 IoT 設備。 移動 App 的 DNS 緩存行為與瀏覽器不同，部分實現每次冷啟動都會重新解析。IoT 設備的 DNS 實現更是良莠不齊，大量設備根本不緩存或緩存時間極短。

一個有實際案例可供參照：獨立博客 yijile.com 在公告後自查發現，其日均解析量超過 30 萬次，接近限額的 300%²——而該站點的頁面訪問量遠未達到同等量級。這說明 DNS 解析量與網站 UV/PV 之間存在顯著的非線性關係，用「日訪問量」來估算「日解析量」並不可靠。

flowchart TB
    A[域名解析請求] e1@--> B{請求來源}
    B e2@-->|瀏覽器| C[TTL 內緩存命中, 不回源]
    B e3@-->|移動 App| D[冷啟動重新解析, 頻繁回源]
    B e4@-->|爬蟲/掃描器| E[持續回源, 大量消耗]
    B e5@-->|IoT 設備| F[緩存行為不可控, 頻繁回源]
    B e6@-->|遞歸 DNS 不遵守 TTL| G[提前刷新, 回源量遠高於理論值]

    C e7@--> H[計入配額: 少量]
    D e8@--> I[計入配額: 大量]
    E e9@--> I
    F e10@--> I
    G e11@--> I

    H e12@--> J[總解析量 ≤ 10 萬/日]
    I e13@--> K[總解析量 >> 10 萬/日]

    J e14@--> L[不受影響]
    K e15@--> M[觸發限速: 延遲/丟包]

    classDef source fill:#E3F2FD,stroke:#1565C0,color:#0D47A1
    classDef good fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20
    classDef bad fill:#FFEBEE,stroke:#C62828,color:#B71C1C
    classDef animate stroke:#EF6C00,stroke-width:2px,stroke-dasharray: 9 5,stroke-dashoffset: 900,animation: dash 25s linear infinite

    class A,B source
    class C,H,J,L good
    class D,E,F,G,I,K,M bad
    class e1,e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13,e14,e15 animate

限速背後的商業邏輯：免費的終點是限速

阿里雲並非第一家對免費 DNS 設置門檻的廠商，也不會是最後一家。

從商業角度看，免費版 DNS 對雲廠商而言是一個「負資產」——它消耗着基礎設施資源（全球解析節點、頻寬、運維人力），但除了品牌曝光和用戶入口價值外，幾乎不產生直接收入。當用戶規模較小時，這種投入可以視為獲客成本；但當免費用戶量級膨脹到影響全局穩定性時，限速就成了必然選擇。

公告中提到的「平台承載的解析總量不斷攀升」和「避免局部流量突增或異常查詢影響正常業務」，翻譯成商業語言就是：免費用戶的超量使用已經開始侵蝕付費用戶的 SLA 保障。

這個邏輯與 Cloudflare、Google Cloud DNS 等國際廠商的路徑一致：先用免費服務建立用戶基礎和市場認知，再逐步收緊免費額度、引導商業轉化。不同的是，阿里雲選擇了更直接的「硬限速」而非「超額後按量計費」——這恰好反映了國內雲服務市場的競爭格局：當免費用戶遷移成本足夠低時，廠商更傾向於直接切走超量用戶，而非通過精細化計費來轉化。

國內替代方案：誰還能免費扛得住

對於日均解析量可能超過 10 萬次的站點，遷移到替代 DNS 服務是現實選項。以下是當前國內主流免費 DNS 服務的核心維度對比：

騰訊雲 DNSPod 是目前信息最透明的替代選項，其免費版明確支持按運營商（電信、移動、聯通）、按地域（境內/境外）和搜索引擎專用線路的分區解析。對於需要區分國內外解析或運營商優化的站點，這是一個阿里雲免費版無法提供的差異化能力。

但需要警惕的是：今天沒有限速，不等於明天不會限速。 DNSPod 免費版同樣面臨用戶增長帶來的資源壓力，只是目前尚未達到觸發閾值。選擇替代方案時，不要把「當前沒有限制」等同於「永遠不會限制」。

遷移策略：不是換一個 NS 那麼簡單

DNS 遷移在技術上並不複雜——修改域名註冊商的 NS 記錄，等待全球遞歸解析器更新即可。但實際操作中有幾個容易被忽略的關鍵點：

記錄導出與格式兼容。 不同 DNS 服務商對記錄類型的支持程度不同。阿里雲支持的部分擴展記錄類型（如顯性/隱性 URL 轉發），DNSPod 和其他廠商可能以不同方式實現或不支持。遷移前需要完整導出所有記錄並逐條校驗。

TTL 的過渡期設計。 遷移 NS 時，新舊兩套權威 DNS 會在過渡期內並存（取決於舊 NS 記錄的 TTL）。最佳實踐是：先在目標平台配置好完全相同的記錄，驗證無誤後，再將 NS 切換到新平台。切換前將舊 NS 的 SOA 記錄 TTL 調低（如 300 秒），以縮短過渡窗口。

分區解析的策略遷移。 如果原來依賴阿里雲付費版的分區解析，遷移到 DNSPod 免費版可以直接複用線路配置；如果遷移到不支持免費分區解析的平台，則需要評估是否接受單一解析策略。

監控先行。 在完全切換之前，建立解析監控——持續從多個網絡環境（電信、聯通、移動）對關鍵子域名進行解析探測，確保遷移後解析結果和延遲都在可接受範圍內。

sequenceDiagram
    participant U as 用戶/運維者
    participant S as 源 DNS (阿里雲)
    participant T as 目標 DNS (如 DNSPod)
    participant R as 遞歸解析器

    U->>S: 1. 導出全部 DNS 記錄
    U->>T: 2. 在目標平台逐條創建記錄並校驗
    U->>T: 3. 從多網絡環境驗證解析正確性
    U->>S: 4. 降低 SOA TTL 至 300s，等待舊 TTL 過期
    U->>R: 5. 在域名註冊商處修改 NS 指向目標平台
    R->>T: 6. 遞歸解析器逐步更新至新 NS
    U->>T: 7. 持續監控解析延遲與正確性
    U->>S: 8. 確認遷移穩定後，刪除源平台記錄

更深一層：免費 DNS 服務的結構性困境

放在更長的歷史維度上看，阿里雲 DNS 免費版限速不是一個孤立事件，而是免費 DNS 服務模式的結構性問題浮出水面。

DNS 權威解析是一項「薄利多銷」的基礎設施服務——邊際成本極低，但穩定性和可用性要求極高。當一個免費服務承載的域名從十萬級增長到百萬級、解析量從億級增長到千億級，免費模式的可持续性就面臨根本性質疑：要麼限速分流，要麼降級服務質量，要麼轉付費。

雲廠商的困境在於，DNS 是最底層的互聯網入口——域名解析失敗意味著整個業務不可達，用戶不會區分「這是免費版所以服務質量差」，只會歸因於「阿里雲/騰訊雲不行」。這種「免費服務綁架品牌口碑」的壓力，是推動限速決策的關鍵因素。

對於站長和開發者而言，這件事的啟示不是「趕緊換到另一個免費平台」，而是：任何免費的、非自控的基礎設施依賴，都內置了一個過期時間。 今天阿里雲限速，明天可能是 DNSPod，後天可能是 Cloudflare Free Plan 調整條款。

結論

阿里雲 DNS 免費版限速 10 萬次/日，在絕對數值上並不苛刻，但它傳遞的信號比數值更重要：國內雲廠商的免費 DNS 紅利期正在收窄。

對於絕大多數日均解析量遠低於閾值的站點，什麼也不需要做。對於處於臨界線附近的站點，建議立即開啟解析量監控，了解自己的真實用量後再做決策。對於已經或即將超限的站點，DNSPod 免費版是當前最務實的遷移目標，但把 DNS 自主可控納入中長期規劃——無論是多供應商冗餘部署，還是自建權威 DNS（哪怕是輕量的 NSD 或 CoreDNS 實例），都值得認真考慮。

免費是暫時的，可控才是長期的。

從兩次 1.1.1.1 事故看家庭 DNS 韌性建設

很多用戶將 DNS 視為「填一個地址就完事」的基本設定，但 2024 及 2025 年兩次公開事故說明：解析器本身也會出故障，而且會直接放大至「網頁打唔開、App 無法上網、全家斷家斷網」嘅體感問題。

本文唔討論「邊間更好」，而係聚焦一件事：點樣將 DNS 由單點依賴改造成可觀測、可切換、可恢復嘅家庭級基礎設施。

兩次可核實事件：發生咗乜

先睇公開資料入面最關鍵嘅時間點（均為 UTC 時間，方便同官方時間線對齊）：

呢兩次事件有一個共通點：

• 用戶睇落去都係「DNS 唔工作咗」；
• 但底層原因完全不同（一次偏外部互聯網路由，一次偏服務內部變更）；
• 結論係一樣一樣嘅：單上游、單入口、單協議會將風險集中到一個點。

技術拆解：點解 DNS 會「睇落去全網壞咗」

當終端將唯一 DNS 指向一個不可用目標時，應用層通常會出現連鎖反應：

• 域名無法解析，表現為 timeout 或 SERVFAIL。
• 瀏覽器同 App 會反覆重試，導致「偶爾恢復、又再次失敗」嘅抖動體驗。
• 即使公網鏈路正常，用戶都會誤判為「寬頻壞咗」或「網站全部掛咗」。

flowchart LR
    A[手機/平板/電視/電腦] --> B[專用加密 DNS 入口 DoH/DoT]
    B --> C{策略層}
    C --> D[廣告/追蹤/惡意域名攔截]
    C --> E[家庭保護同防沉迷規則]
    C --> F[白名單同自訂規則]
    C --> G[主上游解析]
    C --> H[後備上游解析]
    G --> I[權威 DNS / CDN]
    H --> I
    C --> J[查詢日誌同攔截統計]

上面圖嘅重點唔係「多堆功能」，而係三件事：

• 路徑分層：接入層（DoH/DoT）同策略層（攔截/白名單）分開。
• 上游冗餘：主上游異常時，仍有後備解析路徑。
• 可觀測性：有日誌同統計，先可以判斷係誤攔截、上游問題，定係終端問題。

面向家庭網絡嘅落地方案

結合 jqknono 製作嘅 nullprivate/adguardprivate 服務，比較實用嘅一套做法係：

1. 使用專用加密 DNS 入口（DoH/DoT）

   • 目標係減少明文 DNS 暴露同本地網絡干擾。
   • 結合客戶端 ID/裝置識別，區分屋企唔同裝置。

2. 設定主上游 + 後備上游，避免單點依賴

   • 唔好將所有解析都押注單一個解析服務或一個前綴。
   • 結合分流策略，為唔同域名行唔同上游路徑。

3. 將「防廣告、防詐騙、防沉迷」放喺策略層統一管理

   • 廣告同追蹤域名攔截。
   • 惡意/釣魚域名攔截。
   • 針對小朋友裝置設定時段管理同內容攔截。

4. 保留誤攔截修正通道

   • 透過查詢日誌定位被攔截域名。
   • 快速加入白名單，避免長期影響正常業務。

5. 定期做「故障演練」

   • 人手臨時下線主上游，驗證後備鏈路有否生效。
   • 喺家庭網絡驗證關鍵 App（支付、網課、視像會議）能否正常運作。

一個常見誤區

好多人以為「用咗加密 DNS 就絕對唔會中斷」。實際上，加密只解決咗傳輸鏈路嘅隱私同抗竊聽問題，並唔自動等同高可用。高可用來自：

• 上游冗餘設計；
• 策略設定合理；
• 監控同應急動作可執行。

實操檢查清單

• 係咪仍然只有一個 DNS 提供商？
• 係咪只有單一協議（只用 DoT 或只用 DoH）而且冇備用？
• 係咪能喺 3 分鐘內由日誌定位「誤攔截定上游故障」？
• 係咪有為長者／小朋友裝置獨立設定家庭保護策略？
• 係咪每月至少做過一次切換演練？

如果以上大多數答案係否定否定嘅，咁「下一次公開 DNS 事故」好大概率就會直接落到你嘅家庭網絡上。

參考資料（公開可核實）

• Cloudflare：2024 年 6 月 27 日 1.1.1.1 事件復盤（含 BGP 劫持與路由洩漏時間線）
  https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024
• Cloudflare：2025 年 7 月 14 日 1.1.1.1 事件復盤（含 62 分鐘中斷說明與修復時間線）
  https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/
• Cloudflare Radar（可用於觀察公開事件期間嘅 DNS 可用性變化）
  https://radar.cloudflare.com/

對個人同家庭用戶嚟講，DNS 唔止係「快啲」嘅問題，而係一個基礎安全同可用性問題。將專用加密 DNS、廣告攔截、家庭保護同可觀測能力組合起來，先至可以在實際故障入面減少損失同焦慮。

DoH 與 DoT 技術對比分析

DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 是兩種常見的加密 DNS 傳輸方式. 它們都能保護 DNS 查詢不被轻易竊聽或篡改, 但所依賴的協議棧不同.

先看結論:

• DoH: 借助 HTTP 傳輸 DNS, 更容易複用現有 Web 基礎設施.
• DoT: 直接在 TLS 之上傳輸 DNS, 協議路徑更短, 結構更直接.
• 兩者核心目標一致: 保護 DNS 查詢的隱私與完整性.

對應標準如下:

如果想真正理解兩者差異, 最好先從網絡協議層次結構開始看.

網絡協議層次結構

現代網絡協議棲採用分層設計, 每一層負責不同任務. DNS 雖然是應用層協議, 但它並不強綁定某一種傳輸方式.

可以先用以一張表快速理解各層角色:

這裏有幾個關鍵點:

• DNS 屬於應用層.
• TLS 位於應用層和傳輸層之間.
• HTTP/3 仍然是應用層協議, 只是它運行在 QUIC 之上.
• QUIC 常被視作「增強型傳輸層」, 因爲它集成了可靠傳輸, 擁塞控制, 多路複用和加密握手能力.

如果把 DoT 裏的 TLS 拿掉, 它本質上就接近 DNS over TCP. 這說明「是否加密」與「DNS 運行在哪種傳輸之上」其實是兩個不同維度.

Plain DNS 的特點

最普通的 DNS 一般被稱爲 Plain DNS, 常見運行方式是 UDP 或 TCP.

可以簡單理解爲:

• UDP 更輕量: 更適合快速請求.
• TCP 更穩定: 遇到丟包時更有保障.
• 在部分網絡環境下, 尤其是 UDP 丟包嚴重時, TCP 反而可能更穩定.

一些運營商在網絡繁忙時會優先丟棄 UDP 報文. 這種情況下, 依賴 UDP 的 DNS 查詢會受到影響, 而 TCP 由於具備重傳能力, 往往更容易得到穩定結果.

應用層嵌套

DNS 和 HTTP 都屬於應用層協議, 所以 DoH 可以看作是「應用層再包一層應用層」.

這一節可以抓住兩點:

• DoH 的核心不是 HTTP 這個名字, 而是 HTTP 這個承載方式.
• 理論上 DNS 可以承載在很多應用層協議之上, 只是現實中沒有必要把它做得過於複雜.

例如:

• DoH = 把 DNS 請求放進 HTTP 請求裏.
• 未加密的 HTTP 也能承載 DNS, 但幾乎沒有實際優勢.
• 從理論上說, 甚至可以做「DNS over FTP」, 只是沒有現實價值.

flowchart TD
    subgraph L7["應用層"]
        A[DNS]
        B[HTTP]
        C[FTP]
    end
    
    subgraph Security["安全層"]
        D[TLS]
        E[DTLS]
    end
    
    subgraph Transport["傳輸層"]
        F[TCP]
        G[UDP]
        H[QUIC]
    end
    
    subgraph L3["網絡層"]
        I[IP]
    end
    
    subgraph L2["數據鏈路層"]
        J[Ethernet]
        K[WiFi]
    end
    
    A --> D
    B --> D
    C --> D
    D --> F
    E --> G
    H --> G
    F --> I
    G --> I
    H --> I
    I --> J
    I --> K
    
    style A fill:#e1f5ff
    style B fill:#e1f5ff
    style C fill:#e1f5ff
    style D fill:#fff4e1
    style E fill:#fff4e1
    style F fill:#ffe1e1
    style G fill:#ffe1e1
    style H fill:#e1ffe1

傳輸層嵌套

QUIC 基於 UDP, 但提供了很多傳統上傳輸層才具備的能力.

它通常具備這些特徵:

• 面向連接
• 擁塞控制
• 重傳機制
• 流量控制
• 多路複用
• 與 TLS 1.3 深度整合

因此可以把 QUIC 理解爲:

協議組合關係

應用層協議和傳輸層協議之間並不是一對一綁定的. 同一種應用協議, 可以跑在不同傳輸方式上.

先看一個化總表:

如果再用一句話概括:

• DoT: 路徑更短, 直接在 TLS 上跑 DNS.
• DoH: 先走 HTTP, 再承載 DNS.
• DoQ: 用 QUIC 直接承載 DNS.

flowchart LR
    subgraph DoT["DoT DNS over TLS"]
        direction LR
        T1[TCP] --> T2[TLS]
        T2 --> T3[DNS]
    end
    
    subgraph DoH2["DoH over HTTP/2"]
        direction LR
        H1[TCP] --> H2[TLS]
        H2 --> H3[HTTP/2]
        H3 --> H4[DNS]
    end
    
    subgraph DoH3["DoH over HTTP/3"]
        direction LR
        Q1[QUIC] --> Q2[TLS 1.3]
        Q2 --> Q3[HTTP/3]
        Q3 --> Q4[DNS]
    end
    
    subgraph DoQ["DoQ DNS over QUIC"]
        direction LR
        D1[QUIC] --> D2[TLS 1.3]
        D2 --> D3[DNS]
    end
    
    style T1 fill:#e3f2fd
    style T2 fill:#fff3e0
    style H1 fill:#e3f2fd
    style H2 fill:#fff3e0
    style Q1 fill:#e8f5e9
    style Q2 fill:#fff3e0
    style D1 fill:#e8f5e9
    style D2 fill:#fff3e0

性能和兼容性分析

理解協議組合之後, 再看 DoH 和 DoT 的差異會更直觀.

1. 性能

化理解:

• 如果服務商支持 HTTP/3, DoH 往往有更好的低延遲潛力.
• 如果網絡環境對 UDP 不友好, DoT 往往更穩定.
• 理論速度不等於實際體驗, 運營商丟包策略會直接影響結果.

2. 隱私與安全

要點如下:

• DoH 和 DoT 都是加密 DNS.
• 兩者都能有效降低 DNS 明文洩露風險.
• DoT 经常被提到的「容易被識別」, 很很大程度上是因爲 853 端口較顯眼, 而不是協議本身天然暴露更多信息.
• 實際上, DoT 也可以運行在非 853 端口, 只是不同平臺支持程度不同.

3. 擴展性與服務部署

這一點更偏向服務商視角:

• DoH 可以直接複用成熟的 HTTP 服務體系.
• DoH 更容易和其他 Web 服務一起部署在 443 端口上.
• DoT 一般更像「專用 DNS 服務」, 協議路徑更純粹, 但擴展能力不如 HTTP 生態.

4. 平臺兼容性

整體趨勢是:

• DoH 的平臺普及度越來越高.
• DoT 在 Android 上起步較早.
• 對普通用戶來說, 哪個更方便, 往往取決於系統是否提供原生入口.

實際選擇建議

如果只給普通用戶一個簡短建議, 可以直接參考下表:

進一步展開:

• 對大多數用戶來說, DoH 往往更省心.
• 如果服務商支持 DoH/3, 它通常能在網絡良好時提供更低時延.
• 如果網絡狀況較差, DoH 還可能回退到 HTTP/2, 維持可用性.
• 如果本地網絡經常丟 UDP 包, DoT 可能比 DoH/3 更穩定.

選擇時重點看什麼

建議按下面 4 項依次判斷:

1. 服務商是否支持 HTTP/3 / DoH/3
2. 你的運營商網絡是否容易丟 UDP 包
3. 你的設是否原生支持 DoH 或 DoT
4. 你是否更看重省心配置還是更看重網絡穩定性

一個實用建議

推薦嘗試 寧屏, 它支持 DoT 和 DoH/3, 同時提供廣告攔截和 DNS 分流功能. 如果你需要自部署, 也可以使用它的 開源庫.

總結

最後用 3 句話收尾:

• DoH 和 DoT 都能顯著提升 DNS 隱私保護.
• DoH 更偏向兼容性与生態複用, DoT 更偏向直接與穩定.
• 對大多數用戶而言, DoH 通常是更平衡的選擇, 但最終仍要看網絡環境和服務商支持情況.

DNS 私隱防護與用戶畫像防範策略

DNS 私隱防護與用戶畫像防範策略

讀者：關注網絡私隱與數據治理的工程/運維/安全從業者
關鍵詞：本地解析器、遞歸解析、權威伺服器、QNAME最小化、ECS、DNSSEC、DoT/DoH/DoQ

背景與問題概述

在數碼化時代，用戶的網絡行為數據成為企業構建用戶畫像的重要來源。作為互聯網基礎設施的核心組件，域名系統（DNS）在日常網絡活動中承擔著將人類可讀的域名轉換為機器可讀的IP地址的關鍵任務。然而，傳統DNS查詢通常以明文形式在UDP端口53上進行傳輸，這使得用戶的瀏覽歷史、應用使用習慣等敏感信息容易被網絡營運商、互聯網服務供應商以及各種中間人獲取和分析。

用戶畫像是通過收集和分析用戶的各種行為數據而構建的用戶特徵模型，企業利用這些模型進行精準營銷、內容推薦、風險評估等商業活動。雖然這些服務在一定程度上提升了用戶體驗，但也帶來了私隱洩露、數據濫用和潛在的歧視性定價等問題。了解如何通過DNS層面的技術手段來減少用戶畫像的準確性，成為保護個人私隱的重要途徑。

本文將從DNS基礎原理出發，分析用戶畫像構建過程中的數據收集點，探討基於DNS的私隱保護策略，並闡述不同場景下的實現思路與注意事項。

基礎與術語梳理

要理解DNS私隱保護，首先需要掌握DNS查詢的基本流程和相關術語。DNS查詢通常涉及多個參與者，每個環節都可能成為私隱洩露的節點。

flowchart LR
    A[客戶端設備] e1@--> B[本地解析器]
    B e2@--> C[遞歸解析器]
    C e3@--> D[根伺服器]
    D e4@--> E[TLD伺服器]
    E e5@--> F[權威伺服器]
    F e6@--> C
    C e7@--> B
    B e8@--> A
    C --> G[緩存存儲]
    
    e1@{ animation: fast }
    e2@{ animation: slow }
    e3@{ animation: medium }
    e4@{ animation: fast }
    e5@{ animation: medium }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: slow }
    
    style A fill:#e1f5fe
    style B fill:#f3e5f5
    style C fill:#fff3e0
    style D fill:#f1f8e9
    style E fill:#f1f8e9
    style F fill:#f1f8e9
    style G fill:#fce4ec

本地解析器（Stub Resolver）是操作系統或應用程式中的DNS客戶端組件，負責接收應用程式的DNS查詢請求並將其轉發給遞歸解析器。遞歸解析器（Recursive Resolver）通常由ISP或第三方DNS服務提供，負責完成完整的域名解析過程，包括查詢根伺服器、頂級域（TLD）伺服器和權威伺服器，並將最終結果返回給客戶端。

權威伺服器（Authoritative Server）儲存特定域名的DNS記錄，是域名信息的最終來源。緩存機制是DNS系統的重要組成部分，遞歸解析器會緩存查詢結果以減少重複查詢，提高解析效率。TTL（Time To Live）值決定了DNS記錄在緩存中的保存時間。

EDNS Client Subnet（ECS）是一種擴展機制，允許遞歸解析器向權威伺服器傳遞客戶端的子網信息，旨在提高CDN和地理位置服務的準確性。然而，ECS也會暴露用戶的地理位置信息，增加私隱洩露風險。

私隱威脅與動機

明文DNS查詢為用戶畫像構建提供了豐富的數據源。通過分析DNS查詢記錄，攻擊者或數據收集者可以獲取用戶的瀏覽習慣、應用使用情況、地理位置信息等敏感數據，進而構建詳細的用戶畫像。

flowchart TD
    A[用戶上網行為] e1@--> B[明文DNS查詢]
    B e2@--> C[ISP解析器]
    B e3@--> D[公共DNS服務]
    C e4@--> E[用戶訪問記錄]
    D e5@--> F[查詢日誌]
    E e6@--> G[行為分析]
    F e7@--> G
    G e8@--> H[用戶畫像]
    H e9@--> I[精準廣告]
    H e10@--> J[內容推薦]
    H e11@--> K[價格歧視]
    
    L[第三方追蹤器] e12@--> M[跨站點關聯]
    M e13@--> G
    
    N[設備指紋] e14@--> O[唯一標識]
    O e15@--> G
    
    e1@{ animation: fast }
    e2@{ animation: medium }
    e3@{ animation: medium }
    e4@{ animation: slow }
    e5@{ animation: slow }
    e6@{ animation: fast }
    e7@{ animation: fast }
    e8@{ animation: medium }
    e9@{ animation: fast }
    e10@{ animation: fast }
    e11@{ animation: fast }
    e12@{ animation: medium }
    e13@{ animation: fast }
    e14@{ animation: medium }
    e15@{ animation: fast }
    
    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#ffebee
    style D fill:#ffebee
    style E fill:#fce4ec
    style F fill:#fce4ec
    style G fill:#f3e5f5
    style H fill:#e8eaf6
    style I fill:#fff9c4
    style J fill:#fff9c4
    style K fill:#ffcdd2
    style L fill:#ffebee
    style M fill:#fce4ec
    style N fill:#ffebee
    style O fill:#fce4ec

DNS查詢數據對用戶畫像構建的價值主要體現在幾個方面。首先，查詢頻率和時間模式可以揭示用戶的日常作息規律，例如工作日與周末的上網習慣差異、夜間活動模式等。其次，查詢的域名類型可以反映用戶的興趣愛好，如新聞網站、社交媒體、影片平台、購物網站等的訪問偏好。此外，子域名訪問模式可以提供更精細的行為分析，例如用戶是否頻繁訪問特定社交平台的子功能頁面。

地理位置信息是用戶畫像的重要組成部分。通過ECS機制和分析遞歸解析器的位置，可以推斷用戶的物理位置或移動軌跡。結合時間序列分析，還可以識別用戶的常去地點和活動範圍。

跨設備的身份關聯是用戶畫像構建的另一個關鍵環節。通過分析DNS查詢中的特定模式，如相同域名在不同設備上的查詢時間分佈，可能將同一用戶的多個設備關聯起來，構建更全面的用戶畫像。

商業動機驅動著用戶畫像的構建。精準廣告投放是主要應用場景，企業通過分析用戶的瀏覽興趣展示相關性更高的廣告，提高轉化率。內容推薦系統利用用戶畫像提供個性化的新聞、影片和產品推薦，增強用戶粘性。風險評估則應用於金融、保險等領域，根據用戶行為模式評估信用風險或欺詐可能性。

保護策略與原理

針對DNS私隱洩露風險，業界已經發展出多種保護策略，主要圍繞加密傳輸、查詢混淆和源頭控制三個方向展開。這些策略各有特點，適用於不同的場景和需求。

flowchart TD
    A[DNS私隱保護策略] --> B[加密傳輸]
    A --> C[查詢混淆]
    A --> D[源頭控制]
    
    B --> B1[DoT - DNS over TLS]
    B --> B2[DoH - DNS over HTTPS]
    B --> B3[DoQ - DNS over QUIC]
    
    C --> C1[QNAME最小化]
    C --> C2[分批查詢]
    C --> C3[隨機化時序]
    
    C1 --> C1A[逐級發送]
    C1 --> C1B[減少暴露]
    
    D --> D1[本地hosts]
    D --> D2[可信遞歸解析器]
    D --> D3[DNS過濾]
    
    D2 --> D2A[私隱政策]
    D2 --> D2B[無日誌記錄]
    D2 --> D2C[第三方審計]
    
    style A fill:#e1f5fe
    style B fill:#e8f5e8
    style C fill:#fff3e0
    style D fill:#f3e5f5
    style B1 fill:#e8f5e8
    style B2 fill:#e8f5e8
    style B3 fill:#e8f5e8
    style C1 fill:#fff3e0
    style C2 fill:#fff3e0
    style C3 fill:#fff3e0
    style D1 fill:#f3e5f5
    style D2 fill:#f3e5f5
    style D3 fill:#f3e5f5

加密傳輸是DNS私隱保護的基礎手段，主要包括三種技術：DNS over TLS（DoT）、DNS over HTTPS（DoH）和DNS over QUIC（DoQ）。DoT使用TCP端口853傳輸加密的DNS查詢，通過TLS協議提供端到端的加密保護。DoH將DNS查詢封裝在HTTPS流量中，使用標準443端口，能夠更好地融入現有網絡環境，避免被防火牆或網絡管理設備識別和阻止。DoQ是基於QUIC協議的新興方案，結合了UDP的低延遲和TLS的安全性，同時支援連接遷移等高級特性。

QNAME最小化（RFC7816）是一種查詢混淆技術，遞歸解析器在向上游伺服器發送查詢時，逐步發送域名而不是完整域名。例如，查詢"www.example.com"時，先查詢"com"，再查詢"example.com"，最後查詢"www.example.com"。這種方式減少了上游伺服器獲取的完整域名信息，但可能增加查詢延遲。

分批查詢和時序隨機化是額外的查詢混淆手段。分批查詢將多個DNS請求分散在不同時間發送，避免通過查詢模式關聯用戶行為。時序隨機化在查詢間隔中引入隨機延遲，打破時間模式分析的可能。

源頭控制策略關注DNS查詢的發起環節。本地hosts文件可以繞過DNS查詢直接解析常用域名，減少查詢記錄的產生。可信遞歸解析器選擇具有嚴格私隱政策的DNS服務供應商，如承諾不記錄查詢日誌、不接受第三方追蹤的服務。DNS過濾通過阻止已知的追蹤器和惡意域名，減少不必要的數據暴露。

實現路徑與注意事項

DNS私隱保護的實現需要考慮技術可行性、性能影響和部署複雜度。在選擇和實施具體方案時，需要權衡私隱保護效果與實際可用性。

加密DNS的部署可以採用多種方式。操作系統級支援是最理想的情況，如Android 9+、iOS 14+和Windows 11都內置了DoH或DoT支援。應用程式級實現適用於特定軟件，如瀏覽器內置的加密DNS功能。網絡設備級部署則在路由器或防火牆上配置加密DNS，為整個網絡提供保護。

QNAME最小化的實施主要由遞歸解析器負責，用戶需要選擇支援該功能的DNS服務。需要注意的是，QNAME最小化可能會影響某些依賴完整域名信息的性能優化，如預取和負載均衡。

可信遞歸解析器的選擇需要考慮多個因素。私隱政策是首要考慮，包括是否記錄查詢日誌、日誌保留時間、數據共享政策等。服務性能影響用戶體驗，包括解析延遲、可用性和全球分佈。服務透明度也是重要因素，如是否公開營運政策、接受第三方審計等。

DNS過濾需要注意誤報和漏報問題。過於激進的過濾可能導致正常網站無法訪問，而過於寬鬆的過濾則無法有效保護私隱。定期更新過濾規則和提供自定義白名單是必要的平衡措施。

混合策略可以提供更好的私隱保護效果。例如，結合加密DNS和QNAME最小化，同時使用DNS過濾阻止追蹤器。但需要注意的是，過多的私隱保護措施可能影響網絡性能和兼容性，需要根據實際需求進行調整。

風險與遷移

部署DNS私隱保護措施可能面臨多種風險和挑戰，需要制定相應的遷移策略和應急預案。

兼容性風險是主要考慮因素之一。加密DNS可能被某些網絡環境阻止，特別是在企業網絡或限制性嚴格的地區。回退機制至關重要，當加密DNS不可用時，系統應該能夠優雅地回退到傳統DNS，同時盡可能減少私隱洩露。

性能影響需要仔細評估。加密DNS可能會增加查詢延遲，特別是首次連接時的握手開銷。緩存優化和連接復用可以緩解部分性能問題。在選擇加密DNS服務時，應考慮其網絡延遲和響應時間，避免地理位置過遠的伺服器。

合規性要求是企業部署時必須考慮的因素。某些地區可能有數據留存或監控要求，與私隱保護措施可能存在衝突。在部署前需要了解當地法規要求，並在私隱保護與合規性之間找到平衡點。

分層灰度部署是降低風險的有效策略。首先在測試環境中驗證方案可行性，然後逐步擴大到小規模用戶群體，最後全面部署。監控關鍵指標如查詢成功率、延遲變化和錯誤率，及時調整配置。

用戶教育和培訓也不可忽視。許多用戶可能不了解DNS私隱的重要性，需要提供清晰的說明和配置指導。特別是在企業環境中，IT部門應該向員工解釋私隱保護措施的目的和使用方法。

場景化建議

不同使用場景對DNS私隱保護的需求和實施策略各有特點，需要根據具體環境制定針對性的方案。

家庭網絡場景下，路由器級部署是不錯的選擇。支援加密DNS的路由器可以為整個家庭網絡提供保護，包括IoT設備和智能家居產品。選擇家庭友好的DNS服務，如支援家長控制和惡意網站過濾的服務，可以在保護私隱的同時提供額外的安全功能。

移動辦公場景需要特別關注網絡切換和電池消耗。選擇支援連接遷移的DoQ服務可以提高移動網絡切換的穩定性。同時，考慮電池優化策略，避免頻繁的DNS查詢和加密操作過度消耗電量。

企業環境需要在私隱保護與網絡管理之間找到平衡。可能需要部署混合方案，對一般員工流量提供私隱保護，同時對特定業務流量保持可見性以滿足管理和合規要求。DNS過濾可以與企業安全策略結合，阻止惡意域名和數據洩露風險。

高私隱需求場景下，如記者、律師和醫療從業者，可能需要採用多重保護措施。結合加密DNS、VPN和Tor等工具，實現層層的私隱保護。同時，可以考慮使用匿名遞歸解析器，如不記錄任何查詢日誌的服務。

跨境網絡場景需要特別關注網絡審查和地區限制。某些加密DNS服務可能在特定地區不可用，需要準備多個備選方案。了解當地的網絡環境特點，選擇最適合當地條件的私隱保護策略。

開發測試環境可以嘗試最新的私隱保護技術，如實驗性的DoQ實現或自定義的混淆方案。這些環境相對可控，適合測試新技術的影響和兼容性，為生產環境部署積累經驗。

FAQ 與參考

常見疑問

Q: 加密DNS是否完全防止用戶畫像構建？
A: 加密DNS可以防止網絡層面的中間人窺探DNS查詢內容，但遞歸解析器仍然可以看到完整的查詢記錄。選擇承諾不記錄日誌的可信服務供應商很重要，同時結合其他私隱保護措施如瀏覽器防追蹤功能，可以提供更全面的保護。

Q: QNAME最小化會影響DNS解析性能嗎？
A: QNAME最小化可能會增加查詢延遲，因為需要多次向上游伺服器發送查詢。現代遞歸解析器通常通過智能緩存和並行查詢來優化性能，實際影響往往比預期小。對於大多數用戶來說，私隱收益遠超過輕微的性能損失。

Q: 如何驗證DNS私隱保護是否生效？
A: 可以使用專門的測試工具如dnsleaktest.com或dnsprivacy.org提供的檢測服務，驗證DNS查詢是否通過加密通道發送。網絡抓包工具也可以用來檢查DNS流量是否已加密。但需要注意的是，這些測試只能驗證技術實現，無法評估服務供應商的實際私隱政策執行情況。

Q: 企業網絡中如何平衡私隱保護與管理需求？
A: 企業可以採用分層策略，對一般互聯網訪問提供私隱保護，同時對內部業務流量保持必要的監控能力。使用支援分流技術的解決方案，根據域名或用戶組別應用不同的DNS策略。明確的私隱政策和員工溝通也很重要。

Q: 加密DNS會被網絡營運商阻止嗎？
A: 某些網絡環境可能會限制或阻止加密DNS流量，特別是使用非標準端口的DoT。DoH由於使用標準HTTPS端口443，通常更難被識別和阻止。在這種情況下，可以考慮使用多種加密DNS方案的組合，或者配合其他私隱工具如VPN。

參考資源

RFC文檔:

• RFC7858: Specification for DNS over Transport Layer Security (TLS)
• RFC8484: DNS Queries over HTTPS (DoH)
• RFC7816: DNS Query Name Minimisation to Improve Privacy
• RFC9250: DNS over Dedicated QUIC Connections

工具與服務:

• Cloudflare DNS: 1.1.1.1 (支援DoH/DoT，承諾私隱保護)
• Quad9: 9.9.9.9 (支援DoH/DoT，阻止惡意域名)
• NextDNS: 可定制的私隱DNS服務
• Stubby: 開源的DoT客戶端

測試與驗證:

• dnsleaktest.com: DNS洩漏測試
• dnsprivacy.org: DNS私隱測試工具
• browserleaks.com/dns: 瀏覽器DNS配置檢測

延伸閱讀:

• DNS私隱保護技術詳解
• 企業DNS安全與私隱平衡策略

本文從DNS基礎原理出發，分析了用戶畫像構建過程中的私隱風險，並系統介紹了加密傳輸、查詢混淆和源頭控制等保護策略。在實際部署中，需要根據具體場景和需求選擇合適的方案，平衡私隱保護、性能影響和兼容性要求。DNS私隱保護是一個持續發展的領域，隨著技術演進和法規變化，保護策略也需要不斷調整和完善。

深度解析：寧屏DNS代理功能，突破網絡限制實現私隱保護

🌐 DNS代理功能深度解析

在當今複雜的網絡環境中，傳統的DNS服務往往面臨諸多限制。寧屏DNS服務現已全面支援上游DNS代理功能，為用戶提供更加靈活和安全的網絡存取體驗。

為什麼需要DNS代理？

在某些網絡環境下（如企業網絡、校園網或特定地區網絡），直接存取上游DNS伺服器可能會遇到以下問題：

• 網絡限制：某些DNS伺服器（如1.1.1.1、8.8.8.8）被防火牆封鎖
• ISP干擾：營運商可能對DNS查詢進行重定向或污染
• 地理限制：特定地區的DNS服務存取受限
• 私隱保護：需要通過代理隱藏真實IP地址

🚀 核心功能特性

DoH與DoT代理支援

寧屏DNS服務在AdGuard Home基礎上進行了深度定制，新增了以下關鍵功能：

1. 智能DNS分流

   • 自動檢測網絡環境
   • 根據規則智能選擇直連或代理路徑
   • 支援自訂分流配置文件

2. 代理協議全面支援

   • HTTP代理 (http_proxy)
   • HTTPS代理 (https_proxy)
   • SOCKS5代理 (socks5)

3. 安全加密傳輸

   • DoH (DNS over HTTPS) 代理支援
   • DoT (DNS over TLS) 代理支援
   • 端到端加密保護私隱

📋 詳細配置指南

環境變數配置

配置DNS代理功能非常簡單，只需要在系統環境中設定相應的代理變數即可。

Linux/macOS配置

# 臨時配置（當前會話）
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
export ALL_PROXY="socks5://[username:password@]proxyhost:port"

# 永久配置（添加到 ~/.bashrc 或 ~/.zshrc）
echo 'export http_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export https_proxy="http://proxy.example.com:8080"' >> ~/.bashrc
echo 'export ALL_PROXY="socks5://[username:password@]proxyhost:port"' >> ~/.bashrc
source ~/.bashrc

Windows配置

# 命令提示符
set http_proxy=http://proxy.example.com:8080
set https_proxy=http://proxy.example.com:8080

# PowerShell
$env:http_proxy="http://proxy.example.com:8080"
$env:https_proxy="http://proxy.example.com:8080"

Docker容器配置

version: '3.8'
services:
  nullprivate-dns:
    image: nullprivate/nullprivate:latest
    environment:
      - http_proxy=http://proxy.example.com:8080
      - https_proxy=http://proxy.example.com:8080
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "80:80/tcp"
      - "443:443/tcp"

進階配置選項

認證代理配置

如果代理伺服器需要認證，可以使用以下格式：

export http_proxy="http://username:[email protected]:8080"
export https_proxy="https://username:[email protected]:8080"

排除特定域名

某些域名可能不需要通過代理存取，可以設定no_proxy變數：

export no_proxy="localhost,127.0.0.1,.local"

🔧 實際應用場景

企業網絡環境

在企業網絡中，外部DNS伺服器往往被防火牆限制。通過配置代理，可以：

• 突破企業防火牆限制
• 存取被封鎖的DNS服務
• 實現安全的外部網絡存取

校園網優化

校園網絡通常對DNS有嚴格控制，配置代理可以：

• 避免DNS污染和劫持
• 提供更快的DNS解析速度
• 保護學生私隱和學習數據

家庭網絡保護

家庭用戶可以通過代理：

• 隱藏家庭真實IP地址
• 防止ISP追蹤上網行為
• 實現更安全的兒童上網保護

⚡ 技術優勢對比

🛠️ 故障排除指南

常見問題及解決方案

Q: 配置代理後DNS解析失敗

可能原因：

• 代理伺服器無法存取
• 代理伺服器不支援HTTPS
• 網絡連線問題

解決方案：

1. 檢查代理伺服器狀態：curl -x http://proxy.example.com:8080 https://www.google.com
2. 驗證代理配置：env | grep proxy
3. 重啟寧屏服務

Q: 代理連線逾時

可能原因：

• 代理伺服器回應慢
• 網絡延遲高
• 代理伺服器負載過高

解決方案：

1. 更換代理伺服器
2. 調整DNS逾時設定
3. 配置多個代理伺服器進行負載均衡

Q: 特定域名解析異常

可能原因：

• 域名在代理伺服器的黑名單中
• DNS快取問題
• 代理伺服器DNS配置問題

解決方案：

1. 清除DNS快取
2. 檢查代理伺服器配置
3. 嘗試直連模式

📊 性能監控

配置代理後，可以通過以下方式監控性能：

1. DNS查詢延遲：觀察DNS解析速度是否有所改善
2. 成功率統計：監控代理連線的成功率
3. 流量分析：查看代理流量使用情況
4. 錯誤日誌：定期檢查系統日誌中的錯誤信息

🔒 安全注意事項

1. 選擇可信代理：使用可靠的代理服務提供商
2. 啟用加密：優先使用HTTPS代理
3. 定期更換：定期更換代理伺服器以提高安全性
4. 監控流量：定期檢查代理流量使用情況
5. 更新配置：及時更新代理配置以應對網絡變化

🎯 總結與展望

寧屏DNS代理功能的推出，為用戶在複雜網絡環境中使用DNS服務提供了更加靈活和安全的解決方案。通過簡單的配置，即可突破網絡限制，實現更優質的DNS解析服務和私隱保護。

未來規劃

• 支援SOCKS5代理協議
• 增加智能代理選擇算法
• 提供圖形化配置界面
• 支援多代理負載均衡

🚀 立即體驗

想要體驗寧屏DNS代理功能的用戶，可以：

1. 訪問 GitHub倉庫
2. 按照文檔進行部署
3. 配置代理環境變數
4. 享受更安全、更自由的網絡體驗

AdGuardPrivate的更名公告

近日，我們收到AdGuard官方通知，被告知「AdGuard」為註冊商標，在未獲得授權的情況下不可使用該名稱，即使是添加前綴或後綴亦可能涉及侵權。為避免法律風險，我們的服務已正式更名為「NullPrivate」。

對於現有用戶，您的服務完全不受影響，我們仍會透過adguardprivate.com域名為您提供服務，僅官方網站和聯絡方式會進行遷移。

為了防止新用戶誤以為NullPrivate與AdGuard存在關聯，我們特此說明：我們的軟件產品基於AdGuardHome進行fork開發，並添加了新的功能。所有代碼均已開源，並遵守相同的GPLv3協議。

代碼庫地址：https://github.com/nullprivate/nullprivate

用戶可以自行檢視代碼並實現自部署。同時，我們提供的SaaS版本將繼續為用戶提供更實惠的價格和更穩定的服務。

感謝您一直以來的支持，希望我們的服務能持續為您帶來價值！

增加了DDNS功能

如果您已擁有一個NullPrivate服務，現在可以使用DDNS功能。

概述

NullPrivate開源了DDNS腳本，該動態DNS（DDNS）旨在提供一種簡單的方法，無需購買域名即可快速設置私有動態DNS。此DDNS腳本專門為nullprivate.com開發，利用NullPrivate的核心功能，您可以無縫實現這一功能。

使用方法

1. 確保NullPrivate已部署並正在運行。
2. 導航到DNS重寫，下載DDNS腳本。
3. 運行腳本。

Windows

Set-ExecutionPolicy Bypass -Scope Process
./ddns-script.ps1

Linux/macOS

chmod +x ddns-script.sh
./ddns-script.sh

功能特點

• 快速簡便的設置：只需幾個步驟即可完成配置。
• 利用NullPrivate實現DDNS功能：通過NullPrivate的核心功能實現DDNS。
• 支援多平台：支援Windows和基於Unix的系統。
• 多種認證選項：支援Cookie（更安全但可能過期）或用戶名/密碼（更持久但安全性較低）進行認證。

與傳統DDNS的區別

與傳統的DDNS相比，這種私有DDNS具有以下優勢：

• 無緩存時間：更改立即生效，無需等待DNS緩存過期。
• 無DNS傳播延遲：更新即時可用，無需DNS傳播延遲。
• 無需購買域名：可以使用偽域名進行訪問，無需購買域名。
• 隱私保護：只有連接到私有DNS服務的用戶才能解析DNS，確保隱私。

快速入門指南

1. 確保已部署NullPrivate並正在運行。
2. 按照win/ddns.ps1（適用於Windows）或unix/ddns.sh（適用於基於Unix的系統）腳本中的說明配置您的私有DDNS。

開源地址: https://github.com/NullPrivate/nullprivate-ddns

更好的支援ECS

為了獲得最佳的 DNS 解析體驗，我們已經預設了一些建議配置, 但仍然有需要用戶注意的配置, 那就是「EDNS 客戶端子網」。

啟用EDNS客戶端子網(ECS)

為了獲得更佳的體驗，您可能希望 DNS 伺服器返回在地理位置上最接近您的伺服器 IP 結果。EDNS 客戶端子網 (ECS) 能夠實現這一點。它允許將包含地理位置資訊的 IP 子網發送到 DNS 伺服器，以便伺服器返回最佳的 DNS 解析結果。

工作原理:

當啟用 ECS 時，您的 DNS 解析器（例如 AdGuard Home）會將客戶端 IP 位址的一部分（通常是前 24 位，表示客戶端所在的子網）包含在 DNS 查詢中，並將其發送到上游 DNS 伺服器。上游 DNS 伺服器會根據此子網資訊，返回最適合該區域的伺服器 IP 位址。

sequenceDiagram
    participant Client
    participant DNS Resolver
    participant Upstream DNS Server

    Client->>DNS Resolver: DNS Query
    DNS Resolver->>Upstream DNS Server: DNS Query with ECS (Client Subnet)
    Upstream DNS Server->>DNS Resolver: DNS Response (Geo-localized IP)
    DNS Resolver->>Client: DNS Response (Geo-localized IP)

私隱注意事項:

啟用 ECS 能夠在提高 DNS 解析準確性和速度的同時，也可能帶來一定的私隱影響。通過共享客戶端 IP 位址的子網，您的粗略地理位置資訊可能會被上游 DNS 伺服器記錄。請您根據自身情況，權衡是否啟用此功能。

如何權衡:

啟用 ECS 可以在存取速度和準確性之間取得平衡。如果您對私隱保護有較高要求，可以選擇停用 ECS，但可能會降低存取速度。如果您希望獲得最佳的存取體驗，可以啟用 ECS，但請知悉潛在的私隱影響。該私隱資訊由DNS上游搜集, 本服務仍然按照私隱政策承諾, 不搜集利用任何資訊。

寧屏 - 基於AdGuard Home的增強版DNS服務

寧屏: 專注私隱保護的DNS服務

訪問官網了解更多: 寧屏

本項目基於AdGuard Home進行二次開發，遵循 GPL 3.0 開源協議。

源代碼開放在：GitHub - NullPrivate/NullPrivate

功能增強

相比原版AdGuard Home，我們增加了以下特性：

• 📜 自動化SSL證書管理
  • 自動申請與更新證書
  • 支援泛域名證書配置
• 🛡️ 增強的安全特性
  • 智能限流保護
  • 優化的大陸地區訪問體驗
• ⚙️ 優化的系統配置
  • 禁用DHCP服務，專注DNS功能
• 🔄 支援DDNS
• 🌉 支援代理功能
  • 通過代理下載配置文件
  • 支援DoH/DoT代理
• 🚦 支援DNS分流功能
• 🚫 支援防沉迷app名單

託管服務優勢

我們提供專業的DNS託管服務，具有以下特點：

• 🏢 阿里雲杭州節點部署
• 🌐 全面的協議支援
  • IPv6支援，直連主流IPv6上游
  • DoT (DNS over TLS)
  • DoH (DNS over HTTPS)
  • HTTP/3 支援，顯著降低延遲
• 📊 強大的規則管理
  • 支援第三方黑白名單導入
  • 100萬條規則容量
• 📝 完善的日誌與統計
  • 72小時查詢記錄保留
  • 24小時詳細統計分析
• ⚖️ 負載均衡
  • 多伺服器分佈式部署
  • 智能負載分配
• 💰 具有競爭力的價格

性能與效果評估

DNS層面的廣告攔截具有其獨特優勢：

• 💪 優勢

  • 零額外功耗
  • 全設備覆蓋
  • 降低設備網絡喚醒頻率
  • 減少無效數據加載

• ⚠️ 局限性

  • 攔截精度低於瀏覽器插件
  • 無法達到MITM方案的過濾效果

特別適合移動設備使用場景，在保護私隱的同時兼顧設備續航。

全面支援 HTTP/3 協議

NullPrivate 已全面支援 HTTP/3 協議。所有現有用戶都將自動升級享受 HTTP/3 帶來的效能提升，無需任何額外設定。

重要更新說明

• iOS 用戶：現可透過 DoH 協議直接使用 HTTP/3，享受更低的網絡延遲
• Android 用戶：因系統限制，目前仍使用 DoT 協議，待 Google 後續版本更新後即可支援
• 效能提升：初次響應速度較 HTTP/2 顯著提升，連接建立更快捷
• 智能切換：在不支援 HTTP/3 的網絡環境下，系統會自動切換至 HTTP/2，確保服務穩定性

HTTP/3 技術深度解析

HTTP/3 作為 HTTP 協議的最新版本，基於 Google 開發的 QUIC 傳輸協議，帶來了多項革新性的技術優勢：

核心特性

1. 基於 UDP 的 QUIC 協議

   • 顯著減少連接建立時間
   • 改進的多路複用能力
   • 更智能的封包遺失處理機制

2. 優化的效能表現

   • 零握手延遲（0-RTT）
   • 改進的擁塞控制
   • 連接遷移支援

3. 增強的安全性

   • 整合 TLS 1.3
   • 加密握手過程
   • 降低中間人攻擊風險

建連過程對比

使用建議

• 確保您的客戶端支援 HTTP/3 協議
• 保持客戶端版本更新
• 網絡環境受限時，系統會自動降級使用 HTTP/2

注意事項

• 部分地區的網絡可能會限制 UDP 流量，影響 HTTP/3 效能
• 不同網絡環境下效能表現可能存在差異
• 系統會根據網絡狀況自動選擇最優協議

參考資料

• HTTP/3 規範文件
• QUIC 協議詳解
• IETF HTTP/3 標準

推出自訂用戶端名稱功能

功能介紹

為提升用戶體驗，NullPrivate 現已支援自訂用戶端名稱功能。透過這項功能，您可以為不同裝置設定獨特的識別名稱，使裝置管理更加直觀和便捷。

設定指南

根據不同裝置類型，設定方式略有不同：

Android 裝置

只需在域名前添加自訂前綴即可，格式如下：

{裝置名稱}.{原有域名}

示例：xiaomi-15pro.xxxxxxxx.nullprivate.com

iOS 裝置

1. 進入「設定指導」頁面
2. 在「用戶端ID」輸入框中填入自訂名稱
3. 下載並應用新的設定檔

瀏覽器設定（DoH）

在原有 DoH 地址後添加自訂標識：

原有格式：

https://xxxxxxxx.nullprivate.com/dns-query

新格式：

https://xxxxxxxx.nullprivate.com/dns-query/{裝置標識}

示例：https://xxxxxxxx.nullprivate.com/dns-query/pc1-browser

使用建議

• 裝置名稱建議使用有意義的標識，如裝置型號、位置或用途
• 避免使用特殊字符，建議使用字母、數字和連字號
• 保持命名規範統一，便於後期管理

注意事項

• 自訂名稱僅影響顯示，不會影響服務效能
• 修改名稱後需要重新應用設定才能生效
• 建議保存好各裝置的設定資訊，以便日後參考

廣告攔截的必要性：保護數碼時代的注意力與私隱

解構現代廣告生態

廣告商的利潤模式

現代廣告體系構建在一個複雜的利益鏈條之上：

• 廣告商透過媒介平台連接廣告主與用戶
• 收入來源是廣告主的投放費用，而非用戶
• 目標是最大化「轉化率」——將廣告觀眾轉變為付費客戶

轉化率之戰

在這場注意力爭奪戰中：

• 高轉化率意味著更高的廣告單價
• 廣告投放效率直接影響收益
• 「個性化推送」成為提升轉化的核心策略

個性化廣告的真相

數據收集的深度

現代廣告系統透過多重渠道收集用戶資訊：

• 裝置識別與操作系統數據
• 跨平台行為追蹤
• 社交關係網絡分析
• 消費習慣畫像

精準投放的陷阱

看似便利的個性化推送實則暗藏風險：

• 利用認知偏差製造需求
• 放大用戶潛在焦慮
• 創造虛假的緊迫感

廣告對注意力的侵蝕

注意力經濟的代價

• 頻繁打斷破壞工作效率
• 干擾決策判斷能力
• 增加認知負擔
• 模糊真實需求邊界

廣告策略的演變

現代廣告已經從單純的資訊傳遞演變為：

• 強制記憶植入
• 情緒刺激
• 焦慮營銷
• 社交壓力

保護自我的策略

核心防護措施

1. 私隱保護優先

   • 限制應用權限
   • 控制數據分享
   • 使用私隱保護工具

2. 注意力管理

   • 設置專注時段
   • 建立資訊過濾機制
   • 培養主動獲取資訊的習慣

3. 消費決策把控

   • 建立需求評估體系
   • 延遲購買決策
   • 保持理性判斷

技術支援：賽博城府

在這個數據驅動的時代，保持「賽博城府」——即數碼世界中的謹慎與智慧，變得尤為重要。這包括：

• 管理數碼足跡
• 保護個人私隱
• 控制資訊流動

解決方案

「寧屏」作為綜合性防護方案，不僅提供廣告攔截，更重要的是幫助用戶：

• 保護個人私隱
• 優化瀏覽體驗
• 減少注意力分散
• 提供可控的資訊環境

讓我們重新掌控自己的數碼生活，從拒絕廣告騷擾開始。

服務資源優化策略說明

背景說明

隨著用戶數量增長和功能需求提升，我們觀察到部分高資源消耗的配置選項可能導致服務不穩定。為確保服務質素，我們進行了深入分析並制定了相應的優化方案。

資源優化策略

1. 過濾器更新機制優化

現況分析

• 部分用戶設定了每小時更新過濾器
• 每次更新都需要完整的下載-解析-去重流程
• 國際頻寬限制導致更新耗時延長
• 伺服器資源持續高負載

優化方案

我們將更新間隔調整為最短 72 小時，原因如下：

• 大多數過濾清單更新週期為 24-72 小時
• 降低無效的資源消耗
• 確保服務穩定性
• 優化頻寬使用效率

影響評估

• 正面影響
  • 服務回應更穩定
  • 資源使用更合理
  • 降低系統負載
• 最小化影響
  • 規則更新仍保持在合理週期內
  • 不影響防護效果

2. 並行請求策略

當前情況

目前大多數用戶啟用了並行請求功能，但在現有架構下收益有限：

• 阿里雲上游服務延遲差異通常在 5ms 以內
• 可能觸發阿里雲公共服務的請求頻率限制
• 增加不必要的系統開銷

使用建議

• 建議使用負載均衡模式
• 並行請求適用於以下場景：
  • 上游服務延遲差異顯著（>200ms）
  • 服務質素不穩定的情況
  • 跨國存取場景

註：目前暫未發現因並行請求導致的限速問題，此功能暫時保持開放。

3. 第三方清單管理

安全考慮

為確保系統穩定性，我們暫時禁用了部分第三方清單支援：

• 外部清單規模難以預測
• 可能導致資源超限
• 服務穩定性無法保證

後續規劃

我們正在研究更安全的第三方清單管理方案，以便在未來重新開放此功能。

基礎版內存上限調整

部分用戶的環境重啟頻繁, 查看日誌發現退出原因是記憶體占用達到上限300MB, 被強制退出。

現調整單容器上限到500MB, 以緩解重啟問題。

如果您的環境出現登錄或重啟問題, 請放心隨時聯繫我們, 為客戶解決問題是我們的責任。

如需協助

聯絡微信 private6688
或 發送電郵 [email protected]
請詳細描述你所遇到的問題, 我們會盡快回覆.

隨時為您提供支援服務

快速入門指南

為確保您能便捷地開始使用我們的服務，我們提供了詳盡的使用指南

貼心服務支援

專屬指導

我們注意到部分新用戶初次使用時可能會遇到困難。為此，我們：

• 持續優化產品文件結構
• 提供清晰的配置指南
• 準備了常見問題解答

及時回應

雖然我們採用無註冊制度以保障用戶私隱，但這並不影響我們對用戶的服務。您可透過以下方式聯絡我們：

如需協助

聯絡微信 private6688
或 發送電郵 [email protected]
請詳細描述你所遇到的問題, 我們會盡快回覆.

如何設定專用連結

一些收費的AdGuardHome服務提供一個專用連結，不允許用戶進入後台管理，管理員代為管理規則。

這表明其沒有提供私有後台管理功能，而只是透過域名反向代理實現服務，成本相對較低。

需租用一台伺服器運行AdGuardHome服務，並配置Nginx反向代理，以實現該功能。

以服務連結5r69hxdx9onl70hp.example.com為例，Nginx關鍵配置如下：

http {
  server {
    listen 1080;
    server_name 5r69hxdx9onl70hp.example.com;
    location / {
      proxy_pass http://worker.example.com:5002;
      proxy_set_header Host $http_host;
    }
  }
  server {
    listen 1443 ssl;
    server_name 5r69hxdx9onl70hp.example.com;
    ssl_certificate /app/data/certs/5r69hxdx9onl70hp/fullchain.pem;
    ssl_certificate_key /app/data/certs/5r69hxdx9onl70hp/privkey.pem;
    location / {
      proxy_pass https://worker.example.com:5003;
      proxy_set_header Host $http_host;
    }
  }
}
stream {
  ssl_protocols TLSv1.2 TLSv1.3 SSLv3;
  map $ssl_preread_server_name $targetBackend {
    5r69hxdx9onl70hp.example.com worker.internal.com:5004;
  }
  server {
    listen 1853;
    proxy_pass $targetBackend;
    ssl_preread on;
  }
}

每個付費用戶只需新增一條類似的Nginx配置，透過域名解析指向伺服器即可。用戶較多時，單個應用服務壓力較大時，可以代理到不同的後端。

這類服務無法實現真正的個人化, 用戶需要能進入後台才能真正掌握自己的上網數據, 而這是我們的私有服務的優點, 一個用戶真正獨佔一個服務, 使用所有NullPrivate的功能。

全新升級——增強版廣告攔截規則

規則更新說明

為滿足用戶對更強勁廣告攔截的需求，我們全面優化了過濾規則策略。新版規則在維持低誤攔截率的同時，顯著提升了廣告過濾效果。這次更新源於用戶回饋；我們在確保網站正常瀏覽的基礎上，加入了更多精準的攔截規則。

規則列表概覽

我們整理了以下專業規則列表，你可按實際需要選擇使用：

基礎防護規則

內容過濾規則

使用建議

1. 循序漸進

   • 建議先從基礎防護規則開始使用
   • 按實際需要逐步添加其他規則
   • 定期檢查並更新規則清單

2. 效能優化

   • 避免同時啟用過多規則
   • 優先選擇與你最相關的規則
   • 定期清理未使用的規則

3. 問題排查

   • 遇到誤攔截時請及時記錄並回報
   • 可暫時停用特定規則作測試
   • 必要時可用自訂白名單

注意事項

• 部分規則或影響特定網站的正常瀏覽
• 建議定期檢查規則更新
• 若出現頻繁誤攔截，請即時聯絡我們

需要更靈活控制的用戶可選用專業版服務，支援完全自訂規則配置。如有任何問題，歡迎隨時回饋。

如需協助

聯絡微信 private6688
或 發送電郵 [email protected]
請詳細描述你所遇到的問題, 我們會盡快回覆.

試用版服務詳情

作為一家專注於提供自訂廣告過濾規則的服務商，我們深知用戶在選擇服務時的考慮。儘管服務成本較高，但我們始終堅持為用戶提供最大的自訂靈活性。

為了讓您充分了解我們服務的價值，我們推出了超值試用方案。這個版本包含了所有高級功能，與正式服務完全等同，讓您可以零風險體驗自訂化過濾的獨特優勢。

試用說明：

• 優惠價格僅適用於首次使用
• 續費需選擇正式服務方案
• 由於採用無帳號設計，可重複購買試用版
• 每次新購將生成全新的服務實例
• 續費可保留原實例所有配置

我們期待您體驗這一優質服務。如在使用過程中遇到任何問題，我們的客服團隊將隨時為您提供專業支援。

如需協助

聯絡微信 private6688
或 發送電郵 [email protected]
請詳細描述你所遇到的問題, 我們會盡快回覆.