Cloudflare 支持批量创建 Tunnel 与 Mesh 路由：扩容前先完成验证
Cloudflare 于 2026 年 9 月 2 日宣布，仪表板现在可以一次创建多条 Cloudflare Tunnel 与 Cloudflare Mesh 路由。运维人员可同时输入多个 CIDR 网段或主机名，暂存不同的“路由—连接器”组合，并且只重试验证失败的条目；创建成功的条目会从表单移除，便于继续修正剩余失败项。
对于经由私有网络连接代理网关、合规采集任务、广告验证浏览器或市场研究作业的团队，这能减少重复配置。但一次操作覆盖的范围也更大：一批语法正确的路由，仍可能指向错误连接器、覆盖已有前缀、绕过预期检查路径，或造成返回流量不对称。
公开来源说明： Cloudflare，《Create multiple Cloudflare Tunnel and Cloudflare Mesh routes at once》，2026 年 9 月 2 日。
新功能改变了什么
这次更新改变的是批量操作方式，而不是单条路由的含义。一个目标仍需映射到确定的连接器与路由类型。新仪表板允许：
- 为同一连接器一次输入多个主机名或 CIDR；
- 在提交前继续加入其他路由组；
- 在一个暂存批次中使用不同连接器或路由类型；
- 保留失败项供修正，同时从表单移除已完成项；
- 采用与批量 WAN 静态路由相近的交互方式。
“只重试失败项”很实用，却带来对账要求。部分成功后，原批次已分成“已经生效”和“仍未创建”两组。变更单和自动化记录必须保存两组状态，否则再次提交时可能产生重复配置或留下覆盖缺口。
为什么代理与采集团队需要关注
代理出口常按地区、客户、任务或合规边界隔离。路由变化会影响认证流量进入哪个网关、哪些出口组可达，以及日志能否把任务与真实网络路径关联。错误路由因此可能被误判为“代理质量差”，即使提供商与出口地址本身完全健康。
重点观察四类现象：
- 地区或 ASN 不符。 请求成功，但实际经过了错误区域的连接器。
- 直连回退。 路由未匹配时，流量绕开了指定代理或私有路径。
- 部分可达。 IPv4 正常，但 IPv6、特定前缀或一组主机名失败。
- 重试放大。 工作节点把路由故障当成出口故障，轮换大量健康 IP。
可结合代理直连回退检测指南验证故障闭锁，并用代理重试预算指南避免单个路由错误耗尽整个地址池。
提交批次前先做预检
点击创建前，把暂存项目整理成可审阅清单。每行至少包括目标、前缀长度或主机名、路由类型、连接器、环境、负责人、预期出口区域、变更单与回滚路由。
随后检查：
- 规范化 CIDR，拒绝前缀之外仍带主机位的输入；
- 展开别名，让审阅者看到真实目标集合；
- 检测完全重复和网段重叠；
- 不只比较本批次，还要与现有路由表比较；
- 确认更具体的路由不会意外抢占共享路径；
- 验证目标区域连接器的健康度和容量；
- 分别证明 IPv4 与 IPv6 遵循既定策略；
- 标记任何失败后可能允许直接上网的路由；
- 从截图与工单中清除代理密码和客户标识。
主机名路由属于动态状态，还应记录 DNS 变化如何影响匹配，以及连接器与工作节点看到的解析结果是否一致。
采用分阶段上线
不要在批量创建后立即恢复全部并发。先选择一个受控路由组，用自有或明确获准的目标运行一个合成任务。
每次测试记录：
- 工作节点和连接器标识；
- 预期路由与实际连接器；
- 代理网关组与预期地区；
- 实际出口国家、地区、ASN 与 IP 协议族；
- DNS 解析方与返回地址族；
- 隧道建立结果；
- 应用状态与内容校验结果；
- 重试次数、延迟和传输字节数。
通过条件不能只是“连接成功”。请求必须使用预期私有路径，到达获准目标，经由正确代理出口，并返回业务上有效的内容。错误地区或直连路径返回的 200 页面仍然是失败。
对账部分成功的批次
如果多条路由成功而一条失败，先冻结部署记录，再重试。导出或复制已创建清单，标记未完成项，并把两组都与原始清单比较。只修正失败行。
重试后执行三次集合检查：
- 预期减实际： 找出缺失路由。
- 实际减预期： 找出意外或陈旧路由。
- 重叠的有效路径： 找出虽已存在、却不会按预期胜出的路由。
仪表板把成功项移出表单，并不等于提供审计日志。应另存带时间与负责人的不可变变更记录。
回滚与故障边界
提交前就定义回滚：旧连接器或旧路由、最大可接受错误率、观察窗口，以及有权撤销变更的负责人。
按最先出现异常的边界分类：
- 配置拒绝： 目标格式错误或不受支持；
- 路由选择失败： 预期路由没有胜出；
- 连接器失败： 已选连接器不健康或不可达；
- 代理边界失败： 网关认证或隧道建立失败；
- 目标响应： 路径正常，但目标拒绝或限流；
- 内容失败： 传输成功，但语言、时效、结构或页面身份错误。
只有代理边界证据应影响代理健康评分。路由或连接器故障不应导致出口 IP 被隔离。
发布检查清单
- [ ] 已在内部记录官方更新、日期与来源 URL。
- [ ] 每个 CIDR 或主机名都有负责人和环境标记。
- [ ] 已审阅完全重复与网段重叠。
- [ ] 冲突分析包含现有路由。
- [ ] 已检查连接器健康度与地区容量。
- [ ] 直连回退已被禁止或可明确检测。
- [ ] IPv4 与 IPv6 已分别测试。
- [ ] 单任务灰度证明实际连接器与出口地区正确。
- [ ] 已校验业务内容，而非只看状态码。
- [ ] 部分成功项已与原始清单对账。
- [ ] 回滚阈值与负责人已记录。
- [ ] 日志和截图不含密码或个人数据。
合规与安全
私有路由和代理基础设施只能用于你获准访问的系统、账号和数据。遵守目标条款、robots 指引、速率限制、隐私要求和数据最小化原则。批量创建提升的是操作效率，不代表可以扩大目标范围。目标拒绝或限流时应停止并解决授权或容量问题，不得通过改路由或轮换 IP 绕过控制。
常见问题
批量创建会改变路由优先级吗？
官方更新描述的是仪表板工作流，而不是新的路由模型。仍需根据完整路由表评估前缀具体度和选择规则。
一条失败时是否应删除所有成功项？
不应自动删除。先把部分结果与批准清单对账，再按预先批准的变更计划决定保留或回滚成功子集。
连接成功是否足以批准整个批次？
不够。还要验证连接器身份、代理路径、出口地区、IP 协议族和业务内容。在错误路径上成功仍是路由缺陷。
首次灰度应多大？
每类路由先用一个受控目标和一个低并发任务。只有路由、代理与业务证据都匹配清单后再扩大。
