只要在本地写过 Web 应用、给同事演示过内网工具或者试过用家里的旧电脑搭一个小站点大概率都会碰上同一个现实问题人没有公网 IP运营商给的是大内网地址路由器端口映射改得又不痛快。这时候 Cloudflare Tunnel 的常用命令就成了很多人的救命稻草——一条cloudflared tunnel --url就能把本地的 8080 端口变成公网能访问的 HTTPS 地址听起来确实很爽。但在网上搜“Cloudflare Tunnel 常用命令”画风很容易变成“抄命令”。命令是有限的坑是无底的。我见过有人在群里问cloudflared tunnel run一会儿 502 一会儿连接重置实际验证之后发现他的本意是想把两台机器上的不同服务暴露出去却因为没弄清命名隧道、ingress 和快速隧道的分工硬是把自己绕进了配置地狱。这个问题的种子就是经典的 XY 问题“你问的是你自己拟的方案丢的却是真正要解决的目标场景。”Cloudflare Tunnel 日常到底要掌握哪些命令什么场景下用临时隧道什么场景用命名隧道配置文件里的 ingress 规则是怎么按序匹配的我把自己的落地经验整理了一遍中间穿插了一些 XY 问题的避坑反思。希望你看完能像一个老手那样掐着需求直接选对命令。1. 在背命令之前先解开XY问题那层结1.1 所有常用命令都指向同一个目标把本地服务安全地递出去Cloudflare Tunnel 用到的命令其实绕不开四件事登录认证login、建立隧道create、建立 DNS 路由route最后再运行run把流量接进本地。这些操作的核心只有一句话——在你的电脑没有公网 IP 的局域网设备也可以上主动连出一根出站长连接接到 Cloudflare 的全球边缘网络用户访问你的域名时请求先落到 Cloudflare 边缘再由边缘通过这条透明通道把请求交给那台仍在运行的 cloudflared 进程最后由它转发到本机目标端口。全程不需要对外开放入站端口不用改路由器端口映射也不需要在云厂商买一台“中转机”。用五步来理解这个链路本地跑一个 Web 服务监听 8080 端口。运行 cloudflared 进程与 Cloudflare 边缘建立安全的反向连接。在 Cloudflare 为域名配置一条 DNS 记录或者用快速隧道自动生成的子域。边缘将对应域名的 HTTPS 请求安全地转交给 cloudflared 进程。cloudflared 将请求转发回本地 8080 端口再把响应原路返回。把这个模型记在脑子里以后你再去看“常用命令”就不是背 API 了而是在完成这五步里的每一块。命令的输出信息也很关键创建成功会输出隧道 ID路由时会显示 DNS 记录是否创建成功这些就是后续稳定运行的锚点。1.2 当你问这个命令怎么不行的时候先说清楚你的真实需求XY 问题在 cloudflared 社区里尤其常见因为隧道本身是个底层工具很多人会习惯性把“我认为应该怎么搭”当成问题抛出来。有人问“怎样让 cloudflared 同时支持 443 和 8090 两个端口”他真正需要的其实是想让两个不同子域的服务共用同一个本机入口该做的是 ingress 配置而不是研究端口复用。有人问“为什么我用--url开出来的隧道重启电脑就找不回来了”这本来就是临时演示的机制他真正的需求是需要一个长期稳定的入口该用命名隧道而不是快速隧道。有人问“为什么我的隧道跑一会儿就断”最后发现本地开发服务器的进程因为热重载把端口换了隧道本身没有问题。所以遇到 Cloudflare Tunnel 问题第一步先问自己“我想达成的最小可接受结果是什么”如果答案是“把某个本地服务暴露到公网并绑定我自己的域名”那就可以直奔命名隧道 ingress 的稳妥组合如果答案是“别人只看一次我本地跑的效果”快速隧道已经够用。对着 X 选方案而不是对着 Y 修参数后面所有命令都会顺很多。我把常见的伪问题整理成一张对照表方便你自查表面问题Y真实需求X对症方案为什么端口 8080 老是冲突我想让两个子域都访问本机写一份 ingress按 hostname 分流快速隧道重启后地址就变了我需要一个固定地址长期可用改名称为命名隧道走 route dnsrun 的时候日志刷 502本地对应端口根本没有可用服务先用 curl 验证本地服务再查隧道想在同一台机器跑多个隧道其实只要一个隧道 多级映射用 ingress 配置多域名转发2. 快速隧道一条命令就能跑起来但要认清它的一次性本质2.1 先跑通的第一个命令cloudflared tunnel --url快速隧道是最简单的入口适合第一次接触 cloudflared 的人。先安装二进制文件Linux 上我通常直接下载 release 包curl -L https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -o cloudflared chmod x cloudflared sudo mv cloudflared /usr/local/bin/macOS 用户可以直接brew install cloudflaredWindows 则下载对应的.exe放到 PATH 目录里。装好后假设你的本地服务跑在 8080 端口cloudflared tunnel --url http://localhost:8080输出里会给你一行类似https://xxxxx.trycloudflare.com的地址浏览器打开就能看到你的页面。这个过程中不需要登录 Cloudflare不需要域名不需要改 DNS速度也很快非常适合第一次验证“我的本地服务能不能被外网访问”这件事。这里有个小坑我建议 URL 写成http://127.0.0.1:8080而不是localhost。某些环境下localhost会被解析成 IPv6 的::1而你的服务只监听了 IPv4就会出现一种诡异的“本地能开、隧道那边 502”。用 127.0.0.1 可以把这种变量直接抹掉。2.2 为什么说是一次性限制和适用场景快速隧道的主要限制有四个域名是随机生成的不可自定义也没法在 Cloudflare 面板里提前绑定。每次运行产生的子域都不同你只能在当前进程的生命周期里使用它。进程一停链接就失效下次启动又是一个新地址。它本质上是 Cloudflare 给你一个无需账号就能体验的沙箱适合短时联调不适合对外长期交付。合适的用法是给客户演示某个页面、在手机上打开本机调试的 H5、跟 Webhook 对接方做十分钟联调。这类“看一次就走”的场景快速隧道是效率最高的选择。但如果你的目标是让同事每天都能访问或者绑定自己的域名那就要往前再走一步用命名隧道。2.3 快速隧道不适合裸奔生产也别把它当反向代理有人觉得快速隧道都是 HTTPS安全性应该还行。但实际上它没有任何访问控制只要 URL 泄露谁都能访问你的本地服务。真要拿给团队内部用建议要么在应用层加登录鉴权要么直接转命名隧道配合 Cloudflare Access 做一层身份校验。把公网可见面控制在你期望的范围内这是一个基本素养。3. 命名持久隧道login → create → route → run 的完整命令链路命名隧道是生产环境的常态。它会给隧道分配一个固定的 ID凭据写进一个 JSON 文件再通过 Cloudflare 的 API 把域名 DNS 记录绑定好。之后进程重启多少次域名都不会变。整套流程可以拆成四步。3.1 第一步login 认证cloudflared tunnel login第一次运行会打开浏览器让你在 Cloudflare 登录授权页选一个账号并有域名管理权的 zone 进行授权。授权完成后会在本机生成~/.cloudflared/cert.pem这张证书负责后续的“创建隧道、绑定 DNS、删除隧道”等管理操作。这里有几个容易忽略的点cert.pem只用于管理操作不用于运行时验证。运行时靠的是下一步生成的 JSON 凭据文件。它不是账号密码但丢了之后很多管理命令会失效比如无法再修改隧道配置。CI 环境里没法弹窗交互建议在本地跑一次把证书文件一起带到 CI 使用。3.2 第二步create 创建隧道cloudflared tunnel create demo-tunnel成功后会显示Created tunnel demo-tunnel with id f0a4e5df-xxxx-xxxx-xxxx-xxxxxxxxxxxx Credentials file created at /root/.cloudflared/f0a4e5df-xxxx.json这个 JSON 文件就是运行时最重要的资产里面包含隧道 ID 和凭据。一旦丢失即使你在 Cloudflare 面板上能看到隧道列表也无法再完成后续操作。我的习惯是create 成功之后立刻把 JSON 备份到安全位置比如私有 Git 仓库、NAS 或密码管理器。删除隧道时再同步删除备份文件避免留下一堆失效凭据。3.3 第三步route DNS 把域名关联到隧道命名隧道不会自动帮你创建域名记录。你需要显式执行cloudflared tunnel route dns demo-tunnel app.example.com它会在你的 zone 里自动创建一条 CNAME 记录指向tunnel-id.cfargotunnel.com。如果你的域名本来就托管在 Cloudflare这条命令执行完DNS 层就通了。如果域名在其他服务商就需要手动去那边添加 CNAME并确保在 Cloudflare 侧开启代理状态。这里常有人产生误解以为 route dns 之后域名立刻就能访问本地服务。其实不对。route dns 只解决“域名 → 隧道”的 DNS 映射真正要把请求转发到本机哪个端口需要第 4 节的 ingress 配置来完成。3.4 第四步run 启动隧道先准备好配置文件然后启动cloudflared tunnel run demo-tunnel启动成功会看到Registered tunnel connection类似的日志这时浏览器访问app.example.com正常情况下已经能到达本地服务。如果出现 502先回本机 curl 一下端口排除服务本身的问题。一个很容易混淆的点有人以为 run 命令会占用一个本机端口于是去查端口有没有被占用。其实 run 是出站连接它不需要监听本机端口除非你在配置里特意暴露另一个入口。所以“端口被占”很多时候不是隧道的错而是把快速隧道的--url参数和命名隧道的配置机制搞混了。3.5 巡航查账list / info / delete / cleanup运维期最常用的命令我列在这里命令用途cloudflared tunnel list查看当前账户下的隧道列表、是否在运行cloudflared tunnel info demo-tunnel查看单个隧道 ID、连接信息cloudflared tunnel cleanup demo-tunnel清理因异常退出残留的陈旧连接记录cloudflared tunnel delete demo-tunnel删除隧道记录仍在运行时需要加-fcloudflared tunnel --help任何命令记不牢时的通用救法一个绕不开的坑delete之后之前的 DNS CNAME 不会自动删干净。你需要再去面板或手动删掉那条指向uuid.cfargotunnel.com的 CNAME否则域名会出现悬空解析。这条最好写进你的运维 checklist老手也容易忘。4. 多域名多服务下的 ingress 配置文件到底该怎么写命名隧道最有价值的部分就是把多个域名、多个服务整理成一个可维护的配置文件也就是 ingress。这里是很多人卡住的地方也是 XY 问题的高发区。4.1 ingress 规则的本质一张按顺序匹配的“路由表”cloudflared 在转发请求之前会先读取默认路径的~/.cloudflared/config.yml也可以在你运行隧道的目录放一份或用cloudflared tunnel run --config /some/path/config.yml显式指定。然后根据请求的 Host 头依次做匹配。一个典型配置tunnel: demo-tunnel credentials-file: /root/.cloudflared/f0a4e5df-xxxx-xxxx-xxxx-xxxxxxxxxxxx.json ingress: - hostname: blog.example.com service: http://127.0.0.1:8080 - hostname: api.example.com service: http://127.0.0.1:9090 - service: http_status:404第一段声明隧道名是demo-tunnel运行时 cloudflared 会拿它和credentials-file里的 ID 配对。然后配置 blog 子域转发到 8080 端口api 子域转发到 9090 端口。最后一条是一条兜底规则没有hostname字段表示其他未匹配的请求都返回 404。没有兜底的话一些意外走到该隧道的域名就会造成行为不明确。关键点ingress 规则按从上到下的顺序匹配匹配成功即生效。如果你把兜底规则写在最上面所有流量都会落入兜底后面的规则形同虚设。很多人以为问题是端口冲突结果其实是规则排序写错。4.2 service 字段支持的几种类型根据不同协议需求service 字段常见几类值含义http://127.0.0.1:8080HTTP 协议转发到本地端口https://127.0.0.1:8443HTTPS 协议转发到本地端口unix:///var/run/app.sock转发到本地 Unix sockethttp_status:404只响应给定状态码不做版转发适合兜底在此基础上你还可以在规则里加originRequest子字段设置超时、重写 Host 头等。对大多数项目来说先把前两种和兜底规则吃透已经能覆盖 90% 的“本地服务暴露为公网子域”需求。4.3 配完别动手就 run先 validate配置文件有语法错误时直接 run 也能启动但请求会乱跳。更稳妥的做法是先校验cloudflared tunnel ingress validate如果配置正确会输出Valid ingress rules如果哪行 hostname 没匹配、凭据文件找不到、YAML 缩进错误提示会直接告诉你问题大概在哪一行。这条命令的成本极低但能把“配完直接上生产”的翻车率降下来一大截。我现在的习惯是先写一个最简单的单域名、单服务配置跑通之后再复制规则扩展更多域名。加规则永远比一开始就搭一套复杂结构要稳。大型项目几十个域名也是同样原理只是会把配置文件放进 Git 仓库用版本管理维护差异和回滚。5. 我在落地过程中踩过的坑命令背后的雷区标准命令讲完了这一段才是真正没法在文档里找到、靠一次次扑腾攒下来的经验。5.1 502 半天查不出问题root cause 通常在“服务监听地址”有一次我用快速隧道给一个本地调试服务做演示结果 502 了十几分钟。排查到最后发现本机上有一个残留进程占用了同一个端口返回 500Cloudflare 边缘拿到 500 状态码之后又给了 502。问题根本不在 cloudflared而在于“目标端口背后的服务到底是谁”。后来我养成了一个习惯先从本机用curl请求目标端口确认返回内容符合预期再让 cloudflared 转发进去。虽然只是多了一步但它能把“本地服务的问题”和“隧道链路的问题”迅速分离。看到Origin unreachable类似的日志先查本地进程与端口再查 cloudflared 日志最后才看 DNS 与网络这个顺序不会错。5.2 凭据文件丢失数据还在但钥匙没了我重装机器时忘记备份~/.cloudflared/tunnel-id.json后来cloudflared tunnel list还能看到隧道记录心想着应该还能管理。结果发现任何需要验证身份的操作都离不开那串 JSON没了它只能去面板删除隧道记录重建域名 CNAME 也跟着重建。这件事让我确立了几个很硬的原则create 之后第一时间把 JSON 放到可信的备份位置。配置化部署时把 JSON 当密钥处理别明文进代码库。换机器时把cert.pem和 JSON 一起带过去绑定关系才完整。5.3 DNS 悬空或 route 冲突前面提过删隧道不删 CNAME 的问题这里再补一条更隐蔽的使用route dns时如果域名已经存在一条其他 CNAME命令可能会直接失败或者覆盖掉你想保留的解析记录。真正常见的 XY 表现是“我想让一个子域同时给两台服务器做负载均衡”于是非要通过改隧道入口来实现。其实正确路径是交给 Cloudflare Load Balancer 或专门的负载层设备隧道本身并不承担高级流量调度。先看清需求边界才不会自己给自己挖坑。5.4 开机自启与 systemd 的日志闭环命令在终端里跑着都能用但一关终端整个隧道就没了这很正常。要长期运行我更倾向于用官方封装的服务安装方式sudo cloudflared service install它会按/etc/cloudflared/config.yml读配置并交给系统服务管理启动和崩溃重启都由系统托管。安装完之后确认一下systemctl status cloudflared journalctl -u cloudflared -f这套组合的好处是日志有迹可循不用在裸终端里开一个夜班窗口。如果你非要手写 systemd unit记得把 User、ExecStart、配置文件路径全部写完整否则很容易出现“手动能跑、服务起不来”的怪事。6. 剥开命令外壳后真正要回答的其实是我用它做什么把 Cloudflare Tunnel 的常用命令一层层拆开之后你会发现它既不神秘也不复杂。复杂的是每个人把它放到怎样的场景里、给谁访问、需要什么样的稳定性。把这个过滤布做好很多看似绕弯的命令都会自动消失。6.1 动手前回答五个问题这个服务的访问者是固定几个人还是全网公开需要绑定固定域名和 HTTPS 证书吗是需要长期 7x24 运行还是只活一次联调本地进程监听在哪个端口能否接受 cloudflared 访问如果隧道挂了你能接受几秒不可用还是需要自动重启按这五个问题的答案走你基本会自动得出以下命令组合临时公开目测cloudflared tunnel --url http://127.0.0.1:PORT永久稳定暴露先执行cloudflared tunnel login、cloudflared tunnel create NAME、cloudflared tunnel route dns NAME DOMAIN再写好 ingress 配置并cloudflared tunnel run NAME机器重启后仍自动恢复最后加一步sudo cloudflared service install6.2 我的个人经验先在自己的服务层跑通再让 cloudflared 做最后一层传递如果你想更进一步我的做法是先把应用服务本身在本地跑顺再用 nginx 这类工具把“域名 → 端口”的映射提前配好最后让 cloudflared 把公网流量递交给这台 nginx。这样一来遇到 502你能很快把问题圈定在“cloudflared 之前”还是“cloudflared 之后”而不是在几条命令之间反复试探。这其实也是 XY 问题的主旨要多问“为什么这条请求没有到达我预期的地方”而不是纠结“某条命令是不是应该背得更熟”。命令可以随时查但对工具分层和依赖关系的理解才是在真实业务里能落地的根。