前言

我在之前的文章中说过，如果基于cloudflare来建站，在回源方式的选择上，我一直只推荐使用Cloudflare Tunnel回源的方式，因为使用Cloudflare Tunnel(也叫 Cloudflare Argo Tunnel)与传统的Cloudflare 公网地址回源(直接代理)相比，具有很多独特的优势。

只不过，这几天我却发现Cloudflare Tunnel回源的一个”大”问题，这个”大”问题虽然并不涉及安全这种原则性的问题，但是却胜在够隐蔽(默认就生效)，而且会影响网站网址SEO的权重，关键会影响网站的形象(显得较low)～。

Cloudflare Tunnel的优势

虽然本文主要是讲Cloudflare Tunnel的”大”问题，但是实话实说，这个问题和其优势比起来完全微不足道(并且也有解决的方式)。为了避免喧宾夺主，本着先褒后贬的精神，还是先把Cloudflare Tunnel回源和传统公网地址回源的方式从安全性、配置和部署、网络性能和稳定性、可伸缩性和冗余、以及安全性和防御能力这5个方面进行全面比较，用来证明Cloudflare Tunnel回源的优越性：

1. 安全性

Cloudflare Tunnel：

• 隧道加密： Tunnel 会通过加密隧道（TLS）将流量从 Cloudflare 的边缘节点传递到你的源站。这意味着即使源站的服务器没有公开暴露在公网，也能安全地与 Cloudflare 通信。

• 无公网暴露： 使用 Tunnel 时，源站的 IP 地址不会暴露在外部，所有访问都通过 Cloudflare 中继。这有效降低了潜在的 DDoS 攻击、端口扫描和其他网络攻击的风险。

• 阻止未授权访问： 因为源站没有直接对外提供服务，所以黑客或攻击者无法直接访问源站。

传统回源（Cloudflare 直接代理）：

• 源站公开 IP 暴露： 在传统的 Cloudflare 代理模式下，源站的 IP 地址是公开的。虽然 Cloudflare 会代理请求，但源站本身的 IP 地址仍然暴露给外部，因此可能会受到 DDoS 攻击或其他网络攻击。

• 不提供加密隧道： 除非使用额外的加密配置，Cloudflare 在这种模式下并不会为与源站之间的连接提供额外的加密保护。

2. 配置和部署

Cloudflare Tunnel：

• 无需暴露端口： 在使用 Tunnel 时，源站不需要将端口开放到公网，所有的流量都会通过 Cloudflare 的边缘节点传输。你只需要在源站安装 Cloudflare 的 cloudflared 客户端，并配置好 Tunnel，就可以直接将流量转发到 Cloudflare。

• 简化防火墙配置： 由于源站不暴露端口，因此无需在防火墙上进行复杂的端口配置。只需允许 Cloudflare 的 IP 地址段访问你的源站，减少了配置和维护的复杂性。

传统回源（Cloudflare 直接代理）：

• 需要暴露端口： 在传统模式下，源站需要暴露端口（如 80 和 443）来与 Cloudflare 进行通信。此时，需要确保防火墙规则正确配置以允许 Cloudflare 访问。

• 更多的网络和端口管理： 需要更多的手动配置来确保源站能够正确响应 Cloudflare 的请求，尤其是在使用多个端口或服务的情况下。

3. 网络性能和稳定性

Cloudflare Tunnel：

• 智能路由： Cloudflare Tunnel 可以利用 Cloudflare 的 Argo Smart Routing 功能来优化流量的传输路径，选择最佳的路径来减少延迟，提高网站的响应速度和稳定性。

• 穿透防火墙： 如果源站位于内网或某些严格的防火墙后面，Cloudflare Tunnel 通过在源站和 Cloudflare 之间创建安全的隧道，可以绕过防火墙或 NAT 网络设备，确保流量传输不中断。

传统回源（Cloudflare 直接代理）：

• 网络负载和传输： 传统回源依赖于源站和 Cloudflare 之间的网络连接，若源站的网络带宽或稳定性不够，可能导致性能问题，尤其在流量较大时。

• 可能受限的智能路由： 传统的代理模式无法直接使用 Argo Smart Routing 功能，因此源站的网络连接质量可能会直接影响网站的性能。

4. 可伸缩性和冗余

Cloudflare Tunnel：

