给自托管服务绑固定域名：Cloudflare 命名隧道实践与注意事项

背景

自托管服务一多，最先暴露的问题往往不是部署，而是访问地址不稳定。早期我用的是临时隧道：启动时随机生成一个地址，服务能从公网打开，看起来很方便。但隧道进程一重启，地址就换了，之前收藏的链接、手机上的快捷方式、笔记里的入口全部失效，还得重新同步一遍。对只演示一次的场景，临时地址够用；对长期用的面板、网盘、站点，它就是持续的维护负担。于是我换了思路：给隧道起一个固定名字，让域名解析始终指向同一条隧道，服务怎么变、机器怎么重启，入口都不用再改。

方案：命名隧道 + 子域名分流

整体分三层：域名层用自有域名托管在 Cloudflare，以不同子域名区分服务，如 panel.example.com 对应监控面板、files.example.com 对应网盘入口；隧道层在服务器上运行轻量客户端，主动向边缘建立出站长连接，服务器不开放入方向端口；服务层让各服务只监听回环地址 127.0.0.1:端口，不直接对外暴露。

好处是：公网侧只看到边缘入口，看不到服务器真实地址与端口；新增服务只需加一条规则与一条 DNS 记录。

步骤

第一步，创建命名隧道。在 Cloudflare 的 Zero Trust 控制台新建一条隧道并起好名字，系统会给出隧道唯一标识与一份凭证文件。凭证只保存在服务器上，不要放进代码仓库，也不要截图公开。

第二步，在服务器上安装隧道客户端并完成授权。把配置写成一份文件：先声明隧道标识与凭证路径，再逐条写入口规则，每条写明主机名与对应的本地服务地址，例如 panel.example.com 转发到 http://127.0.0.1:端口。规则写完后加一条兜底：未匹配的主机名直接返回 404，避免未知请求误发给某个服务。

第三步，做 DNS 路由。给每个子域名添加一条 CNAME 记录，指向 <隧道标识>.cfargotunnel.com。这一步做完，子域名就与这条命名隧道绑定了，之后无论隧道进程重启多少次，域名都不用再动。

第四步，用系统服务托管隧道进程，设置开机自启与重启策略，并确认日志正常输出。部署完成后逐个打开子域名验证：能打开、证书正常、对应预期服务，才算完成；只看进程“在运行”不够，端到端打开一次才是验收。

踩坑

一是把临时隧道当长期方案用。临时地址换一次，就要同步改一遍所有入口，成本越攒越高。如果一个服务打算用超过一周，一开始就应该用命名隧道，而不是等地址换了几次才迁移。

二是入口规则的顺序与兜底。规则按顺序匹配，写得太宽泛的规则放前面会抢走后面具体服务的流量；没有兜底时，未知主机名的请求可能落到意外的服务上。我的做法是：具体规则在前、通用规则在后、最后一定加兜底。

三是服务监听地址写错。有些服务默认监听全部地址，图省事直接放行，就等于绕过了隧道这一层。正确做法是服务只绑回环地址，公网访问的唯一入口就是隧道。

四是出问题先怀疑域名。隧道打不开时，我的排查顺序是：先看隧道进程与系统服务状态，再看本地服务端口是否真的在监听，最后才看 DNS 与域名配置，多数问题出在前两步。还有一次遇到边缘返回拦截页，差点当成地址过期，后来复查一次就恢复了——偶发拦截要先复查再下结论，别急着换地址把没坏的东西改坏。

五是小内存机器的资源规划。隧道客户端很轻量，但同机还跑着好几个容器时，内存仍要算总账：给每个容器设内存上限、给系统留余量，比出问题后再排查省事得多。

总结

命名隧道解决的不是“能不能从公网访问”，而是“地址能不能长期稳定、且只暴露该暴露的部分”：一个域名、多个子域名分流服务；服务器不开放入方向端口；新增服务只加规则与解析。代价也要认清：流量经边缘中转，不适合对延迟极其敏感的场景；隧道进程是关键路径，要用系统服务托管并定期看日志。

先挑一个最常用的服务按这套流程走一遍：固定隧道、子域名分流、服务只绑回环、端到端验收。跑通一个，后面再加服务就是复制规则的事。