没有公网 IP 也能玩：Cloud in a Bottle 家用服务器公网暴露的 3 种方案-平芜编程栈

【免费下载链接】cloud-in-a-bottle

Deploy, use, and share web apps on a server you control. Your apps, data, and infrastructure stay yours.

项目地址：https://gitcode.com/gh_mirrors/cl/cloud-in-a-bottle

Cloud in a Bottle 是一个让你把自己的服务器变成"私有云"的开源项目：应用像装手机 App 一样从 Git 仓库一键部署，数据全部留在你自己的硬件上。但它的价值在于"拥有可公开访问的 URL"，而家宽用户最大的痛点恰恰是没有公网 IP。别担心，本文带你用 3 种方案把家里的 Cloud in a Bottle 安全地"搬"到公网——从最简单的 Cloudflare Tunnel 隧道，到 Tailscale 组网，再到动态 IP 端口转发，总有一款适合你。

为什么必须把家用服务器暴露到公网？

Cloud in a Bottle 的设计目标是：你的应用（笔记、邮箱、AI 工具、游戏服务器……）部署后拥有https://<应用名>.你的域名.com这样的正式网址，任何设备上的普通浏览器都能打开。要达成这一点，实例需要两样东西：

公网可达性：互联网上的请求能到达你的机器；
独立域名：用于 HTTPS 证书和给每个应用分配子域名。

家里通常两样都没有——ISP 给的是动态 IP，甚至还是 CGNAT（多户共享一个出口 IP）。所以家用场景的公网暴露方案，本质上都是"绕过公网 IP 的缺失"。

方案一：Cloudflare Tunnel 隧道（最推荐 ⭐）

一句话：免费、无需改路由器、无需公网 IP，10 分钟搞定。

Cloudflare Tunnels 的原理是"反向隧道"：由 Cloudflare 在公网侧接收流量，按 HTTP 请求里的域名（Host 头）识别用户，再主动建立隧道把流量送进你家这台被防火墙挡住的机器。因为连接是从内网主动向外发起的，所以路由器不需要任何端口映射，动态 IP 完全不影响使用。

这也是官方文档 docs/src/setup/home_network.md 中推荐的第一方案，步骤概要如下：

前提：你有一个顶级域名（如example.com），且 DNS 托管在 Cloudflare，并开启了 "Always Use HTTPS"；
在面板注册域名：打开 Dashboard 的Settings → Domains，填入域名并选择Public (HTTPS)。此时会报证书错误（ACME account key path must be set...），这是预期现象——因为证书由 Cloudflare 边缘节点终结，实例本身不需要证书；
安装cloudflared：通过 apt 安装 Cloudflare 官方客户端；
创建隧道并授权：执行cloudflared tunnel login在浏览器中授权你的域名，再执行cloudflared tunnel create bottle创建名为 bottle 的隧道；
配置通配符路由：核心是把example.com和*.example.com两条 ingress 规则都指向本地路由器的http://127.0.0.1:8080——Cloud in a Bottle 的 Python 路由器会按应用子域名自动分发请求到对应容器；
注册为系统服务：sudo cloudflared service install后开机自启，从此无需干预。

完成后，在任意设备的浏览器访问你的域名即可看到 Dashboard，应用则位于https://<应用名>.example.com。

⚠️小提醒：隧道方案只转发 HTTP/HTTPS 流量。绝大多数应用都够用，但如果某个应用的 cloudinabottle.toml 清单里声明了非标准[[ports]]（例如 SMTP 收信端口），这类流量在隧道模式下将无法正常工作。

方案二：Tailscale 虚拟组网（适合只给自己和家人用）

一句话：不暴露给公网，只让你的设备（无论在哪）能访问，安全性最高。

如果你并不需要让"互联网上任何人"都能访问，只是希望出差、旅行时手机也能打开家里的服务，Tailscale 是最优雅的选择。它在你的设备间建立端到端加密的虚拟局域网（tailnet），实例仅对 tailnet 内设备可见，公网完全摸不到。

操作步骤：

