博客 - NullPrivate技术分享与产品更新

• 如何保护青少年上网：手机管App，宁屏管浏览器
• 使用 list.adguardprivate.com 创建防沉迷清单
• 阿里云 DNS 免费版限速：免费午餐的终结与 DNS 自主权的再思考
• 从两次 1.1.1.1 事故看家庭 DNS 韧性建设
• DoH 与 DoT 技术对比分析
• DNS 隐私防护与用户画像防范策略
• 深度解析：宁屏DNS代理功能，突破网络限制实现隐私保护
• 宁屏去广告：基于DNS的智能广告拦截方案
• AdGuardPrivate的更名公告
• 增加了DDNS功能
• 更好的支持ECS
• NullPrivate - 基于AdGuard Home的增强版DNS服务
• 全面支持 HTTP/3 协议
• 推出自定义客户端名称功能
• 广告拦截的必要性：保护数字时代的注意力与隐私
• 服务资源优化策略说明
• 基础版内存上限调整
• 随时为您提供支持服务
• 如何设置专用链接
• 全新升级--增强版广告拦截规则
• 试用版服务详情

如何保护青少年上网：手机管App，宁屏管浏览器

如何保护青少年上网，先别急着买第三方管控 App。手机系统已经把高权限收回去了，终端软件越来越难真正管住设备；如果目标只是限制使用时长、使用时段和单个 App，系统自带的家长控制通常就够用。真正需要额外方案的，是浏览器这一层：看清访问记录、远程改屏蔽规则、拦住成人内容。宁屏做的是服务端 DNS 管控，补的是手机管不到的那一段。

终端管控为什么越来越难做成

很多家长会先搜“在手机上装一个管控软件”。这条路现在越来越窄。操作系统不会把核心权限轻易交给第三方应用；当一个 App 申请的权限过多时，应用商店也很难判断它是保护程序还是恶意软件。

安卓上这个问题更明显。过去十几年里，高权限应用里有相当一部分后来被证明是恶意程序。整机厂商因此在出厂时就把高级权限收进自家安全组件，不再对普通应用开放。Root 门槛也越来越高。结果是：你在终端上装的管控 App，常常既装不深，也管不稳。

这不是某一款软件做得差，而是权限模型变了。想靠一个第三方 App 接管整台手机，已经不符合现在的系统现实。

只想管 App，先用手机自带功能

现在的手机大多自带家长控制，苹果和安卓都类似。常见能力包括：

• 统计每个 App 的使用时长
• 限制每天可用时间
• 限制可用时段
• 按 App 单独开关

华为的“健康使用手机”、苹果的“屏幕使用时间”、安卓的数字健康，做的都是这件事。它们由系统提供权限，不需要再向商店申请一堆危险能力，卸载、绕过的成本也更高。

如果您对孩子的监管只需要管到 App，系统自带功能就能覆盖，不必额外为此花钱。宁屏也不会假装自己能替代锁屏密码、应用限额或就寝模式。那一层本来就该交给系统。

浏览器和远程屏蔽，才需要服务端

家长真正容易漏掉的，不是抖音能不能打开，而是浏览器里发生了什么。

App 管控看不到孩子在浏览器里访问了哪些网站，也很难在家长不碰那台手机时远程改规则。孩子换一个浏览器、开无痕模式、点开搜索结果里的陌生链接，终端侧往往只显示“用了 Safari / Chrome 20 分钟”，具体去过哪里并不清楚。

如果您希望同时做到下面几件事，就需要一个在服务端做管控的方案：

• 记录设备的上网域名，而不只是 App 名称
• 远程查看最近访问和拦截情况
• 按网站屏蔽，而不是只按 App 开关
• 拦截成人内容和明显不良站点
• 规则改完立刻对已接入的设备生效

这正是 DNS 过滤 适合补上的一层：设备发起域名查询时，服务端就能决定放行还是拦截，不必在每台手机上再装一个高权限 App。

flowchart TB
    A[孩子使用手机或电脑] --> B{要管什么}
    B -->|App 时长和时段| C[系统自带家长控制]
    B -->|浏览器、网站、远程改规则| D[宁屏服务端 DNS]
    C --> E[限制抖音、游戏、就寝时间]
    D --> F[记录访问、屏蔽站点、拦截成人内容]

宁屏补上服务端这一层

宁屏 是运行在云端的专用 DNS 保护服务，基于 AdGuard Home 增强。设备把加密 DNS 指过来之后，浏览请求会先经过您自己的服务实例，再决定是否解析。

对保护青少年上网来说，关键不是再装一个客户端，而是家长能远程看到、改到、拦住。

先看访问，再决定拦什么

私有服务提供访问记录和统计。您能看到最近请求过哪些域名、哪些域名被拦得最多，而不是只看到“今天用了多久手机”。

这和手机里的“使用统计”不是同一件事。系统统计告诉您 App 开了多久；宁屏告诉您浏览器和后台请求去了哪些站。两者叠在一起，讨论规则时才有共同事实，而不是只靠感觉。

更完整的日志说明见 访问请求日志，家庭场景的使用方式见 青少年网络安全保护指南。

成人内容和站点屏蔽放在服务端

宁屏可以启用家长控制、成人内容过滤，以及自定义屏蔽规则。拦截发生在域名解析阶段，不依赖手机厂商开放额外权限，也不要求孩子那台设备保持某个管控 App 一直存活。

成人内容过滤的原理和适用边界，见 成人内容拦截。它拦的是已知不良站点的域名解析，不是对页面里每一张图做识别；遇到新站、改名站或被套在正常域名后的内容，仍需要结合日志再补规则。

防沉迷清单管的是服务，不是锁屏

