Ich habe einen Kunden, der ständig neue Webanwendungen für seine eigenen Kunden unter neuen URLs hochzieht. Das heißt, ich habe ständig mit neuen SSL-Zertifikaten zu tun — auf Infrastruktur, die ich nicht selbst aufgesetzt habe.
Diese Kombination hat mir etwas auf die harte Tour beigebracht: Wenn du etwas in deiner Infrastruktur änderst — eine Route in HAProxy, ein Zertifikat, einen Redirect — und das Ergebnis im Browser prüfst, dann lügt dich der Browser an. Nicht böswillig. Er tut genau das, wofür er gebaut ist. Aber es bedeutet, dass du eine Stunde damit verbringen kannst, eine Änderung zu debuggen, die die ganze Zeit richtig war.
Cache. Und dann noch mehr Cache.
Die naheliegende Antwort ist "deaktivier den Browser-Cache in den Devtools". Das hilft bei genau einem der beteiligten Caches, und man vergisst es jedes Mal.
Das sitzt tatsächlich alles zwischen dir und dem Server:
Der HTTP-Cache ist der, den jeder kennt, und der, den die Devtools abschalten können.
DNS-Caching passiert im Browser, im OS-Resolver und bei deinem Provider. Zieh einen Hostnamen auf eine neue IP um, und dein Browser kann noch lange mit der alten reden, während dig längst die neue meldet.
Redirect-Caching ist das fieseste. Ein 301 Moved Permanently heißt permanent, und Browser nehmen das ernst — sie folgen dem alten Redirect, ohne den Server überhaupt zu fragen. Schick einen falschen 301 raus, korrigier ihn dreißig Sekunden später, und dein Browser kann dem falschen wochenlang weiter folgen. Deshalb nimmst du 302, bis du sicher bist.
HSTS sorgt dafür, dass der Browser sich weigert, mit einem Host HTTP zu sprechen, so lange die max-age es sagt, und das wird pro Host gemerkt. Irgendetwas auf Port 80 für diese Domain zu testen wird aus diesem Browser heraus unmöglich.
Verbindungs-Wiederverwendung heißt, dass eine offene Keep-Alive-Verbindung zum alten Backend weiter genutzt wird, auch nachdem die Proxy-Konfiguration sich geändert hat.
Jedes Einzelne davon ist korrektes Verhalten für einen Nutzer und falsches Verhalten für einen Test.
Und das ist noch vor dem Inkognito-Modus, nach dem viele als Lösung greifen. Der gibt dir einen frischen HTTP-Cache und keine Cookies, und aktuelle Browser führen für ihn tatsächlich einen eigenen dynamischen HSTS-Speicher. Er nutzt aber weiterhin den OS-Resolver, und die eingebaute HSTS-Preload-Liste gilt weiterhin. Er räumt also einige der Schichten oben ab und keine von denen, die dich normalerweise beißen.
Was ich stattdessen nutze
curl, für alles rund um Header und Redirects
Ein Request, kein Cache, und es zeigt exakt, was zurückkam:
curl -I example.com
Um einer Redirect-Kette zu folgen und jeden Sprung zu sehen — was du beim Prüfen einer Proxy-Regel willst:
curl -sIL example.com | grep -E '^(HTTP|location)'
Das mit Abstand nützlichste Flag, wenn du einen Proxy änderst oder einen Host umziehst, ist --resolve. Es schickt den Request an eine bestimmte IP und präsentiert dabei trotzdem den richtigen Hostnamen und macht den richtigen TLS-Handshake:
curl -I --resolve example.com:443:203.0.113.10 example.com
Damit testest du den neuen Server, bevor du das DNS umziehst. Keine Hosts-Datei-Einträge, die du später vergisst, und kein Warten auf Propagation, um herauszufinden, ob die Konfiguration richtig war.
wget, wenn du das Ganze willst
curl ist besser für Header; wget ist praktisch, wenn du die tatsächliche Antwort herunterladen und anschauen willst, oder prüfen, ob eine Datei wirklich ausgeliefert wird statt einer freundlichen 404-Seite.
Die Hosts-Datei, um einen vhost vor dem DNS zu testen
Immer noch nützlich, immer noch der Klassiker unter den Fehlern. Eintrag rein, testen, und sofort wieder raus. Ein vergessener Hosts-Eintrag ist ein wirklich böser Bug — alles funktioniert für das ganze Team und nur bei dir nicht, oder schlimmer: nur bei dir.
SSL Labs, für das komplette Zertifikatsbild
ssllabs.com/ssltest gibt dir die Kette, die Protokolle, die Cipher und eine Note. Es ist die beste kostenlose Sicht auf das, was ein echter Client sieht.
Eine Warnung, die mich Zeit gekostet hat: SSL Labs cached auch. Führ es nach einer Zertifikatskorrektur aus, und du kannst das alte Ergebnis zurückbekommen. Auf der Ergebnisseite gibt es eine "Clear cache"-Option — nimm sie, sonst debuggst du eine Korrektur, die du längst gemacht hast. Zertifikate verdienen ohnehin ihr eigenes Werkzeugset, das ist ein eigener Artikel.
Die Regel, an die ich mich jetzt halte
Prüf mit einem Werkzeug, das kein Gedächtnis hat. Dann, und erst dann, mach einen Browser auf — als letzte Kontrolle, dass ein echter Client zufrieden ist, nicht als das, was dir sagt, ob die Änderung funktioniert hat.
Wenn curl sagt, der Header stimmt, und der Browser widerspricht, ist die Antwort immer der Browser. Jedes einzelne Mal. Umgekehrt ist es mir noch nie passiert.
Die Folgerung: schick keine 301er raus, solange du noch arbeitest
Der Permanent-Redirect-Cache ist der, der dich am längsten bestraft, denn er ist nicht nur deiner — er ist der jedes Besuchers, und deren kannst du nicht leeren.
Während du einen Redirect einrichtest, nimm also 302. Wenn du sicher bist, wechsel auf 301 und setz anfangs eine kurze max-age. Das kostet nichts und spart dir das Support-Ticket, das mit "die Seite schickt mich auf die falsche Seite und Cache leeren hilft nicht" anfängt.