Let’s Encrypt · HTTP-01 · Hilfe

Let’s Encrypt: manche HTTP-01-Prüfungen laufen in einen Timeout

Vergleiche denselben Challenge-Pfad aus mehreren Netzen und ordne erfolgreiche sowie fehlende Anfragen deinen Logs zu.

Quellenstand: 5. November 2026Redaktion: KAN KAI WORKSRedaktionell aktualisiert:

Kurzantwort

Ein erfolgreicher Aufruf des HTTP-01-Pfads beweist nicht, dass die Zertifikatsprüfung aus allen beteiligten Netzen funktioniert. Bei gemischten Erfolgen und Timeouts müssen Zeitstempel, Adressfamilie, Antwortinhalt und Proxy-Protokolle zusammenpassen. Prüfe denselben harmlosen Testpfad aus mehreren unabhängigen Netzen. Der Ausgangsfall legt keine bestätigte Filterursache fest und rechtfertigt weder eine globale Firewall-Abschaltung noch beliebige CA-IP-Freigaben.

Quellengrundlage: Q1 · Q2

Gilt für
Gilt für HTTP-01 bei wechselnder externer Erreichbarkeit. Der Bericht betrifft Nginx Proxy Manager hinter NAT; eine konkrete Filter- oder Anbieterursache wurde nicht bestätigt.
So prüfst du das Ergebnis
Der Testpfad liefert aus den geprüften unabhängigen Netzen konsistent den erwarteten Inhalt. Ein neuer kontrollierter Zertifikatstest bestätigt anschließend die zuvor gestörte Validierung.
Deine erste Prüfung

Welche Anfragen erreichen den Challenge-Pfad tatsächlich?

Vergleiche dieselbe harmlose Ressource, Uhrzeit und Antwort über mehrere unabhängige Netze. Eine erfolgreiche Einzelprüfung erklärt die übrigen Timeouts nicht.

Ein Zertifikatsantrag scheitert, obwohl du erfolgreiche Aufrufe des Challenge-Pfads im Webserverlog siehst. Daneben meldet die Validierung Timeout after connect. Ein Originalbericht beschreibt diese gemischten Ergebnisse bei Nginx Proxy Manager hinter NAT. Eine Filter- oder Routingursache wurde diskutiert, aber nicht abschließend bewiesen. Q1

Nicht nur den erfolgreichen Aufruf betrachten

HTTP-01 benötigt den erwarteten Inhalt am Nachweispfad des beantragten Namens. Q2 Wenn Anfragen über verschiedene Netze unterschiedlich behandelt werden, kann eine lokale oder einzelne externe Prüfung erfolgreich sein, während der gesamte Zertifikatsauftrag scheitert. Eine Liste vermeintlich fester Validator-IP-Adressen ist keine belastbare Reparatur.

Mit einer Vergleichsmatrix eingrenzen

  1. Exakten Fehlerzeitraum festhalten. Notiere Domain, Challenge-Typ, Fehlermeldung und Zeitzone. Trenne die erfolgreiche Anfrage und die fehlgeschlagene Prüfung zeitlich. Sonst vergleichst du möglicherweise unterschiedliche Antragsversuche.
  2. Harmlosen Testinhalt bereitstellen. Nutze unter eigener Kontrolle einen eindeutig erkennbaren Testpfad im gleichen Routingbereich. Er soll denselben Proxy- und Webserverweg verwenden, ohne echte Challenge-Tokens oder Zugangsdaten zu veröffentlichen.
  3. Mehrere unabhängige Netze vergleichen. Erfasse je Aufruf Zeitpunkt, Zieladresse, Status und Inhalt. Funktioniert nur das eigene Netz, kann dessen Weg vom öffentlichen NAT-/Firewall-Weg abweichen. Unterscheide zudem IPv4 und veröffentlichte IPv6-Adressen.
  4. Logs schichtweise zuordnen. Suche zuerst am öffentlichen Eingang, dann am Proxy und am Ursprung. Erscheint die Anfrage nur vorne, liegt die weitere Untersuchung zwischen diesen Stationen. Fehlt sie bereits dort, sind vorgeschaltete Netz- und Filterprotokolle aussagekräftiger als Änderungen am Zertifikatsschlüssel.
  5. Gezielte Regeln untersuchen. Prüfe Geofilter, Rate-Limits, WAF-Ereignisse, Lastverteilung und Weiterleitungen für diesen Pfad. Eine Regelkorrektur sollte genau den notwendigen Zugriff erlauben. Schalte nicht die gesamte Schutzkonfiguration ab.

Den Befund verlässlich bestätigen

Wiederhole dieselben harmlosen Vergleiche nach einer einzelnen Änderung. Erst wenn der Pfad konsistent antwortet, ist ein erneuter Zertifikatstest sinnvoll. Falls ein vorgeschalteter Anbieter betroffen ist, liefern Zeitfenster und Request-Korrelation einen konkreten Ansatz für dessen Support.

Für die Übergabe helfen eine kleine Ergebnistabelle, anonymisierte Logs, DNS-Antworten und eine Beschreibung von NAT, Proxy und Webserver. Dokumentiere auch negative Befunde: Eine nicht sichtbare Anfrage ist relevant, solange klar ist, welches Log sie normalerweise erfassen müsste.

Häufige Fragen

Beweist ein HTTP-200-Eintrag, dass HTTP-01 überall funktioniert?

Nein. Er belegt nur diese beobachtete Anfrage und ihren Inhalt.

Soll ich das Timeout einfach erhöhen?

Erst klären, wo die Anfrage hängen bleibt. Ein systematisch blockierter oder falsch gerouteter Aufruf wird durch längeres Warten nicht korrekt beantwortet.

Fall beschreiben

Unterstützung bei diesem Fehler

Wir können Challenge-Routing, Firewall-Befunde und Serverprotokolle zusammenführen.

Fall beschreiben →Passende Leistung: Daten & Weiterentwicklung

Quellen