[技术探讨] 使用 Reality 协议若将 dest 填写为 Cloudflare 托管的域名，会导致节点被 GFW 回源实锤

[Akesafe]

目前网络上大多数教程建议 Reality 协议的伪装域名避开使用 Cloudflare（CF）等的域名，理由通常是“防止被当成公共 CDN 薅羊毛”。但这掩盖了一个更致命的安全漏洞：将 dest 设置为 CF 域名的 Reality 节点，在面对主动探测时，GFW 可以通过“回源取证”直接拿到你 VPS 充当代理节点的实锤证据。

---

1. 背景：Reality 的盲转机制+ CF 的 SNI 路由机制

Reality 的核心防御机制是“镜像伪装”。当收到非授权连接（即没有正确私钥的探测请求）时，Reality 会触发 Fallback，作为一个纯粹的 TCP/TLS 透明转发器（Dumb Pipe），将流量盲转给配置的 dest 网站。

为了保证伪装的 100% 真实性，目前Reality 服务端默认不会去校验客户端发来的 SNI，而是将其原封不动地透传给 dest。

• 如果 dest 是独立大厂（如 microsoft.com），那没问题，目标服务器收到不匹配 SNI 的握手包，会直接拒绝连接。探测者什么都得不到。
• 关键来了！如果 dest 是 Cloudflare 节点： CF 的 Anycast 架构允许其任一边缘节点响应所有托管在 CF 上的域名。只要 SNI 属于 CF 网络，边缘节点就会放行并回源，并在CF-Connecting-IP字段和X-Forwarded-For里填入访问者的原始IP。

这给 GFW 提供了一条完美的“钓鱼取证”链路。

2. GFW 的回源实锤链路

假设你的 Reality VPS IP 为 IP_VPS，配置的 dest 为某个套了 CF 的网站。

• Step.1 GFW 注册并控制一个域名 evil-probe.com，接入 Cloudflare。
• Step.2 GFW 向你的 IP_VPS:443 发起 TLS 握手请求，并在 Client Hello 中将 SNI 指定为 evil-probe.com。
• Step.3 你的 Reality 节点未校验通过私钥，进入 Fallback，将包含恶意 SNI 的包盲转给 CF 边缘节点。
• Step.4 CF 边缘节点收到请求，解析 SNI 发现是 evil-probe.com（属于 CF 客户），随即建立连接，并将 HTTP 请求转发至 GFW 控制的源站服务器。
• Step.5 最关键的点 GFW 在其源站服务器上查看收到的请求头（如CF-Connecting-IP ）。该字段中显示是你的服务器的 IP——IP_VPS，而不是探测者（GFW）访问时的原始IP。

这样的话GFW就能100% 证明你的 IP 正在作为一个无限制的公共转发代理运行。 ，而且这种嗅探方式无法通过单纯地给无关流量限速来规避。

你可能想说：加个SNI匹配规则不就好了？很遗憾也不行

当SNI不匹配的请求到达VPS时，如果VPS不转发，它就和正常的CF服务器行为不一致了。因为使用了CF代理的域名指向的服务器的正常行为就是会转发给目标SNI的（只要这个SNI属于CF网络）。因此不转发照样会被识破。
悲催的是，这不是bug，而是reality的feature，很难从协议层面修复，现阶段只能自己检查并确保正确的配置。
因此，唯一的正确做法是：绝对不要 使用任何 Cloudflare、Fastly 等大型共享 CDN 网络作为 dest。

只要选择不带CDN的域名就无懈可击了吗

理论上是非常安全的，但也有一种特别麻烦的探测方式：
比如说：节点配置里dest填的是www.microsoft.com；探测者访问VPS_IP，SNI也同样填写微软的域名，然后登录一个微软账号，随后在登录日志里查看登录来源IP，如果显示为VPS_IP，则说明这个IP是一个reality节点。
这也意味着看似“完美”的reality协议可能并没有我们想像得那么无懈可击。
不过话说回来这种方式的探测成本很高，针对各种不同的目标网站很难规模化/自动化地进行。如果要防御的话，可以考虑选择一些不那么大众的网站或者没有登录/日志系统的网站。

[RememberOurPromise]

反代CF的小白给薅CF worker的小白提供ProxyIP，这不是挺好的吗？属于良性生态，应该予以鼓励，XD

[Akesafe]

哈哈哈角度清奇

[Fangliding]

火星救援之 cloudflare.com/cdn-cgi/trace cf转发一万个特征