第 4 篇：为什么选择 Cloudflare Tunnel——在“无公网 IP + 零端口暴露”前提下，把家里 Mac 变成可交付的线上服务
第 4 篇：为什么选择 Cloudflare Tunnel——在“无公网 IP + 零端口暴露”前提下，把家里 Mac 变成可交付的线上服务
- 1）无公网 IP、零端口暴露：它到底怎么“穿透”的？
- 2）出站连接模型与边界安全：你的“安全边界”变了
- 2.1 边界安全示意：谁能打到哪里？
- 3）适合公开演示 vs 团队访问：策略必须分层，不然迟早翻车
- 3.1 推荐的“分域名/分入口”策略
- 4）把“请求进入本地服务”的流程看成一条可审计链路
- 4.1 请求链路（从用户到你家 Mac）
- 6）我建议你在专栏里明确的“最低安全底线”（强制执行）
- 7）本章行动项（你照着做，下一篇才能进入 config.yml 多服务路由）
- 评论区互动（我想拿到你们的真实约束）
- 下一章
如果你要把 ComfyUI、RAG API、监控面板放在家里 Mac Studio 上长期运行，真正的难点从来不是“能不能跑”，而是这三件事：
- 你大概率没有公网 IPv4（甚至在 CGNAT 后面）；
- 你不想做端口转发，更不想把 22/80/443/8188/8000 裸奔到公网；
- 你既要“给团队用”，又偶尔要“给客户公开演示”。
这就是 Cloudflare Tunnel 的价值：通过出站连接，把本地服务安全地挂到 Cloudflare 边缘网络上，实现“零端口暴露”的公网访问入口。官方文档在这里：[1]
1）无公网 IP、零端口暴露：它到底怎么“穿透”的？
很多人第一次理解 Tunnel 会误以为它是“反向端口转发”。但它更接近一种**“由内向外拨号建立的持久在线连接”**：
- 你家里跑一个
cloudflared（Connector） - 它主动向 Cloudflare 建立出站连接（通常基于 HTTPS/WSS 等）
- 外部用户访问你的域名时，请求先到 Cloudflare Edge，再通过这条已建立的隧道转回你本地服务
你注意这里的本质：家里路由器不需要对外开放任何端口，所以“无公网 IP / CGNAT”不再是门槛。
对比：端口转发 vs Tunnel（你会立刻明白差在哪）
结论一句话：
- 端口转发：是“外网敲你家门”
- Tunnel：是“你家主动打电话给 Cloudflare，并一直保持在线”
2）出站连接模型与边界安全：你的“安全边界”变了
Cloudflare Tunnel 最关键的安全收益来自边界收缩：
- 你的家庭网络不再成为公网可扫描目标
- 攻击面从“你的路由器/服务端口”迁移到 Cloudflare 入口
- 你可以用 Cloudflare Access / WAF / Rate Limit 在边缘层拦截绝大多数风险
2.1 边界安全示意：谁能打到哪里？
你会发现：真正暴露到公网的，不是你的端口，而是 Cloudflare 这一层的“策略入口”。而策略入口的好处是：可控、可审计、可回滚。
3）适合公开演示 vs 团队访问：策略必须分层，不然迟早翻车
很多人把 Tunnel 配好后第一件事就是“分享域名”。然后就出现两种典型事故：
- 管理面板被外部访问（哪怕只是被撞库/爆破）
- Webhook 被滥用导致资源跑满（ComfyUI 队列爆、RAG API 被刷）
所以你需要两套策略：公开演示一套、团队访问一套。
3.1 推荐的“分域名/分入口”策略
一句话策略：
demo.*给客户看：可公开，但要限速、只读、脱敏ops.*给自己/团队用：必须 Access 强认证 + MFAapi.*给 Make/Agent 调用：用 Service Token / mTLS / IP 约束（可选）webhook.*是事故高发区：必须 签名校验 + 重放保护
4）把“请求进入本地服务”的流程看成一条可审计链路
4.1 请求链路（从用户到你家 Mac）
你专栏里要反复强调的一点：
Cloudflare Tunnel 不是“替你做认证”。认证与策略要靠 Access/WAF 来补齐，否则你只是把入口换了个地方。**
6）我建议你在专栏里明确的“最低安全底线”（强制执行）
- 管理面板永不公开：
ops.*必须 Access + MFA - Webhook 永远要验签：不验签就等着被刷
- API 要有机器身份：Make/Agent 调用用 Service Token（或等价机制）
- 分环境：dev / stage / prod 最少要分两套入口
- 默认 404 兜底：没匹配到的路由直接丢弃（减少意外暴露）
可以用这张“最小决策树”作为本章小结：
7）本章行动项（你照着做，下一篇才能进入 config.yml 多服务路由）
- 把域名规划成
demo / ops / api / webhook四类（哪怕先用二级域名占位） - 明确哪些服务属于“只读演示”，哪些属于“管理后台”
- 为
ops.*设定 Access 强认证（至少 MFA） - 为
api.*准备机器身份（Service Token 思路） - 为
webhook.*设计验签与重放保护（下一章我们会给母模板）
评论区互动（我想拿到你们的真实约束）
- 你家宽带是否 CGNAT？（WAN IP 和公网 IP 是否一致）
- 你更常见的需求是：团队远程用（ops）还是客户演示（demo）？
- 你现在最担心的风险点是哪个：管理面板、Webhook、还是 API 被刷导致资源跑满？
如果你回复这三项，我可以把你的域名规划和策略，直接落到下一篇的 Tunnel 多服务 config.yml 母模板里，并顺手给你一套“demo/ops/api/webhook”可复制的路由骨架。
下一章
《第 5 篇：Cloudflare Tunnel 多服务路由模板》
