DNS resolved to a reserved address：域名被解析到保留地址意味着什么
DNS resolved to a reserved address严重程度 High公网域名被解析到了保留地址（0.0.0.0、回环或内网地址），说明这个解析结果在本机或链路上被改写过。最可能是 hosts 文件残留条目或拦截类软件的过滤规则；第一步是检查 hosts 文件里有没有该域名的手工条目。
结论
这条错误的特殊之处在于：解析本身"成功"了。DNS 查询返回了地址、没有超时、没有报 NXDOMAIN——从流程上看一切正常。问题在于返回的地址根本到不了目的地：0.0.0.0 是"这台机器上的任意地址"，127.0.0.1 指回你自己，内网地址指向局域网里某台设备。
这类结果几乎不可能是域名所有者的本意，所以结论很直接：答案在送到你手上之前被人改过。改它的人可能是你自己（hosts 文件）、你装的软件（广告拦截）、你的网络（过滤型 DNS），或者你的公司（内网分离解析）。
适用环境
- 全部桌面与移动平台
- 任何依赖域名解析的场景
一分钟快速判断
connproof dns 目标域名看返回的具体地址：
| 返回地址 | 判定 | 首先怀疑 |
|---|---|---|
0.0.0.0 | fail | hosts 屏蔽条目、广告拦截、DNS 黑洞 |
127.0.0.1 / ::1 | fail | hosts 文件的经典屏蔽写法 |
10.x、172.16–31.x、192.168.x | warning | 企业分离解析（可能正常）或网关劫持 |
169.254.x | warning | 链路本地地址，通常是解析异常 |
0.0.0.0 和回环判为 fail，是因为公网域名解析到它们没有任何合理场景。内网地址只判 warning，因为企业环境的分离解析是正常配置——工具不会把合法配置说成故障。
这条错误代表什么
理解成因需要知道解析结果可能在四个位置被改写：
一、本机 hosts 文件。 优先级最高，早于任何 DNS 查询。把域名指向 0.0.0.0 或 127.0.0.1 是最古老的屏蔽手法，也是最容易被遗忘的——几年前为某个目的加的条目，今天还在生效。
二、本机的拦截类软件。 广告拦截、家长控制、部分安全软件会接管系统解析，对命中过滤名单的域名返回黑洞地址。这类软件的名单会自动更新，你没做任何操作，某天某个域名就被拦了。
三、网络侧的过滤型 DNS。 路由器内置的广告过滤、运营商或机构提供的"安全 DNS"，都会对特定域名返回黑洞地址。特征是换一个网络就恢复。
四、企业分离解析。 同一域名对内网返回内网地址、对公网返回公网地址，这是正常且常见的架构。所以内网地址只报 warning。
与相邻错误码的边界：解析失败（拿不到地址）是 DNS-001；解析明确回答"不存在"是 DNS-002；本页是解析成功但答案被改写。三者的排查方向完全不同。
ConnProof 如何判断
判定逻辑分两步，都是客观的：
第一步：这个域名是否应该解析到公网。 工具会排除 localhost、单标签主机名、.local、.internal、.home.arpa 这些本来就该解析到本地或内网的名字，也排除 IP 字面量。只有看起来是公网域名的名字才进入下一步——这避免了把正常的局域网解析误报为故障。
第二步：返回的地址落在哪个范围。 按 0.0.0.0/8、127.0.0.0/8、10/8、172.16/12、192.168/16、169.254/16（以及 IPv6 的 ::、::1、fe80::/10、fc00::/7）分类，黑洞类判 fail，内网类判 warning。
判定只依赖地址本身，不依赖任何名单或猜测。
最常见原因
- hosts 文件残留：为某个目的添加的条目长期未清理；
- 拦截软件的过滤名单更新：你没改任何设置，名单自己变了；
- 路由器或网络侧的过滤 DNS；
- 企业分离解析（内网地址场景，通常正常）；
- 恶意软件改写 hosts：较少见，但如果多个知名域名同时被指向可疑地址，值得用安全软件全盘检查。
Windows 排查步骤
- 打开
C:\Windows\System32\drivers\etc\hosts（需要管理员权限），搜索目标域名，删除相关行； - 管理员命令行执行
ipconfig /flushdns清缓存后复测； - 检查是否安装了广告拦截或家长控制类软件，查看其过滤名单与日志；
- 换手机热点复测——恢复则说明是原网络的 DNS 在过滤，与本机无关；
- 临时把网卡 DNS 改为其他可信服务器复测，能进一步区分是本机还是网络侧（测完记得改回，避免留下新的配置残留）。
macOS / Linux 排查步骤
- 检查
/etc/hosts； - 清缓存：macOS 用
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder，Linux 视发行版而定（systemd-resolved 用resolvectl flush-caches）； - Linux 额外确认
/etc/nsswitch.conf的 hosts 行没有被第三方软件改成怪异顺序； - 同样做换网络与换 DNS 的对照。
手机端排查步骤
- Android 的"私人 DNS"（DoT）若指向过滤型服务，会产生同样结果——排查期间设为"自动"或关闭；
- iOS 检查 Wi-Fi 详情里是否配置过手动 DNS；
- 手机通常无法编辑 hosts，所以嫌疑集中在网络侧与系统 DNS 设置；
- Wi-Fi 与蜂窝对照能快速区分是哪个网络在过滤。
如何区分本地问题和网络问题
| 证据 | 结论 |
|---|---|
| hosts 文件里找到该域名 | 本机（删除即可） |
| 换网络后恢复正常 | 原网络的过滤型 DNS |
| 换 DNS 服务器后恢复 | 原 DNS 服务器在过滤 |
| 所有网络都返回黑洞地址 | 本机软件或该域名被广泛拦截 |
| 只在公司网络返回内网地址 | 分离解析，属正常配置 |
仍未解决时收集什么信息
- ConnProof 错误码（DNS-004）与脱敏报告（报告中的地址已部分遮盖）；
- 返回的地址类别（黑洞 / 回环 / 内网）；
- hosts 文件检查结果与换网络、换 DNS 的对照结论；
- 操作系统版本与所用的拦截类软件名称。
禁止提交：完整订阅链接、密码、验证码、私钥、Token。
重新运行检测
connproof dns 目标域名 --format markdown --output dns-report.md修复后解析应返回公网地址，状态回到 pass。
相关文档
更新记录
- 2026-07-29：规则 v1 发布，同时在 DNS 检测中加入保留地址分类判定。