无公网IP免费内网穿透最安全方案 Cloudflare Tunnel .增加加速方案

前言

我家里的内网穿透一直用的是 "Lucky + DDNS" 方案，它的核心是依赖公网 IPv6。这套在家里用得好好的，可到了公司环境就尴尬了——公司的网络往往没有 IPv6，导致这套方案直接失效。

于是我开始寻找不依赖 IPv6 的替代品。Cloudflare Tunnel 应该是目前零成本方案中最安全稳定的一种：它无需公网 IP、不用做端口映射、也不把路由器暴露在公网上，而是由你的设备主动"外连"到 Cloudflare 边缘节点，再由 CF 把你的域名流量转发回来。安全性天然更高。

它唯一的缺点是：Cloudflare 边缘节点在国内访问偏慢。对我只用 sun-panel 这类轻量页面服务来说，影响不大；但如果想穿透应用类服务（对延迟敏感的工具、API、远程桌面等），就需要额外给 Cloudflare Tunnel 做优选 IP 加速——这一步设置稍复杂，文章最后会一并演示。

顺带说一句，Cloudflare Tunnel 只是 CF 免费能力里的一项。如果你想先看全貌（Workers / Pages / R2 / KV 各自能白嫖到什么程度），可以先读这篇总纲：Cloudflare Tunnel 完全指南。

先理解三件事，后面就不会晕

这篇教程的配置步骤较多（尤其加速部分），但底层其实只有三个概念。先讲清楚，照着做的时候你就知道每一步在干什么。

① 隧道是"主动拨出去"的，不是"开门等人进来"

cloudflared 这个客户端跑在你的 NAS 上，它会主动去连 Cloudflare 的边缘节点，建立一条长连接。之后外网访问你的域名，流量是先在 CF 边缘落地，再顺着这条已经建好的隧道回传给你的 NAS。

所以：你不需要公网 IP、不需要在路由器上做端口映射、外部扫描也扫不到你家的端口——因为压根就没有对外监听的端口。这也是它比 frp 更安全的原因之一（frp 的公网中转机是实打实开着端口的）。

② --protocol http2 为什么在国内更快

cloudflared 默认优先用 QUIC（跑在 UDP 上）连边缘节点，性能更好。但国内不少运营商对持续的 UDP 大流量有 QoS 策略，会出现"能连上但速度很烂"的情况。加上 --protocol http2 是让它改用 TCP 443 来承载隧道——和普通 HTTPS 流量长得一样，被限速/干扰的概率低得多。

③ "优选 IP"本质上是在选一个对你最快的 CF 入口

Cloudflare 全球的节点用的是 anycast（同一个 IP 在不同地区路由到不同机房）。问题是：CDN 厂商为了"就近"，给你解析到的节点未必是网络质量最好的那个——可能地理上近但绕路严重。

"优选"就是：自己拿一个域名，把它的解析手动指向实测最快的那个 CF 边缘 IP。这样流量先进最快的节点，再走 Cloudflare 的内部网络回源。

听起来简单，但这里有个坎：CF 免费版不允许你随便把 CNAME 指到"别人的 IP"。所以后面才会出现"第二个域名 + 回退源 + 自定义主机名 + DCV 委派"那一整套——它们就是为了绕过这个限制而存在的（下面会逐步解释每一步的作用）。

Cloudflare Tunnel 配置

1. 打开Cloudflare-Zero Trust-网络-连接器-添加隧道

2. 创建隧道，隧道名任意

3. 选择安装方案，我选择用docker部署在NAS上，复制下方命令即可

国内用户在命令中添加--protocol http2变量，可以加快连接速度

docker run cloudflare/cloudflared:latest tunnel --protocol http2 --no-autoupdate run --token xxx

4. 打开NAS的SSH，执行docker命令

5. 稍作等待，页面下方就会显示已连接的隧道

6. 继续设置二级域名，下方填写服务内网地址

7. 打开网址测试一下，没有问题

关于那个 --token xxx：这个 token 里已经包含了隧道的身份凭据，所以不需要额外在本地放证书文件。反过来说，token 泄露 = 别人能以你的身份接管这条隧道，别把它贴到公开的地方（截图、日志、GitHub 都算）。

飞牛OS设置

如果是飞牛OS，直接在应用商店安装Cloudflare Tunnel应用，可以使用可视化界面（不推荐）。

1. 安装应用

2. 创建令牌

3. 填入账号ID和令牌API

4. 创建隧道

5. 添加配置，填入域名和本地链接

6. 等待几分钟就完成配置了

我个人还是建议docker安装，应用商店的版本较低，且无法看到日志，操作反而更复杂了。

