TURN EVIDENCE INTO A NEXT STEP
Troubleshoot your ECH result
Start with the endpoint rows and measurement time. Results describe one resolver and one scanning location. A connection failure is not proof that ECH is disabled.
Missing, invalid or unsupported configuration
Inspect HTTPS DNS records and compare the published ECHConfigList with your provider’s configuration. “Invalid or unsupported” also covers features outside this checker’s scope, such as a different port or a QUIC-only service.
ECH rejected
Check whether all TLS endpoints have keys matching the published configuration. Compare service targets and priorities, and review any recent rollout.
ECH confirmed after retry
The server supplied authenticated replacement keys and the retry succeeded. Check stale DNS answers or key rotation if this persists. Endpoints that succeed immediately and after retry both count as confirmed.
DNS error
Check HTTPS aliases and A/AAAA responses for the advertised target. Look for lookup failures or alias loops. ECHScan also refuses internal and management destinations.
Network error
Check public TCP/443 connectivity. Compare IPv4 and IPv6 rows; timeouts can be temporary or specific to the scanner’s route.
Certificate error
Check expiry, chain and hostname coverage. The requested hostname is verified for acceptance; the outer public name is verified for authenticated rejection. Certificate verification stays enabled.
Mixed endpoint results
Compare failures with successful rows. Inconsistent configuration, missing ECH records or partial reachability can produce a mixed result. A retry difference alone does not.
Not checked or limited coverage
Untested endpoints remain unknown. Check the family counts and the limits in our methodology. No recorded IPv6 test is not proof of absent IPv6 support.
Scanner error or inconclusive result
Submit again after the cache interval shown in the report, subject to rate limits. Keep the JSON export if you need to compare evidence from separate checks.