• 自动负载平衡和容错： Cloudflare Tunnel 可以与 Cloudflare 的负载均衡功能集成，使得流量可以智能地分配到多个源站。如果源站出现故障，Cloudflare 可以自动切换到备用源站，保证网站的高可用性。

• 对多地域支持： 如果你有多个源站分布在不同的地理位置，Cloudflare Tunnel 可以自动管理这些源站之间的流量路由，确保用户请求最优地到达离他们最近的源站。

传统回源（Cloudflare 直接代理）：

• 负载平衡和冗余配置较复杂： 在传统代理模式下，负载平衡和冗余配置通常需要在源站或 Cloudflare 控制面板中进行手动设置。如果你有多个源站，可能需要配置 DNS 或多个代理服务器来处理流量。

• 无自动跨地域支持： 对于跨地域的数据中心或多节点部署，传统回源模式下的流量分配可能不如 Tunnel 高效。

5. 安全性和防御能力

Cloudflare Tunnel：

• 保护内网应用： Cloudflare Tunnel 允许你将内网应用（如仅限公司员工访问的应用）安全地暴露给互联网，而无需将其直接暴露到公网。例如，如果你有一个内部服务，只想让特定的外部用户访问，它可以通过 Cloudflare Tunnel 安全地提供。

• 减少暴露的攻击面： 使用 Tunnel 时，源站的内部应用不会直接暴露在公网，攻击者无法直接针对这些内部应用发起攻击。

传统回源（Cloudflare 直接代理）：

• 暴露攻击面： 在传统的回源模式下，虽然 Cloudflare 代理层能为你提供 DDoS 保护和基本的防火墙功能，但源站暴露在公网的攻击面相对较大，特别是如果没有合理配置额外的防火墙和防护措施。

总结：Cloudflare Tunnel vs. 传统回源

特性	Cloudflare Tunnel	传统回源（Cloudflare 直接代理）
安全性	无需暴露源站，使用加密隧道，减少暴露攻击面	源站暴露 IP，存在被攻击风险，需额外配置安全措施
配置简便性	安装 cloudflared，简化源站配置和防火墙设置	需要手动配置源站端口，配置较为复杂
性能与稳定性	使用 Cloudflare 的 Argo Smart Routing，优化网络路径	网络性能受限于源站网络连接
可伸缩性与冗余	自动负载均衡，支持多地域应用的流量分配	需要手动配置负载均衡，冗余配置复杂
内网支持	可以安全地暴露内网应用，适合内部系统外网访问	主要用于公网暴露，无法方便地处理内网应用

所以，从以上比较可以看出，相对于传统的公网地址回源方式，Cloudflare Tunnel除了在某些比较苛刻的网络环境下运行不够稳定(比如一些有严格限制策略的企业出口设备后面或者使用一些限制策略比较变态的宽带运营商)之外，可以说全方面胜出，360度无死角，完全没有弱点。

问题的发现、分析及解决

无意中的发现

起因源于我的习惯性操作：在google上搜索自己的博客(大部分个人博主应该都有这个有点闷骚的习惯吧～)，正常来讲，如果从第一页开始，一页一页往后走到最后应该最多只有16页：

但是在第16页的最下面会有如下显示：

上图中的155条结果极为相似的条目是什么呢，直到我昨天无意中把鼠标放到了一条搜索记录上才发现类似下面的显示(原本怎么搜到那条记录我已经不记得了，正常搜索中应该会被隐藏)：

怎么会有个8443端口？然后我直接在谷歌里面用”blog.tangwudi.com:8443″进行搜索，结果吓了我一条：

虽然没有16页那么多，也有10页：

8443这个Cloudflare默认开放的端口让我有不详的预感，我在之前的Cloudflare系列教程第3章(详见：家庭数据中心系列 cloudflare教程(三) 如何进入CF的边缘网络及如何选择适合的回源方式)中曾经提到过8443：

只不过，我之前一直认为这个8443(包括其他的2053,2083,2087,2096)只是Cloudflare默认支持的源站服务端口(既如果源站使用这些端口就不用在Cloudflare上使用Origin Rules规则自定义回源端口)，但是今天搜到这个记录就让我有点懵逼了，于是我使用其他几个端口依次进行搜索，都有，只是不多(不像8443有10页那么多)，并且用浏览器加端口都可以访问：

为什么会这样呢？

