Cloudflare WARP 与 Tunnel：VPS 网络经济学、性能、安全及弹性架构分析报告

Cloudflare WARP 与 Tunnel：VPS 网络经济学、性能、安全及弹性架构分析报告

I. 结构性挑战：公网 IP 经济学与 VPS 托管

互联网基础设施正面临 IP 地址资源分配的历史性挑战，这直接影响了虚拟私有服务器 (VPS) 托管的成本结构和运营模式。对公共 IP 地址的依赖，已成为系统管理员和自托管用户面临的主要经济和技术瓶颈。

1.1. IPv4 资源枯竭对云服务成本的直接影响

IPv4 地址的全球耗尽已将这些资源转化为高价值商品。在 2024 年，单个公共 IPv4 地址在转让市场上的价格已达到约 $50 1。这种稀缺性迫使云服务提供商调整其定价策略。大型云服务商（如亚马逊 AWS）已开始对 IPv4 地址收费，从而将资源成本压力转嫁给最终用户，特别是那些依赖动态计算分配或拥有大量闲置 IP 地址的小型运营者和 VPS 用户 2。这种结构性压力导致小型企业和个人预算面临更大压力。

尽管 IPv6 提供了几乎无限的地址空间，是解决 IP 稀缺性的长期方案，但其普及速度依然缓慢。截至 2024 年，通过 IPv6 访问 Google 的互联网用户比例约为 45% 1。完全过渡的挑战是巨大的，涉及复杂的遗留应用兼容性、大量的硬件和基础设施升级，使得在短期内对大多数托管服务提供商而言，完全放弃 IPv4 仍然不切实际 1。因此，运营者仍然需要寻求策略性的方法来规避日益昂贵的 IPv4 成本。

1.2. CGNAT 的普及及其对网络性能和安全模型的冲击

在 IPv4 枯竭的背景下，运营商级网络地址转换 (CGNAT) 已成为服务提供商缓解地址短缺的主要临时手段 4。CGNAT 允许数百甚至数千用户共享一个公共 IPv4 地址，从而实现网络规模的扩展 5。

然而，CGNAT 的广泛应用带来了重大的网络性能和安全模型影响。在性能方面，CGNAT 引入了额外的 NAT 映射层，这可能导致网络延迟增加，给 IT 团队的网络扩展带来操作上的挑战 2。在安全层面，CGNAT 彻底改变了传统的网络安全假设。许多安全机制，例如速率限制、地理定位和异常检测，都建立在“一个 IP 地址代表一个内聚实体或一个用户”的前提之上 5。在 CGNAT 环境中，单一的 IPv4 地址可能代表大量用户，当安全机制不加区别地应用时，可能导致严重的附带损害 (Collateral Damage)，尤其是在 IP 地址资源本就匮乏的欠发达地区，可能造成潜在的社会经济偏差 5。

1.3. Cloudflare 解决方案的经济战略定位

面对 IPv4 的成本通胀和 CGNAT 扩散导致的性能及安全挑战，Cloudflare 的 WARP 和 Tunnel 方案提供了一个战略性的替代路径。

IPv4 价格的持续上涨和 CGNAT 导致的性能/安全风险，共同导致了 VPS 领域的“IP资源惩罚”。Cloudflare 通过其免费层级服务，颠覆了传统的网络经济模型。Cloudflare Tunnel 解决了 入站 (Inbound) 流量对公共 IP 地址的刚性需求，而 WARP 则通过其全球网络解决了 出站 (Outbound) 流量的连接性和路由优化问题 6。通过将 DDoS 防护、路由优化和全球网络带宽作为其安全和性能核心业务的副产品免费提供，Cloudflare 使得用户能够彻底绕过对稀缺 IPv4 地址的直接依赖，从而规避了当前的 IP 经济瓶颈。

II. Cloudflare Tunnel：零公网 IP 入站服务架构分析

