Cloudflare Tunnel 接 SSH：Service URL 写 http://127.0.0.1:22 会怎样

2026 年 11 月 6 日，我在给一台江苏本地 Ubuntu 机器配 Cloudflare 隧道 SSH 入口时，踩了一个很小的坑：隧道的 Service URL 写成了 http://127.0.0.1:22，结果 SSH 死活连不上；改成 ssh://127.0.0.1:22 后立刻通了。

现象

• 机器本身：Ubuntu 26.04.1 LTS，内网 172.21.3.249，SSH 监听 22 端口，本机 ssh localhost 正常。
• cloudflared 已在机器上跑起来，隧道状态正常，公网主机名可以解析。
• 客户端执行 ssh admin@sshl.gmailo.us.ci（经 cloudflared access ssh 做 ProxyCommand），连接直接失败，服务端看不到任何 SSH 握手。

原因

Cloudflare Tunnel 的 Service URL 里的 scheme 不是摆设，它决定 cloudflared 用什么协议去回源：

• http://：cloudflared 把入站流量当 HTTP 处理，尝试做 HTTP 解析/转发；SSH 的二进制握手报文不是合法 HTTP，连接在协议层就被丢弃。
• ssh://：cloudflared 按 TCP 字节流原样转发，不解析应用层协议，SSH 握手才能透过去。

也就是说，隧道应用的 Service URL 必须与后端服务的真实协议一致。SSH 是纯 TCP 协议，不是 HTTP，写 http:// 就等于让代理去“理解”一段它理解不了的流量。

修复

在 Cloudflare Zero Trust 面板（中文界面：访问 → 隧道 → 选中隧道 → 编辑应用）里，把 Service URL 从 http://127.0.0.1:22 改为 ssh://127.0.0.1:22，保存后立即生效，无需重启 cloudflared。改完后客户端同一条 SSH 命令一次连通，并用密钥完成登录验证。

顺带的两条经验

1. 排障时先分层：本机 ssh 127.0.0.1 通、隧道状态正常、公网解析正常，三层都通而端到端不通，问题就锁定在隧道应用的协议配置上，而不是网络或密钥。
2. 同类服务同理：RDP、数据库、任意非 HTTP 的 TCP 服务走隧道时，Service URL 都要写对应的 scheme（rdp://、tcp:// 等），不要图省事一律写 http://。

小结

隧道不是万能字节流转发器，scheme 选错协议，握手在入口就被拦下。配 SSH over Cloudflare Tunnel，记住一句话：Service URL 写 ssh://127.0.0.1:22。