前言#
众所周知，Nat 机器由于大量用户公用一个 ipv4，很容因很容易被照顾，因此通常需要借助使用 cloudflare 使用。但是很多新手对如何套 cloudflare 一头雾水，即使是老手对于一些新的 cloudflare 特性也不是非常了解。还有一些朋友发现，其 nat 服务商的 ipv6 给的是 Hurricane Electric 的网络地址，早年 cloudflare 为了避免滥用 “cf-he” 接入方式完全禁止了 HE 的 ipv6 网段，因此失去了下面要讲的第一种方法的可能性，但这种情况下仍然可以成功利用 cloudflare 的，只是很多人不清楚，因此这里关于 “套 cloudflare” 进行一下总结。
套 cloudflare 其实是一个很土的说法，其实就是利用 cloudflare 作为 CDN，当发起一个 http (s) 请求的时候，先由 cloudflare 接受，然后转发到 nat 服务器。考虑到 cloudflare 作为网络基础设施，其被照顾的影响过于复杂因此很难直接照顾。
为什么 nat 机器不好套 cloudflare 呢，是很多人习惯了直接用 vps 的公网 ipv4 接入 cloudflare，但是 nat 是没有 ipv4 的，无法直接接入。还有一些服务商提供了 ipv6 only 的服务器，直接没有 ipv4 地址，更需要特殊对待。针对不同的情况，有几种变通策略。
使用 ipv6 接入#
最常见的，很多人第一反应就是使用 ipv6 接入，也就是添加 AAAA 解析。
常见的 nat 商家（比如 gullo/webhorizon/natvps.uk 等）都是提供 nat v4 + 独立 ipv6 地址的，因此虽然无法直接使用共享 ipv4 的 80/443 端口进行接入，但是可以使用独立 ipv6 接入，毕竟 ipv6 是独享的所有端口皆可以使用。如下图所示就是接好了。
这种接入方法是最容易想到，也是非常稳定的方案。但是有几种情况不能使用这种方法：
- 如果商家的 ipv6 网络是 Hurricane Electric，cf 禁止接入。比如 gullo 的部分地区（纽约等）
- 商家不提供 ipv6 地址，比如最近很火的 khanwebhost
使用 Origin Rules#
众所周知，nat 服务器之所以被称为 nat 服务器，是因为 ipv4 地址共享，每个人只能使用部分端口。那么我们能不能使用这些端口进行接入呢。在半年前，也许答案是否定的，因为 Cloudflare 支持使用的非标端口很少，并且都是低位端口号，nat 服务商的端口号一般都在 10000 以上，因此不好使用 cf 支持的非标端口。但是今年 cloudflare 免费开放了他们的 Origin Rules，这允许我们使用任何端口接入到 cf 网络。配置如下：
注意，vps 本地的 http 服务器（如 nginx）需要监听对应的非标端口。
使用服务商域名 forwarding + cloudflare 接入#
一般而言，nat 机器服务商，都提供一种服务，就是域名 forwarding，简单而言就是其宿主机器监听公网 80/443 端口，然判断收到请求的域名 (host/sni) 后 forward 到对应的 nat vps 实例的内网地址。
这种想法很好，但问题是很多他们用来监听 80/443 端口的公网地址阵亡了。虽然如此，这并不影响我们使用 80/443 端口接入 cloudflare，我们仍然可以使用 cloudflare 添加 A 记录到这些宿主机器的 ipv4 地址，然后在服务商面板上添加域名 forward 规则。
注意，vps 本地的 http 服务器（如 nginx）需要监听对应的内网地址。
使用 Cloudflare 允许的非标准端口接入#
cloudflare 官方支持一系列非标准 web 端口进行接入，如果你的 ipv4 被照顾了，但是仍然想要接入，除了上面提到的两种方法，还可以使用 Cloudflare 允许的非标准端口。具体可以用的端口如下：
那么你可能会问了，这些端口我的 nat 机器服务商都没有对我开放，怎么办。
nat 服务商除了提供域名映射以外，还提供端口映射，你可以把上面提到的 cf 支持的非标端口转发到内网 ip，然后使用 cf 添加 A 记录解析，最后使用非标端口访问你的域名达到目的。只不过这种方法显得比较鸡肋，作为一种后备方案好了。
使用 cloudflare argo 接入#
最后的最后，有些情况下服务商并没有提供公网 ipv4/ipv6，比如 pikapods 的容器服务，可以使用 cloudflare argo 接入。