Cloudflare Tunnel 是实现 VPS 服务暴露而无需分配公共 IP 地址的核心技术。它通过利用 Cloudflare 的 Zero Trust (ZT) 架构，将传统的入站安全模型转化为基于身份和出站连接的更先进模型。

2.1. 技术原理：cloudflared 守护进程与出站连接模型

Cloudflare Tunnel 的架构核心在于 cloudflared 守护进程。这个守护进程安装在 VPS 或任何内部网络主机上，负责创建一个或多个到 Cloudflare 全球边缘网络的安全、持久、出站 (Outbound-only) 连接 7。

这些隧道利用 Cloudflare 的 Argo Smart Routing 技术，通常基于 HTTP/2 或 QUIC 协议在 TCP/UDP 端口 7844 上建立 9。关键在于，由于连接始终由 VPS 主机主动发起，外部实体无法在未事先验证和通过 Cloudflare Edge 的情况下直接连接到 VPS。这种架构彻底消除了传统网络中对公共 IP 地址和入站端口转发的需要 7。当请求从互联网访问时，它们首先到达 Cloudflare Edge，然后通过预先建立的隧道转发到 VPS 内部的服务。

2.2. 安全优势：天然的入站防火墙和 Zero Trust Access 集成

Cloudflare Tunnel 架构的固有特性提供了一个强大的安全优势，即最小化攻击面 (Attack Surface Reduction)。它实现了正向安全模型 (Positive Security Model) 9。由于所有的入站流量都被阻止，VPS 的防火墙配置可以大大简化，只需允许 cloudflared 所需的特定出站连接（TCP/UDP 7844）即可 9。

此外，即使在免费计划中，用户也能立即受益于 Cloudflare 强大的安全能力。Cloudflare 提供了业界排名第一的 DDoS 缓解解决方案，网络容量高达 449 Tbps，远超已知最大 DDoS 攻击的规模，确保流量在到达源站之前就得到清洗 6。

更重要的是，Tunnel 是 Cloudflare Zero Trust 架构的基石。它可以与 Cloudflare Access 结合，为内部服务（包括 SSH、RDP 或任意 L4 TCP/UDP 流量）强制执行基于身份和上下文的最小权限访问策略 12。这种模式有效地取代了传统的 [虚()专()网()] 访问，通过持续验证用户身份、设备状态和权限，将网络安全边界从 IP 地址推向身份认证 13。这种 L4-L7 统一策略管理极大地简化了 VPS 的安全管理，解决了传统 IP 暴露带来的风险。

2.3. 免费层级的功能边界与应用限制

Cloudflare 为其免费层级用户提供了慷慨的 Tunnel 资源，以鼓励用户体验其 Zero Trust 平台。例如，用户可以创建多达 10 个 WARP 连接器，每个隧道配置多达 1,000 个路由，并支持多达 25 个活跃的 cloudflared 副本 15。这种限制对于大多数自托管用户或小型企业而言绰绰有余。

对于测试和开发用途，用户甚至可以使用 TryCloudflare 工具，在不需要拥有域名或更改 DNS 配置的情况下，快速启动临时的、随机子域名的免费隧道 10。

虽然免费计划在功能上非常丰富，但用户必须认识到其服务质量 (QoS) 的潜在限制。尽管 Cloudflare 没有对免费流量设定硬性的带宽上限 6，但根据行业惯例和用户报告，免费流量通常被视为 Cloudflare 的闲置或过剩带宽资源，在网络拥塞时可能会被降级处理 (deprioritized)，优先级低于付费用户的流量 16。

以下表格总结了 Cloudflare Tunnel 免费方案的关键限制与功能：

Table 1: Cloudflare Tunnel 免费方案关键限制与功能

