← Problem Library
K8s L4 K8S 1404 · 12 min

An HTTP01 challenge solver succeeds on IPv4 and fails globally

The solver service is healthy, yet the preferred family on the edge routes challenge traffic toward nodes that do not host the temporary solver workload.

K8sPlatform ReliabilityLevel 4Pro12 min
Scenario

ACME renewals begin failing after dual-stack ingress is enabled while manual checks from IPv4-only hosts still pass.

What to check first
  • Identify the primary failure signal in the The Solver Was Ready on One Family and the Listener Introduced the Internet to the Other One First scenario.
  • Separate visible symptoms from the underlying technical dependency.
  • Describe the safest recovery path and the follow-up prevention work.
Checking checklist
  1. Summarize the current impact and the last known change.
  2. Collect direct evidence from logs, runtime state, and configuration before changing anything.
  3. Separate immediate recovery from permanent prevention work.
Recovery and prevention

Inspect address-family preference and temporary solver placement before recreating certificates or changing DNS.

Questions worth viewing together
What should you verify first when An HTTP01 challenge solver succeeds on IPv4 and fails globally appears?

Community-field Kubernetes problem inspired by cert-manager and Kubernetes discussions where the HTTP01 solver was exposed through the wrong address fam... Dual-stack rollouts can turn a healthy solver pod into a globally failing validation path if the preferred family lands elsewhere.

What usually causes An HTTP01 challenge solver succeeds on IPv4 and fails globally in production?

Teams often blame ACME provider instability when the edge is simply preferring an address family with no solver reachability.

What should you document after resolving An HTTP01 challenge solver succeeds on IPv4 and fails globally?

Certificate renewals over HTTP01 should be tested from both IP families whenever ingress exposure changes.