更新日期：2026-10-18
家里的服务没有公网入站条件，或者不想为每个应用开放源站端口时，可以评估 Cloudflare Tunnel。它通过运行在源站侧的 cloudflared 建立连接，将指定主机名的请求送到本地服务。
本文使用远程管理的命名隧道与 HTTP 应用场景：域名已经接入对应 Cloudflare 账号，应用和 cloudflared 部署在同一台 Linux 主机。容器部署、私有网络路由和非 HTTP 客户端接入的配置不同，需要另行核对。Tunnel 也不自动为应用添加用户登录验证，管理后台应另配 Access 或应用自身的访问控制。
先确认本地应用正常
假设应用实际监听在 127.0.0.1:8080，先在源站执行：
ss -lntp
curl -v --max-time 10 http://127.0.0.1:8080/
这一步应获得预期页面或应用响应。如果本地已经连接拒绝、超时或返回应用错误，先修复应用，再建立隧道。否则，公开域名只会把同一个问题多包一层。
回环地址只适用于进程处在同一网络命名空间。如果 cloudflared 在容器里，127.0.0.1 指向该容器自身。此时应根据容器网络使用可达的服务名或主机地址，而不是照抄宿主机命令的成功结果。
创建远程管理的隧道
进入 Cloudflare One 控制台的 Tunnel 管理页面，创建 cloudflared 隧道，选择实际系统和架构，按页面生成的安装指引部署连接器。控制台导航会调整，使用官方创建指南核对当前入口。
安装凭据属于连接器敏感信息，应放入服务或部署系统的秘密管理中，不提交到仓库，也不放进截图和公开工单。本文不提供一个假的固定令牌让读者复制；实际安装命令以自己的控制台生成为准。
在常见 systemd 安装方式下，可检查：
cloudflared --version
systemctl status cloudflared --no-pager
journalctl -u cloudflared -n 80 --no-pager
服务名以实际安装方式为准。日志显示连接正常，并且控制台识别到连接器后，再配置应用路由。连接器在线只能说明隧道这一段正常，不能证明本地应用能够访问。
绑定域名时，把协议和端口写对
为计划使用的应用主机名创建发布路由，将服务指向 http://127.0.0.1:8080。这里的协议描述 cloudflared 到源站这一段，不是用户浏览器到 Cloudflare 的协议。
例如浏览器使用 HTTPS，并不要求本机回环服务一定同时提供 HTTPS。若源站本身启用了 TLS，就按其真实协议、证书和名称配置，不要用 HTTP 连接 TLS 端口，也不要用 HTTPS 连接明文端口。
| 配置项 | 应核对的内容 |
|---|---|
| 主机名 | 是否为预期域名，是否存在冲突的 DNS 记录 |
| 服务地址 | cloudflared 所在网络能否访问 |
| 协议 | HTTP 或 HTTPS 是否与源站一致 |
| 端口 | 是否为应用真实监听端口 |
| 应用外部 URL | 回调、重定向和 Cookie 是否使用公开地址 |
若应用按 Host 区分站点，还要验证实际收到的主机名。登录后跳回内网地址，通常应检查应用的外部 URL 与可信代理配置，而不是反复创建隧道。
管理后台先配置访问控制
准备公开管理界面之前，先为计划使用的主机名创建 Access 自托管应用，设置明确的允许对象，再发布或切换路由。避免在配置完成前留下临时公开窗口。Access 官方指南
用两个独立会话验收：一个获准账号可以登录，另一个未获准账号被拒绝。再用无痕窗口确认没有因为旧会话而误判。需要自动化访问的客户端，应使用适合机器身份的策略，不能把所有用户放行来修复脚本访问失败。
同时检查源站是否还保留可绕过 Access 的公网入口。若应用只应经隧道访问，就按实际部署约束其入站路径。Tunnel、Access 和应用账号体系各自解决不同层面的问题，不能仅凭其中一个已经启用就宣布全部访问安全。
502 与 1033，先查不同链路
Cloudflare 文档将两类常见情况分开：1033 指向无法找到健康隧道连接等连接问题；带有“无法到达源站服务”说明的 Tunnel 502，通常意味着连接器已接入网络，但无法正常访问配置的本地服务。官方常见错误
| 现象 | 优先检查 |
|---|---|
| 1033 | 连接器是否运行、出口连接、控制台健康状态 |
| Tunnel 源站 502 | 本地进程、监听地址、端口、协议与证书 |
| 访问被拒绝 | Access 规则、身份、会话与应用自身权限 |
| 登录循环 | 外部 URL、Cookie、重定向与可信代理 |
| 页面能开，长请求中断 | 应用超时、流式处理及各层连接限制 |
排障时保留一次请求的时间、主机名、状态码与相关日志，再逐段测试。泛泛的“Cloudflare 502”不能直接说明是哪层出错，应用自己也可能返回相同状态码。
运行维护与回退
建立隧道之后，还要考虑主机重启、连接器更新、凭据泄露和本地应用停机。若使用多个连接器实例，应验证每个实例都能正确访问对应服务；多个实例不自动解决数据库或单台应用主机故障。
凭据疑似泄露时，按当前官方流程轮换并处理旧连接器，不要只修改一份配置就假定所有旧连接已经失效。记录连接器归属和部署位置，才能完整撤销。
回退应提前设计：若从旧入口迁入，保留旧配置和访问控制；若这是唯一公开入口，关闭路由意味着服务停止对外访问。不要把“回退到源站裸露公网”作为临时默认做法。
验收至少包含重启后恢复、允许与拒绝两类身份、应用核心动作、日志查询和一次源站停机告警。完成这些，才算把自托管入口纳入日常维护。