Cloudflare Tunnel怎么用？Quick Tunnel、持久隧道与502排查
简答：如果你只是临时演示本地Web服务，先运行Quick Tunnel；如果要长期使用固定域名，选择Dashboard创建的持久隧道；如果需要配置文件和脚本化管理，再考虑本地管理隧道。最短流程是：准备Cloudflare账户和域名，进入Networking > Tunnels创建隧道，安装cloudflared，运行控制台生成的命令，在Routes中添加Published application，再从源站、隧道状态和公网域名三层验证。
定义：Cloudflare Tunnel是一种由内网中的cloudflared主动建立到Cloudflare网络的出站连接，让公网请求通过该连接访问内网服务，发布Web应用时通常不要求源站拥有公网IP或开放入站端口。
30秒选型：先判断你需要哪一种Tunnel
如果你正在把本地网站、API、NAS或开发服务临时分享给别人，先选Quick Tunnel；如果需要固定子域名和长期运行，选择Dashboard创建的持久隧道；如果需要通过配置文件、命令行或自动化脚本管理路由，再选择本地管理隧道。Cloudflare官方文档将Quick Tunnel定位为测试和开发用途，并说明持久隧道具有账户中的稳定记录；两者不要混用。Cloudflare Tunnel fundamentals
| 方案 | 适合什么场景 | 前置条件 | 主要限制 |
|---|---|---|---|
| Quick Tunnel | 临时演示、开发预览、Webhook测试 | 安装cloudflared和本地HTTP服务 | 地址随机，停止进程后失效，不适合固定生产入口 |
| Dashboard持久隧道 | 网站、API、NAS或长期服务 | Cloudflare账户、已接入Cloudflare的域名和服务器 | 仍需维护源站、连接器、访问控制和日志 |
| 本地管理隧道 | CLI配置、配置文件、自动化部署 | 域名、DNS和cloudflared本地配置 | 需要自行维护配置文件、路由和系统服务 |
Quick Tunnel的最短命令是：
cloudflared tunnel --url http://localhost:8080
命令会输出随机的trycloudflare.com地址。官方说明该地址只在cloudflared进程运行期间有效，任何拿到地址的人都可能访问本地服务，因此不要把含有管理功能、个人数据或内部接口的服务直接用于临时公开。Quick Tunnels官方说明
Dashboard持久隧道：从创建到发布公网主机名
- 准备账户和域名：需要Cloudflare账户、已经添加到Cloudflare的域名，以及一台能够访问源站服务并连接互联网的服务器或虚拟机。若只做Quick Tunnel，则不需要自有域名；固定公网主机名则需要域名接入Cloudflare。Cloudflare Tunnel入门文档
- 创建Tunnel：进入Cloudflare控制台的
Networking > Tunnels，选择Create Tunnel，填写隧道名称并创建。当前官方流程使用的是这一入口，但不同账户类型或控制台版本可能出现名称差异，找不到时应以当前官方文档中的Tunnels页面为准。Dashboard创建Tunnel - 安装连接器：创建后选择服务器操作系统和架构，复制页面提供的安装或服务命令，在源站服务器执行。不要手动猜测令牌，也不要把完整Tunnel Token提交到代码仓库、截图或公开日志中。
- 确认连接：回到隧道详情页，等待连接器上线。官方页面会显示隧道状态；如果状态为Inactive、Down或Degraded，应先检查cloudflared进程和出站网络，再继续配置域名。Tunnel状态说明
- 添加公网应用：进入隧道的
Routes标签，选择Add route，再选择Published application。填写子域名、域名和Service URL。官方当前流程就是从Routes添加Published application，而不是先手工创建一个普通入站端口。Published application官方步骤
Service URL必须是运行cloudflared的机器能够访问的实际地址。同一台机器上的服务可以写成http://localhost:8000；如果服务在同一局域网的另一台主机上，可以写成类似http://192.168.1.20:80的示例地址，但必须替换为真实内网IP和端口，不能照抄。添加后先在cloudflared所在机器测试该地址，再访问公网主机名。
路径路由不会自动删除或重写请求路径。例如访问/api/users时，源站通常仍会收到完整路径；如果应用需要去掉前缀或重写路径，应使用Cloudflare边缘URL重写规则或本地反向代理。Cloudflare路径路由说明
Windows、macOS、Linux与Docker：安装方式怎么选
| 平台 | 建议做法 | 长期运行 | 失败回退 |
|---|---|---|---|
| Windows | 安装对应版本的cloudflared，在管理员命令提示符执行控制台提供的服务命令 | 按官方命令安装为Windows服务 | 先运行cloudflared.exe --version，确认文件、架构和PATH |
| macOS | 可使用官方安装方式或Homebrew安装 | 配置为系统启动服务或按官方服务方式运行 | 检查终端PATH、权限以及Apple芯片或Intel架构是否匹配 |
| Linux | 使用官方安装包或软件源，并在源站主机运行服务 | 安装为systemd等系统服务 | 查看服务状态和日志，确认源站地址可达 |
| Docker | 使用官方cloudflared镜像和Tunnel Token | 固定镜像版本，设置容器重启策略 | 先以前台方式运行并查看日志，确认连接后再后台运行 |
官方入门页给出了Windows、Linux、macOS和Docker的安装或运行示例。Docker快速示例使用cloudflare/cloudflared:latest，但长期部署不建议无条件跟随latest；为了便于回滚和复现，应根据官方发布信息选择经过验证的固定版本，并把Token交给Docker secrets、平台密钥管理或其他受控注入方式，而不是写进镜像、仓库或公开编排文件。官方安装与运行示例
Linux服务命令通常需要管理员权限，Windows服务安装也需要管理员命令提示符。安装完成后，先验证cloudflared版本和源站本地访问，再验证Tunnel状态；不要把“程序已安装”误认为“应用已经发布成功”。
HTTPS源站、TLS校验与访问控制
如果Service URL使用HTTPS，Cloudflare Tunnel需要能够验证源站证书。证书覆盖的主机名可能与Service URL中的localhost或内网IP不同，此时应在路由的Additional application settings中设置正确的Origin Server Name，让cloudflared按证书主机名进行校验。官方文档默认启用TLS证书验证，只有在明确理解风险且正在临时定位问题时，才会考虑关闭验证。Origin parameters官方说明
如果错误提示类似“certificate is valid for example.com, not localhost”，优先检查Origin Server Name；如果提示证书颁发机构不受信任，可以配置正确的CA证书池。直接设置noTLSVerify会接受任意源站证书，应视为临时排障手段，修复证书链后恢复TLS验证。Cloudflare常见错误排查
隧道连通不等于应用已经完成身份保护。发布应用后，默认的公网主机名可能允许互联网用户访问；如果目标是NAS、后台、内部工具或管理接口，应创建Cloudflare Access应用和访问策略，再用非管理员账号验证登录流程。访问控制、源站权限和Tunnel连接是三个不同层次，不能只依赖其中一个。
SSH、RDP和私有网络：不要照搬网页发布步骤
Cloudflare Tunnel可以用于部分非HTTP服务，但SSH、TCP和RDP不能简单复制网页的“域名加Service URL”流程。Cloudflare官方入门文档明确提示，非HTTP服务通常还需要在客户端运行cloudflared，并按照对应协议的客户端配置连接。若需求是让用户访问整个私有网段，而不是公开一个网页，应使用私有网络路由、CIDR路由和相应的用户访问策略。官方Tunnel与非HTTP服务说明
选择前先回答三个问题：访问对象是单个应用还是整个网段；客户端是否允许安装软件；是否需要身份认证和按用户授权。如果是单个Web应用，Published application通常更直接；如果是内部IP资源，应查看私有网络连接文档；如果是SSH或RDP，则要按照非HTTP协议的官方客户端流程配置，不要把浏览器访问网页的结果当成协议连通性证明。
Cloudflare Tunnel连不上：按三层顺序排查
- 先查源站：在运行cloudflared的机器上访问Service URL，例如
curl http://localhost:8000，或访问真实的内网地址。如果这里失败，先启动应用、检查监听端口和本机到内网主机的路由。 - 再查连接器：确认cloudflared进程没有退出或反复重启，检查Tunnel页面状态和本地日志。若状态异常，重新核对Token、系统权限、服务器时间和进程启动方式。
- 核对出站网络：这里不是要求你开放一个本地入站端口，而是要确认运行cloudflared的主机能够向Cloudflare建立必要的出站连接。官方入门文档特别提示，受限防火墙环境应先核对到Cloudflare的7844端口连通性；实际允许的TCP/UDP流量应以官方连接错误文档和当前网络策略为准。官方连接前置条件
- 最后查公网主机名：确认Routes中使用了正确的Tunnel、子域名和Service URL，域名已经添加到Cloudflare，DNS状态正常。不要只反复修改DNS，因为Tunnel Healthy但页面502时，问题更常见于源站地址、协议、端口或TLS配置。
- 遇到502：先判断cloudflared能否连接Origin。如果Service URL写成
localhost，它代表cloudflared所在机器，不代表局域网中另一台服务器；跨主机部署时必须改成cloudflared主机可访问的真实内网地址。 - 遇到1033：检查Tunnel是否有健康的cloudflared连接。官方说明，1033通常意味着Cloudflare找不到健康的连接器实例，应检查Tunnel状态、进程和连接日志。官方常见错误说明
推荐的判断顺序是“源站本地访问 → cloudflared进程 → 出站网络 → Tunnel状态 → DNS和主机名 → Access策略”。每一步都先获得一个可观察结果，再进入下一层，避免把应用没启动误判成DNS或线路故障。
发布前验证清单
- 源站服务能从cloudflared所在机器访问。
- Service URL中的协议、内网地址和端口与实际监听一致。
- Dashboard中的Tunnel状态正常，连接器没有持续重启。
- Routes中已添加Published application，并选择了正确域名和Tunnel。
- HTTPS源站的证书主机名、CA信任链和TLS校验已经核对。
- 管理后台、NAS和内部工具已设置访问控制，不是仅依赖随机或固定域名。
- Token未写入公开仓库、网页、截图和普通日志。
- Quick Tunnel仅用于临时开发或测试，长期服务已根据实际运维能力选择持久隧道。
- 出现失败时保留源站日志、cloudflared日志、Tunnel状态和浏览器错误码，便于逐层定位。
Cloudflare Tunnel解决的是连接路径问题，不会自动修复源站应用、域名配置、权限策略、证书链或网络访问控制。是否适合长期运行，还取决于源站备份、日志、更新、访问权限和故障回退方案。
常见问题
Cloudflare Tunnel需要公网IP吗？
发布普通Web应用时通常不需要源站公网IP。cloudflared从内网主动建立到Cloudflare的连接，公网请求再通过该连接到达源站；但运行cloudflared的主机必须能访问应用，并允许必要的出站网络连接。
Quick Tunnel和持久隧道有什么区别？
Quick Tunnel使用随机的trycloudflare.com地址，停止cloudflared进程后地址失效，适合开发和临时演示。持久隧道有账户中的隧道记录，可以绑定固定主机名和路由；但长期运行仍需要源站、连接器、日志和访问控制维护。
Cloudflare Tunnel连不上，先检查什么？
先在cloudflared所在机器测试Service URL，再检查cloudflared进程和Tunnel状态，然后核对到Cloudflare的出站网络、7844端口、DNS、主机名路由和TLS设置。页面502时，优先检查源站地址、端口和协议，而不是只修改DNS。
Cloudflare Tunnel中的7844端口是入站还是出站？
排查重点是cloudflared主机到Cloudflare的出站连通性，不是单纯在路由器上开放本地入站端口。官方入门文档要求受限防火墙环境核对7844端口，具体TCP或UDP通道应以当前官方连接错误文档和网络策略为准。
Cloudflare Tunnel能发布SSH或RDP吗？
可以按照对应的非HTTP协议文档配置，但不能照搬网页发布步骤。官方文档提示，SSH、TCP和RDP等服务通常需要客户端侧也运行cloudflared，并应配合身份认证和最小权限策略。
HTTPS源站为什么会出现证书错误？
常见原因是证书覆盖的主机名与Service URL中的主机名不一致，或源站证书的CA不受cloudflared信任。应优先设置正确的Origin Server Name或CA证书池，并保持TLS验证开启；关闭验证只能作为临时排障手段。