特性 (Feature)	限制/政策 (Limit/Policy)	分析要点 (Analysis)
入站连接需求	零（Outbound-only） 7	彻底消除 VPS 对公网 IP 的依赖
DDoS 保护	全球顶级缓解 (449 Tbps) 11	包含在免费计划中
Tunnel 副本数 (Replicas)	每隧道 25 个活跃副本 15	提供高可用性和故障转移 (HA)
带宽/流量限制	无硬性上限 (No hard cap) 6	基于公平使用原则，免费流量可能被降级 (deprioritized) 16
协议支持	HTTP/S, L4 TCP/UDP (需 ZT Access) 8	广泛支持 Web 和基础设施服务

III. Cloudflare WARP：出站网络优化与 IPv6 接入

Cloudflare WARP（或作为 WARP Connector 部署在 VPS 上）是一种高性能、安全且注重隐私的 [虚()专()网()]/隧道解决方案，专注于优化出站网络连接，并为缺乏原生 IPv6 支持的环境提供连接性。

3.1. WARP 协议栈解析与高性能基础

WARP 客户端的设计基于现代化、高性能的 WireGuard 协议 17。Cloudflare 使用了其内部定制的 WireGuard 实现——boringtun，其代码库规模远小于传统的 IPsec 实现，提高了可理解性和安全性 17。

在架构层面，WARP 客户端通过虚拟接口转发 DNS 和网络流量到 Cloudflare 的全球网络 19。它通过 UDP 使用 WARP 隧道（基于 WireGuard 或 MASQUE）发送 IP 数据包，并建立 DoH (DNS over HTTPS) 连接来处理 DNS 请求 19。对于 VPS 场景，WARP 客户端可以作为 WARP Connector 部署 20，这意味着 VPS 上的所有出站流量都可以通过 Cloudflare 的优化网络进行路由。

为了保证性能，连接的 MTU (Maximum Transmission Unit) 配置至关重要。WARP 客户端支持 PMTUD (Path Maximum Transmission Unit Discovery) 功能，允许客户端动态调整数据包大小，推荐 MTU 为 1381 字节，从而优化连接性能 21。

3.2. 解决 IPv6 痛点：为缺乏原生 IPv6 的 VPS 提供连接

WARP 在解决 VPS 托管中的 IPv6 接入问题上发挥了关键作用。鉴于许多 VPS 供应商在底层基础设施中仍主要提供 IPv4 或对 IPv6 收取额外费用，WARP 提供了一个免费的替代方案。当 WARP 客户端（作为 WARP Connector）启用时，它会在设备上创建一个虚拟接口，从而允许该 VPS 获得 IPv6 连接能力，即使底层宿主网络不提供原生 IPv6 地址 19。

此外，WARP 利用 Cloudflare 全球 330 多个数据中心和 Argo Smart Routing 骨干网的优势，提供路由优化。许多用户面临 ISP 或 VPS 供应商路由不佳的问题，导致高延迟。通过将流量注入到 Cloudflare 的网络，WARP 能够绕过这些低效的路由。例如，在某些对延迟敏感的应用场景中，用户报告显示延迟可以从大约 230ms 显著降低到 150ms 23。WARP 提升了网络连接的可预测性 (Predictability)，因为它抽象掉了底层 VPS 供应商的路由质量，强制流量通过更优化的路径。

3.3. 隐私与数据处理承诺的深度审查

作为 Cloudflare Zero Trust 平台的一部分，WARP 对数据隐私做出了明确承诺。Cloudflare 承诺不会出售、出租或分享用户的个人信息 25。当 WARP 客户端启用时，仅收集有限的 DNS 查询和流量数据，但明确排除数据载荷 (payload) 25。

这些有限的数据包括应用安装 ID、通过 Cloudflare 网络传输的数据量和平均速度 25。对于其公共 DNS 解析器 (1.1.1.1)，有限的非个人身份查询数据仅存储 25 小时 26。这种高标准的隐私承诺，使其成为那些寻求路由优化和连接性，同时对数据记录有顾虑的用户群体的有力选择。

3.4. 平台兼容性挑战与 MTU 管理

