SSH über Cloudflare-Optimierungsdomains beschleunigen: ein Rückblick, der beim Reparieren immer mehr zum Krimi wurde

Allgemein
1

SSH-Beschleunigungs-Nervtaten-Best-of: Wie wir „geht irgendwie“ zu „läuft endlich stabil“ verfrickelt haben

Vorweg das Fazit, damit du nicht nach der Hälfte die Seite zumachst:

  • Diese Lösung verbessert die „Stabilität“, senkt aber nicht unbedingt spürbar die „Latenzzahlen“.
  • Kostenloses Cloudflare + wstunnel kann dir das Leben retten, macht aber nicht aus dem Nichts eine Standleitung.
  • Der größte Gewinn ist: Bei ähnlichen Problemen weißt du künftig, welche Schicht du zuerst prüfst – statt dich auf Voodoo zu verlassen.

Kapitel 1: 300 ms sind nicht schlimm – schlimm ist „ruckelt wie eine PowerPoint“

Die Geschichte beginnt ganz unspektakulär:

  • China nach Singapur, ping 300 ms.
  • Die Business-Website wirkt noch benutzbar, weil es CF-Reverse-Proxy und optimierte Domains gibt.
  • Aber sobald man SSH tippt, beginnt die Lebensphase „du redest, ich überlege kurz und antworte dann“.

Also die Seelenfrage:

„HTTP kann man beschleunigen – kann SSH nicht auch ein bisschen mitnaschen?“

Antwort: Kann es, aber du musst akzeptieren, dass es keine „Ein-Klick-Magie“ ist, sondern ein mehrschichtiges Puzzle.

Kapitel 2: Wir dachten, es ist das Netz – am Ende haben sich Konfigurationen gegenseitig verprügelt

Der Teil, der am ehesten wie ein Krimi war:

  • ssh.cafe.de5.net sieht erreichbar aus.
  • ssh.aiya.de5.net Zertifikat auch active.
  • Der Client wirft aber ständig connection closed by foreign host, Connection refused usw.

Später stellte sich bei der Ursachenanalyse heraus:

  • Cloudflare SaaS Custom Hostnames bringen ihren eigenen Host beim Origin-Request mit.
  • Wenn Nginx server_name ssh.aiya.de5.net nicht mit abdeckt, fällt es auf die falsche Site/den falschen vHost zurück.
  • Und dann siehst du keinen „klaren Fehler“, sondern nur „irgendwie stimmt gar nichts“.

In einem Satz:

Es ist nicht down – es ist nur auf jeder Schicht „fast richtig“.

Kapitel 3: 400 im Browser ist eigentlich eine gute Nachricht

Viele erschrecken beim ersten Mal:

Wenn du https://ssh.xxx aufrufst und Invalid protocol request oder 400 siehst, denkst du, es ist explodiert.

In dieser Architektur ist das aber oft ein gutes Zeichen:

  • Es zeigt, dass der Request bereits beim wstunnel-Backend ankommt.
  • Du schickst nur mit dem Browser HTTP – nicht den Protokollstrom von SSH-over-WS.

Heißt:

  • 400 kann bedeuten „Leitung steht, aber falsches Protokoll“;
  • 404 sieht eher aus wie „hat dein erwartetes Backend gar nicht erreicht“.

Kapitel 4: Der Client ist die letzte Meile (und auch die unfallträchtigste)

Selbst wenn der Server sauber konfiguriert ist, kann der Client immer noch crashen:

  • Du glaubst, du verbindest dich mit der beschleunigten Domain, in Wirklichkeit verbindet FinalShell zu 127.0.0.1:10022, aber der lokale Tunnel läuft nicht.
  • wstunnel-Versionen haben inkompatible Parameter; ein -v führt direkt zu unexpected argument.
  • In SSH-Logs steht kex_exchange_identification: Connection closed – im Kern ist einfach der Tunnel nicht stabil aufgebaut.

Am Ende ist die korrekte Vorgehensweise erstaunlich simpel:

  1. Lokal wstunnel client starten, damit lokal 10022 lauscht.
  2. Danach FinalShell/Terminal auf 127.0.0.1:10022 verbinden lassen.
  3. Wenn es nicht geht: zuerst prüfen, ob der lokale Port überhaupt lauscht – nicht gleich am Leben zweifeln.

Kapitel 5: Hat das nun wirklich „beschleunigt“?

Das verdient ein eigenes Kapitel.

Meist bekommst du:

  • Latenzzahlen: kaum Veränderung (teils praktisch gleich)
  • subjektive Stabilität: deutlich besser (keine random Disconnects, weniger Zicken)

Warum?

  • Kostenloses CF ist keine Argo-Standleitung und zaubert die physische Entfernung nicht weg.
  • Aber es kann oft „miese Routing-Jitter“ in etwas Kontrollierbareres verwandeln.

Darum ist diese Lösung eher:

SSH bekommt einen „Anti-Wackel-Gimbal“, nicht einen „Lichtgeschwindigkeitsmotor“.

Anti-Fallen-Checkliste für Nachzügler (komprimiert)

  1. Erst das Link-Modell klären: Nutzt du wstunnel oder cloudflared tunnel? Begriffe nicht vermischen.
  2. Bei SaaS Custom Hostnames unbedingt custom_origin_server und den Origin-Host auf Matching prüfen.
  3. Nginx server_name muss die SaaS-Hostname(s) abdecken, sonst landest du im falschen vHost.
  4. Wenn der Browser beim SSH-Domainaufruf 400 zurückgibt, ist das nicht zwingend schlecht.
  5. Beim Client zuerst lokalen Port-Listen-Status prüfen, dann SSH-Logs.
  6. Ziel zuerst auf „stabil“ setzen – nicht darauf versteifen, dass „Latenz muss sinken“.

Zum Schluss ein Satz (für dich, der nachts Netze debuggt)

Der größte Wert dieses Gefummels ist nicht „ein bestimmter Befehl funktioniert endlich“, sondern dass du eine komplexe Kette in verifizierbare Module zerlegt hast:

  • DNS
  • SaaS Hostname
  • Origin
  • Tunnel
  • Client

Wenn du schichtweise debuggen kannst, werden „mystische Netzwerkprobleme“ zu „normalen Engineering-Problemen“.

Glückwunsch: Von „vom Netzwerk gequält“ zu „das Netzwerk quälen“ weiterentwickelt.

1 „Gefällt mir“