這是本節的多頁可列印檢視。按此列印.

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

寧屏技術網誌，分享DNS服務、私隱保護、網絡安全等技術文章。了解最新產品功能、行業動態和技術教程

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

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

深入了解寧屏如何透過DNS過濾技術實現高效廣告攔截，提供清爽的瀏覽體驗，保護您的數碼私隱。

2025 August 18

在當今數碼化時代，廣告已成為互聯網生態的重要組成部分，但過多的廣告不僅影響用戶體驗，還可能帶來私隱洩露風險。寧屏（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採用了相同的核心技術原理：

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

用戶體驗優化

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

透明化管理

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

易用性設計

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

私隱保護

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

使用建議

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

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

結語

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

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

DoH 與 DoT 技術對比分析

從網絡協議層面深入分析 DNS over HTTPS 和 DNS over TLS 的技術實現、性能差異和適用場景

2026 February 11

DNS over HTTPS (DoH) 和 DNS over TLS (DoT) 是兩種常見的加密 DNS 傳輸方式, 它們通過不同的協議棧來實現 DNS 查詢的安全傳輸. DoT 的標準由 RFC 7858 定義, 而 DoH 則由 DNS Queries over HTTPS (DoH) 標準化. 理解這兩種技術的本質區別, 需要從網絡協議層次結構入手分析.

網絡協議層次結構

現代網絡協議棧採用分層設計, 每一層提供不同的功能. DNS 作為應用層協議, 本身並不綁定特定的傳輸方式, 可以運行在多種承載協議之上.

應用層 (L7) 包含 HTTP/1.1, HTTP/2, HTTP/3, FTP 和 DNS 等協議. 值得注意的是, HTTP/3 的語義仍然在應用層, 只是 QUIC 作為傳輸承載. 安全層位於應用層和傳輸層之間, 主要包括 TLS 及其變體. TLS 通常運行在 TCP 上, 比如 HTTPS 和 DoT. DTLS 是 TLS 的數據報版本, 可以運行在 UDP 上. QUIC 協議比較特殊, 它將 TLS 1.3 的握手與密鑰派生直接集成在協議內部.

QUIC 可以被視作 L4.5 層協議, 它基於 UDP 擴展, 提供了傳統傳輸層的能力. 傳輸層 (L4) 包含 TCP, UDP 和 QUIC. 雖然從工程實現角度 QUIC 基於 UDP, 但它自帶可靠性, 擁塞控制, 多路復用和加密握手等功能, 因此在工程上被當作獨立的傳輸層協議. 網絡層 (L3) 使用 IP 協議 (IPv4/IPv6) 負責數據包的選路和轉發. 數據鏈路層 (L2) 包括以太網和 Wi-Fi (802.11) 等技術.

TLS 作為加密手段, 工作在應用層與傳輸層之間. 如果將 TLS 加密從 DoT 中剝離, DoT 本質上就變成了 DNS over TCP. 這種分層設計讓加密成為可選項, 而不是協議本身的強制性約束.

Plain DNS 的特點

最普通的 DNS 稱為 Plain DNS, 它可以運行在 UDP 或 TCP 上. UDP 是最常見的承載方式, 因為連接建立簡單, 首次查詢速度快. 但 UDP 的弱點是不可靠, 數據包容易在網絡中丟失. TCP 雖然握手次數多, 首次連接速度比 UDP 慢約 30%, 但它在建立長連接後, 響應速度與 UDP 相同.

運營商在網絡繁忙時會選擇丟棄 UDP 報文以緩解設備壓力. 對於某些運營商 UDP 丟包嚴重的地區, 指定使用 TCP 進行 DNS 查詢可能更有利. TCP 具有重傳機制, 即使丟包也能保證數據可靠到達, 而丟 UDP 包不會減少小運營商設備的負載壓力, 反而會因為重試引入更多不確定性.

應用層嵌套

DNS 和 HTTP 都屬於應用層協議, DoH 本質上是一個應用層協議嵌套了另一個應用層協議. DoH 不必然是 DNS over HTTPS, 使用普通的 HTTP 也是可行的, 只是未加密的 DoH 是明文請求, 相比 Plain DNS 沒有任何優勢, 只有極少數特殊需求場景才會使用.

理論上可以在任何應用層協議上承載 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, 同時在傳輸層提供了面向連接的服務. QUIC 實現了 TCP 已有的面向連接, 擁塞控制, 重傳, 流量控制, 分片和組裝等傳輸層能力. 相較 TCP, QUIC 延遲更低. 相較 UDP, QUIC 更先進且可靠.