为什么"看不到日志"这么致命？ 因为隧道出问题时，cloudflared 的日志是唯一能告诉你"卡在哪"的东西——它要连哪个边缘节点、握手成功没有、回源请求是不是被本地服务拒绝，全在日志里。应用商店版把这些盖住了，一旦连不上你就只能干瞪眼。Docker 版直接 docker logs -f <容器名> 就能看，排错效率完全不是一个量级。

加速访问

前半段做完，服务已经能用了。但如果你穿透的是应用类服务（对延迟敏感），会明显感觉卡。下面这部分就是解决它。

1. 先测个速，延时还是挺高的，应用类的服务基本就不太能用了

2. 准备第二个域名，托管到CF上，这个域名只做优选试用，所以我注册了个免费域名
   对域名有需要的可以翻我之前的文章如何40元注册10年顶级域名，或者注册个免费域名。 3. 编辑已有的隧道

这一步是整篇最容易被绊倒的地方，说明一下为什么要第二个域名：

你的主域名要用来对外提供服务（而且要能优选），加速域名则专门负责"指向优选 IP"。两个角色分开，才不会被 CF 的 DNS 规则卡住。如果你还没搞定域名，可以看40 元注册 10 年顶级域名并托管到 EdgeOne——免费的 .us.ci 这类域名也行，操作思路一样。

4. 添加已发布应用程序路由，域填写加速域名

5. 给加速域名设置回退源，等待显示有效

6. 添加自定义主机名，主机名填写主域名

到这一步，"链条"就搭起来了：

纯文本

访客 → 主域名（自定义主机名）→ 回退源（加速域名）→ 隧道 → 你 NAS 上的服务

注意这里的顺序：自定义主机名负责"接收主域名的流量"，回退源负责"把流量交给隧道"。这么绕是因为 CF 免费版不允许直接把外部的自定义主机名指到你的隧道上——必须借道一个"属于你账号的域名"（加速域名）当跳板。

7. 查看自定义主机名状态，复制于验证txt名称及值

8. 在主域名中添加一条txt的dns解析，将复制的txt名称和值填入。

9. 重复操作，添加一条证书的验证

10. 验证有效即可，如果出现错误，多等一会再试，实在不行把主域名Tunnel的值改成txt的值，就过了。

11. 添加自定义主机名的 DCV 委派，实现证书自动续费
    主域名新建cname解析，名称和值填写如下

填好后是这样

DCV 委派是干什么的？ SSL 证书有有效期，到期前 CA 需要重新验证"这个域名还是你的"。手动验证就是第 8、9 步那套 TXT 记录——每 90 天来一次，谁受得了。DCV 委派相当于告诉 CF："以后验证域名所有权的事，你替我办"，CF 就能自动完成续签。加了这条，就不用再管证书了。

12. 加速域名添加加速记录，www.visa.cn可以换成别的，需要网上自己找

这一步填的就是"优选 IP"——即你实测出来的、对本地网络最快的那个 Cloudflare 边缘 IP。所以这个值因人因地而异，别照抄别人的。社区里有公开的优选 IP 列表，也可以自己扫。

13. 主域名修改解析地址为加速域名speedup.1day.us.ci

14. 再次测速，感觉好多了

加速部分常见报错

这一段的报错信息不太友好，列几个高发的：

小结

回到出发点：当没有 IPv6、也不想买服务器时，Cloudflare Tunnel 是目前最省心也最安全的内网穿透选择——装上 cloudflared、填个 token，就能用域名访问家里的服务，全程不暴露端口。

• 只穿透页面类轻服务：直接按前半段流程走，几分钟就好，无需加速。

• 要跑应用类服务 / 国内访问卡：再叠加后半段的"优选 IP 加速"，延时能从几百毫秒降到几十毫秒级别。

• 飞牛用户建议：优先用 Docker 部署而非应用商店版本，Docker 版能看日志、可升级、可控性更好。

如果你手上有一台带公网 IP 的服务器，那另一条路也值得看看：自建 frp 中转（用 frp 通过域名访问本地服务）。它的延时通常比 CF Tunnel 更低（因为中转机是你自己挑的、线路可控），代价是要自己维护服务器、且中转机是真实暴露在公网的。两者并不互斥：轻服务走 CF Tunnel 图省事，对延迟苛刻的服务走自建 frp。

整体来说，这套方案兼顾了"零成本 + 安全 + 相对可用"，对国内用户唯一的门槛就是那段优选加速配置。按文中的 14 步走完，效果立竿见影——测速对比里的改善是很明显的。