SSH 走 Cloudflare 优选域名加速：一场越修越像悬疑片的复盘

通用
1

SSH 加速迷惑行为大赏：我们如何把“能连”折腾成“终于连得稳”

先说结论，避免你看到一半想关网页：

  • 这套方案能提升“稳定性”，不一定显著降低“延迟数字”。
  • 免费 Cloudflare + wstunnel 能救命，但不会凭空变专线。
  • 最大收获是：以后遇到同类问题，知道先查哪一层，不用靠玄学。

第一章：300ms 不可怕，可怕的是“卡得像 PPT”

故事开始很朴素：

  • 中国到新加坡，ping 300ms。
  • 业务站点看着还能用，因为有 CF 反代和优选域名。
  • 但 SSH 一敲就进入“你说话我缓一缓再回你”的人生阶段。

于是灵魂发问：

“HTTP 能加速，SSH 能不能也蹭一下？”

答案：能，但你得接受它不是“一键魔法”，而是一套多层拼图。

第二章：我们以为是网络，结果是配置互相打架

这次最像悬疑片的点是：

  • ssh.cafe.de5.net 看着通。
  • ssh.aiya.de5.net 证书也 active。
  • 客户端却各种 connection closed by foreign host、Connection refused。

后来定位才发现：

  • Cloudflare SaaS 自定义主机会带自己的 Host 回源。
  • Nginx server_name 没把 ssh.aiya.de5.net 包进去时，会掉到错误站点。
  • 然后你看到的就不是“明确报错”，而是“怎么都不对劲”。

一句话概括：

它不是挂了，它只是每一层都“几乎正确”。

第三章：浏览器报 400 其实是好消息

很多人第一次会被这个吓到：

访问 https://ssh.xxx 看到 Invalid protocol request 或 400，以为炸了。

但在这套架构里，这往往是好事：

  • 说明请求已经打到 wstunnel 后端。
  • 只是你用浏览器发的是 HTTP，不是 SSH-over-WS 的协议流。

也就是说：

  • 400 可能代表“链路通了但协议不对”；
  • 404 才更像“压根没打到你期望的后端”。

第四章：客户端才是最后一公里（也是最容易翻车的一公里）

服务端都配好了，客户端仍可能翻车：

  • 你以为连的是加速域名，实际 FinalShell 在连 127.0.0.1:10022，但本地隧道没起。
  • wstunnel 版本参数不兼容，一个 -v 直接报 unexpected argument。
  • SSH 日志里 kex_exchange_identification: Connection closed，本质是隧道没稳定建立。

最后正确姿势其实很朴素：

  1. 先在本机跑 wstunnel client，让本地 10022 监听。
  2. 再让 FinalShell/终端连 127.0.0.1:10022。
  3. 连接不上先查“本地端口有没有监听”，别先怀疑人生。

第五章：那它到底有没有“加速”？

这个问题值得单独说。

多数情况下你会得到：

  • 延迟数字：变化不大（甚至差不多）
  • 体感稳定性：明显更好（不乱断、不抽风）

为什么？

  • 免费 CF 不是 Argo 专线，不会把物理距离魔法抹掉。
  • 但它常能把“烂线路抖动”变得更可控。

所以这套方案更像：

给 SSH 上了“防抖云台”，不是换了“光速引擎”。

给后来者的避坑清单（浓缩版）

  1. 先确认链路模型：你是 wstunnel 还是 cloudflared tunnel，别混用概念。
  2. SaaS 自定义主机一定检查 custom_origin_server 和回源 Host 匹配。
  3. Nginx server_name 要覆盖 SaaS 主机名，不然会掉错站。
  4. 浏览器打开 SSH 域名返回 400 不一定是坏事。
  5. 客户端先看本地端口监听，再看 SSH 日志。
  6. 目标先定成“稳定”，不是盯死“延迟一定下降”。

最后一句（给熬夜调网的你）

这次折腾最大的价值不是“某条命令终于成功”，而是你把一套复杂链路拆成了可验证的模块：

  • DNS
  • SaaS 主机
  • 回源
  • 隧道
  • 客户端

当你能按层排查，所谓“玄学网络问题”就会变成“普通工程问题”。

恭喜，从被网络折磨，进化到折磨网络。

1 个赞