朱明朝说实话，我玩内网穿透差不多有五年了。最早用 frp，后来用 ngrok，再后来实在懒得维护一堆服务端配置，Cloudflare 官方出了 cloudflared tunnel，迁移过去之后基本就是“无脑托管”状态。如果你手里有一台没有公网 IP 的机器，却想在外面访问家里的 NAS、开发服务或者自托管应用，这篇就是给你写的。复制几条命令、跑一个进程，十几分钟就能把本地服务暴露到公网，而且不需要在路由器里做任何端口映射。
cloudflared tunnel 最大的优势在于：它不需要你自己的公网服务器，也不依赖动态 DNS，只要机器能正常访问外网，就能和 Cloudflare 的边缘节点建立一条出站连接，外部请求通过这条连接转到本地服务。对没有公网 IP、没有 IPv6、被运营商 CGNAT 卡住的场景，这基本就是“救星”级别的东西。下面我从安装、建隧道、绑域名、配置细节、生产部署到排障，一步步给你顺一遍，都是实际跑过之后的经验。
1. 为什么最后选了 cloudflared tunnel
1.1 它是做什么的
Cloudflare Tunnel 是 Cloudflare 官方提供的隧道服务，cloudflared 就是跑在你自己机器上的客户端进程。它跟 frp 那种“客户端连服务端”思路最大的不同在于：你这个本地进程会主动向外连到 Cloudflare 的边缘节点，然后保持一条常连接。用户访问你的域名时，Cloudflare 的边缘节点会把请求沿着这条已经建立好的连接转发到你的机器上。
用大白话解释就是：你的电脑不需要有公网 IP，也不用在路由器上开端口，甚至不需要让外部任何请求直接打到你机器上。所有外部流量都先落在 Cloudflare 的边缘网络，再由边缘节点“反向地”递给你的本地进程。这个设计有几个天然好处：源站 IP 不会暴露，本地不需要开放任何入站端口，防火墙策略可以收得很紧。
而且 cloudflared 是 Cloudflare 自家工具，跟 Cloudflare 的 DNS、CDN、Access 身份验证都是无缝配合的。你只要把域名托管在 Cloudflare，然后创建一条隧道，再绑一个 CNAME 记录，就能把某个子域名指向本地的任意端口服务。
1.2 和 frp、ngrok 放在一起比
当初我试过的方案有很多，简单列一下对比，方便你判断它适不适合你。
| 方案 | 是否需要公网服务器 | 免费额度 | 配置复杂度 | 长期维护 |
|---|---|---|---|---|
| frp | 需要 | 取决于自建服务器 | 中，需要自己维护服务端、客户端、token、权限 | 中 |
| ngrok 官方 | 不需要 | 免费版域名随机、连接数有限制 | 低，下载即用 | 低 |
| ngrok 自建 | 需要 | 同 frp | 高 | 高 |
| cloudflared tunnel | 不需要 | 免费，可用自有域名 | 低，官方工具全流程支持 | 低 |
frp 的优势是延迟可控、流量完全走你自己的服务器，适合对速度和数据路径有强要求的人。ngrok 胜在开箱即用，但免费版限制多，随机域名也不好长期使用。cloudflared tunnel 则把“免费的边缘网络”和“配置简单”结合得很好，尤其适合个人开发、自托管、NAS 这类场景。
当然它也不是万能的。Cloudflare 的边缘节点离你远不远、你本地到边缘节点的连接质量怎么样，直接决定访问延迟。如果你在国内访问，实际体验会有波动，这个要有心理准备。另外，Cloudflare 免费计划对流量、内容类型是有使用条款约束的，拿它当大流量下载分发通道不合适，容易收到警告。
1.3 我实际用到了哪些场景
我自己用得最多的是三类。第一类是开发联调，本地起了一个 Web 服务，需要暴露给第三方平台回调，比如 GitHub Webhook、支付回调，或者给同事临时看一下页面效果，一条 quick tunnel 就能解决。第二类是个人 NAS 和管理面板，比如 Home Assistant、Jellyfin、Nextcloud 这些自托管服务，在外部网络用自己域名访问。第三类是 SSH 远程连接，只要把 22 端口映射成隧道，出门在外也能安全地连回家里机器。
还有一个很典型的场景：很多人的宽带处于运营商大内网环境，没有真正的公网 IP，就算有动态 DNS 也解决不了端口映射问题。cloudflared tunnel 的出站连接机制完全绕开了这个限制，只要你的机器能访问外网，就能把服务映射出去。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 安装与登录：从零跑通临时隧道
2.1 安装 cloudflared
cloudflared 的安装方式很完善，Windows、macOS、Linux、Docker 都有官方支持。拿最常见的 Debian/Ubuntu 来说，直接在 GitHub Releases 下载 deb 包然后用 dpkg 安装就行。
bash复制curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
macOS 用户用 Homebrew 一条命令：
bash复制brew install cloudflared
Windows 用户直接下载 exe 文件，放到一个固定目录里，在命令行里调用即可。也可以用 Docker 方式跑：
bash复制docker run cloudflare/cloudflared:latest tunnel --url http://localhost:8080
装完先验证一下版本，确认二进制正常：
bash复制cloudflared --version
如果输出版本号，说明安装成功。要注意的是，不同平台、不同冷门 CPU 架构，GitHub 的发布页面都有对应包，ARM 设备比如树莓派、部分 NAS，选 arm64 版本就行。
2.2 先跑一条临时隧道试试水
不急着搞账号和域名，先用 quick tunnel 验证一下能不能通。Quick tunnel 是 Cloudflare 提供的零配置临时隧道，不需要你拥有域名，直接跑一条命令就能拿到一个 *.trycloudflare.com 的临时地址。
我一般用一个简单的本地服务来测试。比如在另一个终端启动 Python 自带 HTTP 服务：
bash复制python3 -m http.server 8080
然后运行：
bash复制cloudflared tunnel --url http://localhost:8080
cloudflared 会启动并和 Cloudflare 边缘节点建立连接，命令输出里会有一行类似这样的地址：
code复制https://random-string.trycloudflare.com
把这段地址丢到浏览器里，如果能打开刚才那个 Python 服务的页面，说明隧道已经通了，工具本身没有任何问题。这里有个小坑：新版本 cloudflared 跑 quick tunnel 时有可能会要求你先登录一次，不用慌，按提示执行 cloudflared tunnel login 即可，登录不消耗任何费用，只是为了防滥用。
2.3 注意临时隧道和正式隧道的差别
Quick tunnel 很爽，但只适合临时调试。它的域名是随机分配的，每次重启都会变，而且这个域名是公开的，拿到链接的人都可以访问你本地服务。所以它不适合做正式服务入口，更不要用它暴露敏感的管理后台。
正式使用要创建“命名隧道”（named tunnel），也就是在 Cloudflare 账户里登记一条有固定 ID 的隧道，然后用自己的域名绑定到这条隧道上。这样域名是稳定的、可控的，还可以配合访问控制做安全加固。后面第三部分就重点讲正式隧道的创建。
3. 创建正式隧道，绑定自己的域名
3.1 登录授权并创建命名隧道
正式隧道的第一步是登录授权，让 cloudflared 有权限管理你 Cloudflare 账户下的域名和隧道。
bash复制cloudflared tunnel login
执行后，终端会弹出一个链接，复制到浏览器打开，选择你要授权的域名，授权完成后 cloudflared 会下载一个 cert.pem 证书文件到本地，默认放在 ~/.cloudflared/cert.pem。这个文件相当于账户凭证，后续创建隧道时会用到，务必保管好。
然后创建隧道，名称自己定，比如 home 或者 nas：
bash复制cloudflared tunnel create home
执行后，cloudflared 会生成一个隧道 ID，并在 ~/.cloudflared/ 目录下生成对应的凭据 JSON 文件，比如 <隧道ID>.json。这个 JSON 文件是隧道的身份凭证，别丢。你可以通过 cloudflared tunnel list 查看当前账户下的所有隧道。
其实现在还有更简单的路子：在 Cloudflare Zero Trust 的 Dashboard 里创建隧道，页面会直接生成一条包含 token 的运行命令，形如 cloudflared tunnel run --token <一串很长的token>。把这条命令在你机器上跑起来，隧道就上线了。这种模式不需要本地维护 cert.pem，适合不想折腾配置文件的场景。但如果你要同时映射多个域名和服务，我还是建议用传统本地配置文件的方式，清晰可控。
3.2 用 DNS 路由把域名指向隧道
隧道创建好了，接下来把域名绑上去。比如我有一个域名 example.com，想用 app.example.com 访问本地服务：
bash复制cloudflared tunnel route dns home app.example.com
这条命令本质上是帮你在 Cloudflare DNS 面板里创建了一条 CNAME 记录，指向 <隧道ID>.cfargotunnel.com。也就是说，Cloudflare 把流量从你的子域名转发到对应隧道，再由隧道转发到本地服务。
如果不喜欢命令行，也可以去 Cloudflare Dashboard 的 DNS 页面手动添加：记录类型选 CNAME，名称填 app，目标填 <隧道ID>.cfargotunnel.com，代理状态保持开启。两者效果一样，手动添加更适合喜欢在网页上操作的人。
在这里我想提醒一句：如果之前这个子域名已经有 A 记录或者其他记录，建议先删掉，避免冲突导致解析不稳定。我就踩过一次，旧 A 记录没删干净，隧道明明在线但访问时好时坏。
3.3 用配置文件管理多个服务
如果你只想映射一个服务，可以跳过配置文件，直接用命令运行。但实际使用中，一台机器上往往有多个服务要映射，这时候就要写配置文件了。
cloudflared 默认会读取 ~/.cloudflared/config.yml。下面是一个可以照抄的例子：
yaml复制tunnel: <你的隧道ID>
credentials-file: /root/.cloudflared/<你的隧道ID>.json
ingress:
- hostname: app.example.com
service: http://localhost:8080
- hostname: nas.example.com
service: http://localhost:5000
- hostname: ssh.example.com
service: ssh://localhost:22
- service: http_status:404
写完后运行：
bash复制cloudflared tunnel run home
有几点需要特别注意。第一，ingress 规则从上到下按顺序匹配，请求域名如果匹配到第一条就不会继续往下走了，所以细致的规则要放前面。第二，最后一定要放一条没有 hostname 的 catch-all 规则，否则配置校验过不了；如果配置了一个没有被任何规则匹配的域名，cloudflared 会返回 404，方便你发现规则写漏了。第三，credentials-file 路径要写对，用相对路径容易在各种诡异路径下踩坑，我习惯写绝对路径。
如果你想在配置里同时管理多条隧道，也可以把 tunnel 字段换成 tunnel token 并通过 --token 参数指定，但那是更进阶的玩法，一般不需要。
4. 核心细节：流量路径、协议与常见配置
4.1 一次请求是怎么从外网打到源站的
理解了完整链路，后面排查问题会轻松很多。当用户访问 https://app.example.com 时，第一步是 DNS 解析，因为你在 Cloudflare 上托管了域名，所以解析结果会指向 Cloudflare 的 Anycast IP，也就是离用户最近的边缘节点。第二步，Cloudflare 边缘节点看到该域名对应一条隧道，于是把请求通过这条已经建立的出站连接转发给你机器上的 cloudflared 进程。第三步，cloudflared 根据配置里的 ingress 规则，把请求转发给对应的本地服务，比如 http://localhost:8080。
整个过程里，你的机器到 Cloudflare 边缘的连接方向始终是“出站”的，也就是由你机器主动发起。这意味着什么？意味着即便你的出口 IP 是动态的、随机的，甚至被 CGNAT 包了一层，都不影响连接建立。也正因为没有入站端口，外部扫描器很难发现你源站的真实 IP，安全性比传统端口映射高一个档次。
还有一点，如果你的机器到 Cloudflare 边缘的连接断了，cloudflared 会自动重连。重连期间访问请求会失败，但恢复后不需要任何人工干预。这一点比 frp 稳很多，frp 客户端掉线后偶尔会卡在重连状态，cloudflared 的自动恢复机制做得相当成熟。
4.2 HTTP、TCP、UDP 都支持，怎么选
很多初学者以为 cloudflared 只能代理 HTTP 流量，其实不是。它支持 HTTP、HTTPS、TCP、UDP、Unix Socket 多种协议。常见配置里，HTTP 服务直接写 service: http://localhost:端口，SSH 服务可以写 service: ssh://localhost:22，其他 TCP 服务比如数据库可以写 service: tcp://localhost:5432。
我自己的经验是：能用 HTTP 就用 HTTP，因为 Cloudflare 边缘节点对 HTTP 流量的优化最完善，可以配合缓存、WAF、Access 这些功能。SSH 本身是基于 TCP 的，用 ssh:// 类型即可，连接质量还不错。如果你要穿透的是任意 TCP 协议，比如 RDP 或者自研协议，用 tcp:// 就行。
另外 cloudflared 与 Cloudflare 边缘之间的连接，可以选择 http2 或 quic 协议。默认现在一般会走 QUIC，也就是需要在你的机器上开放 UDP 7844 端口的出站流量。如果公司网络或路由器把 UDP 封了，cloudflared 可能连接不稳定，这时候可以显式指定走 HTTP/2：
bash复制cloudflared tunnel --protocol http2 run home
如果你的网络出口比较干净，我建议保持 QUIC。QUIC 的连接复用和多路复用能力更强，长期运行下连接数更低，对弱网环境也更友好。
4.3 TLS 证书到底由谁负责
这个问题很多人第一次用会犯迷糊：我本地服务是 HTTP 的，浏览器访问会不会报证书错误？实际上不会。TLS 的终止点发生在 Cloudflare 边缘节点，也就是说，用户和 Cloudflare 之间是 HTTPS，证书由 Cloudflare 自动签发和管理；而 Cloudflare 到你的 cloudflared 进程、再到本地服务这一段，走的是经过复用的内部连接，本地服务根本不需要部署证书。
这也是 Cloudflare Tunnel 设计上的一个优势：源站不需要证书、不需要 443 端口、不需要处理证书续期。本地服务哪怕只是个临时起的 Python HTTP 服务，外网用户看到的也是一个正常的 HTTPS 地址。
但有一种情况你要注意：如果你在配置里把 service 写成了 https://localhost:端口，而本地服务用的是自签证书，cloudflared 默认会校验证书导致请求失败。这时候可以在对应 ingress 规则里加一行 noTLSVerify: true，让 cloudflared 跳过对源站证书的校验。不过这种做法只建议在可控内网环境下使用，能避免还是尽量让本地服务走明文 HTTP 或者用正规证书。
还有一个细节：当你的域名走 Cloudflare Tunnel 后，DNS 解析记录要保持“Proxied”状态（橙色云朵），不能设成灰色云朵，否则流量不会经过 Cloudflare 边缘，隧道也就不生效。
5. 生产级部署：开机自启、参数调优与安全加固
5.1 systemd 守护进程配置
本地跑一下验证功能是一回事，放进生产环境长期运行是另一回事。Linux 下最稳的方式是用 systemd 托管。安装 cloudflared 时，部分发行版会自动生成 systemd 服务文件，但还是建议自己写一份，明确启动参数和用户权限。
在 /etc/systemd/system/cloudflared.service 里写：
code复制[Unit]
Description=Cloudflare Tunnel Agent
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
User=cloudflared
ExecStart=/usr/local/bin/cloudflared tunnel run home
Restart=on-failure
RestartSec=5s
LimitNOFILE=1048576
[Install]
WantedBy=multi-user.target
其中 User=cloudflared 建议单独建一个低权限用户，不要用 root 跑，减小风险。Restart=on-failure 保证异常退出后自动重启。写完以后执行：
bash复制sudo systemctl daemon-reload
sudo systemctl enable cloudflared
sudo systemctl start cloudflared
用 systemctl status cloudflared 可以看当前状态。这里有个容易忽略的点：如果 ExecStart 里用了本地配置文件，要确保配置里的 credentials-file 路径对 systemd 运行用户可读，否则进程起不来。常见错误是 root 创建的 JSON 文件，cloudflared 用户没权限读。
如果你不想用 systemd，用 Docker 跑 cloudflared 也很方便，加上 --restart unless-stopped 就能保证容器长期运行。但要注意把配置文件和凭据目录挂载进容器，环境变量也要传对，否则容器里找不到配置。
5.2 常用启动参数与监控
cloudflared 的启动参数有不少，我用得比较多的是这几个。
--loglevel 控制日志级别，调试期可以设成 debug，稳定运行后建议设成 info 或 warning，避免日志刷爆磁盘。--metrics 可以暴露一个本地监控端口，比如：
bash复制cloudflared tunnel run home --metrics localhost:3456
然后通过 curl localhost:3456/metrics 就能拿到连接数、流量等监控指标，如果你有 Prometheus，甚至可以接入统一监控面板。--no-autoupdate 用来关闭自动更新，因为自动更新在长期运行的生产机器上可能导致版本突然跳变，配合 systemd 重启策略反而容易出意外，我一般手动控制升级节奏。
还有一点，如果你的机器网络环境比较奇怪，比如出口只允许特定端口，可以配合 --protocol http2 绕过 UDP 限制。但别一上来就指定，先默认跑，观察日志是否稳定，再决定要不要改。
5.3 用 Cloudflare Access 加一层访问控制
隧道把本地服务暴露到公网，本身就是一种风险缓解措施。但如果你暴露的是管理后台、家人共用的 NAS 页面，你肯定不想让任何知道域名的人直接打开。Cloudflare 提供了一个免费好用的东西：Access。简单说，你可以在 Cloudflare 边缘层拦一道，要求访问者登录邮箱、提供身份验证后才放行。
配置路径是 Zero Trust Dashboard 的 Access 页面，选择你要保护的域名，添加一个访问策略，比如规定必须使用 @你的域名 邮箱才能进入。配置完成后，访问者会先看到一个 Cloudflare 的登录页，验证通过后才能访问你本地服务。
这个功能对自托管场景特别实用。比如我把 Home Assistant 的地址放在公网上，外面能访问，但只有我在内的几个邮箱账号能通过 Access 验证。这样就算有人扫到了域名，也没法轻易进入管理后台。免费版 Access 支持的账号数有限，但个人使用完全够。
5.4 安全配置清单
我自己踩过一些坑，整理成了一份安全配置清单，你照着检查一遍能避免大部分低级问题。
第一，不要把 Tunnel Token 或者 cert.pem、credentials JSON 提交到 GitHub 或者其他公开仓库。拿到这些文件的人可以直接控制你的隧道，甚至在你机器上重新创建隧道，风险等同于拿到服务器密码。第二，本地服务尽量只监听 127.0.0.1，不要监听 0.0.0.0。cloudflared 和本地服务在同一台机器上，完全可以通过回环地址访问，没必要把端口暴露到局域网。第三，定期更新 cloudflared 版本，Cloudflare 会修复一些底层协议漏洞，长期不升级会产生安全隐患。第四，对敏感服务启用 Access 或至少设置 IP 白名单，不要让敏感后台在公网裸奔。第五，使用 quick tunnel 调试后要及时停止，不要让临时通道长期挂在后台。
6. 常见问题与排查实录
6.1 域名能打开但一直 502 / 503
这是最常遇到的问题之一。域名解析正常、证书正常，但页面返回 502 或者 503，通常意味着 Cloudflare 边缘节点已经找到隧道，但 cloudflared 没能把请求正确转发到源服务。
我一般按这个顺序排查。先确认本地服务真的在监听，比如 curl http://localhost:8080 能不能通，很多情况是服务根本没起来，或者起了但端口不对。再确认配置文件里的端口和实际服务端口一致，尤其改过代码之后容易忘记更新配置。然后看 cloudflared 日志，有没有 connection refused 或者 timeout 之类的关键字，日志里通常会直接告诉你连接失败的原因。
有一种比较隐蔽的情况：本地服务监听的是 IPv6 地址 ::1，而配置写的是 localhost，某些系统上 localhost 解析为 IPv4 127.0.0.1，导致连接失败。解决办法是配置里明确写 http://127.0.0.1:端口，或者直接写 IPv6 地址。
6.2 解析没问题，但访问提示没有匹配到 ingress 规则
这种情况通常是访问了一个没有在 ingress 里配置的域名，或者 hostname 配置有误。比如你只配了 app.example.com，结果拿根域名 example.com 去访问，就会触发 catch-all 规则返回 404。
检查方法很简单，打开 cloudflared 日志，看请求来时它匹配到了哪条规则。如果日志显示没有匹配项，就把你要访问的域名加到 ingress 列表里，并确保 DNS 记录已经指向对应隧道。另外，注意 CNAME 记录一定要指到 <隧道ID>.cfargotunnel.com，不要顺手写错成别的值。
还有一个常见坑：配置修改后没有重启服务。cloudflared 读配置文件是在进程启动时，不是热加载，你改了 config.yml 后必须重启进程才能生效。我一度以为它会自动 reload，后来才发现改了没动静。
6.3 隧道反复重连，日志里一堆错误
这是比较影响体验的问题，表现是 cloudflared tunnel 进程活着，但日志里频繁出现连接断开、重连失败等记录。优先怀疑网络环境对 cloudflared 依赖的协议有限制。如果日志里频繁出现 QUIC 相关错误，基本就是 UDP 7844 出站被防火墙或运营商封了。
解决办法是切换协议：
bash复制cloudflared tunnel run home --protocol http2
如果切到 HTTP/2 后稳定了，那就是 UDP 的问题。另外还有一种情况是出口带宽跑满或者网络抖动严重，导致连接质量差。可以尝试在 cloudflared 的 systemd 服务里加上 Restart=always，并且调低日志级别，至少保证重连是自动完成的。
6.4 配置文件改了没生效
前面提过 cloudflared 不会热加载配置，每次修改 config.yml 后必须重启进程。但这里有一个需要额外注意的小细节：如果你用 systemd 托管，重启时要保证配置文件的权限正确，否则服务可能起不来。还有，有些命令组合里，--config 指定的配置路径和默认路径不同，改错了文件当然不会生效。
我自己的习惯是，所有配置都放到 /etc/cloudflared/config.yml，然后在 systemd 的 ExecStart 里显式指定：
bash复制cloudflared tunnel --config /etc/cloudflared/config.yml run home
这样至少路径是明确的，不会出现“我以为改了配置，其实改了个没用上的文件”这种尴尬。
关于 cloudflared tunnel 的一些个人体会
用了这么久，如果要我给一个总结性的判断，我会说 cloudflared tunnel 是目前个人自托管场景下性价比最高、门槛最低的内网穿透方案之一。它的出站连接设计让它天然适应没有公网 IP 的环境，自带域名绑定和 TLS 管理又省去了大量证书维护工作，配合 Cloudflare Access 还能在边缘层做访问控制，整体体验非常顺滑。
最后再分享一个我的习惯：做任何改动之前，先备份 ~/.cloudflared/ 目录下所有 JSON 和 YAML 文件。虽然 Cloudflare Dashboard 里能重建隧道，但本地的凭据文件丢了，旧配置就得重来一遍。对于想稳定长期使用的服务，我会先在 quick tunnel 上验证端口和协议是否正确，确认没问题再切换到命名隧道正式上线。这套流程看起来多一步，但实际能帮你省掉很多“重启、看日志、再重启”的时间。