Cloudflare Tunnel 入门指南：不用公网 IP 暴露内网服务

Tue, 23 Jun 2026 20:37:00 +0800

Cloudflare Tunnel 是 Cloudflare 提供的一种反向连接方案。它的核心思路很简单：服务器不再主动开放公网端口，而是在内网机器上运行一个轻量级守护进程 cloudflared，由它主动向 Cloudflare 建立出站加密连接。

这样一来，你的 Web 服务、API、测试环境、家庭服务器、NAS 面板，甚至某些内网应用，都可以通过 Cloudflare 分配的公共主机名访问，而源站本身不需要公网 IP，也不需要在路由器上做端口转发。

官方文档入口：

Cloudflare Tunnel 解决了什么问题

传统暴露服务的方式通常绕不开几个麻烦点：

服务器需要公网 IP；
路由器或云防火墙要开放入站端口；
源站 IP 容易被扫描和攻击；
家宽、内网、临时测试环境不方便直接对外提供 HTTPS 访问；
反向代理、证书、端口转发、动态 DNS 都要自己维护。

Cloudflare Tunnel 换了一个方向：不是让外部流量直接打到你的服务器，而是让你的服务器主动连到 Cloudflare。外部用户访问域名时，流量先进入 Cloudflare，再通过已经建立好的 Tunnel 转发到你的本地服务。

对普通使用者来说，最直观的好处就是：

不需要公网 IP；
不需要开放入站端口；
可以隐藏源站地址；
可以复用 Cloudflare 的 HTTPS、WAF、DDoS 防护、Bot 管理等能力；
适合把内网 Web 服务安全地挂到一个正式域名下面。

它的工作方式

一个典型的 Cloudflare Tunnel 流程大致是这样：

在服务器、虚拟机、家用主机或容器里安装 cloudflared。
cloudflared 主动连接到 Cloudflare 全球网络。
在 Cloudflare 控制台里创建 Tunnel，并把某个公共主机名映射到本地服务。
用户访问这个公共主机名。
Cloudflare 接收请求，并通过 Tunnel 把请求转发到你的内网服务。

比如你本地有一个服务跑在：

`1`	`http://localhost:8080`

你可以把它映射成：

`1`	`app.example.com`

用户访问 https://app.example.com 时，请求会先经过 Cloudflare，然后再转发到本机的 http://localhost:8080。

Cloudflare 文档里还提到，每个 Tunnel 默认会维护多条长连接，并连接到不同的 Cloudflare 数据中心。生产环境里也可以运行多个 cloudflared 副本，用来提高可用性。

适合哪些场景

Cloudflare Tunnel 最适合下面几类场景：

内网 Web 面板：比如 NAS、Homelab、开发机上的管理后台。
临时演示环境：把本地开发中的 Web 应用临时分享给别人。
自建服务公开访问：把 API、博客后台、监控面板等服务挂到域名下。
没有公网 IP 的环境：家宽、校园网、公司内网、NAT 后面的机器。
想隐藏源站 IP 的业务：减少源站被直接扫描、撞库、攻击的机会。
多服务统一入口：一个 Tunnel 可以发布多个公共主机名，对应不同本地服务。

不过要注意，Cloudflare Tunnel 不是简单意义上的“万能内网穿透”。如果你要发布 SSH、RDP、TCP 这类非 HTTP 服务，通常还需要在客户端侧也运行 cloudflared，或者结合 Cloudflare Zero Trust / Access 做更完整的访问控制。

如果只是发布一个普通 Web 服务，它上手会非常快；如果想把它当成公司级内网访问方案，就需要额外设计身份认证、权限分组和审计策略。

准备条件

正式创建 Tunnel 之前，建议先确认几件事：

你有 Cloudflare 账号；
你的域名已经托管在 Cloudflare；
有一台能访问互联网的服务器、虚拟机、容器或本地机器；
这台机器可以连接 Cloudflare 网络；
如果环境有严格防火墙，需要确认能访问 Cloudflare Tunnel 使用的出站连接端口。

官方文档中特别提到，如果服务器在限制比较严格的网络环境里，可以检查是否允许访问 Cloudflare 的 7844 端口。

在控制台创建 Tunnel

最简单的方式是直接走 Cloudflare Dashboard。

进入 Cloudflare 控制台后，大致路径是：

`1`	`Zero Trust / Networking -> Tunnels -> Create Tunnel`

然后按页面提示操作：

选择 Cloudflare Tunnel。
给 Tunnel 起一个名字。
选择服务器的操作系统和 CPU 架构。
复制 Cloudflare 生成的安装命令。
在服务器上执行命令，安装并启动 cloudflared。
回到控制台确认 Tunnel 状态变成 Healthy。