尽管 WARP 提供了强大的功能，但在特定环境中仍存在兼容性挑战。例如，在 Linux 主机上，当 Docker 容器使用默认桥接网络时，启用 WARP 可能会导致连接问题 22。这是因为 Docker 在 Linux 上无法执行 WARP 所需的底层网络 MTU 更改 22。对于在 VPS 上依赖 Docker 进行应用部署的用户来说，这要求他们必须采用更复杂的网络配置或在主机级别而非容器内管理 WARP Connector。

此外，由于 WARP 依赖虚拟网络接口和路由表修改，用户必须确保其操作系统环境（如 Windows 上的 Teredo）不会与 WARP 争夺 IPv6 流量的路由控制权，否则 WARP 客户端将无法提供 IPv6 连接 22。

IV. 依赖性与关键业务局限性风险评估

采用 Cloudflare WARP 和 Tunnel 解决方案，尽管在成本和安全方面带来了巨大的优势，但也引入了对单一中心化平台的固有依赖，并在某些关键业务场景中存在难以克服的技术限制。

4.1. 中心化依赖：Cloudflare 作为单一故障点 (SPOF) 的风险

将核心入站和出站路由功能委托给 Cloudflare 的全球网络，本质上引入了中心化依赖风险。尽管 Cloudflare 致力于提供极高的弹性，但历史数据显示，其平台并非完全免于中断。

Cloudflare 曾经历过涉及多个核心服务的长时间中断，包括控制平面、Workers KV、Access、WARP 和 Cloudflare 仪表盘 27。这些中断，即使是发生在控制平面而非数据平面，也可能导致 Tunnel 配置无法更改、WARP 客户端无法认证或服务不可访问。因此，专业用户在部署时必须将 Cloudflare 平台本身视为一个潜在的单一故障点，并制定相应的灾难恢复策略。

4.2. 关键业务限制：邮件服务器 (SMTP) 的 IP 信誉挑战

在使用 Cloudflare Tunnel 免费方案自托管服务时，最大的业务限制之一是邮件服务器 (SMTP) 的运营。这个问题源于 Tunnel 架构的出站流量使用了 Cloudflare 的共享出口 IP 地址。

由于这些共享 IP 地址池（类似于 CGNAT 环境）被大量用户用于各种流量，它们的 IP 信誉通常较低 29。对于电子邮件服务而言，IP 信誉至关重要。试图通过 Tunnel 共享 IP 发送出站邮件时，主流邮件服务提供商（如 Microsoft Outlook）可能会因为 IP 信誉不佳而拒绝或暂时限速这些邮件，导致邮件无法可靠送达 29。

这种技术限制实际上是对需要高信誉 IP 服务的用户的有效 paywall。用户若要成功运行邮件服务器，必须绕过 Tunnel 的出站流量，并采用独立的解决方案，例如：

1. 在拥有干净 IP 地址的专用 VPS 上设置 SMTP 中继。

2. 使用商业 SMTP 中继服务（如 SendGrid 或 Amazon SES）作为 Smarthost 30。

这意味着，尽管 Cloudflare Tunnel 免费解决了入站 Web 访问的成本问题，但对于需要高信誉 IP 的核心业务，用户仍需承担部分基础设施或服务费用，从而部分抵消了“零公网 IP”的经济优势。

4.3. 非标准应用限制与 L4 协议支持的边界

Cloudflare Tunnel 主要设计用于处理 HTTP/S 流量，以及通过 Zero Trust Access 保护的 L4 基础设施服务（如 SSH、RDP） 8。对于其他任意 L4/L7 协议流量，尤其是在需要高性能和精细控制时，会受到限制。

Cloudflare 明确规定，将 Cloudflare Tunnel 源站指向付费服务 Spectrum（用于保护任意 TCP/UDP 应用的服务）的应用是不受支持的配置 32。这意味着对于复杂的、非 Web 的 L4 协议，用户如果需要 Cloudflare 的高级保护和性能特性，必须升级到付费的 Spectrum 或 Argo Smart Routing 服务 33。这种技术边界策略性地引导了有复杂网络需求的用户转向付费产品，体现了其“免费吸引，付费转化”的业务模型。

