cloudflared 的隧道容量

既然你的 Cloudflare Tunnel 已经正常运行，请评估 cloudflared 是否有足够的系统资源来处理来自最终用户的预期请求量。

与吞吐量由服务器内存、CPU 和其他硬件规格决定的旧版 VPN 不同，Cloudflare Tunnel 的吞吐量主要受系统软件中配置的端口数限制。因此，在调整您的 cloudflared 服务器大小时，最重要的元素是调整机器上可用端口的大小，以反映 TCP 和 UDP 流量的预期吞吐量。

要确定你需要多少台 cloudflared 主机服务器：

1. 从我们的基线建议开始：

   • 每个网络位置在两台专用主机上运行一个 cloudflared 副本。使用两台主机可实现服务器端冗余和流量平衡。
   • 每台主机配置至少 4GB 内存和 4 个 CPU 核心。
   • 为每台主机上的 cloudflared 进程分配 50,000 个端口。

   这种设置通常足以处理来自 8,000 个用户（每台主机 4,000 个用户）的流量。

2. 在完成此学习路径并有用户积极与网络交互后，计算你实际的隧道使用量。

3. 决定要包含多少余量，并在需要时重新调整隧道大小。

扩展 Cloudflare Tunnel 有两种方式：你可以添加现有隧道的额外副本 (图 1)，或者可以将网络的 IP 空间划分到多个隧道中 (图 2)。

flowchart TB
accTitle: 图 1：代理所有私有网络的隧道的多个副本。
subgraph replica1[my-tunnel]
  ip1[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
subgraph replica2[my-tunnel]
  ip2[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
subgraph replica3[my-tunnel]
  ip3[10.0.0.0/8 </br> 172.0.0.0/8 </br> 192.0.0.0/8]
end
replica1 <--> C((Cloudflare))
replica2 <--> C
replica3 <--> C

flowchart TB
accTitle: 图 2：代理不同私有网络的多个隧道。
subgraph tunnel-1
  ip1[10.0.0.0/8]
end
subgraph tunnel-2
  ip2[172.0.0.0/8]
end
subgraph tunnel-3
  ip3[192.0.0.0/8]
end
tunnel-1 <--> C((Cloudflare))
tunnel-2 <--> C
tunnel-3 <--> C

添加现有 Cloudflare Tunnel 的额外副本（基线建议为两个）应当仅用于支持发往该隧道中 IP 路由的额外流量。副本应始终添加在彼此相同的物理位置，以便它们能够以池化模式运行。如果你正在考虑在不同的地理位置添加副本，请重新评估 Cloudflare Tunnel 的网络代理设计，并参阅何时添加隧道。

当你的网络分散在不同的地理位置时，请考虑创建全新的隧道。例如，假设由 10.0.0.0/8 代表的网络在与美国东部几乎完全连续，只有 10.0.50.0/24 在西北太平洋地区提供服务的非重叠例外。我们建议将 10.0.50.0/24 拆分为一个单独的 Cloudflare Tunnel，而不是从西北太平洋地区提供额外的副本。从西北太平洋地区附近的主机提供此新隧道，并带有其自己的均衡副本实施。

即使网络中的所有路由都从同一个物理位置提供服务，从控制平面冗余的角度来看，将网络拆分为不同的隧道而非添加副本也可能是明智之举。

例如，如果你通过带多个副本的单个隧道代理范围 10.0.0.0/8、172.0.0.0/8 和 192.0.0.0/8，你可能会在穿过众多网络的流量方面达到端口耗尽的程度。将 10.0.0.0/8、172.0.0.0/8 和 192.0.0.0/8 拆分为它们自己的独立隧道（每个隧道带有一个副本）可能是明智之举。或者，你可以查找产生大量独立流量的特定应用程序或功能（如 DNS 服务器或其他功能），并将它们拆分为带有适当额定吞吐量和副本卷的独立隧道。