Contents
前言
在上一篇文章中(参见：家庭数据中心系列 cloudflare教程(二) CF整体方案流量序列中各技术节点功能简介)，我介绍了用户的访问请求从"进入CF的边缘网络"直到将请求"准备发往源服务器"这期间CF做的事，不过，在"进入CF的边缘网络"之前，CF如何让用户的访问请求进入边缘网络？以及"准备发往源服务器"之后，CF具体用哪种方式将用户的访问请求发到源服务器上呢？
这一篇文章就是来探讨上述2个问题。
如何进入CF的边缘网络？
什么是边缘网络？
CF的边缘网络是一种分布式网络架构，旨在通过在全球范围内部署数据中心和服务器，优化互联网流量的传输和处理。
CF边缘网络的简要描述如下：
- 全球分布
• 描述：Cloudflare 在全球 200 多个城市部署了数据中心，覆盖超过 100 个国家和地区(少数几个特殊国家除外)。
• 用途：确保用户无论身处何地，都能享受到快速和可靠的网络服务。 - 低延迟
• 描述：通过将内容和计算能力放置在离用户更近的边缘位置，减少数据传输的距离和时间。
• 用途：加快网页加载速度和应用响应时间，提升用户体验。 - 高可用性
• 描述：通过多点冗余和自动故障转移机制，确保服务的持续可用性。
• 用途：即使某些节点出现故障，流量也能自动切换到其他节点，保证服务不中断。 - 安全性
• 描述：在边缘网络上集成多层安全防护措施，包括 DDoS 防护、Web 应用防火墙 (WAF) 和恶意软件检测等。
• 用途：在靠近攻击源头的位置拦截和过滤恶意流量，保护网站和应用的安全。 - 边缘计算
• 描述：通过 Cloudflare Workers，开发者可以在边缘节点上运行无服务器代码，处理请求并执行计算任务。
• 用途：在用户请求到达源服务器之前进行预处理，减少服务器负担，提高应用性能。
说人话就是：边缘网络可以理解为CF整个网络的边缘部分，既可以很贴近实际的访问用户，又可以很贴近源服务器，通过将CF的各种服务部署到边缘网络，既可以让用户的访问请求快速得到需要访问的内容(比如通过CDN将源服务器的响应内容缓存到离访问用户最近的边缘网络的缓存里)，又可以拦截恶意的访问请求(比如在离恶意访问者最近的边缘网络的WAF里就拦截掉攻击，使其根本无法进入CF的网络，更不会到达源服务器)，还可以快速的回源(从离源服务器最近的边缘网络对源服务器发起请求并将其响应内容缓存)。
总之，CF的边缘网络和部署在其中的各种服务能够大大提高用户对应用的访问体验。
注：上述描述是理论上的，而实际上，国内Free计划的用户称呼CF为"负优化"，究其原因是因为CF并未真正将其骨干网络延伸进入国内(原因大家都懂)，而只是通过国内合作伙伴(以前是百度云，现在貌似是京东云)间接性的提供服务，主要服务对象是付费用户。
而对于国内一般的Free计划的用户(白嫖的站长们)，CF明显就不太顾得过来了：比如按照前面所说，回源的时候，CF应该从离源服务器最近的边缘服务器发起请求，但是现实中，回源的地址大部分被直接分配到美西的圣何塞数据中心，这下子回源一去一回都要跨太平洋了，这响应速度可想而知。再加上国内用户正常访问时会遇到类似的情况(有些区域甚至无法访问)，最终导致访问体验上，不使用CF反而感觉更快。
那国内Free计划的站长们有没有办法能提升自己站点从国内访问的速度呢？当然有，且听下节分解。
站长角度：如何让用户访问请求进入CF的边缘网络？
常规方式：小橙云
当域名托管在CF上以后(托管域名到CF上的配置步骤可以参见：家庭数据中心系列 通过国内备案云主机白嫖cloudflare实现国外快速访问国内)，新建一个主机名默认的代理状态是"已代理"，也就是通常所说的"小橙云"状态：
在这种状态下，用户使用DNS解析对应主机名时(例如上图中的abc.tangwudi.com)，虽然我设置的解析地址是110.110.110.110，但是用户实际解析的结果却是如下：
上图中104.21.76.18和172.67.185.18，就是CF边缘网络的入口IP地址，我前面提到的负优化，也是指的直接使用这个地方进行访问的效果。
那么，使用Free计划的站长有没有办法提升自己站点的访问速度呢？当然有。
加速方式1：优选IP
CF的优选 IP(Preferred IP)功能主要用于优化网络性能。
优选 IP 是指通过特定机制(比如地理位置、延迟等等)选择和分配的 IP 地址，这些地址通常是经过优化和筛选的，能够提供更好的连接质量、更低的延迟。像我前面提到的国内访问者被分配到美西的数据中心，但是如果使用了优选IP功能，则可能会被分配到国内云合作伙伴的地址上，这样一来访问体验就会得到大大的提升，可惜的是，优选IP目前是付费用户专项的服务，Free计划的用户无法享受(以前倒是有段时间能通过CF的国内合作伙伴白嫖，但是现在早已不行了，我没享受到，甚是可惜)。
不过，也有间接的方式享受优选IP功能(民间土方法)，就是CF的"自定义主机名"功能+国内域名供应商的解析功能+特定软件探测出的"自选IP"：
然后通过软件选出成功率最高，延迟最小的节点：
将合适的节点IP(上图中第一个IP)，在国内域名供应商的控制台中配置到需要优选IP的主机名对应的记录值里即可：
注1：这种方式选择的"自选IP"严格意义上来讲只能短期内生效，所示如果采用这种方式，需要频繁的进行测试以保持"自选"IP的可用性，效率不高。
注2：使用自定义主机名的方式来实现优选IP的教程网上有很多，大家感兴趣可以自己去搜索一下，后续如果有必要，我也会考虑专门用一片文章的篇幅来介绍详细的配置步骤，主要是我现在已经不用这个方案了(去年还是使用备案域名的时候用过)，所以暂时没啥动力写这个教程(关键也不是几句话能说清的～)。
加速方式2：Workers
利用 CF的Workers，可以通过编程灵活地控制流量路由和请求处理，优化网络性能，间接实现优选 IP 的效果，这主要基于Workers的以下几点特性：
- 边缘计算：
Workers 在CF全球分布的边缘数据中心运行，可以在靠近用户的位置处理请求。通过在用户附近处理请求，减少传输距离和时间，从而提升响应速度和减少延迟。
- 智能流量路由：
使用 Workers 代码动态选择最佳的后端服务器或 API 端点，根据实时的网络状况和性能指标来判断，实现流量的智能路由，选择最优的路径和服务器，达到优选 IP 的效果。
- 实时监控和调整：
通过 Workers 代码实时监控网络性能和服务器健康状态，动态调整流量路由，根据实时数据，自动调整路由策略，避免拥堵和故障，提高网络稳定性和性能。
- 缓存管理：
使用 Workers 控制缓存策略，在边缘节点缓存静态内容或预处理动态内容，减少对原始服务器的请求频率，加快内容传输速度，同时减少服务器负载。
配置worker加速网站访问的详细配置步骤参见文章：家庭数据中心系列 cloudflare教程(七) CF worker功能介绍及基于worker实现”乞丐版APO for WordPress”功能加速网站访问的实操、验证及相关技术原理研究。
注：这部分内容很重要，是对使用Free计划的站长们非常实用的一个功能，如果能够合理配置，就相当于拥有了一天100000请求免费额度的优选IP加速功能，而正常情况下，一般的个人博客100000请求根本用不完(除了特殊情况，例如被DDOS攻击，我就被整郁闷过～)，后续我会专门用一片文章的篇幅详细的描述配置过程。
访问者角度：WARP
CF WARP是一项提供更安全、更私密和更快速互联网连接的服务。它最初是作为 CF 1.1.1.1 DNS 解析器的扩展，现已成为一款独立的应用程序和服务。
WARP 功能的简要介绍如下：
- 增强的隐私和安全性
• 描述：WARP 加密用户设备和互联网之间的流量，防止数据被窃取或篡改。
• 用途：保护用户的上网隐私，防止黑客、中间人攻击和监视。 - 提高连接速度
• 描述：WARP 使用 Cloudflare 的全球边缘网络优化数据传输路径，减少延迟。
• 用途：加快网页加载速度和应用响应时间，提供更流畅的上网体验。 - DNS 加密
• 描述：WARP 集成了 Cloudflare 1.1.1.1 DNS 解析服务，通过 DoH (DNS over HTTPS) 或 DoT (DNS over TLS) 加密 DNS 查询。
• 用途：防止 DNS 查询被窃听和篡改，提升上网安全性和隐私性。
简单来说，WARP可以理解为一个"拨号程序"，只要能够"拨通"(连接成功)，就可以直接以加密的方式接入CF的边缘网络，如果其他需要访问的网站也是托管在CF上的，那么访问速度就可以大大提升。当然，我估计以前使用WARP的朋友主要目的反而是别的什么附带功能，但是其实WARP的本来功能就是用来接入CF的边缘网络而已～～。
总之，WARP算是从访问者的角度可以主动接入CF边缘网络的手段了(详细配置步骤可以参考我的另外2篇文章：家庭数据中心系列 合理利用cloudflare WARP来提高自己访问网站的速度(桌面版)以及家庭数据中心系列 云主机上部署cloudflare warp来提高网络访问速度(Linux cli版))。
注1： WARP+(高级版)，会使用 Cloudflare 的 Argo 智能路由技术(就是官方版的优选IP)进一步提升性能，正常来说这是付费功能，不过这个可以通过Zero Trust的team来免费使用。
注2：6月中旬以后，WARP+貌似稳定性也不好说了(以前我的WARP是从来连不上的，WARP+到是能稳定连上)，有时可以有时不行，估计比较看人品，这是因为WARP(+)是基于wireguard，而wireguard在混淆方面完全不行(毕竟本来人家设计出来也不是干这个的)，特征非常明显，所以很容易被针对(参考目前国内使用IPsec VPN的"规律间歇性"掉包～)，真要干扰和封锁也是非常简单的事情。
如何选择适合的回源方式
什么是回源？
回源是CDN中的概念：如果应用发布使用了CDN，那么当访问者请求的内容在 CDN 的边缘缓存服务器上不可用（缓存未命中或已过期）时，CDN 服务器会向源服务器（Origin Server）请求该内容，这就叫回源 (Origin Pull)。
注：可以将CDN看做一个启用了缓存功能的的反向代理服务器(本质上也是)，这样就容易理解多了：
1、如果访问请求的内容在反向代理上有缓存，则反向代理会直接把缓存的内容返回给访问者
2、如果访问请求的内容在反向代理上没有缓存，则反向代理会向上游服务器请求相应的内容，并将上游服务器的响应返回给访问者，这一步搁在CDN上就是回源。
可选的回源方式
公网IP地址回源
什么是公网IP地址回源？
使用公网 IP 地址回源（Origin with Public IP Addresses）功能是指在CF的内容分发网络（CDN）中，边缘服务器通过公网 IP 地址向源服务器请求内容，这是CF回源机制中的一种常见配置方式，允许用户将其网站或应用程序的源服务器配置为公网 IP 地址(需要源服务器拥有公网IP地址，v4或者v6地址均可)，以便通过CF的边缘网络进行内容分发和请求处理。
具体的配置步骤依旧可以参考文章：家庭数据中心系列 通过国内备案云主机白嫖cloudflare实现国外快速访问国内。
注1：这种方式其实就是前面讲到的"小橙云"对应的回源方式，配置也很简单，其实就是在DNS里的A记录配置正确的源服务器公网IP地址，然后打开"小橙云"即可，如前面所说，使用这种方式，不用担心源站地址暴露，因为对外发布且被用户解析到的都是CF的CDN地址。当然，所有CDN都是这种形式，所以也没啥稀奇～。
注2：Free计划中使用"小橙云"方式进行公网回源时，仅能通过"Origin Rules"规则改变回源请求的目标端口(适合源服务器未使用标准80,443的情况)，而无法改变其他参数(比如host等头部参数)，具备配置可以参考文章：家庭数据中心系列 通过cloudflare的Origin Rules解决建站有公网IP却没有合法的80、443端口的问题。
注1:采用这种方式只建议采用动态博客(因为静态博客随便找个免费托管商一丢就行)且部署的云主机是非国内云主机的朋友使用。
为什么不建议使用国内云主机作为源站呢？技术上其实哪管国内国外，但是不要忘了国内政策的特殊性，一来80和443端口不可用，需要备案(其他非标端口现在也不安全了)，二来现在国内对未备案域名的监管打击力度日益增大，SNI白名单制度的正式实施也只是时间早晚的问题，在这种背景下，何必去赌呢？
注2：CF默认支持的HTTP和HTTPS度端口很多，不止80和443，但是除了8080支持缓存之外，其他端口Free计划都不支持缓存，只支持回源
- HTTP
8080(可缓存),8880,2052,2082,2086,2095 - HTTPS
2053,2083,2087,2096,8443
附加福利：省心的SSL证书服务
全面转移到CF之后，最让我开心的一件事莫过于：再也不用在SSL证书上花费精力了。回想我从去年9月份开始研究建站以来，最让我烦心的一件事就是SSL证书的更新问题了(为了做各种测试，我的3级域名太多了，好几十个。。。)。最开始是折腾家里和云主机上反向代理的SSL证书(开始还不懂let’s Encrypt，都是白嫖当时腾讯云1年期的免费证书，结果直接把20个额度干满了)，到后来腾讯云CDN上的SSL证书，然后最后因为想统一管理所有SSL证书的更新又去研究ohttps～～～(参见文章：家庭数据中心系列 SSL证书一站式管理工具OHTTPS使用教程)，总之就是折腾。
而转到CF之后，一旦相关域名开启了"小橙云"，按照SSL/TLS的默认配置，所有对相关域名的访问请求到达边缘网络之后会被强制跳转为https，并且在边缘网络就完成了后续ssl证书的验证及加解密的操作，这些都是自动完成的，根本不需要站长们做任何操作。
当然，站长们也可以根据自己的需要，设置访问者、CF边缘网络、CF边缘服务器和源站之间的通信方式：
- 关闭(不安全)
访问者到CF边缘网络以及CF边缘服务器到源站之间都采用http。 - 灵活
访问者到CF边缘网络之间采用https，而CF边缘服务器到源站采用http。 - 完全
访问者到CF边缘网络之间采用https，CF边缘服务器到源站也采用https，但是源站的ssl证书不是合法证书。 - 完全(严格)
访问者到CF边缘网络之间采用https，CF边缘服务器到源站也采用https，源站的ssl证书是合法证书。
注1："完全"方式很有用，可以直接在源站使用超长期而非合法的证书(比如CF提供的15年证书)，这样就省去了源站再去折腾SSL证书的动作。
注2：其实国内CDN默认都是采用的"完全"方式，既：不校验源站证书的合法性。
采用Tunnel方式回源
CF Tunnel(也称为 Argo Tunnel)是一项使得服务器、应用程序和设备可以安全地连接到 Cloudflare 的边缘网络的服务，无需公开暴露公网 IP 地址。
CF Tunnel 功能的简单介绍如下：
- 安全访问：
• 描述：通过加密隧道，安全地连接内部网络、应用程序和设备到 Cloudflare 的边缘网络。
• 用途：避免直接暴露服务器的公网 IP 地址，防止外部攻击和未经授权的访问。 - 简化网络配置：
• 描述：通过 Cloudflare Tunnel，不需要配置复杂的防火墙规则或 VPN。
• 用途：简化网络管理，减少配置和维护工作量。 - 零信任架构支持：
• 描述：与 Cloudflare Access 集成，支持零信任安全模型，对用户和设备进行严格身份验证。
• 用途：确保只有经过验证和授权的用户才能访问内部资源。 - 自动化的流量管理：
• 描述：Cloudflare Tunnel 自动处理流量路由和负载均衡。
• 用途：提高应用程序的可靠性和可用性，优化流量路径。
一句话高概括总结：Tunnel就是直接打通CF边缘服务器和用户设备以及设备所在网络的加密隧道。从技术角度详细描述：就是直接打通CF边缘服务器和安装Tunnel客户端(cloudflared)的用户设备，并且可以借助安装Tunnel客户端的用户设备直接访问用户设备所在整个内网范围的地址(内网路由或者策略允许的前提下)。
举例说明：假设A、B是相同用户网段的2个设备，IP地址分别是192.168.100.1，192.168.100.2。A上部署了web1网站，对应域名是web1.tangwudi.com，端口是80；B上部署了web2网站，对应域名是web2.tangwudi.com，端口是81。
将cloudflared部署在A上，那如果我们要发布web1.tangwudi.com的网站，只需要如下配置：
B上的web2.tangwudi.com的网站配置如下，因为实际上CF是通过A上安装的cloudflared经网络去访问B，所以B的地址必须填192.168.100.2:81，如下图：
注1：B上看见发起http://192.168.100.2:81请求的源地址是A的地址192.168.100.1。
注2：使用Tunnel方式，相比公网IP回源更加灵活，比如：可以改变host以及一些连接方面的参数：
注3：不管任何场合，建站我都优先推荐采用Tunnel的方式：可以不用在意是不是有公网IP，是不是有合法的80和443端口，甚至不管是国内国外。
注4：使用Tunnel的唯一缺点是敏感时期稳定性难说，当然，那时所有CF上的网站访问都难说。而如果某个时候CF彻底退出国内市场(连合作伙伴都没了)，那么Tunnel方式也就彻底没了意义。
关于Tunnel详细的配置步骤参见文章：家庭数据中心系列 通过tunnel技术，让无公网IP的家庭宽带也能白嫖cloudflare实现快速建站(推荐)。
后话
最难写的"筑基"三部曲：3篇介绍CF整体方案中的主要功能点和关键概念的文章终于写完了，说实话，写这个比直接写某个功能怎么配置麻烦不知道多少倍，我以前之所以对CF系列教程的态度一直是能拖就拖不想写也是源于此：不写的话，从整体方案的角度来说没有骨架，后续不好延伸和细化；写的话，涉及面太大，会写得我头疼(并且我估计真正愿意看的人也没多少～)。
不过好在这次逼了自己一把，终于写完了，后续就简单了：只需要描述主要功能点的配置即可。当然，CF的功能远不止这些：比如R2(对象存储)，比如CF pages(静态页面托管)，还有其他我没用过的功能，不过这些功能并不是流量序列中的节点功能，关联性不是那么强，所以我后续用单独的文章介绍即可。
至于后续介绍功能模块的配置，我就不会按照流量序列的顺序来写了，因为实现某些功能需要一些功能模块配合来实现(比如DDOS攻击的完全防护需要DDOS功能模块和WAF功能模块配合来完成)，所以我会按照自己的逻辑顺序来写。
