Übersicht
Vor einer Woche lud die Nexus-Oberfläche in unter einer Sekunde. Diese Woche plötzlich nicht mehr. Jeder Klick dauerte zwei Sekunden, manche Seiten kamen gar nicht durch. Nach einer durchwachsenen Abend-Session mit vielen Umwegen, einigen Sackgassen und einer Erleuchtung gegen Mitternacht haben wir unsere komplette Web-Infrastruktur umgestellt. Ergebnis: 15-fache Beschleunigung, kein Cent Mehrkosten, volle Kontrolle. Hier die Geschichte.
Das Symptom
Ein Kunde meldet: "dev-Instanz ist langsam geworden". Erste Reaktion: Nexus-Code ist das Problem. Wir hatten in den Tagen davor einige Performance-Refactorings gemacht, neue Plugins aktiviert, das Permissions-System umgebaut. Naheliegend, dass einer dieser Changes ein Flaschenhals geworden ist.
Wir graben. API-Response-Times sehen gut aus (unter 10 Millisekunden). Database-Queries auch. Container-CPU bei 0.2 Prozent. Alles, was wir messen, sagt: der Server ist nicht überlastet.
Trotzdem dauert ein Seitenaufruf zwei Sekunden.
Die erste Erkenntnis
Wir stellen eine simple Messung an: einmal messen wir die Ladezeit über den regulären Weg (durch Cloudflare), einmal direkt zum Server. Cloudflare ist der Dienst, der zwischen dem Internet und unserem Server sitzt. Wie eine Art Rezeption: Requests kommen rein, Cloudflare prüft, leitet weiter, gibt die Antwort zurück.
Über Cloudflare: 2 Sekunden. Direkt zum Server: 80 Millisekunden.
Das ist ein Faktor 25. Der Server selbst ist schnell. Cloudflare ist der Flaschenhals.
Warum?
Cloudflare hat weltweit Rechenzentren. Normalerweise routet ihr Netzwerk automatisch zum nächstgelegenen Standort. Aus Deutschland sollte das Frankfurt oder Hamburg sein. Einen Tag vor unserem Problem war das auch so.
Dann irgendwann zwischen Nacht und Morgen änderte sich das Routing. Unser Traffic ging plötzlich über Singapur. Für jeden einzelnen Request: Deutschland → Singapur → zurück zum Server in Deutschland → Singapur → Deutschland. Einmal halb um die Welt und zurück.
Das ist ein technisches Detail, das wir nicht beeinflussen können. Cloudflare ändert ihre Routen dynamisch, das steht in ihrem Recht. Auf dem kostenlosen Plan gibt es keine Garantie für eine bestimmte Region. Das zu ändern hätte uns den Business-Plan gekostet. Zwanzig Dollar pro Monat pro Domain. Bei mehreren Domains summiert sich das.
Die zweite Erkenntnis
Parallel bemerken wir: ein Zertifikat ist seit fünf Tagen abgelaufen. Unser Deployment-Tool, das auf dokploy.startandconnect.com läuft, war für Browser nicht mehr erreichbar. Warum ist das nicht aufgefallen? Weil Cloudflare sein eigenes Zertifikat vor dem abgelaufenen Origin-Zertifikat angezeigt hat. Im Browser sah alles grün aus, in Wirklichkeit war das Cert dahinter längst tot.
Warum war es abgelaufen? Weil unser API-Token für die automatische Zertifikatserneuerung seit Wochen ungültig war. Niemand hatte es bemerkt. Die Erneuerungen schlugen still im Hintergrund fehl.
Das war ein echter Weckruf. Wir hatten eine Schicht in unserer Infrastruktur, die Probleme verschleiert statt sichtbar macht.
Die Entscheidung
Wir standen vor drei Optionen:
Erstens: zwanzig Dollar pro Domain bezahlen und das Routing-Problem mit einem Premium-Feature lösen. Kurzfristig billig, langfristig pro Kunde teuer, wenn wir wachsen.
Zweitens: zu einem anderen Anbieter wechseln. Es gibt günstigere Alternativen mit garantiert europäischen Standorten. Aber ein Providerwechsel ist Arbeit, und wir sind erst mal abhängig vom neuen Anbieter.
Drittens: den Zwischenlayer ganz weglassen. Direkt vom Internet zum Server. Alles, was Cloudflare für uns getan hat, kann unsere eigene Infrastruktur auch: Zertifikate automatisch ausstellen und erneuern, Traffic routen, Verbindungen terminieren.
Wir entschieden uns für Option drei.
Die Umsetzung
Der eigentliche Umbau war kleiner als befürchtet. Auf dem Server läuft ohnehin schon ein sogenannter Reverse-Proxy, der eingehende Verbindungen verarbeitet und weiterleitet. Dieser Proxy kann auch Zertifikate selbst verwalten, über den offenen Standard Let's Encrypt. Wir mussten ihn nur ein paar Konfigurationszeilen ergänzen und die Schlüssel für die automatisierte Zertifikatserstellung erneuern.
Dann flippten wir die Schalter. Domain für Domain. Erst unser eigener Bereich, dann schrittweise die Kunden-Domains. Nach jedem Schalter: prüfen. Lädt die Seite? Ist das Zertifikat gültig? Antwortet die API? Wir hatten uns für jeden einzelnen Flip einen Rollback-Befehl bereitgelegt, der den Zustand in dreißig Sekunden wiederherstellt. Wir brauchten ihn kein einziges Mal.
Besonders spannend war der Moment, als wir die Wildcard-DNS-Einträge für unsere Kunden-Bereiche umgeschaltet haben. Über zwanzig Kunden-Instanzen waren in dem Moment betroffen. Alle mit eigenen Domains, alle mit eigenen Zertifikaten. Theoretisch hätte viel schief gehen können.
Es ging nichts schief. Ein Kunde hatte seinen Shop an einer eigenen Domain hängen, die über ein Drittsystem auf uns verwies. Diese Kette durchlief plötzlich keinen Proxy mehr, sondern ging direkt zu unserem Server. Und weil unser Proxy sich längst selbst ein Zertifikat für diese Domain geholt hatte (sobald die Route angelegt wurde, weil das so konfiguriert war), funktionierte alles ohne eine einzige Änderung auf Kundenseite. Zero-Touch.
Die Ergebnisse
Wir haben hinterher gemessen:
| Seite | Vorher | Nachher |
|---|---|---|
| Hauptseite (Marketing) | 2 Sekunden | 130 Millisekunden |
| Admin-Login | 2,7 Sekunden | 140 Millisekunden |
| Kunden-Shop (eigene Domain) | 2,8 Sekunden | 210 Millisekunden |
Der Effekt ist auf jeder Seite spürbar. Klicks sind sofort da, statt einen halben Gedanken später. Nebenbei haben wir 85 Gigabyte Disk-Speicher freigeräumt, alte Images und Build-Caches die sich angesammelt hatten. Aus "87 Prozent voll" wurde "56 Prozent voll" auf unserem Hauptserver.
Was wir gelernt haben
Eine Infrastruktur-Schicht, die nicht transparent ist, kostet dich irgendwann Zeit. Cloudflare hat seit fünf Tagen unsere abgelaufenen Zertifikate versteckt. Das ist kein Vorwurf, das ist das Design. Aber wenn wir die Schicht weglassen, wird jedes Problem sofort sichtbar.
Kostenlose Features sind manchmal teuer. Der Cloudflare-Proxy ist gratis. Die Latenz, die er uns gebracht hat, hätte uns in einer Geschäftsvariante Geld gekostet. Die Self-Hosted-Alternative kostet null Euro und läuft besser.
Weniger Schichten sind fast immer besser. Jede Schicht ist eine Stelle, wo Dinge schiefgehen können. Je schlanker der Stack, desto einfacher die Fehlersuche. Der Moment, wo wir die zweite Proxy-Schicht entfernt haben, war der Moment wo alles plötzlich klar wurde. Zwei Messwerte, zwei Verhalten, eine simple Diagnose.
Reversibilität ist wichtiger als Perfektion. Wir hätten wochenlang planen können. Stattdessen haben wir kleine Flips gemacht, jeden einzeln verifiziert, immer mit einem Rollback-Kommando in der Hinterhand. Nach drei Stunden war alles umgestellt. Nach einer Nacht war die Dokumentation geschrieben.
Was bleibt
DNS-Hosting machen wir weiter über Cloudflare. Das ist kostenlos, die API ist gut, und wenn wir irgendwann wechseln wollen, ist das kein Lock-In.
Eine kleine Hintertür haben wir eingebaut: falls wir jemals unter Angriff geraten sollten, können wir in dreißig Sekunden wieder auf den vollen Cloudflare-Schutz schalten. Kostenlos. Panic-Button-Style.
Und für die Zukunft: wenn wir wachsen, wollen wir mit einem Open-Source-Tool namens Crowdsec unseren eigenen kleinen Schutzlayer bauen. Rate-Limits, Bot-Erkennung, alles verteilt und unter unserer Kontrolle. Dafür ist aber noch Zeit.
Fazit
Ein Umbau, den wir seit Monaten aufgeschoben hatten, haben wir in einer Nacht durchgezogen. Das Ergebnis ist eine Infrastruktur, die nicht nur schneller ist, sondern auch transparenter. Jedes Zertifikat gehört uns. Jeder Request läuft direkt. Wenn etwas schiefgeht, sehen wir es sofort.
Für unsere Kunden: nichts zu tun. Ihre Seiten laden schneller. Fertig.
Für uns: ein gutes Gefühl. Ein Stück Tech-Schuld weniger. Und die Erinnerung daran, dass die simple Lösung oft die richtige ist — man muss sie nur zulassen.
