技术指南
Cloudflare Tunnel 与 frp：如何选择内网访问方案
从信任边界、路由和访问控制比较 Cloudflare Tunnel 与 frp，并准备可验证的切换与回滚。
Cloudflare Tunnel 和 frp 都能把内网服务连接到外部入口，但信任模型不同。Tunnel 由 `cloudflared` 主动建立到 Cloudflare 的出站连接，再把公共主机名映射到本地服务；frp 通常需要自管公网 frps。选择前应先决定是否接受第三方边缘、是否需要非 HTTP 协议、谁控制公网端点，以及故障时怎样恢复管理入口。
按信任边界选择
| 维度 | Cloudflare Tunnel | 自管 frp |
|---|---|---|
| 公网入口 | Cloudflare 网络与账号 | 自有 frps 主机和公网地址 |
| 入站端口 | 源站通常只需出站连接 | frps 需要明确开放控制与服务端口 |
| 访问控制 | 可结合 Cloudflare Access | 需自行设计认证、TLS 与网络 ACL |
| 运维责任 | 账号、token、路由、cloudflared | 客户端、服务端、证书、防火墙与容量全部自管 |
部署前画清请求路径
- 记录公共域名、隧道连接器、本地监听地址和最终应用四个节点。
- 确认应用只监听需要的接口；同机服务优先回环地址，不默认监听 0.0.0.0。
- 列出 WebSocket、上传大小、长连接、真实客户端 IP 和身份认证要求。
- 保留独立的带外管理路径，不能让待配置的隧道成为唯一 SSH 入口。
Cloudflare Tunnel 的安全落点
Cloudflare 官方文档把 Tunnel 描述为出站连接，不要求给源站开放公共入站端口。创建 tunnel 后，将主机名路由到明确的本地服务，例如 `http://localhost:8080`。这不会自动让应用变成私有：公开 hostname 仍可能对互联网开放，需要按用途配置 Access、应用鉴权、WAF 和最小权限成员角色。
当本地上游使用 HTTPS 时，应设置与证书匹配的 `originServerName` 或可信 CA。Cloudflare 故障文档把 `noTLSVerify` 仅作为最后手段且不建议生产使用；不能为了消除 x509 错误长期关闭验证。
自管 frp 的额外责任
frps 所在主机成为新的公网边界。控制通道和暴露的服务端口应由云防火墙与主机防火墙双重限制，客户端与服务端版本要兼容，认证材料独立保存并轮换。不要把数据库、Docker API 或无鉴权管理面板直接映射到公网。HTTP 服务仍应通过 TLS 反向代理和应用认证。
从外到内验证
- 从外部网络访问公共主机名，验证 TLS、身份策略、状态码和目标内容。
- 从不受信账号或隐私窗口确认未授权请求确实被拒绝。
- 扫描源站公网地址，确认旧端口已关闭且 DNS 历史暴露风险已处理。
- 停止一个连接器观察告警和恢复；需要高可用时部署独立副本而非同一宿主机多个进程。
- 检查日志中的真实客户端信息、敏感头部和 token 是否被正确处理。
回滚和故障分层
切换 DNS 或路由前保留旧入口但限制访问。故障时先区分隧道是否在线、`cloudflared`/frpc 能否访问本地服务、以及应用自身是否健康。Cloudflare 常见的 502 类问题可能表示隧道已连通但上游地址错误或服务未监听。回滚时移除新路由、恢复旧入口和防火墙规则，并轮换测试期间暴露的凭据。