nginx和cloudflare的origin rules实现端口转发的区别

两者本质都是实现自定义域名的端口转发，因为cloudflare里面部署A记录来dns我们的vps的公网ipv4地址，它不能指定vps的公网端口，默认只支持80，443等有限几个端口。如果我们的服务开放在11451端口，那么只用cloudflare的DNS配置的话是无法访问成功的，所以就需要哟个到ngInx或用cloudflare的的origin rules额外设置规则.

ngInx本质上就是监听在我们vps的80端口，这个端口是cf可以直接发数据到的，但是如果没有在vps上装证书的情况下，cf要开灵活模式才行，不然发到80端口的是https加密的，开了灵活模式后，我们访问域名时，开启小黄云，首先访问到的是cf的服务器，然后cf的服务器再去连接我们的vps,只有我们与cf直接的通信是https，cf与vps之间是http明文的。如果用完全（严格）模式的话，就是全过程用https了，如果vps没有证书，ngInx就无法知道发来了什么东西。

vps配置好证书以后，nginx就可以快速对80端口发来的内容解密，然后内部明文转发到我们在vps运行的项目所在的端口，项目的程序就能处理到我们请求了，程序处理好后，就把明文交还给 Nginx，Nginx 再次加密，发回给 Cloudflare。

如果用的是origin rules的话，它只能实现端口转发，如果我们是灵活模式的话，cf可以直接帮我们把数据用http的明文形式发到我们vps公网ip里项目开发的端口比如11451，但是如果用origin rules的话，即便我们的vps里面放了证书，cf大概率还是只能用灵活模式（cf支持对子域名单独设置tls模式，在configruation rules里添加规则就行，可以不用全局改），除非我们部署的项目自带解密https加密的tls数据的功能，比如cliproxyapi这个项目就支持。否则的话，项目的程序最终接收到的是经过https加密的程序，它自身不会解密的话，就无法响应我们的请求了。

如果cf关闭了小黄云，我们的自己电脑的ip就会直接访问到vps的公网ipv4，区别就是不会先经过cloudflare的cdn服务器。那么此时cloudflare设置的无论是tls完全（严格）模式还是灵活模式，都不再起作用了，此时除非我们的vps里有通过使用 Let's Encrypt 等工具，去申请的一张真正的、全球公认的免费证书。如果还是用的cloudflare的证书的话，我们的https数据发过去给vps他是接受不了的

对于一些serverless平台，比如Vercel, Netlify：它们已经为你包揽了底层架构，自带高级 CDN。此时的 Cloudflare 只能老老实实做一个纯粹的 DNS 解析器（灰云）

补充一下例如vercel平台设置自定义域名的原理：

当你绑定自定义域名时，Vercel 会自动向 Let’s Encrypt 机构申请一张免费的 SSL 证书。申请的条件是：Let’s Encrypt 的机器人必须能直接通过你的域名访问到 Vercel 的服务器，以验证你是域名的真正主人。

小黄云的阻截：如果你开了小黄云，CF 的节点接管了流量。Let’s Encrypt 的机器人跑来验证时，撞到的是 CF 的大门，根本见不到 Vercel。

结果：Vercel 迟迟等不到验证，最终报错，你的博客永远卡在 Generating SSL Certificate 这一步，无法正常开启 HTTPS访问。

因此，只有当你在cf开灰云，证书才能申请通过

（证书通过之后，当你用域名访问时，流量是去到vercel的服务器，这个根本不是一台具体的服务器，而是一个极其庞大的全球边缘计算网络（甚至它的底层很多节点就是直接租用 Cloudflare 和 AWS 的）。当你把博客部署到 Vercel 时，它已经自带了 CDN 加速。）

如果对于我们自己购买的独立vps，在cloudflare设置域名dns时，用灰云的话，想用https连接就需要用比如向 Let’s Encrypt 机构申请一张免费的 SSL 证书放在服务器里面，这样就可以直接用https在灰云情况下通过域名访问到我们的vps了，否则如果没有ssl证书，就只能用http连接我们的域名了，在域名后面加 :端口号 走 HTTP 可以直接访问到我们在vps部署的程序，也可以用nginx反代端口，nginx也可以处理http。