Cloudflare Tunnel 安全升级
收到 Cloudflare 强制升级通知后，我在不修改隧道、DNS 和业务路由的前提下，把 cloudflared 从 2026.5.1 升级到 2026.10.3，并验证连接器与公网入口正常。
技术 · 2026-10-27 · 约 5 分钟阅读 · 标签：Cloudflare、自托管、cloudflared、Tunnel、安全运维
起因
2026 年 10 月，我收到一封 Cloudflare 的强制升级通知：旧版 cloudflared 仍然信任一批使用弱密钥的 eMudhra/emSign 中间证书。攻击者如果能拿到对应私钥，就可能伪装成受信任的 HTTPS 站点或服务。
Cloudflare 明确表示，暂时没有发现这些证书被用于攻击 Cloudflare 服务，但这不代表可以继续使用旧客户端。邮件给出的最低版本是：
| 运行方式 | 要求 | | --- | --- | | 通用安装 | cloudflared >= 2026.10.2 | | macOS 非 Homebrew 安装 | >= 2026.10.3 | | Docker | cloudflare/cloudflared:2026.10.3 |
我先检查了正在运行的客户端，版本还是 2026.5.1，确实低于要求。升级不能只把新文件装进磁盘，还必须重启原来的连接器；否则旧进程会继续用旧版本工作。
先确认影响范围
升级前先确认了三件事：当前版本、实际运行的进程，以及隧道由谁托管。结果是本机只有一个固定隧道，客户端由 Homebrew 安装，并由现有的用户级守护进程负责拉起。
这一步很重要。brew upgrade 只替换磁盘上的二进制文件，正在运行的 cloudflared 不会自动换成新版本。如果直接重启整个服务，还要接受一次短暂断线：邮件里写明连接器重启时约有 30 秒宽限，但 WebSocket、SSH、TCP 和 UDP 会话仍可能断开。
因此我没有新建隧道，也没有改 ingress、DNS 或任何业务路由，而是只准备升级客户端和重启原有连接器。升级前还保留了旧版二进制，方便出现意外时回退。
升级与重启
升级命令本身很直接：
brew upgrade cloudflared
cloudflared --version版本从 2026.5.1 升到了 2026.10.3。随后重启原来那个守护进程：
launchctl kickstart -k gui/$(id -u)/<现有服务标签>重启后约 2 秒，新的 cloudflared 进程已经拉起。这里的关键不是“命令执行成功”，而是确认新进程确实使用了升级后的二进制，并且隧道重新连回了 Cloudflare 边缘节点。
验证结果
我按运行状态、连接状态和真实访问三层做了检查。
| 检查项 | 结果 | | --- | --- | | 客户端版本 | 2026.10.3 | | 隧道状态 | running | | 守护进程退出码 | 0 | | 新连接器启动耗时 | 约 2 秒 | | 已建立的边缘 TCP 连接 | 6 条 | | 5 个现有公网入口 | 最终全部 HTTP 200 | | 配置、DNS、业务路由 | 均未修改 | | 升级费用 | 0 |
其中两个入口直接返回 200，两个旧别名先返回 301 再跳转到正式入口，另一个独立服务也返回 200。升级后继续观察了一分钟，连接器保持运行，没有出现 lastError，也没有源站证书链错误。
这次没有通过 noTLSVerify 或其他方式关闭 TLS 校验。邮件要求排查那些证书链最终落到受影响 eMudhra 根证书的 HTTPS 源站；如果以后新增源站证书，仍应优先更换证书，而不是绕过验证。
费用问题
这次升级没有产生费用，也不需要改账单。
Cloudflare Tunnel 客户端升级本身是免费的；Cloudflare 当前的 Zero Trust Free 方案也是永久 $0，包含 Application Connector Software，免费方案面向 50 人以内的小团队。只有账户主动使用其他付费功能时，才会涉及另外的订阅或用量费用。这次操作没有开通任何付费项。
取舍
| 方案 | 优点 | 问题 | 结论 | | --- | --- | --- | --- | | 立即升级并重启原连接器 | 满足安全要求，保留原有架构 | 可能短暂断开长连接 | 采用 | | 只升级文件、不重启进程 | 没有即时断线 | 实际仍运行旧版本，不解决问题 | 否决 | | 新建一条隧道替换 | 看似可以并行迁移 | 会扩大变更范围，增加 DNS 和路由风险 | 否决 | | 继续使用旧版本 | 不需要维护 | 继续信任有风险的证书链 | 否决 |
结果
这次升级完成了三件事：把 cloudflared 从 2026.5.1 升到 2026.10.3，只重启了原有的固定隧道连接器，并用真实公网入口验证了服务恢复。隧道拓扑、DNS 和业务配置都没有变化，费用也没有变化。
对自托管环境来说，这类“客户端必须升级”的通知不适合拖。正确做法不是重做隧道，而是确认实际运行版本、升级二进制、重启原进程，再检查连接器和真实入口。
本文记录个人自托管环境的升级过程与通用结论，不公开具体域名、地址、端口、隧道标识或凭据。