当 Tunnel 状态变成 Healthy，说明你的服务器已经成功和 Cloudflare 建立连接。

发布一个公共主机名

Tunnel 建好之后，还需要配置路由，也就是告诉 Cloudflare：

`1`	`哪个域名 -> 转发到哪个本地服务`

比如：

`1`	`app.example.com -> http://localhost:8080`

常见的本地服务地址可以是：

1
2
3

http://localhost:80
https://localhost:443
http://192.168.1.10:8080

配置完成后，Cloudflare 会自动创建一条 DNS 记录，把你的公共主机名指向类似下面这样的 Tunnel 地址：

`1`	`<TUNNEL_ID>.cfargotunnel.com`

这个地址不需要用户直接访问，它只是 Cloudflare 内部用来把域名流量路由到 Tunnel 的目标。

一个 Tunnel 可以发布多个应用。比如：

1
2
3

nas.example.com      -> http://192.168.1.20:5000
git.example.com      -> http://192.168.1.30:3000
monitor.example.com  -> http://localhost:9090

这样就可以用一个 cloudflared 实例管理多组内网 Web 服务。

常见运行方式

在 Linux 或 macOS 上，Cloudflare 控制台通常会给出类似这样的服务安装命令：

`1`	`sudo cloudflared service install <TUNNEL_TOKEN>`

Windows 上则类似：

`1`	`cloudflared.exe service install <TUNNEL_TOKEN>`

如果你更喜欢 Docker，也可以用官方镜像运行：

`1`	`docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TUNNEL_TOKEN>`

这里的 <TUNNEL_TOKEN> 是非常敏感的凭据。不要把它提交到公开仓库，也不要截图发到公共论坛。拿到这个 token 的人，理论上就有机会把自己的 cloudflared 接到你的 Tunnel 上。

Quick Tunnel 适合临时测试

Cloudflare 还提供了一种更快的临时方式，叫 Quick Tunnel。

在本机执行：

`1`	`cloudflared tunnel --url http://localhost:8080`

它会生成一个随机的 trycloudflare.com 子域名，让外部临时访问你的本地服务。

这个方式非常适合：

临时演示；
本地调试 webhook；
给同事看一个开发中的页面；
不想马上绑定正式域名的测试。

但它不适合生产环境。官方文档说明，Quick Tunnel 有一些限制，比如随机域名不可控、并发请求有限制，也不支持某些长连接能力。正式服务还是应该创建标准 Tunnel，并绑定自己的域名。

几个容易踩坑的地方

1. 本地服务监听地址不对

如果你的服务只监听在某个容器内部地址，或者只允许特定网卡访问，cloudflared 可能连不上。

排查时可以先在运行 cloudflared 的机器上执行：

`1`	`curl http://localhost:8080`

如果本机都访问不了，Cloudflare Tunnel 也转发不了。

2. 防火墙拦了出站连接

Cloudflare Tunnel 不需要开放入站端口，但它需要主动连出去。如果公司网络、云安全组或本机防火墙拦截了出站连接，Tunnel 可能一直无法 Healthy。

这种情况要重点检查出站访问策略，尤其是 Cloudflare 文档提到的 Tunnel 连接端口。

3. 域名没有托管在 Cloudflare

如果你要发布正式公共主机名，域名需要在 Cloudflare 上管理。否则 Cloudflare 无法自动帮你创建对应 DNS 路由。

4. 管理后台不要裸奔

Cloudflare Tunnel 解决的是“怎么安全连到源站”，但它不等于自动给你的应用加了登录系统。

如果你暴露的是 NAS、Git、监控、数据库管理后台这类敏感服务，建议至少再加一层 Cloudflare Access，按邮箱、组织账号或身份提供商限制访问。

5. 配置文件模式要有兜底规则

如果你使用 API 或本地配置文件管理 ingress rules，官方文档要求最后放一个兜底规则。常见写法是返回 404：

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404

这样可以避免没有匹配到的请求被错误转发到不该访问的服务。

一句话总结

Cloudflare Tunnel 最适合用来把内网 Web 服务安全、稳定地发布到公网域名上。它不要求公网 IP，不要求开放入站端口，部署成本也不高。

如果你只是想把家里或服务器上的一个 Web 面板挂出来，Cloudflare Tunnel 是非常实用的选择；如果你要做更复杂的企业内网访问，还应该配合 Cloudflare Access、Zero Trust 策略和更细的权限控制一起使用。

Cloudflared on KnightLi的博客