Cloudflare默认开放的端口

在网上搜了一下，Cloudflare在其Anycast IP(泛播IP)默认开放的端口(8443、2053、2083、2087、2096)，是为了支持多种服务和协议，这些端口并非专门为每个用户的特定需求而开放，而是针对 Cloudflare 本身的基础设施和常见用途的配置：

1. Cloudflare 服务的默认端口

这些端口通常用于与 Cloudflare 的特定服务交互，或者与常见的第三方应用兼容。具体来说：

• 8443：这是一个常见的备用 HTTPS 端口，通常用于 HTTPS 协议的非标准端口。在很多情况下，企业级应用和某些网站服务会使用此端口作为安全的 HTTPS 连接。Cloudflare 默认支持此端口，用于某些与 Cloudflare 服务的通信或代理流量。

• 2053：此端口通常用于 Cloudflare 的 HTTP 流量代理。Cloudflare 会通过这个端口路由流量，通常用于支持各种协议的特殊服务。

• 2083：这个端口通常是为 cPanel 控制面板提供支持。cPanel 是一种广泛使用的网站管理控制面板，默认使用 2083 端口来进行 HTTPS 连接。Cloudflare 支持此端口，通常是为了代理来自 cPanel 的流量。

• 2087：与 2083 类似，2087 是为 WHM（WebHost Manager） 提供的端口，通常用于提供托管服务和管理服务器配置。Cloudflare 支持此端口是为了方便 Web 主机服务提供商的集成。

• 2096：这个端口用于 cPanel Webmail。Webmail 端口通常用于访问 cPanel 提供的 Web 邮件界面，Cloudflare 同样支持这个端口以便为用户提供兼容性。

2. 为什么 Cloudflare 会开放这些端口？

• 兼容性：这些端口对应许多常见的 Web 应用和服务，尤其是在 Web Hosting 和 企业托管 环境中。Cloudflare 为了确保最大范围的兼容性，会开放这些端口，尤其是对于使用 cPanel、WHM 等面板的托管服务提供商。

• 流量代理支持：Cloudflare 的核心功能之一是代理流量并提供性能优化和安全防护。为了支持多种服务和协议，Cloudflare 需要允许这些端口上的流量通过其网络进行路由，从而提供全面的 DDoS 保护、内容分发和性能优化。

• HTTPS 代理：对于需要通过 HTTP(S) 进行安全通信的各种服务，Cloudflare 默认开放 8443 和其他端口，作为 HTTPS 代理的备用端口。这使得用户和服务提供商可以在标准端口之外使用其他端口进行加密流量的传输。

3. 安全性考虑

尽管这些端口是 Cloudflare 默认开放的，但是它们并不会自动暴露给所有的用户。Cloudflare 实际上会在其边缘节点上代理这些端口上的流量，并提供 DDoS 防护、Web 应用防火墙（WAF） 和其他安全功能，从而保障流量的安全性。

以上的内容说人话说就是：在所有Cloudflare的 Anycast IP(访问托管在Cloudflare上的域名时解析到的IP地址)上，这些端口在4层上都是通的(可以建立tcp 3次握手，可以用telnet访问端口进行简单的测试，也可以用其他工具测试4层端口的可用性)，并且提供和443端口一样的防护，但是这些端口并不会直接暴漏给所有用户(就是用户默认情况下不能用域名加端口的方式进行访问)，也就是7层上正常应该是不通的。

---

对”www.visa.com“的8443端口进行4层可达性测试，的确是通的：

对”www.visa.com“的8443端口进行7层可达性测试(命令行下可以使用curl)，使用浏览器的确不能访问：

以上测试的确证明了Cloudflare官方的说法。

---

罪魁祸首：Cloudflare Tunnel？

说实话，这个还真是把我搞懵逼了，关键在Cloudflare的仪表盘里根本没有类似的选项可以设置，最后，我唯一能够想到的，就是回源方式的差别，会不会是因为公网地址回源和Cloudflare Tunnel回源这2种方式造成的差别？要确认这个问题，就必须找实际的例子进行比较，为了稳妥起见，传统公网回源和Cloudflare Tunnel回源的例子都需要。

传统公网地址回源