V. 故障转移与弹性架构设计 (SRE Focus)

在 Cloudflare Tunnel 这种中心化依赖的架构中，高可用性 (HA) 和故障转移策略至关重要。Cloudflare 提供了原生 HA 机制，并结合了付费组件以实现更高级别的弹性。

5.1. Cloudflare Tunnel 的原生 HA 机制：多副本部署

Cloudflare Tunnel 提供了原生的、免费的高可用性解决方案，即通过部署多个 cloudflared 副本 (Replicas) 并使它们连接到同一个 Tunnel ID 34。

冗余与容错： 每台主机上的 cloudflared 副本会建立四条独立的、持久连接到 Cloudflare Edge，以确保在单个连接、服务器或数据中心发生故障时，服务仍能持续可用 35。用户在部署时可配置多达 25 个活跃副本 15。

被动 HA 路由决策： 这种多副本策略主要用于提供可用性 (Availability) 和基本的故障转移。它不提供复杂的流量控制算法。当请求到达 Cloudflare Edge 时，系统会默认将请求转发给地理位置最近的健康副本。如果最近的连接失败，Cloudflare 会重试其他可用连接，但不保证特定连接的选择顺序 35。因此，专业用户应该在至少两个独立的 VPS 或容器上部署 cloudflared 副本，以防止单主机故障导致服务中断。这种依赖于 Cloudflare 边缘的随机/地理最近性选择的 HA 机制，可以被描述为一种“被动 HA”。

5.2. 结合商业组件的进阶故障转移策略

对于对服务质量 (QoS) 有更高要求、需要主动健康检查和精细流量控制的关键工作负载，用户需要结合付费的 Cloudflare Load Balancer (负载均衡器) 组件，实现“主动 HA”。

Load Balancer 集成： Load Balancer 允许用户主动监控源站的健康状态，并根据预设的算法（如地理路由）将流量智能地分配给健康的 Tunnel 后端 37。在 Load Balancer 设置中，Tunnel 可以作为一个池 (Pool) 的后端地址，使用 UUID 形式的 cfargotunnel.com 域名作为端点 38。通过这种方式，Cloudflare 可以实时将流量导向健康的 Tunnel 连接，实现零停机故障转移 37。

零停机故障转移 (Zero-Downtime Failover)： Cloudflare 的 Zero-Downtime Failover 机制在请求连接第一个源站失败时，会立即无缝地尝试连接同一 Load Balancing 池中的其他源站 IP 或 DNS 记录 39。虽然这在每一次失败尝试时都会增加一点延迟，但它在主动健康检查策略生效之前提供了瞬时保护，显著提高了 L7 服务的弹性 39。

5.3. 应对 Cloudflare 服务中断的故障转移策略

鉴于 Cloudflare 自身的历史中断记录 27，系统管理员必须具备在 Cloudflare 平台发生严重故障时，将客户端流量从 Zero Trust 网络中安全释放的能力。

Global WARP Override (紧急断开机制)： Cloudflare Zero Trust 提供了 Global WARP Override 功能作为紧急安全开关。当管理员启用此功能时，Cloudflare 会强制断开所有连接到该 Zero Trust 组织的 Windows、macOS 和 Linux WARP 客户端（包括 WARP Connector Hosts）40。此操作使设备流量恢复到原生网络路由，从而防止客户端在 Cloudflare 控制平面或核心服务中断时，流量被困在无法工作的 Cloudflare 隧道内，有效管理了中心化依赖带来的单点故障风险。

以下表格对比了 Cloudflare 平台提供的不同 HA 和 SRE 机制：

Table 2: Cloudflare 故障转移能力对比 (HA & SRE)