協議組合關係

應用層和傳輸層之間沒有必然的限制關係, 加密可以添加也可以不添加. HTTP 可以運行在 TCP 上, 也可以運行在 QUIC 上. DNS 可以運行在 TCP 上, 可以運行在 UDP 上, 也可以運行在 QUIC 上.

基於這些可能性, 可以總結出以下組合關係. Plain DNS 等於 UDP 或 TCP 加上 DNS 協議. HTTP/2 等於 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 HTTP 協議. HTTP/3 等於 QUIC 加上 TLS 1.3 再加上 HTTP 協議.

DoH (DNS over HTTPS) 等於 HTTP/2 或 HTTP/3 再加上 DNS 協議. DoT (DNS over TLS) 等於 TCP 加上 TLS 1.2 或 TLS 1.3 再加上 DNS 協議. DoQ (DNS over QUIC) 等於 QUIC 加上 TLS 1.3 再加上 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 的優缺點.

TCP 和 QUIC 的對比需要結合運營商的實際網絡環境來討論. QUIC 是較新的協議, 解決了一些老舊網絡問題, 但它畢竟基於 UDP. 從網絡延遲角度看, 基於 QUIC 的協議延遲比 TCP 低約 35%, 因此 DNS over HTTP/3 和 DoQ (DNS over QUIC) 理論上會比 DNS over HTTP/2 和 DoT 性能更好.

但是實際網絡環境中存在丟包導致的重傳延遲問題. 運營商在網絡繁忙時會選擇丟棄 UDP 報文, QUIC 會被識別為 UDP 而進行丟棄. 雖然 QUIC 支持重傳, 但重傳引入的延遲會導致 QUIC 的實際延遲可能比 TCP 更高.

私隱和安全方面, DoH 和 DoT 都是加密流量, 不會被竊取和篡改. 關於 DoT 被識別後封鎖的問題, 主要是由於 Android 系統的加密 DNS 設置默認使用 853 端口, 導致 853 端口成為敏感端口. DoT 本身是常見的普通加密流量, 不會被識別為 DNS 專用流量. 實際上任意端口都可以提供 DoT 服務, 這在 Android 上需要第三方應用來實現, iOS 上則原生支持使用任意端口的 DoT.

擴展性是 DoH 的一個重要優勢. 相比 HTTP 封裝的 DNS 和 Plain DNS, HTTP 具有明顯更優的擴展性. 服務商可以在 443 端口上提供無數服務, 包括 DoH, 並且可以方便地擴展功能. DoT 和 DoQ 一般需要獨佔端口, 擴展能力完全基於 Plain DNS. 這是服務商視角的區別, 對於普通用戶來說暫時沒有明顯感知.

DNS 請求的處理速度上, HTTP 的處理速度確實可能比 Plain DNS 慢幾個 CPU 時鐘週期, 但這種差異在實際使用中可以忽略不計. 兼容性方面, DoH 可能會更主流, 因為對服務商來說 DoH 擴展性好.

當前主流平台對加密 DNS 的支持情況各有不同. Chromium 內核的瀏覽器支持 DoH. Windows 11 系統原生支持 DoH. Android 8 及以上版本系統原生支持 DoT. Android 11 及以上版本系統原生支持 DoT 和 DoH. macOS 系統原生支持 DoT 和 DoH. iOS 系統原生支持 DoT 和 DoH.

實際選擇建議

對普通用戶來說, 使用 DoH 會比 DoT 省心. DoH 相較 DoT, 多數時間提供更優的延遲, 少數時間提供相似的延遲. DoH 相較 DoQ, 多數時間有相似的延遲, 少數時間提供更優的延遲.

這個結論的前提是服務商提供 DNS over HTTP/3 服務. 如果服務商不提供 HTTP/3, DoH 和 DoT 沒有明顯區別. DoH 會在網絡質量好時, 自動使用 DoH/3 獲得較低延遲, 在網絡質量差時, 自動降為 HTTP/2. 這種自適應能力需要服務商實現, 不過主流服務商一般都實現了.

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

網絡協議的選擇需要綜合考慮多個因素, 包括運營商網絡質量, 服務商支持情況, 設備兼容性等. 對於大多數用戶而言, DoH 是一個平衡了性能, 兼容性和私隱保護的優秀選擇.

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

圍繞DNS查詢與用戶畫像構建，從原理與風險出發，基於公開標準與資料闡述可行的私隱保護策略與注意事項，避免臆測性的評測與實操。