以我比较欣赏的一个博主(苯苯)的博客(https://blognas.hwb0307.com)作为传统公网回源测试的例子。
8443端口4层可达性：

2053端口4层可达性：

2083端口的4层可达性：

8443端口的7层可达性(7层只测8443端口就行，都一样)：

可以看到和前面www.visa.com的结果是一样的，也间接证明了传统公网地址回源默认使用8443端口进行访问都应该是超时。

Cloudflare Tunnel回源

这个稍微麻烦点，因为不认识使用tunnel方式建站的人，只能在网上直接找了，我准备专门找那种介绍Cloudflare Tunnel方式建站的个人博客，如果其域名解析的IP是属于Cloudflare的IP地址段，那大概率就是使用Tunnel方式建站的，这个想法真是太天才了有没有？就使用”Cloudflare Tunnel建站”的关键字，立马找到目标：

先验明下正身，确认下是否是使用的Cloudflare：

使用”ip138″查询IP信息，确认就是目标：

例行检查8443端口的4层可达性(2053、2083、2087、2096端口的检查就省略了，都是一样的)，是通的：

然后测试7层可达性：分别访问默认的443，然后是8443、2053、2083、2087、2096(第一个测试对象完整测试所有端口)，并且为了便于观测，使用curl命令进行访问；由于首页内容较多，不适合观察，所以选择/about.html(就是关于页面)进行测试。
默认的443端口：

8443端口：

2053端口：

2083端口：

2087端口：

2096端口：

以上已经基本可以证明我的”哥德巴赫无敌猜想”：基于Cloudflard Tunnel方式回源的网站，默认情况下除了标准的443端口，还有8443、2053、2083、2087、2096，均可以通过https的方式访问。

为了进一步验证，我还找了一些博客(域名解析都是Cloudflare的IP地址，并且只验证8443端口即可，其他端口就懒得一一截图了，都是一样的效果，大家感兴趣自行验证其他端口即可)：
1、https://liuhouliang.com:8443

2、https://mszx.me:8443

3、https://dmesg.app:8443

4、https://www.nodeseek.com:8443

…….

按照我这种思路用”Cloudflare Tunnel建站”为关键字在google上进行搜索，基本上每一页都会找到使用Tunnel建站的网站，接着会发现这些端口都是默认打开的。

原理分析(不喜欢技术细节的朋友可以跳过)

在”传统公网地址回源”和”Cloudflare Tunnel 回源”2种不同的回源方式下，端口行为的差异是由于它们的”流量转发方式”和”代理处理机制”的根本不同所导致的。

传统公网回源时端口超时的原因

1. Cloudflare 代理的端口限制

• 在传统公网回源方式中，Cloudflare 作为反向代理服务器，主要负责将用户的请求转发到你的源站。Cloudflare 对外暴露的标准端口是 80（HTTP） 和 443（HTTPS），即通过这两个端口，流量才会被正常代理到源站的指定端口范围(既HTTP协议的80、8080、8880、2052、2082、2086、2095端口，HTTPS协议的8443、2053、2083、2087、2096端口)，这里的指定端口范围的意思是选择其中任何一个端口都行，Cloudflare只要发现源站这其中的一个或者多个端口是可以访问的，就会把来自HTTP 80或者HTTPS 443端口的访问转发到源站对应协议的一个或者多个端口上。

• 对于其他非标准端口的访问请求（比如HTTP的2052或者HTTPS的2053），Cloudflare也会转发，但是却只会往”源站相同的端口转发“。

2. 源站防火墙和端口配置

• 虽然Cloudflare转发了非标准端口上的访问请求，但是源站的防火墙和端口设置决定了这些非标端口的访问结果。如果源站没有针对这些端口的正确防火墙规则，或者没有开启相应端口来接收流量，Cloudflare转发了流量，也会出现超时或连接失败的情况，这就是默认超时的原因，因为正常情况下源站根本不会开放这些非标端口(使用传统公网地址回源方式建站的朋友，可以自己进行验证)。

Cloudflare Tunnel 回源时所有端口都可以正常访问的原因

1. 加密隧道的端口灵活性

• Cloudflare Tunnel（cloudflared）与传统回源方式不同。它通过建立一个 加密隧道，将流量从 Cloudflare 的边缘节点转发到你的源站，而源站的实际 IP 地址和端口并不直接暴露给外部世界。

• 在这种模式下，Cloudflare 不再受限于 80 和 443 端口(可能是因为Cloudflare认为隧道足够安全所以放飞了自我？)，它将自己Anycast IP上所有默认开放端口上收到的访问请求都转发到了源站的指定端口上。

2. 隧道转发机制不受端口限制

• Cloudflare Tunnel 的核心工作机制是通过加密隧道将请求转发到源站。这个隧道是由 cloudflared 客户端负责处理的，它通过 HTTPS 与 Cloudflare 的边缘节点进行通信。

• 隧道内的流量被封装和加密后， Cloudflare 可以将它转发到任何指定的端口。无论是 8443、2053 还是其他非标准端口，Cloudflare 都能通过隧道将这些请求转发到本地的 cloudflared 客户端，再由客户端将请求交给源站处理。

• 这种方式让源站的端口暴露在 Cloudflare Tunnel 内部，而不再需要公开或配置防火墙规则来允许特定端口直接通过传统公网回源。

3. 源站端口与 Cloudflare 隧道内的分离

• 与传统回源不同，Cloudflare Tunnel 在隧道内建立了一个 “虚拟的代理层”，使得源站的端口不直接暴露在互联网上。源站的流量被加密隧道处理后才到达源站，因此它不受公网防火墙和端口屏蔽规则的限制。

• 隧道中的流量是完全由 Cloudflare 和 cloudflared 客户端控制的，源站本地的端口配置变得更加灵活，只需要保证 cloudflared 客户端能够正确地转发流量，Cloudflare 则负责通过隧道将流量送到正确的端口。

4. 无端口映射和端口转发需求

• 在传统回源模式下，如果源站配置了非标准端口，Cloudflare 必须允许这些端口的流量通过并进行相应的端口转发。但在 Cloudflare Tunnel 中，所有端口流量都通过隧道传输，外部用户与 Cloudflare 的交互并不依赖源站的开放端口。因此，任何端口都可以通过隧道访问，而不需要手动设置端口映射。

小总结

以上一通分析其实没啥意义，本质上就是看Cloudflare的喜好，目前看来，它就是在公网回源方式中，443端口以外的非标流量只转发到源站的相同端口，(http协议的那几个端口会被强制重定向到https，所以不考虑)；而在Tunnel模式下，就把所有https协议端口(443、8443、2053、2083、2087、2096)的请求全都转发到源站的特定端口上，就这么变态。

另：说不定啥时候它一不开心就改了呢？

带来的影响

其实吧，如果以上这些端口都一样要通过Cloudflare所有的安全检测，那这样到不会有什么安全方面的问题，这可能也是Cloudflare觉得无所谓的原因。问题的关键在于：因为这些完全是默认的行为，所以导致你可能完全没有意识到：除了https协议的443端口，还会有这么多端口的访问流量会被转发到你的源站！

不管Cloudflare是因为什么原因默认转发这些除了443之外的额外端口访问的流量到源站，事实行却可能给网站带来一些负面的影响。

1. SEO 问题

• 重复内容问题：虽然多个端口会指向同一应用，但如果这些端口能被公开访问（如 8443、2053 等），且没有进行 URL 规范化，那么搜索引擎可能会将其视为不同的页面，从而认为是出现了重复内容，进而可能会认为这些不同的 URL 是独立的页面(尽管它们实际上内容相同)，这样就有可能影响你站点的”SEO 排名“。

2. 端口管理复杂性

• 维护和管理压力：虽然 Cloudflare Tunnel 可以将流量路由到同一个后端应用，但如果你没有明确配置管理规则，多个端口的转发可能会增加源站的流量管理和维护难度。例如，不同端口的访问日志可能会变得冗杂，或者如果某些端口暴露了不必要的服务，这些端口可能会成为意外的流量入口。

• 流量不必要分配：虽然这些端口不会造成实际的安全隐患，但如果没有合理的访问控制，源站可能会承受更多的流量，这样的流量通常并不会带来额外的业务价值。

3. 品牌/用户体验影响

• 信任与专业性：如果用户或者潜在客户发现你的网站能够通过多个端口访问，尤其是一些看起来像是“技术细节”的端口（例如 8443 或 2053），可能会对网站的”技术水平”或”专业性”产生疑问(就是我前面提到的”较low”)。虽然大多数用户并不会深入了解后台设置，但多端口的暴露可能会让某些用户认为网站缺乏”精细的配置”或”管理不当”。

• 用户感觉：有些用户可能并不关心这些端口，但对”品牌形象”有较高要求的用户，可能会因此对网站的专业性产生怀疑。尤其是在竞争激烈的行业中，细节往往能影响用户的印象。

解决的办法

要解决除了80，443之外端口可以访问的问题倒是很简单，只需要在WAF的自定义规则最优先的位置加入如下一条规则规则即可(以我的域名举例，大家需要修改为自己的域名)：

http.host contains "tangwudi.com" and cf.edge.server_port ne 80 and cf.edge.server_port ne 443

要注意的是，上述命令只能用编辑表达式的方式写入，因为常规的GUI里没有这个可选项：

之后在访问其他端口就会被阻止，以我现在博客域名的8443端口为例：

注：为什么我要建议在最优先位置添加一条阻止规则呢？因为正常来说，如果我们要做网站的SEO，Cloudflare WAF的自定义规则中一般都有一条优先级很高的跳过规则来允许各种经过认证的自动化程序(包括搜索引擎的蜘蛛)的访问，如下：

如果阻止非80、443端口访问的规则在这条跳过规则之后，那么因为自定义规则的优先级问题，搜索引擎仍旧可以通过所有端口访问网站，只是常规用户的浏览器访问被阻止，所以搜索记录中，一条网址有多条搜索记录(不同端口)的问题依然存在，SEO问题依旧没解决。而如果这条阻止访问的规则在最优先的位置，那么所有对非标端口的访问(包括搜索引擎蜘蛛)都会被阻止，自然就解决了这个问题：

注：如果对Cloudflare WAF自定义规则不熟悉的朋友，可以参看我另一篇文章：家庭数据中心系列 cloudflare教程(四) CF WAF功能介绍及详细配置教程。

附加知识：部分其他”隐藏参数”

在 Cloudflare 的使用过程中，有一些 “隐藏参数”，这些并不是普通用户能直接接触到的，也不容易被察觉，但却能在一定程度上影响站点的行为、流量管理或安全性。这些参数通常属于 Cloudflare 更高级的 Worker 或 Firewall Rules 配置，它们涉及一些底层的流量控制和安全规则。这些参数对于开发者或站点管理员可能非常重要，但普通用户一般不需要直接了解或使用它们(类似上一节中用到的”cf.edge.server_port”参数)。

以下是一些类似于 cf.edge.server_port 的参数，通常不为普通用户所知，且通常需要更深入的 Cloudflare 配置权限：

1. cf.edge.server_port

• 功能：此参数是Cloudflare 边缘节点接收到请求时使用的端口，而 Cloudflare Tunnel 会将这些请求根据设定的隧道配置转发到源服务器上指定的端口。

• 使用场景：WAF自定义规则中用于控制通过特定端口的流量。

2. cf.client.ip

• 功能：返回发起请求的客户端的 IP 地址。虽然普通用户可以通过日志查看自己的 IP，但在 Cloudflare 中，这个值是非常常见的，用于设置防火墙规则、访问控制和速率限制。

• 使用场景：可以根据 IP 设置访问白名单或黑名单，甚至进行 速率限制 或 地理限制。

3. cf.ray

• 功能：这个是 Cloudflare 请求追踪标识符。每个请求都会生成一个唯一的 Ray ID，它用于在 Cloudflare 的后台查找和跟踪特定的请求。

• 使用场景：通常用于 调试 或查看请求的详细信息，帮助支持团队分析请求路径和问题。

4. cf.visitor.ip

• 功能：这是访问者的真实 IP 地址，当 Cloudflare 作为反向代理时，原始客户端的 IP 地址会保留在请求头中。

• 使用场景：同 cf.client.ip，可以用于设置 IP 限制、请求分析等。

5. cf.pragma

• 功能：该参数显示 Cloudflare 缓存相关的标头，具体来说，它展示是否启用了 Cache-Control 或其他缓存设置。通常用于调试缓存行为。

• 使用场景：当想检查或调整缓存设置时使用，特别是在 Cache Rules 中进行调试时。

6. cf.cf_access

• 功能：返回 Cloudflare Access 认证相关的信息，例如用户的身份验证状态、是否需要进行身份验证等。

• 使用场景：Cloudflare Access 是一种基于身份验证的应用访问控制工具，使用此参数可以设置应用的访问权限和认证机制。

7. cf.browser.bot

• 功能：这是 Cloudflare 用来判断访问请求是否来自 爬虫（Bot）的参数。如果为 true，表示请求来自机器、爬虫等非人类用户，可能会触发一些与用户行为无关的安全策略或规则。

• 使用场景：通常用于 WAF 防火墙规则中，过滤爬虫流量或执行 Bot 管理 策略。

8. cf.warp

• 功能：指示请求是否通过 Cloudflare 的 Warp 服务进行加速和加密。Warp 是 Cloudflare 提供的 VPN 服务，主要用于加速用户的互联网连接。

• 使用场景：可以用来为通过 Warp 加速的用户设置不同的路由规则或策略。

9. cf.edge.timing

• 功能：提供有关请求处理过程的性能信息，显示了从 Cloudflare 边缘节点到源站的延迟等信息。该参数对于性能分析和调优非常重要。

• 使用场景：用于 性能监控 和优化。

10. cf.edge.request

• 功能：该参数可以提供 Cloudflare 请求的更多详细信息，比如请求的 处理时间，从 Cloudflare 到源服务器的响应时间等。

• 使用场景：通常在 诊断工具 或请求优化中使用，帮助检测响应瓶颈。

11. cf.worker

• 功能：与 Cloudflare Worker 相关的参数，返回 Worker 服务的执行信息。Worker 是 Cloudflare 的无服务器计算平台，可以用来运行 JavaScript、处理请求、修改响应等。

• 使用场景：用于 自定义请求处理，比如修改 HTTP 请求/响应、增强缓存控制、访问权限控制等。

12. cf.mirror

• 功能：表示 Cloudflare 是否正在使用 镜像 数据，即某些场景下，Cloudflare 会根据内容类型或其他因素启用缓存镜像。

• 使用场景：适用于高级缓存和内容分发策略。

13. cf.origin.latency

• 功能：显示从 Cloudflare 到源站的延迟时间。可以帮助你了解源站性能，特别是在请求响应时间较长时。

• 使用场景：用于 性能监控，检测网络瓶颈。

14. cf.ratelimit

• 功能：返回请求是否受到 速率限制 的信息。这个参数通常与 Cloudflare 的速率限制功能结合使用，帮助检测流量是否超过设定的阈值。

• 使用场景：防止 DDoS 攻击、暴力破解等恶意请求的控制。

注：在上面讲的这些参数中除了”cf.edge.server_port”以外，其他参数的信息只是收集而来，我还没机会使用，不能保证功能说明一定正确，等以后有机会再来验证吧。

总结

这些控制参数大多属于高级功能，普通用户通常不会涉及到，但是对于流量分析、安全防护、性能优化和自定义配置这些管理、监控方面的需求来说却很重要，大多数情况下，只有具有管理员权限的用户或开发者才会接触到这些参数，一般的朋友当个附加知识了解下即可。

后话

其实，本文说起来对于一般的个人博主而言并无太大的实际作用：因为使用传统公网地址回源方式的朋友用不上，而使用Cloudflare Tunnel方式建站的朋友一般也未必在意这个事(除了一些比较关注站点SEO的博主)，所以本文充其量只能算是一个关于Cloudflare Tunnel技术探讨方面的文章。

不过，通过本文也引出了一个没啥用的小技巧，可以快速分辨出一个套Cloudflare的网站(域名解析出来是Cloudflare的Anycast IP地址的网站)是基于”传统的公网地址回源”还是基于”Cloudflare Tunnel回源”：只需要使用浏览器或者curl之类的命令行工具访问网站的8443(或者2053、2083、2087、2096)端口，如果是超时就是基于”公网地址回源”；如果可以访问或者显示被”blocked”，就是基于”Cloudflare Tunnel回源”。

注1：本文也算是在发现应用访问相关问题时，如何快速定位问题发生的层次(4层还是7层)以及如何进一步排查问题点及解决问题的一个比较有意思的案例(正常人肯定想不到Cloudflare会区别对待不同的回源方式吧)，以前我还在上班时，被冤枉自家设备有问题(搞过应用交付设备的朋友应该都懂)的时候经常需要自证清白，那种情况就少不了干这种定位排查的事，结果最后90%以上的问题都跟自家设备没关～。

注2：既然本文谈到了SEO，下一篇文章就写SEO相关的内容吧～。