Zum Inhalt springen

Weiterleitungskette

Was zwischen deiner Eingabe und der Seite passiert, die am Ende erscheint — jede Station mit Statuscode, Ziel und Protokoll.

Beispiele

Ohne Schema wird ab http:// geprüft — nur so wird sichtbar, ob auf https umgeleitet wird. Es wird ein GET geschickt, der Inhalt aber verworfen. Private und lokale Adressen sind gesperrt.

Was hier geprüft wird

Jede Adresse, die du eintippst, ist selten die Adresse, die am Ende geladen wird. Dazwischen liegen Weiterleitungen: von http auf https, von der nackten Domain auf www, von der alten Seite auf die neue. Diese Seite läuft den Weg ab und zeigt jede Station einzeln.

Jede Weiterleitung kostet eine volle Antwortzeit, bevor auch nur ein Byte der Seite kommt. Zwei Sprünge, die einer sein könnten, sind auf einer schnellen Leitung kaum zu merken — im Mobilfunk sind sie ein spürbarer Teil der Wartezeit.

Grenzen: höchstens 10 Weiterleitungen, je Station 8 Sekunden, insgesamt 18 Sekunden. Wiederholt sich eine Adresse, ist das der Befund — dann wird abgebrochen statt gewartet.

Passt dazu

HTTP-Header-Check →

Hier geht es um den Weg. Wie die Zielseite ihre Sicherheits-Kopfzeilen setzt — HSTS im Detail, CSP, X-Frame-Options — steht im Header-Check.

TLS-Zertifikat →

Bricht die Kette mit einem Zertifikatsfehler ab, zeigt die Zertifikatsprüfung, woran es liegt.

Selbst nachprüfen

Dieselbe Prüfung kannst du im Terminal machen — unter Linux und macOS mit diesen Befehlen:

Die ganze Kette ab http:// — Statuscode und Sprungziel je Station, mit GET wie hier auf der Seite. Bei einer Schleife meldet curl „Maximum redirects followed" auf der Fehlerausgabe; in einem Skript zusätzlich den Exitstatus prüfen.
curl -sS -L --max-redirs 10 -o /dev/null -D - http://example.com/ | grep -Ei "^(HTTP/|location:)"
Welche HTTP-Version tatsächlich ausgehandelt wird: 2 heißt HTTP/2, 1.1 heißt, der Server hat es nicht angeboten.
curl -sS --http2 https://example.com/ -o /dev/null -w "%{http_version}\n"
Dasselbe eine Ebene tiefer: Was der Server bei der ALPN-Aushandlung wählt.
openssl s_client -connect example.com:443 -servername example.com -alpn h2,http/1.1 </dev/null 2>/dev/null | grep ALPN
Das HTTP/3-Angebot in der Alt-Svc-Kopfzeile. Kommt nichts, kündigt der Server hier kein HTTP/3 an — beweisen lässt sich damit nichts.
curl -sS -o /dev/null -D - https://example.com/ | grep -i alt-svc
Die zweite Quelle: der HTTPS-Record im DNS. Steht dort alpn="h3,…", weiß der Browser schon vor der ersten Verbindung Bescheid.
dig +short HTTPS example.com

Die Befehle sind bereits mit deiner Eingabe gefüllt. Weicht ein Ergebnis von dem hier ab: Ein Server darf jeder Anfrage anders antworten: je nach Methode, nach ausgehandeltem Protokoll, nach Herkunftsland oder danach, welcher Knoten eines CDN gerade antwortet. Unterschiede zwischen Terminal und Seite müssen also kein Fehler sein.