2025 October 09

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存取限制問題，實現更安全的網絡私隱保護。包含完整配置指南和最佳實踐。

2025 August 25

🌐 DNS代理功能深度解析

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

為什麼需要DNS代理？

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

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

🚀 核心功能特性

DoH與DoT代理支援

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

智能DNS分流
- 自動檢測網絡環境
- 根據規則智能選擇直連或代理路徑
- 支援自訂分流配置文件
代理協議全面支援
- HTTP代理 (http_proxy)
- HTTPS代理 (https_proxy)
- SOCKS5代理 (socks5)
安全加密傳輸
- 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:password@proxy.example.com:8080"
export https_proxy="https://username:password@proxy.example.com:8080"

排除特定域名

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

export no_proxy="localhost,127.0.0.1,.local"

🔧 實際應用場景

企業網絡環境

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

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

校園網優化

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

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

家庭網絡保護

家庭用戶可以通過代理：

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

⚡ 技術優勢對比

特性	AdGuard Home	傳統DNS	寧屏DNS代理
DoH代理支援	❌	❌	✅
DoT代理支援	❌	❌	✅
智能分流	❌	❌	✅
配置複雜度	中等	簡單	簡單
網絡適應性	一般	一般	優秀
私隱保護	良好	一般	優秀

🛠️ 故障排除指南

常見問題及解決方案

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

可能原因：

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

解決方案：

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

Q: 代理連線逾時

可能原因：

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

解決方案：

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

Q: 特定域名解析異常

可能原因：

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

解決方案：

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

📊 性能監控

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

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

🔒 安全注意事項

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

🎯 總結與展望

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

未來規劃

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

🚀 立即體驗

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

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

AdGuardPrivate的更名公告

由於商標使用授權問題，我們的服務正式更名為「NullPrivate」。現有用戶的服務不受影響，僅官網和聯絡方式進行遷移。

2025 August 11

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

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

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

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

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

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

增加了DDNS功能

本文詳細介紹了新增的DDNS功能，包括其使用方法、功能特點及與傳統DDNS的區別。通過NullPrivate或AdGuardHome，用戶可以輕鬆設置私有動態DNS（DDNS），無需購買域名即可實現快速配置，並支援多平台和多種認證方式。

2025 July 21

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

概述

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

使用方法

nullprivate-ddns

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

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，確保隱私。

快速入門指南

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

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

更好的支援ECS

本文詳細介紹 AdGuard Home 中建議的 DNS 設定，特別是 EDNS 客戶端子網 (ECS) 的作用、原理、私隱影響以及替代方案，協助您優化 DNS 解析體驗。

2025 March 10

為了獲得最佳的 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服務，支援廣告過濾、DoT、DoH等特性。相比原版AdGuard Home增加了SSL證書管理、安全特性優化、代理功能等企業級功能

作者 寧屏團隊 | 2025 January 20

寧屏: 專注私隱保護的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 協議，為用戶帶來更快速、更安全的網絡體驗

2025 January 15

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

重要更新說明

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

h3的訪問

HTTP/3 技術深度解析

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

核心特性

基於 UDP 的 QUIC 協議
- 顯著減少連接建立時間
- 改進的多路複用能力
- 更智能的封包遺失處理機制
優化的效能表現
- 零握手延遲（0-RTT）
- 改進的擁塞控制
- 連接遷移支援
增強的安全性
- 整合 TLS 1.3
- 加密握手過程
- 降低中間人攻擊風險

建連過程對比

響應時間對比

連接建立過程對比

使用建議

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

注意事項

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

參考資料

推出自訂用戶端名稱功能

NullPrivate 推出自訂用戶端名稱功能，讓用戶可以更直觀地識別和管理不同裝置的 DNS 設定，大幅提升管理體驗。

2024 December 29

功能介紹

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

用戶端管理介面

設定指南

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

Android 裝置

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

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

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

iOS 裝置

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

iOS設定介面

瀏覽器設定（DoH）

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

原有格式：

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

新格式：

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

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

瀏覽器設定示例

使用建議

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

注意事項

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

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

深入剖析現代廣告生態系統的運作機制，探討廣告攔截對保護用戶私隱和注意力的重要性

2024 December 04

解構現代廣告生態

廣告商的利潤模式

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

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

轉化率之戰

在這場注意力爭奪戰中：

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

個性化廣告的真相

數據收集的深度

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

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

精準投放的陷阱

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

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

廣告對注意力的侵蝕

注意力經濟的代價

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

廣告策略的演變

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

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

保護自我的策略