如果目标是学习时段关掉微博、TikTok 一类服务，宁屏提供的是应用级阻止清单，而不是再去做一套手机桌面管控。您可以从 list.adguardprivate.com 生成防沉迷直链，导入后再按时间表生效。

操作步骤见 创建并导入防沉迷清单，完整演示见 使用 list.adguardprivate.com 创建防沉迷清单。上网时段的设置见 设置上网时段。

这一层适合回答“晚上 9 点后不许刷短视频网站”，不适合回答“把整台手机锁死”。后者继续用系统自带功能。

两层一起用，比再买一个管控 App 更稳

比较常见的有效组合是：

设备接入后，规则在服务端统一生效。孩子换浏览器、换无痕模式，只要 DNS 还走宁屏，网站屏蔽和访问记录就还在。家长改规则时也不必把孩子的手机拿过来点来点去。

它做不到的事情也要说清：宁屏不能替代亲子约定，不能识别所有变种站点，也不能在设备根本没接入加密 DNS 时生效。保护青少年上网，技术是辅助，家庭里怎么谈规则 仍然更重要。

如果您已经确认需要服务端这一层，可以从 购买宁屏服务 开通实例，再按 使用指南 把设备指过来。只想先看效果，也可以从试用版开始。配置过程中有问题，直接找我们即可。

如需帮助

联系微信 private6688
或 发送电子邮件 [email protected]
请详细描述您所遇到的问题, 我们会尽快回复.

使用 list.adguardprivate.com 创建防沉迷清单

list.adguardprivate.com 用于从已收录的互联网服务中选择目标，生成可供宁屏防沉迷功能加载的规则清单。本指南以微博和 TikTok 为例，说明网页操作、生成结果的含义，以及如何将生成的直链保存到服务配置源。

生成的直链包含账号标识和服务选择信息。不要把完整直链、浏览器 Cookie、登录令牌或密码贴到公开页面、Issue 或聊天记录中。

操作演示

下面的视频从选择微博和 TikTok 开始，随后生成防沉迷清单，进入宁屏的“防沉迷”页面，展开“显示配置源”，添加并保存清单直链，最后勾选两个服务并保存。红色波纹标记了点击位置。

下载演示视频

网页操作

1. 在名单站选择服务

1. 打开 list.adguardprivate.com。
2. 在搜索框分别搜索“微博”和“TikTok”。
3. 选择目标条目：www.weibo.com 与 www.tiktok.com。
4. 打开顶部的“名单生成器”，确认已选择 2 个服务。
5. 保持“防沉迷规则 (JSON)”选项，等待“生成的名单”出现 blocked_services JSON。

服务名可能相同，但服务 ID 不一定相同。以域名 ID 精确确认，可以避免将 tiktok 这样的同名条目误加入清单。

2. 获取防沉迷直链

在名单生成器中点击“获取链接”。此功能需要名单站已登录。生成后的防沉迷直链大致包含：

/api/lists/anti-addiction?username=<账号标识>&ids=www.weibo.com,www.tiktok.com

请始终使用页面生成的完整链接，不要手动拼接 URL。网页预览会受“包含域名”和“包含广告域名”选项影响；而防沉迷直链由服务端生成，按服务 ID 返回相应规则。

3. 保存到宁屏服务配置源

1. 打开宁屏管理页面，进入“过滤器”中的“防沉迷”。
2. 点击“显示配置源”。
3. 点击“添加URL”。
4. 将名单站生成的防沉迷直链粘贴到“输入服务配置源URL”输入框。
5. 点击配置源面板里的 save，等待服务列表重新加载。
6. 勾选“微博”和“TikTok”。
7. 点击页面底部的“保存”。

配置源保存后，服务列表会按清单内的服务重建。此时微博与 TikTok 的内部 ID 是完整域名，因此应确认页面上显示的服务名称，而不要依赖旧的简写 ID。

验收方式

保存后重新进入“防沉迷”页面，检查以下内容：

• “服务配置源”中包含刚生成的防沉迷直链。
• 服务列表中存在“微博”和“TikTok”。
• 两个服务均为已勾选状态。
• 保存后刷新页面，勾选状态仍保留。

若服务列表为空，先检查配置源是否可访问，再确认名单站内的两个服务都已成功选中。若“获取链接”不可用，请重新登录名单站后再试。

常见问题

选择后名单仍为空

名单站使用浏览器本地存储保存已选择服务。请返回首页重新选择，进入名单生成器后确认顶部显示“已选择 2 个服务”，并等待服务详情加载完成。

配置源保存后服务列表变化

这是正常现象。宁屏会按配置源中可用的服务规则重新加载列表。保存后再勾选微博和 TikTok，并点击页面“保存”。

完成保存后，防沉迷规则会按照所选服务生效。

阿里云 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[手机/平板/电视/PC] --> 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 分钟内从日志定位“误拦截 vs 上游故障”？
• 是否给老人/孩子设备单独配置了家庭保护策略？
• 是否每月做过至少一次切换演练？

如果以上多数答案是否定的，那么“下一次公开 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. 享受更安全、更自由的网络体验

宁屏去广告：基于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过滤技术，为用户提供了一个高效、精准且注重隐私的广告拦截解决方案。我们致力于在保护用户免受广告骚扰的同时，确保不影响正常的网络使用体验。选择宁屏，让您的网络环境更加清爽、安全。

在数字时代，每个人都应该拥有一个干净、私密的网络空间。宁屏正是为了实现这一目标而设计，帮助用户重新掌控自己的数字生活。

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上游搜集, 本服务仍然按照隐私政策承诺, 不搜集利用任何信息。

NullPrivate - 基于AdGuard Home的增强版DNS服务

NullPrivate: 专注隐私保护的DNS服务

访问官网了解更多: NullPrivate

本项目基于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]
请详细描述您所遇到的问题, 我们会尽快回复.