Cloudflare Tunnel 多服务路由：一份配置搞定所有域名和端口

部署过 Cloudflare Tunnel 的读者应该都体会过那种纠结：服务器上跑了好几个服务，API 一个端口、前端一个端口、文件服务又一个端口，用 Tunnel 暴露的时候到底该怎么组织？开多条隧道吧，每条维护起来都是负担；隧道前面再套一层 Nginx 反代吧，链路又多了一层，断层排错时难受得很。这系列文章前面几篇讲了不少 Tunnel 的基础玩法，这一篇专门来解决"多服务怎么优雅地共用一个隧道"的问题——直接利用 Cloudflare Tunnel 的 ingress 规则做多服务路由，一份配置文件搞定所有域名和路径的转发，不用多开进程，也不用额外架反向代理。

这个方案适合谁用？手头有 NAS、软路由、自建博客、监控面板、几个开发环境接口，希望统一从 Cloudflare 网络暴露出去但又不想被端口号折磨的人。也适合刚把服务迁到容器、想把 80/443 留空给更干净网络结构的人。读完这一篇，你会拿到一份能直接套用的配置模板、一整套落地步骤，还有我在实际部署里踩过的几个只有真实环境才会遇到的坑。

1. 一个隧道管多个服务的刚需

1.1 多服务暴露到公网的几种笨办法

先说一个几乎所有自建服务玩家都会遇到的场景。我有一台内网主机，上面跑了三个服务：一个是自己写的短链接 API，监听在 8090；一个是家庭网络监控面板，监听在 3000；还有一个是给手机同步用的文件服务，监听在 5000。三个服务都要在外面访问，最朴素的思路是给每个服务单独建一条 Tunnel。这确实可行，但你会发现几件事很快让人难受：

• 每建一条 Tunnel 就要做一次cloudflared tunnel create，然后得记住好几个 Tunnel 的 UUID，配置分散在各自的 YAML 文件里，排查问题时要来回切换。
• 每个 Tunnel 都会在本地起一个独立的 cloudflared 进程。虽然单进程资源占用不大，但多了以后在主机上看进程列表乱成一团，想定位某一个服务的连接状态还得对应着找。
• Cloudflare 侧每个 Tunnel 要配对应的 DNS 记录，域名多了以后，DNS 记录和 Tunnel 之间的对应关系完全靠脑子记，过一个月再看基本忘光。

比较常见的第二种办法是在内网先架一个 Nginx 或 Caddy，把 8090、3000、5000 统一反代到某个端口，再让 Tunnel 只暴露这个反代端口。这个方案也能跑，但问题在于链路变长了：请求从 Cloudflare 边缘进来，先到 cloudflared，再转发给 Nginx，Nginx 再转给后端服务。链路每多一跳，就多一个可能的故障点和日志断层。而且 Nginx 自身的证书、缓存、upstream 健康检查都要维护，很多玩法其实和 Cloudflare Tunnel 重复了。

1.2 单隧道多服务路由为什么更顺

Cloudflare Tunnel 本身就有路由分发能力，官方叫 ingress 规则。它的思路很简单：一条隧道连接本地服务和 Cloudflare 边缘之间，在 cloudflared 这里是多个服务共用一个入口，然后由本地配置文件决定"哪个域名、哪个路径的请求转到哪个本地服务"。这相当于把 Nginx 的 server_name 和 location 功能浓缩到一份 cloudflared 的 YAML 配置里。

用这个方式的好处很直接：

1. 配置集中：所有服务的路由规则、本地端口、Tunnel 归属信息都写在同一个文件里。新增一个服务时，只需要在 ingress 列表里加几行，不需要动任何系统服务、不需要新增进程。
2. 链路短：请求到达本地之后不再经过额外反代层，直接到业务服务。日志断层少，网络瓶颈少。
3. 控制面统一：DNS 记录、Tunnel、访问策略都在同一个 Cloudflare 账号下管理，域名和服务的对应关系一目了然。