故障类型	Tunnel Replicas (免费)	Load Balancer (付费)	Global WARP Override (紧急)
单个主机/连接故障	自动路由至健康副本 (随机/最近) 35	主动健康检查，智能重定向 37	N/A
Cloudflare Edge 故障	自动切换至最近的健康数据中心	N/A	N/A
Cloudflare 控制平面中断	隧道可能保持连接，但配置无法更改 27	N/A	强制断开所有 WARP/Tunnel 连接，恢复原生网络 40
核心机制	内建 L4 级可用性 (被动 HA)	L7 级流量控制和主动监控 (主动 HA)	管理员应急安全开关 40

VI. 综合性能与安全性评测

6.1. 免费层级服务质量 (QoS) 考量

在性能方面，Cloudflare Tunnel 提供了强大的连接能力。根据现有数据，单个 cloudflared 连接的理论带宽上限高达 1 Gbps 36。通过部署多达 25 个副本，单个逻辑隧道可以聚合提供高达 25 Gbps 的理论带宽 15。

尽管理论性能强大，但免费层级的服务质量受制于 Cloudflare 的资源分配策略。免费层级本质上是利用平台的冗余容量，因此在网络拥塞时，免费流量可能会被降级处理 (Deprioritized) 16。对于对延迟和吞吐量有严格要求（即高 QoS SLA）的核心生产业务，这种不确定性是一个风险因素，可能需要升级到付费计划（如 Argo Smart Routing）以获得性能保障 33。

在延迟方面，WARP 和 Tunnel 均利用 Argo Smart Routing 优化，通常能提供比原生互联网路由更稳定、有时更低的延迟，因为它能绕过 ISP 的低效路由 23。协议效率也得益于基于 WireGuard 的 boringtun 实现，该协议以其高性能和低开销著称 17。

6.2. 安全架构的深度优势

Cloudflare Tunnel 和 WARP 的结合实现了现代的 Zero Trust Perimeter 14。这一架构将安全信任模型从传统的“基于网络位置的隐式信任”转变为“永不信任，始终验证”，通过身份、权限和设备态势来验证每次访问请求 14。

通过 Tunnel 架构，VPS 获得了天然的入站防护。而 WARP 不仅用于出站上网，还可以用于构建 WARP-to-WARP 私有网络。这允许在任何运行 WARP 的设备之间创建私有网络，支持 TCP、UDP 和 ICMP 协议 41。这对于构建跨地域、设备或云环境的零信任内网，同时保护基础设施服务（如数据库或内部 API）免受公共互联网攻击至关重要 12。

6.3. 依赖性：域名、身份与配置管理

部署 Cloudflare Tunnel 需要特定的前置条件。用户必须拥有一个域名，并将其权威 DNS 指向 Cloudflare 的名称服务器。同时，cloudflared 守护进程必须通过基于浏览器的认证流程，获取并绑定证书到 Cloudflare 账户和选定的站点，以确保只有经过身份验证的实体才能建立隧道 8。这些配置步骤虽然保证了安全性，但也意味着用户在域名管理和身份验证方面对 Cloudflare 平台存在配置依赖。

VII. 结论与部署策略建议

7.1. 综合效益权衡：成本节约与服务可靠性的平衡

Cloudflare WARP 和 Tunnel 免费解决方案为 VPS 托管环境中的 IPv4 成本问题提供了颠覆性的经济模型。通过消除对公共 IP 地址的需求（Tunnel 入站）和提供免费的 IPv6 接入及路由优化（WARP 出站），该方案实现了极高的成本效益，同时提供了行业领先的 DDoS 缓解和 Zero Trust 安全能力 6。

然而，这种模型是以对 Cloudflare 平台的中心化依赖为代价的。通过部署 Tunnel Replicas 35 和配置 Global WARP Override 紧急断开机制 40，可以在很大程度上管理由此产生的单点故障风险。

7.2. 针对不同 VPS 应用的最终建议清单

