众所周知，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接入。限于篇幅，感兴趣的可以搜索相关教程，有时间可能会单独开一帖子介绍相关有趣玩法。
讲了这么多，我们论坛里面的小鸡应该使用那种方式接入呢，其没有独立ipv6，但是有很多直连端口，可以使用Cloudflare Origin Rules 接入。
Comments | NOTHING