一劳永逸：使用 DNAT 加速托管在 Cloudflare 上的所有网站
为什么会存在“优选 IP”的概念
Uniform software: The functionality of every data center and of every server inside a data center is identical. We use the same software stack on all the servers around the world. Each machine can perform any action, for any product. This enables easy debugging and good scalability.
Cloudflare servers don’t own IPs anymore – so how do they connect to the Internet?
Within a single data center, any of the servers can handle a connection for any of our services on any of our anycast IP addresses. This uniformity keeps things simple and avoids bottlenecks.
根据 Cloudflare 的说法，其遍布全球的数据中心组成了一个巨大的任播网络（Anycast），且在单个数据中心内，任何服务器都可以处理任何服务。所以一些人利用 Cloudflare Partner 接口，将自己域名解析至 1.1.1.1 和 1.0.0.1 的靓号 IP。但 IP 网络并非 Segment Routing，其数据包传递的路径由沿途每一个路由所决定。Cloudflare 并未因此将全部服务托管在同一个 IP 后（例如 1.1.1.1），它仍然为每个托管的网站分配两个固定的 IP 地址，不因地域而异。因此，当用户访问某些网站时，会被路由至北美，而某些则路由至香港地区。
我们可以使用 CloudflareSpeedTest 从 Cloudflare IP 段中随机选取地址进行测试，得出速度和延迟较优的 IP。
使用 Destination NAT (DNAT) 加速所有托管在 Cloudflare 上的网站
传统方案基于本地 Hosts 文件和 DNS 抢答，相对比较繁琐，并且只适用于少量的网站，例如在 NAS 上加速 PT 站 tracker 的域名。而 Destination NAT (DNAT) 方案则相当简单。
MikroTik RouterOS 的 DNAT 规则如下：
1 | # 需要将 Cloudflare IP 段添加到名为 cf 的 address-list |
如下是 iptables 方案，也可以搭配 ipset 使用，这样就只需创建一个 iptables 规则，然后维护 ipset 即可。
1 | # 需要为每个 CIDR 格式的 IP 段创建一个规则 |
以上规则只针对经过路由的流量，如果需要对于路由本身发出的流量进行重定向，还需在 OUTPUT chain 中添加一条规则。
验证加速效果
所有 Cloudflare 的 Endpoint 都提供了 /cdn-cgi/trace 页面，可以查看当前连接的 IP 地址和数据中心节点信息。在加速生效后，访问该页面应当看到 colo 字段为较低延迟的数据中心（例如 HKG）。
讨论和总结
本方案中 DNAT 起到了透明代理的作用。在用户侧，无法观测也无需修改任何配置，相对优雅。缺点是，短时间内的大流量传输可能会触发 GFW 策略，导致 IP 被空路由。因此务必结合 Netwatch 和 Scheduler 检测连通性，在失败时切换 IP 或禁用 DNAT 规则。
DNAT 仅修改了 IP 的 dst address，不会修改数据包的 payload，所以 HTTPS Client Hello 的 SNI 对中间设备是可见的。访问被 GFW 拉黑的域名仍然会遭遇 connection reset 等情况。
Chrome 已经默认启用 Encrypted Client Hello (ECH)。你还可以在这里检查当前浏览器是否支持 ECH。