基于对依赖性、性能和业务限制的全面分析，以下为针对不同 VPS 工作负载的最终部署建议：

推荐场景 (高度适用性)：

• Web 服务器和 API 服务： 强烈推荐使用 Tunnel。它完美解决了公网 IP 需求，提供了免费的 CDN 加速、顶级 DDoS 保护和 Web 应用防火墙 (WAF) 功能，极大地提升了安全性和弹性。

• 内部服务 (SSH, RDP, Database)： 推荐使用 Tunnel 结合 Cloudflare Access。这种 Zero Trust 模式提供了身份驱动的访问控制，有效取代了传统 [虚()专()网()]，消除了在 VPS 上暴露任何端口的需要 12。

• 缺乏 IPv6 接入的 VPS： 部署 WARP Connector。这不仅提供了 IPv6 连接能力，还能通过 Cloudflare 的骨干网优化出站路由，解决潜在的 ISP 路由瓶颈 19。

不推荐场景 (关键业务限制)：

• 邮件服务器 (SMTP Outbound)： 坚决不推荐使用 Tunnel 的共享出口 IP 发送邮件。由于共享 IP 信誉低下，邮件会被主流服务商拒绝或限速 29。用户必须承担额外成本，通过专用的、IP 信誉良好的 VPS 或第三方商业 SMTP 中继服务解决出站邮件问题 30。

• 需要极高 QoS SLA 的生产业务： 尽管免费层级提供了强大的功能，但在网络拥塞时，免费流量可能面临被降级的风险 16。对于对延迟或吞吐量有严格保证要求的关键生产环境，应考虑升级到付费的 Argo Smart Routing 或 Spectrum 服务以确保性能指标 33。

• 复杂 L4/L7 非 Web 协议： 对于需要 Cloudflare 边缘高级保护但又无法使用 Web 协议或标准 L4 协议的应用，可能需要付费的 Spectrum 服务，因为 Cloudflare Tunnel 源站与 Spectrum 的直接集成是不支持的 32。

引用的著作

1. IPXO Helps Hosting Companies Mitigate IPv4 Exhaustion, 访问时间为 十一月 18, 2025， https://www.ipxo.com/blog/ipv4-exhaustion-hosting/

2. IPv4 Exhaustion Explained: Causes, Factors, Impacts, and Solutions for Organizations, 访问时间为 十一月 18, 2025， https://blog.servermania.com/ipv4-exhaustion-guide

3. AWS IPv4 pricing: Azure is 20% cheaper, GCP ipv4 is 50% cheaper - Reddit, 访问时间为 十一月 18, 2025， https://www.reddit.com/r/aws/comments/1behwsp/aws_ipv4_pricing_azure_is_20_cheaper_gcp_ipv4_is/

4. Improve Network Scalability with BIG-IP CGNAT - F5, 访问时间为 十一月 18, 2025， https://www.f5.com/resources/solution-guides/how-big-ip-cgnat-provides-network-scalability-solution-overview

5. One IP address, many users: detecting CGNAT to reduce collateral effects, 访问时间为 十一月 18, 2025， https://blog.cloudflare.com/detecting-cgn-to-reduce-collateral-damage/

6. Free Plan Overview - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/plans/free/

7. Connect with cloudflared · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/cloudflared/

8. Arbitrary TCP · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/access-controls/applications/non-http/cloudflared-authentication/arbitrary-tcp/

9. Tunnel with firewall · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-with-firewall/

10. Quick Tunnels · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare/

11. DDoS Protection & Mitigation Solutions - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/ddos/

12. Zero Trust Network Access (ZTNA) solution - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/zero-trust/products/access/

13. Zero Trust security | What is a Zero Trust network? - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/learning/security/glossary/what-is-zero-trust/

14. theNET | The business case for zero trust - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/the-net/business-case-zero-trust/

15. Account limits · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/account-limits/

