SSHをCloudflareの優選ドメイン経由で高速化：直すほどミステリー化する振り返り

AIDO デバッグ
,
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 を listen させる。
  2. それから FinalShell/端末で 127.0.0.1:10022 に接続する。
  3. 繋がらないなら先に「ローカルポートが listen しているか」を確認し、いきなり人生を疑わない。

第五章：で、結局「高速化」できたの？

これは単独で語る価値がある。

多くの場合こうなる：

  • 遅延の数値：あまり変わらない（むしろほぼ同じ）
  • 体感の安定性：明らかに良くなる（変に切れない、暴れない）

なぜか？

  • 無料 CF は Argo 専用線じゃない。物理距離を魔法で消せない。
  • でも「クソ回線の揺れ」を、より制御しやすくしてくれることが多い。

だからこの仕組みはむしろ：

SSH に「手ブレ補正ジンバル」を載せたのであって、「光速エンジン」に換装したわけではない。

後から来る人向けの落とし穴回避リスト（圧縮版）

  1. まず経路モデルを確認：wstunnel なのか cloudflared tunnel なのか、概念を混ぜない。
  2. SaaS カスタムホストは必ず custom_origin_server とオリジンへの Host の一致を確認。
  3. Nginx の server_name は SaaS のホスト名をカバーしないと、別サイトへ落ちる。
  4. ブラウザで SSH ドメインを開いて 400 が返っても、必ずしも悪いことではない。
  5. クライアントはまずローカルポートの listen を見て、それから SSH ログを見る。
  6. 目標はまず「安定」。 「遅延が必ず下がる」に固執しない。

最後に一言（徹夜でネット調整してる君へ）

今回の最大の価値は「あるコマンドがやっと成功した」ことではなく、複雑な経路を検証可能なモジュールに分解できたこと：

  • DNS
  • SaaS ホスト
  • オリジン
  • トンネル
  • クライアント

層ごとに切り分けできるようになれば、「オカルトなネットワーク問題」は「普通のエンジニアリング問題」に変わる。

おめでとう。ネットに虐められる側から、ネットを虐める側へ進化した。

「いいね！」 1