第 5 篇：Cloudflare Tunnel 多服务路由模板
-
- [1）总体原则：先规划子域，再写 ingress；先收口，再扩展](#1）总体原则：先规划子域，再写 ingress；先收口，再扩展)
- [2）`ingress` 设计：匹配越具体越靠前，最后必须 404 兜底](#2）
ingress设计：匹配越具体越靠前，最后必须 404 兜底) - [3）一份可直接复制的"多服务 config.yml 母模板"（建议你直接当专栏交付物）](#3）一份可直接复制的“多服务 config.yml 母模板”（建议你直接当专栏交付物）)
- [4）最佳实践：把"路由"与"策略"分开（路由在 config，访问控制在 Cloudflare）](#4）最佳实践：把“路由”与“策略”分开（路由在 config，访问控制在 Cloudflare）)
- 5）常见坑位清单（我建议你在专栏里"强制提醒"）
- [6）本章行动项（你按这个执行，下一篇就能写 Access 策略与零信任）](#6）本章行动项（你按这个执行，下一篇就能写 Access 策略与零信任）)
- 评论区互动（我会用你们的反馈补全"母模板第二版"）
- 下一章
上一章我们讲清楚了"为什么选 Cloudflare Tunnel"。这一章进入实操：如何用一份 config.yml 做多服务路由，并把"默认 404 兜底""子域划分""最小暴露面"这三件事一次性做对。
你会发现：config.yml 写得好不好，决定了你后面做 Make Agent 工具化、灰度发布、回滚、审计------到底是"工程化"还是"手工艺"。
参考官方配置文件说明（你后续可以对照参数补全）：[4]
1）总体原则：先规划子域，再写 ingress；先收口，再扩展
我强烈建议你的多服务入口按"职责"拆成 4 类子域（与你专栏体系完全对齐）：
- ComfyUI ：
cui.example.com（内容工厂） - RAG API ：
rag.example.com（运营系统 API） - Dashboard ：
ops.example.com（监控/面板/管理） - Webhook Receiver ：
hook.example.com（Make/外部回调入口）
这样做的好处是：策略可分层、风险可隔离、审计可追踪。
用户/团队/Agent
Cloudflare Edge
cloudflared-Mac
ComfyUI :8188
RAG API :8000
Dashboard :3000/8501
Webhook :9000
2）ingress 设计：匹配越具体越靠前，最后必须 404 兜底
Cloudflare Tunnel 的 ingress 是自上而下匹配的。工程上最常见的事故是：
- 你漏写默认兜底
- 或把"宽泛规则"放在上面，把敏感服务误路由出去了
所以我给你一个硬规则：
所有 ingress 最后一条必须是 http_status:404，否则你迟早"意外暴露"。
命中 hostname
都没命中
请求到达 Tunnel
按 ingress 顺序匹配
转发到本地 service
http_status:404 兜底
响应返回
3）一份可直接复制的"多服务 config.yml 母模板"（建议你直接当专栏交付物）
说明：端口按你本地规划举例；你可以把 Dashboard 替换成 Grafana/Streamlit/自研面板的端口。
yaml
# ~/.cloudflared/config.yml
# Cloudflare Tunnel 多服务路由模板（生产骨架）
tunnel: <TUNNEL-UUID>
credentials-file: /Users/<YOU>/.cloudflared/<TUNNEL-UUID>.json
# 建议显式声明日志与运行参数（便于排障）
loglevel: info
transport-loglevel: warn
# （可选）metrics 端口：本地观测 cloudflared 状态（只绑定本机）
metrics: 127.0.0.1:4318
# ingress 自上而下匹配，最后必须 404 兜底
ingress:
# 1) ComfyUI（内容工厂）
- hostname: cui.example.com
service: http://127.0.0.1:8188
originRequest:
noTLSVerify: true # 本地回环可忽略证书验证（视情况开启/关闭）
# 2) RAG API（智能运营系统）
- hostname: rag.example.com
service: http://127.0.0.1:8000
originRequest:
httpHostHeader: rag.example.com
# 3) Dashboard（监控/管理面板）
- hostname: ops.example.com
service: http://127.0.0.1:3000
originRequest:
httpHostHeader: ops.example.com
# 4) Webhook Receiver（Make / 外部回调）
- hostname: hook.example.com
service: http://127.0.0.1:9000
originRequest:
httpHostHeader: hook.example.com
# 兜底：任何未显式声明的 hostname 一律 404
- service: http_status:404你会注意到：我刻意把 service 都指向 127.0.0.1。原因很简单：
Tunnel 只需要在本机打通服务，不要让这些服务在局域网"随便可见"。
（你后面要做最小暴露面，这条原则很关键。）
4）最佳实践：把"路由"与"策略"分开（路由在 config，访问控制在 Cloudflare）
config.yml 负责"把请求送到哪里"；访问控制（Access/WAF/Rate Limit）负责"谁能访问、怎么访问"。工程上建议这样做：
ops.example.com：强认证（MFA、邮箱域、设备姿态）hook.example.com：Webhook 验签 + 限速（防刷）rag.example.com：机器身份（服务 Token）cui.example.com：通常不对公众开放（至少只给内部/团队）
用一张图把"谁访问谁"讲透，你的读者就不会乱配：
机器调用
团队/自己
公网访问者
可选：只读演示
强认证
服务身份
验签回调
访客/客户
你的设备/成员
Make / Agent
cui.example.com
ops.example.com
rag.example.com
hook.example.com
5）常见坑位清单（我建议你在专栏里"强制提醒"）
- 忘记 404 兜底：任何未知 hostname 都可能落到最后一个 service（风险极高）
- 把服务绑到 0.0.0.0：导致局域网随便访问，边界失守
- 把 ops 与 demo 混在一起：演示时把管理面板一并公开
- Webhook 不验签：被人随便 POST，直接让你队列跑满
- Ingress 顺序写反：宽泛规则在上，精确规则被"吞掉"
6）本章行动项（你按这个执行，下一篇就能写 Access 策略与零信任）
- 先确定 4 个子域：
cui / rag / ops / hook - 把本地服务全部绑定到
127.0.0.1（减少内网暴露面） - 复制并落地
config.yml，最后一条必须http_status:404 - 为
ops规划强认证策略（下一篇讲 Access） - 为
hook预留验签与防重放（下一篇或专门一节讲）
评论区互动（我会用你们的反馈补全"母模板第二版"）
- 你准备把 Dashboard 用 Grafana 还是 Streamlit？端口是多少？
- 你希望
cui对外开放到什么程度：仅自己、团队、还是客户演示？ - 你的 Make 场景里 Webhook 触发更像"回调通知"，还是"直接触发生产任务"？（这决定验签与限速策略的强度）
你把这三项信息回我，我可以把本章模板升级成"可直接贴进专栏交付物"的版本：包含 dev/stage/prod 三环境 、以及 灰度切流（RAG v1/v2 双端口） 的 ingress 结构。
下一章
《第 6 篇：访问控制与零信任策略》