16. Is there a rate limit in the free cloudflare tunnel tier? I'm noticing slow loading times - Reddit, 访问时间为 十一月 18, 2025， https://www.reddit.com/r/CloudFlare/comments/1is6kfp/is_there_a_rate_limit_in_the_free_cloudflare/

17. The Technical Challenges of Building Cloudflare WARP, 访问时间为 十一月 18, 2025， https://blog.cloudflare.com/warp-technical-challenges/

18. How to build your own [虚()专()网()], or: the history of WARP - The Cloudflare Blog, 访问时间为 十一月 18, 2025， https://blog.cloudflare.com/how-to-build-your-own-[虚()专()网()]-or-the-history-of-warp/

19. WARP architecture · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/configure-warp/route-traffic/warp-architecture/

20. Connect private network to Internet · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/warp-connector/site-to-internet/

21. Download WARP stable releases - Cloudflare One, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/download-warp/

22. Known limitations - WARP · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/troubleshooting/known-limitations/

23. Cloudflare WARP significantly increasing latency - what does this mean? - Reddit, 访问时间为 十一月 18, 2025， https://www.reddit.com/r/CloudFlare/comments/p4y80m/cloudflare_warp_significantly_increasing_latency/

24. Learn how to fix routing issues with your provider using Cloudflare WARP - Masterdaweb, 访问时间为 十一月 18, 2025， https://masterdaweb.com/en/blog/learn-how-to-fix-routing-issues-with-your-provider-using-cloudflare-warp

25. Privacy · Cloudflare WARP client docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/warp-client/privacy/

26. Privacy Policy - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/privacypolicy/

27. Post Mortem - The Cloudflare Blog, 访问时间为 十一月 18, 2025， https://blog.cloudflare.com/tag/post-mortem/

28. Post mortem on the Cloudflare Control Plane and Analytics Outage, 访问时间为 十一月 18, 2025， https://blog.cloudflare.com/post-mortem-on-cloudflare-control-plane-and-analytics-outage/

29. IP reputation - Email Routing - Cloudflare Community, 访问时间为 十一月 18, 2025， https://community.cloudflare.com/t/ip-reputation/842732

30. selfhosted email server, AT HOME with residential IP - Reddit, 访问时间为 十一月 18, 2025， https://www.reddit.com/r/selfhosted/comments/17w21f8/selfhosted_email_server_at_home_with_residential/

31. Cloudflare Tunnels vs VPS - Cyber Security & Hacking - Lawrence Systems Forums, 访问时间为 十一月 18, 2025， https://forums.lawrencesystems.com/t/cloudflare-tunnels-vs-vps/20544

32. Limitations · Cloudflare Spectrum docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/spectrum/reference/limitations/

33. Our Plans | Pricing - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/plans/

34. How to make cloudflare tunnel automatic failover? - Load Balancing, 访问时间为 十一月 18, 2025， https://community.cloudflare.com/t/how-to-make-cloudflare-tunnel-automatic-failover/368606

35. Tunnel availability and failover · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/configure-tunnels/tunnel-availability/

36. Free tier Tunnel (Zero trust) limitation : r/CloudFlare - Reddit, 访问时间为 十一月 18, 2025， https://www.reddit.com/r/CloudFlare/comments/1on16xd/free_tier_tunnel_zero_trust_limitation/

37. What is server failover? | Failover meaning - Cloudflare, 访问时间为 十一月 18, 2025， https://www.cloudflare.com/learning/performance/what-is-server-failover/

38. Public load balancers · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/routing-to-tunnel/public-load-balancers/

39. Correct way to do a failover setup - Application Performance - Cloudflare Community, 访问时间为 十一月 18, 2025， https://community.cloudflare.com/t/correct-way-to-do-a-failover-setup/169871

40. WARP settings · Cloudflare One docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/warp/configure-warp/warp-settings/

41. Create private networks with WARP-to-WARP - Cloudflare Docs, 访问时间为 十一月 18, 2025， https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/private-net/warp-to-warp/