域名被解析成 2001::1 哨兵地址？排查思路与 curl --resolve 绕过实测

现象

最近在一台 Linux 服务器上做自动化时遇到一个怪现象：访问某个站点一直失败，用 curl -v 一看，连接卡在 Trying 2001::1...，根本没到 IPv4 就超时了。用 dig +short AAAA 域名 验证，返回的赫然是 2001::1 ——一个看起来"合法"的 IPv6 地址。

更隐蔽的是，另一些域名返回的是 face:b00c::25de 这类地址。如果你认识 b00c 这个十六进制串，就知道它其实属于 Facebook 的地址段——明显不是目标网站的真实地址。

2001::1 是什么

2001::1 落在 IANA 保留的 IETF 协议分配段（2001::/23）内，不是可路由的全球单播地址。它和 0.0.0.1、127.0.0.1 一样属于特殊用途地址，正常情况下不可能是一个网站真实的服务地址。

这类"哨兵地址"通常是网络中间设备或本地 DNS 对特定域名应答时注入的：DNS 应答被替换成一个固定的黑洞地址，连接要么超时要么被重置。特点是 AAAA 查询有结果但必然连不通，而 A 记录查询可能正常或同样被污染。

排查三步

# 1. 确认拿到的是哨兵地址
dig +short AAAA example.com
# 返回 2001::1 / face:b00c::25de 等 → 被污染

# 2. 换可信 DNS 对比（DoH 走 443，不受 53 端口劫持影响）
curl -s "https://1.1.1.1/dns-query?name=example.com&type=A" \
  -H "accept: application/dns-json"

# 3. 用真实 IP 直连验证服务本身是否正常

绕过方法：curl --resolve

确认服务本身可达后，最快的方式是让 curl 跳过本地 DNS，直接把域名钉到真实 IP 上：

curl -sv --resolve workers.dev:443:104.18.26.90 https://workers.dev/

--resolve host:port:ip 的优先级高于系统 DNS，等价于临时的 /etc/hosts，不需要 root 改文件，也不会影响其它请求。程序化场景里（比如脚本要访问多个被污染域名），先通过 DoH 查出真实 A 记录，再逐个拼 --resolve 参数即可稳定复现"能通"的状态。

另一个思路是走代理出站（如 HTTPS_PROXY 指向本地代理），让域名解析发生在远端，本地污染自然失效。两种方法按场景选：单次请求用 --resolve 最轻量；长期访问走代理一劳永逸。

连带影响：安全工具的误判

还有个容易忽略的坑：一些安全校验逻辑会把保留地址段当作"私有地址"拦截（常见于 SSRF 防护），2001::1、face:b00c::/16 这类哨兵地址也会撞上同一规则，导致"解析成功了但被自己的防护拦下"，报错却指向一个看似不相干的位置。如果你的工具支持白名单配置（比如 IP 段黑名单里加例外），需要把 2001::1/128 这类哨兵地址显式加入排除，否则它们会被当成攻击载荷拒绝。

小结

排查口诀：先看 AAAA 是不是特殊地址段 → DoH 拿真实 IP → curl --resolve 钉住直连验证服务。三个动作基本能在一分钟内分清"是网站挂了"还是"是 DNS 被做了手脚"。