实际用下来它最像什么？就像一个总机分机系统。域名相当于总机号码，path 相当于分机键，本地不同的服务就是不同的分机。接进来之后，总机根据你拨的分机号把电话转到对应人手里。ingress 规则就是这个总机的接线表。

1.3 适用边界与前置条件

这个方案不是万能的，先说清边界，免得读者照搬后踩到预期之外的问题。

• 它适合 HTTP/HTTPS 或 TCP 类的服务。如果是 UDP 协议、或是需要固定公网端口的特殊业务，Cloudflare Tunnel 的适用性就会差一些。
• 依赖 Cloudflare 的 DNS 接入。域名必须托管在 Cloudflare 且启用代理状态，否则 Tunnel 无法收到流量。
• 本地服务最好监听在127.0.0.1而不是0.0.0.0，这一点后面会细说。目的就是让服务只接受来自 cloudflared 的本地转发，不额外暴露局域网端口。

如果是一条已经存在的 SSH 或数据库这类非 HTTP 服务，可以通过额外配置 TCP 路由来支撑，不过这属于进阶话题，这一篇的重心还是多服务 HTTP 路由模板。

2. 多服务路由模板的核心机制

2.1 ingress 规则的匹配逻辑

理解 Cloudflare Tunnel 多服务路由的关键，就是把 ingress 规则当成一条"从上到下逐条匹配，命中即停"的路由表。每一条规则都包含 hostname 和 service 两个核心字段，也可以额外加 path 来做更细粒度的控制。cloudflared 收到一个请求后，会检查请求的 Host 头和 URL 路径，然后按顺序逐条规则去比对：

• 先看 hostname 是否匹配当前规则的 hostname，如果匹配再看 path 是否匹配（如果这条规则定义了 path 的话）。
• 如果完全命中，就把请求转发到这条规则指定的本地 service 地址。
• 如果当前规则没命中，就继续往下找。
• 一直到最后一个 catch-all 规则。如果请求都没匹配上前面任何一条，就按最后一条规则处理，通常会配一个返回 404 的兜底。

这个机制决定了两个事：一是规则的书写顺序非常关键，二是 catch-all 规则必须有，否则匹配不到任何规则时 cloudflared 会返回 502。这两条我在实际部署中都踩过，section 4 会详细展开。

2.2 一份能直接套用的完整模板

下面这份配置是我当前在用的结构简化版。它覆盖了过去我遇到的三种典型需求：两个不同域名的服务走不同端口、同一个域名下通过不同路径切到不同服务、额外的域名直接透传给一个监听在 8080 的容器服务。

# /etc/cloudflared/config.yml tunnel: <你的-tunnel-id> credentials-file: /etc/cloudflared/<你的-tunnel-id>.json ingress: - hostname: shortlink.example.com service: http://127.0.0.1:8090 - hostname: monitor.example.com service: http://127.0.0.1:3000 - hostname: app.example.com path: /api/* service: http://127.0.0.1:8090 - hostname: app.example.com service: http://127.0.0.1:3000 - hostname: "*.files.example.com" service: http://127.0.0.1:5000 - service: http_status:404

逐条说一下：