安装 Tailscale：在实例上执行sudo snap install tailscale --classic，然后sudo tailscale up登录。长期运行的服务器建议在管理后台关闭密钥过期，避免定期重新认证；
域名指向 Tailscale IP：执行tailscale ip -4取得分配的 100.x 内网 IP，在你的 DNS 服务商处创建一条A记录和一个通配符A记录（如*.bottle.example.com），值都填这个 Tailscale IP。通配符记录保证每个应用都有自己的可用子域名；
在面板添加域名：Settings → Domains中填入域名，选择HTTP（最省事）或HTTPS（需通过 acme.sh 的 DNS API 插件完成 DNS-01 验证来签发通配符证书，完整命令见官方文档）；
设为主域名：新域名生效后点击Make primary，实例与应用会重启并切换到新域名。

细节可直接查阅官方指南 docs/src/setup/home_network.md 的 "Tailscale" 章节。

对比维度	Cloudflare Tunnel	Tailscale
公网暴露程度	完全公开（需认证保护）	仅 tailnet 设备可见
配置难度	低	低
支持 HTTPS 自动证书	是（Cloudflare 终结）	需 acme.sh 配合 DNS API
非 HTTP 协议	不支持	tailnet 内全协议可达
适合场景	分享给朋友/对外服务	纯个人私有云

方案三：动态 IP + DDNS 端口转发（进阶玩法）

一句话：最"传统"的路子，能走通全端口，但前提条件最多、收益相对最小。

官方文档明确标注这条路不是官方支持路径，但如果你就是喜欢完全掌控链路，原理如下：

确认你的网络不是 CGNAT：登录光猫/路由器查看 WAN 口 IP，若为10.、100.64.、172.16.等内网段，说明 ISP 做了大内网，此方案直接作废；
DDNS 动态解析：家用 IP 会周期性变化，需要 DDNS 客户端（或脚本）监控 WAN IP 变化并自动更新域名 A 记录；
路由器端口转发：把外部 80/443（以及 53，因为实例自带 CoreDNS 权威 DNS）转发到家庭服务器。注意 53 端口转发在家用 NAT 下非常棘手，这也是官方不推荐的原因之一；
ISP 端口封锁：居民线路通常封禁 25（SMTP）等端口，收信类应用会受限。

官方原文的结论很直白："好处相比 Cloudflare Tunnel 来说收益很低，设置却难得多。" 因此它只适合折腾爱好者。

顺带一提：另外 2 条"正规军"路线

静态 IP 服务器：如果你有一台带静态公网 IPv4 的机器（哪怕家里的宽带升级了静态 IP 套餐），流程反而最简单——把整个域名区（NS 记录）委托给实例自己，实例内置的 CoreDNS + Caddy 会自动完成通配符解析和 ACME DNS-01 证书签发，详见 docs/src/setup/static_ip.md；
IPv4 隧道服务：团队也观察到"给一台被防火墙挡住的实例挂一个 IP"是刚需，目前正在自研这项服务，官方预告"即将上线"，可以先关注项目路线图 docs/src/roadmap.md。

部署与延伸阅读

想先在家里把 Cloud in a Bottle 跑起来（先装成仅本地访问的模式，再按上面的方案上公网），仓库提供了一键部署脚本，参考官方文档 docs/src/setup/dedicated_homeserver.md：

git clone https://gitcode.com/gh_mirrors/cl/cloud-in-a-bottle # 按照 dedicated_homeserver 文档执行 provision.sh， # 用 --local-http-only 参数装成纯本地模式，SSH 隧道即可访问 Dashboard

更多操作细节：

家用网络暴露完整指南：docs/src/setup/home_network.md
静态 IP 暴露指南：docs/src/setup/static_ip.md
域名与 TLS 配置相关源码：compute_space/src/compute_space/core/domains.py
域名 API 路由：compute_space/src/compute_space/web/routes/api/domains.py
Caddy HTTPS 反向代理集成：compute_space/src/compute_space/core/caddy.py

写在最后

没有公网 IP，只是少了一台"路由器上的门牌"，并不是私有云的死胡同：Cloudflare Tunnel 适合想要公开分享的你，Tailscale 适合纯粹自用、安全优先的你，动态 IP 转发留给享受折腾的你。三条路走通任何一条，你家里的旧电脑、树莓派，就正式成为你云端版图里真正属于自己的一块角落了 🍾