Cloudflare Tunnel 是什么
一句话总结
Cloudflare Tunnel 是一种加密反向隧道，让内网服务器通过
cloudflared客户端主动连接 CF 边缘，而不是让用户直接连接服务器——不需要开任何入站端口。
🤔 为什么会有它 / 解决了什么问题
传统暴露内网服务需要开防火墙端口、配公网 IP、面对 DDoS 和端口扫描攻击。Tunnel 把连接方向反过来——服务器主动”打电话”给 CF，所有入站流量由 CF 边缘过滤后再通过隧道转发。
🔍 具体原理 / 运作逻辑
在内网机器上运行 cloudflared 守护进程，它向最近的 CF 边缘节点发起加密连接（基于 QUIC 或 HTTP/2）。用户域名 DNS 指向 CF，CF 收到请求后通过已有隧道转发给内网服务，响应原路返回。
更硬核的技术细节（点击展开）
Tunnel 连接基于 mTLS 双向认证，客户端依赖一个 DNS 记录（
<tunnel-id>.cfargotunnel.com）来注册，CF 侧通过这个记录路由流量到对应隧道。多个 Tunnel 支持负载均衡和故障转移。
🧭 什么情况下会用到 / 什么场景会遇到它
- Growth App 的 Press 控制面板（
press.getgrowth.app通过 Tunnel 穿透 DO VPS 防火墙） - 开发环境暴露到公网调试 Webhook（不需要 ngrok）
- DePIN 节点编排（容器启动后主动打隧道到 CF，无需固定公网 IP）
🛠️ 怎么上手 / 在哪操作
在服务器安装 cloudflared，运行 cloudflared tunnel create <名称> 创建隧道，配置 DNS 指向，启动隧道即可。所有配置在 Cloudflare Dashboard → Zero Trust → Networks → Tunnels 管理。
⚖️ 副作用 / 代价 / 取舍
- 对延迟敏感的场景，Tunnel 引入额外的封装开销（比直连多几毫秒）
cloudflared是 Go 写的，内存占用约 10-30MB，在低配机器上需注意- 依赖 CF 服务可用性——CF 挂了 Tunnel 也断了（虽然 CF 的 SLA 比大多数单服务器高得多）
🕰️ 来历
- 谁提出/创造的：Cloudflare（原 Argo Tunnel，后更名为 Cloudflare Tunnel）
- 什么时候出现的：2018 年作为 Argo Tunnel 发布，2020 年并入 Cloudflare for Teams，2021 年更名为 Cloudflare Tunnel
🔗 关联 / 经常一起出现的概念
- cloudflared：Tunnel 的客户端守护进程，安装在被代理的服务器上
- Cloudflare Zero Trust：Tunnel 是 Zero Trust 网络架构的一个组件，配合 Access 策略做身份验证
- DDoS 防护：Tunnel 天然隐藏源站 IP，CF 在边缘层完成 DDoS 清洗后再转发
⚠️ 注意事项 / 常见误区
“有了 Tunnel 就不需要防火墙了”——Tunnel 只保护入站流量，服务器仍需防火墙隔离内网横向移动。同时注意 cloudflared 进程本身要保持高可用，单点故障建议配多个 Tunnel 做 Fallback。
📎 记忆锚点
“不用开端口，你的服务器打给 CF，CF 转接给用户——就像内线电话让总机转接。”
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |