Eine Domain, vier Einstiege: unter welcher Adresse eine Seite wirklich antwortet

Bei einer öffentlichen Website ergeben HTTP und HTTPS zusammen mit der Basisdomain und dem www-Host vier häufige Einstiegsadressen. Namensauflösung (DNS), verschlüsselte Übertragung (TLS) und Serverregeln bestimmen Erreichbarkeit und Endziel. Diese vier Kombinationen sind eine nützliche Prüfliste, aber nicht sämtliche möglichen Adressen einer Domain.

Ein datiertes Beispiel: 2. September 2026

Die archivierte Messung umfasst zwölf Domains mit jeweils vier Varianten. Bei neun Gruppen steht für alle vier Varianten dieselbe End-URL. Drei Gruppen unterscheiden sich: kernel.org und apache.org behalten getrennte www- und Basisdomain-Ziele, nginx.org getrennte HTTP- und HTTPS-Ziele. Gleiche URLs belegen keine erfolgreiche Auslieferung: Die protokollierte HTTP-Basisdomain-Kette von stackoverflow.com endet mit 403.

Für die zwölf HTTP-Basisdomain-Einstiege verzeichnet der Schnappschuss sieben Ketten mit einem Sprung, vier mit zwei Sprüngen und eine Antwort ohne Weiterleitung. Diese Zahlen gelten für diese Einstiegsvariante, nicht für alle 48 Tests. Der Datensatz beschreibt beobachtete Antworten an diesem Datum. Aktuelle Konfigurationen, Gründe für die Entscheidungen oder allgemeine Rankingfolgen lassen sich daraus nicht ableiten.

Herkunft und Cookie-Geltungsbereich unterscheiden sich

http://example.com und https://www.example.com haben wegen Schema und Host unterschiedliche Origins. Eine Origin kombiniert Schema, Host und Port. An die Origin gebundener Browserspeicher bleibt getrennt. Für Cookies gelten andere Regeln: Ohne Domain-Attribut bleibt ein Cookie auf den jeweiligen Host beschränkt, auch bei der Basisdomain. Mit Domain=example.com kann ein Cookie die übergeordnete Domain samt Subdomains abdecken. Ein zulässiges Cookie für die übergeordnete Domain lässt sich auch von www.example.com setzen. Secure, Path und weitere Attribute stellen zusätzliche Bedingungen. Die Wahl von www verhindert allein keine gemeinsame Cookie-Nutzung.

Eine bevorzugte Adresse ohne Rankingversprechen

Für gleichwertige öffentliche Seiten vereinfacht ein einheitliches HTTPS-Ziel Navigation, Verlinkung und Pflege. Google kann Duplikate auch ohne ausdrückliche Vorgabe erkennen und eine kanonische URL wählen: die Hauptadresse, die diese Kopien in der Suche vertritt. Mehrere erreichbare Kopien bedeuten deshalb nicht automatisch zwei Indexeinträge oder dauerhaft aufgeteilte Linksignale.

Dauerhafte Weiterleitungen und rel="canonical" sind beide starke Signale für die kanonische Auswahl. Interne Links und Sitemaps sollten zum vorgesehenen Ziel passen. Eine Canonical-Angabe leitet keinen Besucher um und verschlüsselt keine HTTP-Verbindung. Keine solche Angabe garantiert Googles Auswahl. Parameter mit eigenständiger inhaltlicher Bedeutung sollten nicht pauschal wegkanonisiert werden.

Sowohl 301 als auch 308 kennzeichnen einen dauerhaften Umzug. Im Gegensatz zur historisch möglichen Behandlung von 301 erhält 308 Methode und Anfrageinhalt. Anmeldeformulare, POST-Endpunkte und APIs benötigen deshalb eine gesonderte Prüfung. Temporäre Weiterleitungen können bei vorübergehenden Zuständen korrekt sein.

Zertifikate und der bewusste zweite Sprung

Jeder angesprochene HTTPS-Hostname benötigt gültige TLS-Abdeckung, bevor die HTTP-Weiterleitung lesbar wird. Ein Zertifikat kann beide Namen abdecken; getrennte korrekt eingerichtete Zertifikate sind ebenfalls möglich. Eine Weiterleitung ersetzt weder funktionierendes DNS noch einen erreichbaren TLS-Endpunkt oder ein passendes Zertifikat.

Eine direkte Weiterleitung von http://example.com/path nach https://www.example.com/path spart einen Netzwerksprung. Dieser Besuch etabliert aber kein HSTS für example.com: Die von www empfangene Richtlinie gilt nicht nach oben für die Basisdomain. Eine bewusste Alternative ist zuerst HTTP auf HTTPS beim selben Host und anschließend der Hostwechsel. Die HTTPS-Zwischenantwort kann die Richtlinie für den ursprünglichen Host setzen. Zwei Sprünge sind deshalb nicht automatisch ein Konfigurationsfehler.

HSTS gehört auf HTTPS-Antworten

Strict Transport Security weist unterstützende Browser an, künftige HTTP-Zugriffe innerhalb des Geltungsbereichs auf HTTPS umzustellen. Über HTTP wird der Header ignoriert; eine gültige HTTPS-Weiterleitung kann einen wirksamen Header enthalten. Die Richtlinie ist nicht auf die endgültige Inhaltsantwort beschränkt.

Die Einführung benötigt geprüfte HTTPS-Abdeckung und eine geeignete kurze Testdauer. includeSubDomains erweitert den Geltungsbereich auf verschachtelte Subdomains und muss zur unterstützten Infrastruktur passen. Eine Richtlinie auf einem untergeordneten Host schützt nicht die Basisdomain. Eine spätere Antwort mit max-age=0 entfernt die gespeicherte Richtlinie dieses Hosts, beseitigt aber weder eine unabhängig geltende übergeordnete Richtlinie noch sofort einen Eintrag in der Preload-Liste des Browsers.

Beim Preloading steht die Domain auf einer mit dem Browser ausgelieferten Liste. Dadurch gilt die HTTPS-Pflicht bereits vor dem ersten Besuch. Das ist eine gesonderte langfristige Entscheidung, kein automatischer nächster Schritt. Das Preload-Projekt empfiehlt aktuell HSTS, aber kein allgemeines Preloading. Für eine Aufnahme gelten weiterhin strenge Anforderungen: HTTP auf HTTPS beim selben Host, gültiges HTTPS für Subdomains und die erforderlichen Header-Direktiven. Automatische HTTPS-Upgrades und vorhandene Preload-Regeln bedeuten außerdem, dass auch ein erster Besuch ohne ausgeschriebenes Schema nicht zwangsläufig mit einer HTTP-Netzwerkanfrage beginnt.

Vier Prüfungen mit nachvollziehbaren Belegen

Das folgende Shell-Beispiel führt für jede reservierte Beispieladresse einen GET-Aufruf aus und zeigt Antwortheader sowie das nächste Weiterleitungsziel. Weiterleitungen werden bewusst nicht automatisch verfolgt. Die Domain benötigt eine Ersetzung durch das tatsächliche öffentliche Prüfziel.

for url in \
  'http://example.com/' 'https://example.com/' \
  'http://www.example.com/' 'https://www.example.com/'
do
  printf '\n%s\n' "$url"
  curl --silent --show-error --connect-timeout 10 --max-time 20 \
    --dump-header - --output /dev/null \
    --write-out 'status=%{http_code} next=%{redirect_url}\n' "$url"
done

Jedes Location-Ziel benötigt anschließend eine eigene Prüfung bis zur Endantwort oder zu einem dokumentierten Fehler. Eine begrenzte Kette, Zeitpunkte, HTTP-Methoden, Endstatus, TLS-Fehler und exakte URLs machen das Ergebnis nachvollziehbar. HEAD-Aufrufe mit -I können anders reagieren als GET. Ein Kommandozeilenclient bildet gespeichertes HSTS, zwischengespeicherte Weiterleitungen, Cookies oder JavaScript-Navigation eines Browsers nicht automatisch nach.

Alle vier erfolgreichen Ergebnisse müssen zur vorgesehenen gleichwertigen Ressource führen, nicht bloß zwei erreichbare Varianten. Eine Kleinschreibung von Pfaden oder Abfragewerten kann reale Unterschiede verdecken. Auch ein Endstatus 200 belegt noch nicht den richtigen Inhalt.

Der Redirect-Ketten- und Canonical-Host-Tracer protokolliert serverseitige Weiterleitungsketten und hebt mögliche Probleme hervor. Der aktuelle Vergleich arbeitet heuristisch: Übereinstimmung erreichbarer Varianten belegt keinen Erfolg aller vier Einstiege; außerdem normalisiert der URL-Vergleich Pfade zu weitgehend. Exakte URLs und Fehler benötigen eine Kontrolle. Ein temporärer Code oder zwei Sprünge sind Prüfanlässe, keine Fehlerbeweise.

Fragen und Antworten

Wie kann Apache auf HTTPS weiterleiten?

In einem eigenen HTTP-VirtualHost für example.com lautet eine einfache Regel für denselben Host:

Redirect permanent "/" "https://example.com/"

Der anschließende Pfadteil und die Abfrage werden bei dieser Form weitergegeben. Ein eigener HTTP-VirtualHost für www verwendet den zugehörigen festen HTTPS-Hostnamen. Ein HTTPS-VirtualHost kann danach den freigegebenen Hostwechsel ausführen und auf dieser Weiterleitung HSTS senden. Das sind Konfigurationsausschnitte, keine vollständige TLS-Einrichtung oder allgemeine Regel für sämtliche Anwendungsmethoden.

Was ändert sich hinter CDN oder Load Balancer?

Endet TLS am vorgeschalteten Dienst, kann die HTTPS-Variable des Backends trotz ursprünglich verschlüsselter Anfrage eine unverschlüsselte Verbindung melden. Die Weiterleitung gehört dann an die passende vertrauenswürdige Grenze oder benötigt geprüfte Proxyangaben. Ein öffentlich angelieferter Header X-Forwarded-Proto ist für sich nicht vertrauenswürdig. Direkter Backendzugriff und Headerersetzung benötigen eine definierte Konfiguration. Blinde Headerprüfungen können Schleifen oder Umgehungen verursachen.

Ist ein Sprung immer das beste Ergebnis?

Nein. Unnötige Ketten erhöhen die Latenz, aber HSTS-Etablierung, eine bewusste Pfadänderung oder eine andere dokumentierte Anforderung können einen zusätzlichen Schritt begründen. Neben der Sprungzahl zählen das richtige Ziel, eine sichere Übertragung und die weiterhin korrekte Funktion der Anwendung, etwa die unveränderte Übergabe von Formulardaten.

Quellen

• RFC 6797: HTTP Strict Transport Security
• MDN: HTTP-Cookies verwenden
• Google-Suche: Kanonische URLs und Zusammenführung von Duplikaten
• Google-Suche: Weiterleitungen
• MDN: Strict-Transport-Security
• Chromium: Anforderungen und Empfehlungen für HSTS-Preloading
• Chromium: HTTPS als Standard
• Apache HTTP Server: Weiterleiten und Zuordnen von Adressen
• Apache HTTP Server: Redirect-Direktive
• MDN: Weiterleitungen in HTTP
• curl: Handbuch