GFW 对 icu 顶级域名的临时性封锁

昨天
#DNS #Network

在 4 月 28 日 icu 顶级域名遭遇了 GFW 的封锁，导致本站点在国内网环境无法直接访问。

https://www.safwire.net/p/gfw-icu-tld

一开始发现站点无法访问一度以为问题是出在 Vercel 上，或许是 Vercel 的 NS 宕机了或者是被 GFW 封锁了。（因为最近 Vercel 的 AI Gateway 很火，很容易联想到因此上了 GFW 的名单）

Vercel DNS 托管方式

在查问题之前让我们回顾一下 Vercel 的域名解析是怎么运作的。

在 Vercel 某次控制台大改版之后域名管理被提升到了团队账号维度，Vercel 的 NS 会自动更新两条 ALIAS 类型的 DNS Records 用于路由所有的子域名到对应的项目域名配置。

NameTypeValue
*
ALIAS
cname.vercel-dns-x.com.
ALIAS
x.vercel-dns-x.com

前者是所有子域名路由，后者是 @ 根域名的解析路由，通常会指向其中一个项目。

域名 NS
↓
ns1.vercel-dns.com / ns2.vercel-dns.com
↓
ALIAS cname.vercel-dns.com.
↓
IP project server

DNS Records 概念

有几个相关概念做一些补充：

  • A 记录：是我最早接触的 DNS Records 配置方式，实际上就是将一个子域名影射到一个固定 IP 上。概念最简单、效率最高、配置完全固定。
  • CNAME 记录：记录值从固定 IP 变化为固定域名，优势就是其背后的 IP 可以是动态的，劣势就是需要多几次查询效率变低，不能用于根域名。
  • ALIAS 记录：这是一种非标准的记录，是 DNS 服务商提出来的扩展类型。实际上 ALIAS 是一种变相的 A 记录，由 DNS 服务商后台做解析并缓存，浏览器可以直接得到 IP 无需二次查询。 因此它解决了 CNAME 记录需要多次查询和不能用于根域名这两个问题。
  • Nameservers：权威服务器，缩写为 NS。早年间不少 DNS 服务商会屏蔽掉这个概念不怎么了解，最近几年 DNS 服务商都开放了 NS 的配置允许用户跨服务商解析域名。

排查思路

使用 Domain Information Groper 命令行工具查看 DNS 解析过程

通过 dig july.icu +short 查询 IP 解析是否正确

216.198.79.65
64.29.17.65

光看 IP 数字看不出问题，通过 whois 216.198.79.65 查看 IP 归属：

20260429151829070.png

从结果来看 IP 确实属于 Vercel，使用 dig july.icu NS +short 查看 NS 也确实解析到了 Vercel 的权威服务器。

ns2.vercel-dns.com.
ns1.vercel-dns.com.

看起来域名解析的链路也没有问题：

20260429152911887.png

到这一步最大的嫌疑是 IP 有误，虽然 IP 归属于 Vercel 但不一定是正确的项目 IP 也有可能是“占位 IP”，譬如域名停放或配置错误情况的默认 IP。

毕竟 NextJS 和 Cloudflare 最近也接连出过大事故（世界就是个巨大的草台班子），遂又在 Vercel 后台重置了 DNS 配置、重新绑定项目等操作仍然无法解决问题。

然后我灵机一动在电脑上开了网络代理之后居然可以正常访问了！！

这里有两种可能性：

  1. 代理之后请求的 DNS 根服务器不同，代理的服务器返回了“较早缓存的正确 IP 值”；
  2. 是 GFW 在作怪，而代理绕过了 GFW 所以没有问题。

第一种可能性在核对了解析 IP 相同之后被排除，只剩下第二种情况。那么 GFW 是通过何种手段作怪是解决问题的关键。

回顾之前的结论，域名解析路径是通畅无阻的，那么猜测是 GFW 屏蔽了所属 Vercel 的部分 IP。

反向代理

使用 Cloudflare 可以快速配置 域名反向代理（并且免费）。

20260429160855223.png

具体配置方式是：

  1. 修改 Vercel 后台域名管理的 NS 到 Cloudflare 的 NS
  2. 配置 Cloudflare 后台 DNS Records ，填入 Vercel 指定的 CNAME 或 IP。

这样一通操作之后 GFW 监测到的 IP 就从 Vercel 变成了国内友好的 Cloudflare 名下的 IP，理论上可以解决问题。

NS 的变更通常需要几分钟到几个小时，通过 dig july.icu @1.1.1.1 +short 查询配置是否传播到全球 DNS。

然后的然后问题仍然没能解决！所以 IP 的问题被排除。

SNI 污染

另一个重要特征是当尝试使用 curl 请求 july.icu 时，Vercel 和 Cloudflare 都表现出相同的特征：在 TLS 握手阶段被重置

Recv failure: Connection reset by peer
* LibreSSL/3.3.6: error:02FFF036:system library:func(4095):Connection reset by peer
* Closing connection

将相关的线索询问了 Claude 之后得到一种可能性：我的域名遭遇了 SNI 级别的封锁

SNI 污染原理

SNI 是在 TLS 握手阶段的一次明文通讯，作用是告诉服务器要访问的域名方便其返回证书：

Client Hello:
  SNI = www.july.icu

GFW 可以通过审查此次明文通讯来对部分域名实行拦截，拦截的方式通常有：断开（丢包）、TCP RST 注入（连接重置）。

从特征来看我的情况非常符合后者。当然我的网站本身不具备如此影响力，所以很容易推断出来可能是 .icu 这个顶级域名整个被屏蔽了。

截止 4 月 29 日，针对 .icu 的封锁似乎已经解除。不过 .icu 本身是一个“较敏感”的顶级域名，所以这个事件促使我更换了域名。