• 第一、二条是常规域名到端口的映射，最简单、最常用。
• 第三、四条演示了同一个域名、不同路径的分流。app.example.com/api/*的请求全部到 8090 的短链接 API，剩下所有app.example.com请求到 3000 的监控面板。注意这里隐含了一个规则：path 匹配的规则写在前面，不带 path 的兜底规则写在后面。顺序反了的话，不带 path 的规则会先把所有请求都吃掉。
• 第五条用了泛域名。如果给*.files.example.com配置了泛解析 CNAME，那么任意子域名前缀都会转发到同一台本地文件服务。这个适合动态子域名的场景。
• 最后一条http_status:404就是 catch-all。所有没匹配到任何 hostname 的请求都会收到 404。也可以换成http_status:403，看你对未知请求的态度。

这份模板没有用到高级参数，但对大部分多服务场景已经够用。核心思路就是"先精确、后兜底"——把精确匹配的规则往前排，把通配和兜底往后放。

2.3 hostname、path、priority 的隐藏要求

有几个细节只有在实际配的时候才会发现：

hostname 不能带协议头。https://shortlink.example.com这种写法会直接报配置错误，必须是纯域名。泛域名支持，但格式是*.example.com，星号必须放在最左边。

path 只支持前缀模式和精确路径。Cloudflare Tunnel 的 ingress path 匹配规则和 Nginx location 类似但不完全一样。/api匹配/api以及/api/abc，但是不匹配/apixyz，因为它是按路径段分开处理的。需要更精确控制时，建议直接在本地服务的路由层去做，不要在 cloudflared 这层堆太多魔法。

service 字段支持http://、https://和unix://。如果某个服务监听在本机网络命名空间里的另一个网卡地址，比如http://192.168.50.2:8080，也没问题。但一般不建议跨内网访问别的机器再走 Tunnel，那样一圈回来延迟很难看。

配置校验做好之后可以先用 cloudflared 自带的命令检查：

cloudflared tunnel ingress validate

这个命令只做语法和结构检查，不会校验 DNS 记录、Tunnel 凭证是不是真的能用。所以它报 passed 只是第一步，不代表网络侧已经全部就绪。

3. 完整落地实操流程

3.1 创建 Tunnel 与获取凭证

多服务路由的前置动作和单 Tunnel 一样。如果你已经在用 Tunnel，可以直接看 3.2 之后的步骤。这里还是给新读者走一遍完整流程。

在服务器上安装好 cloudflared 之后，需要先登录这个"第一次登录"其实是到 Cloudflare 账号授权：

cloudflared tunnel login

执行后终端会输出一个授权链接，浏览器打开、选好你的域名所在区域、允许授权，就算完成了。之后创建隧道：

cloudflared tunnel create multi-service

创建完成后，cloudflared 会在本地配置目录生成一条隧道记录，并输出对应的 Tunnel ID 和凭证文件路径。凭证文件通常叫<tunnel-id>.json。它默认的位置在/root/.cloudflared/或用户目录下的.cloudflared/里，取决于你以什么用户身份运行的命令。

这个步骤容易困惑的是：创建隧道的机器可以不等于运行隧道的机器。凭证文件是可以拷贝到另一台机器使用的，前提是tunnel ID和credentials-file字段保持一致。多服务路由中如果有多台主机需要接入同一隧道，可以分别拷贝凭证，各自运行独立的 cloudflared，但要注意每台机器的连接都会占用 Tunnel 的连接配额。目前免费额度下连接数限制是足够的，不过别在几十台机器上共用一个 Tunnel ID，那就有点滥用味道了。

3.2 打通 DNS 路由

创建好 Tunnel 后，需要把域名和隧道关联起来。这一步在 Cloudflare 面板上手动操作也可以，但我更建议用命令行：一是可复制，二是出错率低。

cloudflared tunnel route dns multi-service shortlink.example.com cloudflared tunnel route dns multi-service monitor.example.com cloudflared tunnel route dns multi-service app.example.com cloudflared tunnel route dns multi-service "*.files.example.com"

执行完这些命令之后，Cloudflare 会自动在 DNS 面板里创建对应的 CNAME 记录，目标是指向<tunnel-id>.cfargotunnel.com。不需要手工填 IP，也不需要管代理是否开启，Cloudflare 会自动配置好。

这个环节的一个常见误区是：以为route dns已经把路由配好了。其实它只做了 DNS 绑定，真正决定"请求到本地哪个服务"的是 ingress 规则。所以route dns做完之后，还要保证config.yml里确实存在对应 hostname。两者没有强制的先后顺序，但如果 DNS 记录建好了而本地配置没有对应规则，请求会进到 catch-all 然后返回 404。

3.3 本地服务监听地址的选择

很多人在自建服务时默认监听在0.0.0.0:3000或0.0.0.0:8090，这在上线调试阶段很常见，但放在多服务路由里会带来两个实际问题。

如果是监听0.0.0.0，意味着同一局域网内的其他设备可以直接访问这个端口。假如某个设备被攻破，攻击者在内网横向移动时，这些端口就成了更宽的入口。Cloudflare Tunnel 的一大优势就是本地服务不需要暴露任何端口。配合127.0.0.1监听，可以让服务只接受 cloudflared 本机转发过来的请求，局域网内其他设备根本发现不了这个端口。

还有一个更现实的问题：如果你在同一台机器上启动了多个服务，且它们都监听 0.0.0.0 的同一端口，会直接冲突启动失败。用 127.0.0.1 反而能让你更清楚地意识到每个服务占用的端口，因为配置里都要显式写出来。

所以我的建议是：在配置文件里直接把service写成http://127.0.0.1:8090这类形式，同时业务服务本身监听也要改到 127.0.0.1。这一步在一些自带 Web 服务的软件上要仔细找配置项，比如某些文件服务默认监听 0.0.0.0，需要在启动参数里加上--listen 127.0.0.1:5000之类的选项。

3.4 启动、验证与常用维护命令

配置完成之后，在 Linux 下推荐用系统服务来托管 cloudflared：

cloudflared service install

这条命令会把 cloudflared 注册为 systemd 服务，并把当前用户下已经保存好的 Tunnel 配置一起带进去。之后用标准方式管理：

sudo systemctl enable cloudflared sudo systemctl start cloudflared sudo systemctl status cloudflared

启动后立刻看状态，确认没有语法错误和连接故障：

sudo journalctl -u cloudflared -f

如果日志显示Registered tunnel connection说明连接建立成功。接下来验证路由是否生效，可以不用浏览器，直接用 curl 命令带 Host 头来测：

curl -H "Host: shortlink.example.com" http://127.0.0.1:8090

但要注意：这个命令只会验证本地服务是否正常，并没有真正走到 cloudflared 的 ingress 路由。更接近真实请求的验证是：

curl -I https://shortlink.example.com

从公网发起请求，观察返回头里是否出现cf-ray字段，如果出现了就说明流量确实经过了 Cloudflare 边缘。接下来你可以依次访问四个域名，逐个确认每一个域名都分别转到了对应的本地端口。这里有个小技巧：先在本地让不同服务返回一个带识别特征的内容，比如 service 名或字体颜色，再从外网访问，就能一眼看出路由有没有转错。

4. 实测中遇到的坑与排查手册

4.1 路由全部打到 404：DNS 与 ingress 的错位

我在最初切换到多服务模板时遇到的最诡异的问题：四个域名全部能访问，但全部返回 Cloudflare 的 404 页面。一开始以为是 cloudflared 配置有问题，反复validate都通过，日志也没有报错。

后来才反应过来：cloudflared tunnel route dns已经创建好了 DNS 记录，但config.yml里我用的 hostname 和 DNS 记录不完全一致。比如 DNS 里配的是shortlink.example.com，ingress 里却写了一个多余的www.shortlink.example.com。肉眼看着挺像，可 cloudflared 对比时是严格字符串匹配的。请求进来后，DNS 解析到 Tunnel 没问题，但 Tunnel 自己拿着 Host 头和 ingress 逐条比对，始终对不上，就落到了最后的 catch-all，返回 404。

排查方式很简单：在 Cloudflare 面板看访问日志不太直观，最快的办法是直接在服务器上看 cloudflared 日志。如果看到请求进来但显示no ingress rule matched之类的信息，说明问题几乎一定出在 hostname 不一致。把所有 hostname 列出来对比一遍 DNS 记录，逐一修正就行。

4.2 服务 502：cloudflared 连不上本地端口

另一个高频问题就是 502。日志提示无法连接到 upstream。这个往往是服务监听地址的问题。典型场景是：业务服务监听的是127.0.0.1:8090，但它在容器里运行，而 docker 默认会做一个网络隔离。如果你在容器内给服务绑定了容器的 eth0 内部 IP，宿主机通过127.0.0.1:8090根本访问不到。

解决办法几个：

• 不推荐省事直接改 service 地址成http://172.17.0.2:8090，那个 IP 是 docker 网桥动态分配的，每次容器重建都可能变。
• 更稳的做法是用host.docker.internal或者在启动容器时指定--network host。
• 另外也可以用unix://方式挂 socket 文件，这样既不依赖 IP，也不会在局域网暴露端口。

还有一个小问题会被忽略：服务监听起来了，但服务本身启动特别慢，或者测试时服务还在初始化，cloudflared 的健康检查会认为 upstream 不存在，返回 502。这种情况下等几秒再访问往往自己就恢复了，不算真故障。

4.3 多服务下配置热更新失败

cloudflared 服务运行中，如果改了config.yml，systemd 托管下不会像本地手动运行那样自动重载。很多人改完配置发现访问没有任何变化，就以为是模板错了。

实际上只要重载一下服务：

sudo systemctl restart cloudflared

还有更小的内存易错点：如果一条 Tunnel 同时在多台机器上运行，比如负载均衡场景，你改了其中一台的配置，其他机器不会自动同步。多服务路由的配置分布在所有节点上，这个在排错和以后更新配置时一定要记住。

4.4 高频问题排查速查表

5. 路由之外：安全加固与负载均衡

5.1 用 Access 策略给多服务加锁

多服务路由上线后下一个自然需求是：有些服务并不想对所有人公开访问。比如监控面板、内部文件服务，这些业务如果直接挂到公网域名下，等于向全网开放了入口。Cloudflare Tunnel 和 Cloudflare Zero Trust 可以结合起来，靠 Access 策略在边缘侧做一层认证，不用改任何本地业务代码。

具体做法是在 Cloudflare Zero Trust 后台创建一个 Access Application，填入刚才绑定的域名，然后选一种鉴权方式。常见的有：

• 邮箱 OTP 验证
• 允许某个邮箱域下的用户免密访问
• 对接 IDP 单点登录

当一个请求到达 Cloudflare 边缘，如果它命中了 Access Application，Cloudflare 会先要求用户认证，认证通过后才会把请求通过 Tunnel 转发到本地服务。也就是说，即使你本地的监控面板没有任何登录功能，外面的人不通过 Access 认证是看不到内容的。

这个对我的价值是：短链接 API 有一个管理后台，我不想让它完全暴露，但暂时不想给它写登录逻辑，那么用 Access 策略就能把后台和公开 API 分开处理。

5.2 把已有的 Nginx 上游平滑迁移到 Tunnel 路由

很多读者的现状是：本地已经用 Nginx 做了多服务反代，现在想改成 Tunnel 多服务路由。一种思路是保留 Nginx，把service指到 Nginx 的某个 server_name 端口上。但这种方案等于隧道转发给 Nginx、Nginx 再转发给后端，链路没有变短，反而多了一层理解成本。

更强的方案是直接在 cloudflared 的 ingress 里把各个域名对应的本地服务端口写清楚，让 cloudflared 成为唯一的入口转发层。迁移时只需在 Nginx 配置里找到每个域名实际对应的 upstream 端口和路径规则，然后把它们翻译成 ingress 规则。Nginx 里的location /api/ { proxy_pass http://127.0.0.1:8080; }对应到 ingress 就是hostname: app.example.com, path: /api/*, service: http://127.0.0.1:8080。

翻译完成后，可以先把 Nginx 的监听地址改到另一个端口做保留，用新的 ingress 规则验证一段时间。没问题之后再把 Nginx 停掉。这中间唯一需要细心的是路径匹配规则：Nginx location 的匹配逻辑和 Cloudflare Tunnel 的 path 逻辑不完全一致，尤其是有正则改写、proxy_pass 带 URI 的那类配置，需要逐条测试。

迁移过一次之后，我个人的体会是：如果服务全都是 HTTP、且不存在复杂的 rewrite 需求，Tunnel 原生 ingress 完全够用，还能少维护一套反代配置。真的遇到重定向、缓存、内容改写这类复杂逻辑，那就别硬塞到 ingress 里，该用 Nginx 的地方还是继续用，Tunnel 只负责最外层和公网接入。

5.3 进阶玩法：同一服务多实例负载均衡

说完入口侧，再说一个路由之外的进阶：同一个服务在本地开了多个实例，比如 API 服务起了两个进程，分别监听 8090 和 8091。Tunnel ingress 支持一个 service 地址配多个实例吗？原生ingress不直接支持轮询、权重均衡，只能把 service 写一个地址。

想实现多实例负载均衡，通常有几个办法：

• 在本地起一个轻量负载均衡器（比如 Nginx、HAProxy）把 8090 和 8091 聚合到一个端口，ingress 里的 service 指向这个聚合端口。链路多了但更可控，适合本地实例很多的情况。
• 如果只是临时做双机容灾，可以在 Cloudflare 侧用 Load Balancing 功能，对同一个 Tunnel 做多个 origin 的流量分配。但这里有个限制：Cloudflare Load Balancing 的 origin 一般指多云服务器上的 Tunnel，配置关系和单机多端口不太一样，需要单独理解。
• 最朴素的方案是：让三个域名指向同一个本地服务端口，由不同 subdomain 区分用途。严格说这不是负载均衡，而是路由复用，但很多时候需求就是这个，别过度设计。

我实际不建议在 cloudflared 层做负载均衡。维护成本高又不好测试。如果确实需要负载均衡，优先在本地用一个成熟的单端口入口做聚合，Tunnel 只负责把公网流量交到这个端口。

6. 部署这套模板时其他值得注意的经验

多说几个容易踩但又不至于出大故障的细节，都属于配置之外的"软经验"。

第一，配置文件里不要注释掉 catch-all 那行。有些人觉得反正自己所有域名都写进 ingress 了，最后一条 404 多余。但Cloudflare官方规范里 ingress 数组的最后一个元素必须是一个没有 hostname 的 catch-all 规则。一旦遗漏，cloudflared tunnel ingress validate会直接报错，服务根本启动不起来。这个规则不会商量。

第二，DNS 记录的代理状态（橙色云朵）一定保持开启。Tunnel 只能工作在 Cloudflare 代理的流量上。要是把某个域名改成仅 DNS（灰色云朵），外部请求会直接解析到源站 IP——如果源站端口没有开对应的服务，访问必然失败；更糟的是，一旦这个域名被攻击者盯上，源站 IP 就暴露了。Cloudflare Tunnel 最有价值的地方恰恰在于隐藏源站 IP，千万别亲手把这个优势丢在 DNS 设置上。

第三，多服务路由模板配好之后要做好文档记录。这个不是技术强制，而是运维建议。ingress 规则其实就是一个微型的服务注册表：域名、路径、端口、用途，这些信息不写下来，三个月后自己看配置也发懵。我现在的习惯是在 config.yml 旁边放一个 README，记录每个域名目前承载什么服务、哪个本地端口、大约为什么这样分流。维护成本几乎为零，但关键时刻能省很多回忆时间。

第四，如果你用了容器化部署，注意 cloudflared 容器和你业务服务的网络模式。容器之间如果用 compose 网络，service地址可以直接写成http://业务服务名:端口，因为 Docker 内部 DNS 会做解析。但这个写法和本机127.0.0.1不一样，环境迁移到纯本机部署时容易忘记改。所以要么全容器，要么全本机，混用的时候一定要写清楚连接方式。

第五，升级 cloudflared 版本前最好先在非生产环境试一下。某些旧版本在 ingress 规则的解析上有细微差异，尤其泛域名 path 组合的场景。我在一次升级后遇到过原配置在旧版本正常、新版本下规则匹配顺序发生变化的情况。后来养成了习惯：升级前先validate一把，并且重启之后访问一轮所有服务再收工。

这篇内容到这里，主要把多服务路由的配置模板、落地步骤、常见排错都过了一遍。如果你现在正被几个服务的暴露问题缠住，不妨直接把 2.2 的模板拿来改改跑一遍。我自己从多隧道切到单隧道多服务路由之后，最大感受不是省了多少内存，而是排查问题的时候整个世界都安静了——所有出入口的路由表就摆在那一个文件里，域名和服务的对应关系清清楚楚。