Cloudflare Tunnel 扩容：租户连接如何管理

路由容量变大，租户边界仍要自己设计

Cloudflare 在2026年10月16日的更新公告中，将每账户默认路由上限从1000提高到50000，并推出允许单账户超过1000条隧道的 Tunnels for Platforms。前者涵盖 CIDR 与主机名路由，公网应用主机名不计入这项路由额度。两种容量不能混为一谈。

这一变化为按客户、设备或环境划分连接提供了更大的组织空间，但不能直接推导出业务吞吐提高或租户天然隔离。本文以下讨论属于架构分析与设计建议，没有进行容量测试，也不把额度提升解释成性能承诺。

先区分连接数量与系统能力

一条隧道对应怎样的业务责任，应当先于容量采购决定。对于连接客户私有环境的平台，按客户建立连接，有利于解释资源归属；对于临时开发环境，按环境分配则更容易与创建、到期和回收关联。两者都合理，前提是管理模型保持一致。

假设一个客户拥有生产和测试网络，单纯以客户名称合并所有连接，就可能掩盖环境之间的不同风险。反过来，每台机器都创建独立资源，也会扩大配置、凭证和清理的管理面。粒度选择应回答“出故障时希望一起隔离谁”，而不是只追求资源数量最少。

控制面要记录意图，而非只保存资源 ID

本文建议在平台侧维护一份连接登记表，记录租户、环境、负责人、预期用途与退出条件。这是一种通用建模建议，并非厂商规定的表结构。它的作用，是让业务状态与外部网络资源能够互相解释。

创建成功不等于业务准备完成

开通流程往往跨越多个步骤：创建连接、下发配置、启动连接器、检查服务可达性，再允许业务使用。如果平台只保存最后一步的成功标志，中途失败会留下难以辨认的半成品；如果刚获得资源 ID 就宣布客户已开通，又可能把等待与故障暴露给终端用户。

更清楚的做法，是将“已申请”“连接待就绪”“业务验证通过”等状态分别记录，并给每个状态设置可以重试的动作。重试应针对未完成阶段，而不是从头重复整个流程。这样，即使外部请求超时，也能先查询实际状态，再决定是否补发。

幂等性需要覆盖业务关系

一个稳定名称能帮助找到资源，但仅靠名称仍不足以解释重名与迁移。例如同一客户更换网络时，新旧连接可能合法共存。可以在业务侧引入明确的部署版本，并记录哪个版本当前承担流量、哪个版本正在退出。

这使回收工作不必依赖“看起来很旧”的判断。创建者、使用者与清理者可以通过同一条业务记录协调，避免一个任务刚创建完资源，另一个任务就因尚未观察到连接而将其判为废弃。

扩容之后，回收比创建更容易被忽视

产品文档说明，账户中存在的隧道都会占用数量额度，即使没有活动连接；额外隧道的公开价格为每条每月4.50美元，企业计费可另行协商。容量与连接活跃状态因此必须分别统计。文档是当前规则参考，10月16日公告才是本文的事件日期依据。

不在线不代表不需要

离线可能来自客户设备停机、维护窗口或临时网络故障，并不自动意味着客户已经离开。若清理程序只根据连接状态删除资源，正常的短暂中断可能变成需要重新配置的长期故障。

建议把回收依据放在业务生命周期中：合同或环境是否结束，是否存在有效负责人，是否完成退出确认。离线状态可以触发检查，但不应单独承担删除决策。对于临时环境，可在创建时写明到期时间，再通过保留期与通知机制处理例外。

成本归属需要与业务归属一致

统一账户可以减少分散管理，却也可能让多个团队共享同一份成本账单。平台应能解释某类环境为何增长、谁负责回收、哪些容量属于预留。否则，额度提高会暂时隐藏管理问题，直到成本或运维负担集中暴露。

这里不提供预算预测。实际费用还取决于购买方式、已有容量和其他服务。架构评审更应关注成本能否被追溯，而不是根据一个单价草率估算整个平台的总成本。

租户隔离需要验证失败路径

拥有独立连接，不意味着应用层身份、网络路由与操作权限已经正确对应。本文建议把隔离验证设计成可重复的检查：合法用户能够访问预期资源，不属于该租户的请求必须失败，配置更新后仍保持这一关系。

从最容易混淆的边界开始测试

生产与测试、相似客户名称、复用地址段和迁移中的旧资源，都是值得优先检查的边界。测试不必一次覆盖所有组合，但应明确最危险的误配置会如何表现，以及日志中如何找到其影响范围。

对权限变化也要保留审批与审计线索。能够管理账户资源的人，不一定应该接触每个客户的业务数据；网络连通性与数据访问资格应分别论证。平台规模越大，越不能依赖管理员记忆维护这种区别。

一条可落地的渐进采用路径

第一步，盘点现有连接与真实业务对象的对应关系，先处理无法解释归属的资源。第二步，选择低风险环境试点自动化开通，记录每个阶段的失败与恢复方式。第三步，再把回收、配额预警与责任人通知接入同一流程。

验收要包含退出和恢复

演练至少应回答三个问题：开通过程在中间失败后能否继续，客户离开时能否安全退出，错误配置能否恢复到已知状态。观察指标可以包括开通耗时、人工介入次数与无法归属的资源数量，但这些都需要团队自行测量，本文没有给出未经验证的收益数字。

50000条路由提供的是更宽的容量边界。真正决定平台是否可靠的，是每条连接能否说清归属，每次重试能否辨认已有结果，每次退出能否留下可核查的记录。规模化连接的下一步，不是尽快填满额度，而是让资源增长仍然可解释、可恢复、可管理。