你是不是也遇到过这种情况。
云厂商首月看着便宜，第二个月续费直接翻脸。便宜 VPS 带宽只有 1M 到 2M ，拉个镜像都嫌慢。家里明明还有一台吃灰的旧笔记本、迷你主机，甚至是 N100 小主机， CPU 、内存、硬盘都比很多入门 VPS 豪横，但就是因为没有公网 IP ，只能在局域网里自娱自乐。
说白了，很多人缺的根本不是算力，也不是硬盘，而是“最后那一截公网入口”。
这篇就把这件事彻底讲透：怎么用家宽 + 域名 + Cloudflare Tunnel ，把家里的旧机器变成一台可以被公网访问、还能挂 HTTPS 、还能做访问控制的“私有 VPS”。
先给结论
如果你的目标是把家里的网页服务、 API 、面板、个人工具站稳定暴露到公网， Cloudflare Tunnel 是目前最省钱也最稳的一条路。
它不要求公网 IP ，不要求路由器端口映射，不直接暴露你家里的真实地址。你只需要：
- 一台一直开机的本地机器
- 一个已经托管到 Cloudflare 的域名
- 一个 Cloudflare 账号
然后用 `cloudflared` 主动向 Cloudflare 建立出站连接，就能把本地服务发布出去。
一张图看懂整套链路
为什么这套方案比“买个小水管 VPS 中转”更香
传统内网穿透最烦的地方，不是配置，而是你绕了一圈之后，还是得额外买一台带公网 IP 的跳板机。
而且跳板机往往最拉垮。
配置最麻烦的是它。带宽最小的是它。出了问题最先怀疑人生的也是它。
Cloudflare Tunnel 的逻辑完全反过来。不是公网主动打进你家，而是你家里的 cloudflared 主动向 Cloudflare 发起连接。这个差别看起来像一句话，实际体验差了一个量级：
截至 2026 年 6 月 28 日， Cloudflare 官方文档仍然把这条路线作为 Tunnel 的标准用法，控制台路径也已经统一到 Networking > Tunnels 和 Routes > Add route > Published application 一套流程。
先把边界讲清楚：它适合什么，不适合什么
这套方案很强，但别把它神化。
适合拿来干这些事：
Nginx、Caddy、Docker 服务发布成公网网站AList、Nextcloud、Immich、3x-ui、Uptime Kuma、n8n、Gitea 这类自部署工具不太适合拿来干这些事：
别嘴硬。家宽的天花板，很多时候不是 CPU ，不是内存，是上传带宽和运营商策略。
搭建前准备
你至少准备这 4 样：
可以是 Ubuntu / Debian / CentOS 主机，也可以是 Docker 宿主机、家里旧电脑、迷你主机，甚至 WSL2 。
重点不是“有域名”，而是这个域名的 DNS 必须已经托管到 Cloudflare 。也就是 nameserver 已经切到 Cloudflare 。
免费版就够起步。
比如：
http://localhost:3000 上跑着你的站点http://localhost:8080 上跑着管理面板https://localhost:8443 上跑着自签名证书服务ssh://localhost:22 上跑着 SSHCloudflare Tunnel 负责的是“把入口打通”，不是帮你修本地服务本身。你在本机上先确认服务能正常访问，再去接 Tunnel 。别一上来就怪 Cloudflare 。
核心原理：你并没有“暴露路由器端口”
很多人第一次用 Tunnel 会误以为，自己只是换了一种端口映射。
其实不是。
真正发生的事情是：
cloudflaredcloudflared 主动向 Cloudflare 建立出站连接所以公网看见的是 Cloudflare ，不是你家的路由器。
这也是为什么它在 没有公网 IP 、甚至在 CGNAT 环境下 也能工作。
第一步：把域名正式交给 Cloudflare
如果你还没做这一步，先停一下。
进入 Cloudflare 后台，把你的域名加进去，然后去域名注册商后台，把 nameserver 改成 Cloudflare 给你的两条 nameserver 。等域名状态变成 Active 再继续。
没有这一步，后面就算隧道配好了，公网域名也接不起来。
第二步：在 Cloudflare 创建 Tunnel
按照 Cloudflare 截至 2026-06-28 的官方控制台流程：
Networking > TunnelsCreate Tunnelhome-vpsLinux 上常见的安装方式大致像这样：
curl-L--outputcloudflared.deb
https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudodpkg-icloudflared.deb
sudocloudflaredserviceinstall<YOUR_TUNNEL_TOKEN>
如果你看到 Tunnel 状态从 Inactive 或 Down 变成 Healthy，说明这台机器已经和 Cloudflare 建好了连接。
Tunnel 创建和 Published application 路由
第三步：把本地 Web 服务映射成公网域名
接下来不是去 DNS 手搓记录，而是在 Tunnel 里加一条“发布路由”。
官方控制台路径是：
Networking > Tunnels > 你的 Tunnel > Routes > Add route > Published application
假设你本机跑了一个面板，地址是 http://localhost:56545，那么可以这样配：
| 配置项 | 示例值 |
|---|---|
| Subdomain | panel |
| Domain | example.com |
| Type | HTTP |
| URL | localhost:56545 |
保存之后， Cloudflare 会自动给这个 hostname 创建一条指向 Tunnel 的 DNS 记录。大多数标准接入场景下，你不需要手动再去 DNS 页面补 CNAME 。
这时访问：
https://panel.example.com
请求链路就是：
用户浏览器 -> Cloudflare -> Tunnel -> 你本地的 localhost:56545
第四步：如果本地是 HTTPS ，要知道什么时候开 No TLS Verify
很多人会在这一步翻车。
如果你的本地服务本来就是：
https://localhost:8443
而且还是自签名证书， Cloudflare 侧很容易报 502 或证书校验错误。
这时去对应应用的高级设置里，把：
Additional application settings > TLS > No TLS Verify
打开。
注意，这个开关的含义不是“公网不加密”，而是 Cloudflare 到你本地源站这一段 不再校验证书链。用户浏览器到 Cloudflare 这一段 HTTPS 仍然是正常加密的。
如果你的本地服务根本没配 HTTPS ，那就老老实实选 HTTP，别为了“看起来高级”强行选 HTTPS。
第五步： SSH 可以做，但别以为能直接 ssh 到域名
这里是整篇最容易误导新手的地方，我单独拎出来说。
你当然可以把本地 SSH 通过 Tunnel 发出去，比如这样：
| 配置项 | 示例值 |
|---|---|
| Subdomain | ssh |
| Domain | example.com |
| Type | SSH |
| URL | localhost:22 |
但是，这不等于你立刻就能在任意电脑上直接执行：
sshroot@ssh.example.com
对于 Cloudflare 官方的 Published Application 路线， SSH 流量默认是走 Cloudflare 代理的 WebSocket / Access 流。常见的接法有两种：
cloudflared，然后执行：cloudflaredaccessssh--hostnamessh.example.com
再配合本地 ~/.ssh/config 做 ProxyCommand。
如果你只是想远程敲命令，第一种最省事。要是你一开始就按“传统 VPS”的思路硬连，大概率第一反应会是：完了，教程骗人。
不是教程骗人，是 SSH 这条链路跟 HTTP 根本不是一类东西。
SSH 不是直接裸连，而是走 cloudflared
第六步：给暴露出去的服务再上一道锁
能访问，不代表该裸奔。
如果你要暴露的是后台面板、私有 API 、管理页，强烈建议再配一层 Cloudflare Access 。
常见做法是：
Access 相关应用配置panel.example.com 这类域名纳入保护范围最简单的就是邮箱验证码登录。你每次访问面板前，先过一层 Cloudflare 的身份校验，再进你自己的服务。
这招很土，但非常有效。
因为很多自部署项目本身的登录页，做得真不怎么样。
第七步：建议你直接把 cloudflared 做成系统服务
如果你每次开机都要手动跑一遍隧道，这玩意就不是“服务器”，只是“偶尔能用的实验品”。
在 Linux 上，最稳的方式就是把 cloudflared 安装成系统服务。 Cloudflare 官方用 cloudflared service install <token> 这条路，本质上也是帮你把它常驻起来。
你至少要保证这几件事：
建议顺手检查：
systemctlstatuscloudflared
journalctl-ucloudflared-n100--no-pager
第八步：最常见的 6 个坑
1. Tunnel 显示 Healthy ，但网页打不开
先本机测：
curlhttp://localhost:56545
本机服务都不通，就别先怪 Tunnel 。
2. 访问域名返回 502
大概率是你：
HTTPS 但源站证书不被信任No TLS Verify 没开3. 访问域名返回 1033
这通常说明 Cloudflare 没找到健康的 cloudflared 连接。去机器上看服务状态和日志。
4. SSH 配好了却连不上
先确认你走的是 Cloudflare 官方推荐的 SSH 连接方式，而不是直接裸 ssh。这一点上栽过的人非常多。
5. 域名已经加到 Cloudflare ，但 Tunnel 路由建不起来
检查域名是否真的已经 Active，以及这个 hostname 是否已有冲突记录。
6. 面板能打开，但总觉得不放心
那说明你的直觉是对的。去配 Access ，不要让后台长期裸露在公网入口上。
这套“家宽 VPS”最适合拿来做什么
我更推荐你把它当成一台“个人基础设施节点”，而不是“替代一切的公网服务器”。
比较香的用途包括：
如果你家里那台机器是 16G 内存、 512G SSD 、再加一个大机械盘，它在很多个人场景里，实际体验真能吊打一堆入门 VPS 。
问题只是以前你进不去。
现在入口有了。
最后一层提醒：免费的不是“没有成本”
这套方案确实很省钱，但它不是没有代价。
你的代价是：
所以，别把它当成“零成本魔法”。更准确地说，它是把钱省下来了，把运维责任拿回自己手里。
有人嫌麻烦。有人觉得很值。
我属于后者。
给后台再加一道 Cloudflare Access
一份可以直接照抄的最小配置清单
如果你想最快跑通，就照这个顺序做：
http://localhost:8080Networking > Tunnels 创建 TunnelcloudflaredRoutes > Add route > Published application 里把 app.example.com -> http://localhost:8080 映射出来https://app.example.com这就是整套链路。没有公网 IP 。没有端口映射。没有额外中转机。