核心防護措施

私隱保護優先
- 限制應用權限
- 控制數據分享
- 使用私隱保護工具
注意力管理
- 設置專注時段
- 建立資訊過濾機制
- 培養主動獲取資訊的習慣
消費決策把控
- 建立需求評估體系
- 延遲購買決策
- 保持理性判斷

技術支援：賽博城府

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

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

解決方案

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

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

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

服務資源優化策略說明

詳細說明 NullPrivate 服務資源優化策略，包括過濾器更新機制改進、並行請求優化建議及第三方清單使用規範，旨在提供更穩定可靠的服務體驗。

2024 December 02

背景說明

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

資源優化策略

1. 過濾器更新機制優化

現況分析

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

優化方案

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

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

影響評估

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

2. 並行請求策略

當前情況

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

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

使用建議

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

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

3. 第三方清單管理

安全考慮

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

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

後續規劃

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

基礎版內存上限調整

2024 November 29

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

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

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

如需協助

聯絡微信 private6688
或發送電郵 service1@nullprivate.com
請詳細描述你所遇到的問題, 我們會盡快回覆.

隨時為您提供支援服務

NullPrivate 致力提供優質的客戶支援服務，確保每位用戶都能輕鬆使用我們的產品。無論您遇到任何問題，我們都將隨時為您提供協助。

2024 November 20

快速入門指南

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

貼心服務支援

專屬指導

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

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

及時回應

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

如需協助

聯絡微信 private6688
或發送電郵 service1@nullprivate.com
請詳細描述你所遇到的問題, 我們會盡快回覆.

如何設定專用連結

寧屏私有服務配置指南：詳細介紹專用連結設定方法，包含Nginx反向代理配置。透過私有服務獲得完整後台管理權限，實現個人化廣告攔截和私隱保護。

2024 October 29

一些收費的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的功能。

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

介紹 NullPrivate 新版攔截規則，提供更全面的廣告過濾和安全防護能力，同時保持優良的兼容性

2024 October 28

規則更新說明

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

規則列表概覽

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

基礎防護規則

類別	AdGuard	功能說明
廣告攔截	Link	全面過濾各類廣告伺服器及廣告網站
追蹤防護	Link	阻止用戶行為追蹤及個人資料收集
重新導向防護	Link	防止惡意網址重新導向

內容過濾規則

類別	AdGuard	描述
詐騙網站	Link	專門用於欺騙用戶的網站列表
廣告	Link	廣告伺服器及廣告網站
加密貨幣	Link	加密貨幣及挖礦相關網站 ^{可能會影響正常加密貨幣網站}
毒品	Link	非法藥品相關網站 _{包括在港非法持有的處方藥}
全部規則	Link	包含所有非測試版清單的域名
Facebook	Link	屏蔽 FB 及其相關服務
詐騙	Link	詐騙網站
賭博	Link	所有賭博相關網站（合法與非法）
惡意軟件	Link	已知的惡意程式寄存網站
釣魚	Link	用作網絡釣魚的網站
盜版	Link	已知的非法下載網站
色情	Link	色情或宣傳色情網站
勒索軟件	Link	已知的勒索軟件寄存或包含勒索程式網站
重新導向	Link	把用戶從預期網站重新導向到其他網站的網域
騙局	Link	旨在欺詐用戶的網站
TikTok	Link	阻擋並防止於裝置定型複製
種子	Link	種子站點 _{可能阻擋合法軟件下載所用的合法種子網站}
追蹤	Link	專門拿來追蹤與收集訪客資料的網站

使用建議

循序漸進
- 建議先從基礎防護規則開始使用
- 按實際需要逐步添加其他規則
- 定期檢查並更新規則清單
效能優化
- 避免同時啟用過多規則
- 優先選擇與你最相關的規則
- 定期清理未使用的規則
問題排查
- 遇到誤攔截時請及時記錄並回報
- 可暫時停用特定規則作測試
- 必要時可用自訂白名單

注意事項

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

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

如需協助

聯絡微信 private6688
或發送電郵 service1@nullprivate.com
請詳細描述你所遇到的問題, 我們會盡快回覆.

試用版服務詳情

寧屏試用版服務：零風險體驗完整廣告攔截、防沉迷、私隱保護功能。支援自訂規則、裝置管理，全功能試用協助您評估服務價值。

2024 October 28

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

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

試用說明：

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

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

如需協助

聯絡微信 private6688
或發送電郵 service1@nullprivate.com
請詳細描述你所遇到的問題, 我們會盡快回覆.