Let’s Encrypt · HTTP-01 · Help

Let’s Encrypt: some HTTP-01 checks time out

Compare the same challenge path from independent networks and match both successful and missing requests to your logs.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

One successful request to an HTTP-01 path does not prove that every relevant validation path is reachable. Mixed successes and timeouts require matching timestamps, address families, response content and proxy logs. Test the same harmless path from several independent networks. The original report does not establish a specific filtering cause or justify disabling the firewall globally or inventing CA IP allowlists.

Source basis: Q1 · Q2

Applies to
Applies to inconsistent external HTTP-01 reachability. The documented case used Nginx Proxy Manager behind NAT, without confirming a specific filtering or provider cause.
How to verify the result
The test path consistently returns the expected content from the independent networks checked, and a new controlled certificate test completes the previously failing validation.
Your first check

Which requests actually reach the challenge resource?

Compare the same harmless resource, time and response from independent networks. One successful check does not explain the remaining timeouts.

Certificate issuance fails even though your web-server log contains successful challenge requests. Other validation attempts report Timeout after connect. An original report describes this mixed outcome with Nginx Proxy Manager behind NAT. Filtering and routing were discussed as possibilities, but the report did not establish a definitive resolution. Q1

Look beyond the successful request

HTTP-01 needs the expected content at the challenge path for the requested hostname. Q2 If different network paths receive different treatment, a local check or one external request can succeed while the certificate order still fails. A presumed permanent list of validator IP addresses is not a dependable repair strategy.

Build a small comparison matrix

  1. Record the exact interval. Keep the domain, challenge type, complete error and timezone. Match successful requests and failed validation attempts to the same order. Otherwise, apparently conflicting observations may come from different attempts or configurations.
  2. Prepare harmless test content. Use a clearly identifiable resource under your control in the same routing area. It should traverse the relevant proxy and origin path without exposing real challenge secrets or account credentials.
  3. Compare independent networks. Record time, destination address, status and response content for each request. If only your own network works, its route may bypass the public NAT or firewall path. Separately test any published IPv4 and IPv6 endpoints.
  4. Correlate logs by layer. Start at the public entry point, then check proxy and origin logs. A request visible at the entry point but absent at the origin narrows the next investigation to the intervening path. If it never arrives at the entry point, inspect upstream network and filtering evidence.
  5. Examine relevant rules. Look for geographic restrictions, rate limits, WAF events, load-balancer differences and redirects affecting this path. Any correction should allow the required operation narrowly. Turning off the entire protection stack makes the test less controlled and creates unnecessary exposure.

Confirm the finding

Repeat the same harmless comparisons after one bounded change. Once the path responds consistently, a fresh certificate test can assess the corrected setup. When an upstream provider is involved, timestamps and correlated requests give its support team something concrete to investigate.

For handoff, prepare a small results table, sanitised logs, DNS answers and the NAT/proxy/origin arrangement. Include negative findings too: an absent request matters when you can identify the log that would normally record it. Keep the original certificate and configuration available during the investigation.

Frequently asked questions

Does an HTTP 200 log entry prove that validation works everywhere?

No. It establishes only the observed request and the content that request received.

Should I increase the timeout first?

First locate the stalled stage. More waiting does not correct a consistently blocked or misrouted request.

Describe your case

Support with this issue

We can correlate challenge routing, filtering evidence and server logs.

Describe your case →Related service: Data & improvements

Sources