What is this error?
“ERR_ECH_FALLBACK_CERTIFICATE_INVALID” is a browser error that appears when a site using TLS with ECH (Encrypted Client Hello) fails to fall back correctly, or when the certificate presented does not match the expected host name. Users reported it happening intermittently, particularly in setups using Traefik (a dynamic reverse proxy), Let’s Encrypt wildcard certs, Cloudflare, local DNS resolution (Pi-hole, etc.).
As per one user’s report:
- The error showed up locally (not just via external access). Reddit
- The setup: Traefik on Docker, wildcard certs via Let’s Encrypt, domain registered through Cloudflare; local DNS via Pi-hole v6 with upstream forwarding, etc. Reddit
- The issue worsened after upgrading to Pi-hole v6. Reddit
Why you can’t simply turn ECH off in Chrome anymore
Older versions of Chrome allowed toggling ECH off via chrome://flags or command-line switches. However, recent Chrome versions have removed the option to disable ECH via those flags. In other words, you can’t rely on a “just disable ECH” approach through browser settings any longer. This means if the browser attempts to use ECH, and your server / DNS / TLS setup isn’t matching what Chrome expects, you may get fallback certificate mismatches (hence the “fallback certificate invalid” error).
Root cause (as inferred from community reports)
From what users observed:
- Local DNS sometimes resolves domains inconsistently. For example, your local
.localor internal hostnames might sometimes forward AAAA or A records upstream, or not be handled strictly locally. This can introduce mismatch between what the browser expects and what the certificate is for. Reddit - The domain cloudflare-ech.com is involved. Cloudflare uses ECH, and clients may attempt to contact or query something related to
cloudflare-ech.com. If that name resolves incorrectly (or is allowed), browser behaviour can cause fallback certificate issues. Reddit
The workaround: block cloudflare-ech.com
Since disabling ECH at the browser layer is no longer an option, one effective workaround is to prevent resolution or access to the domain cloudflare-ech.com. By blocking that domain in your DNS/resolving path, you effectively stop Chrome from fetching or using its ECH-related domain name metadata, which avoids triggering the fallback-certificate-invalid issue.
How to do this:
- Clash (or other network-layer proxy / firewall rules): Add a rule like:
- DOMAIN-KEYWORD, cloudflare-ech.com, REJECTSo that any DNS query or connection attempt containingcloudflare-ech.comis rejected. That prevents the browser / system from using that domain. - AdGuard Home (or similar DNS-level blocker): Add
cloudflare-ech.comas a blocked domain or blacklist entry. That way, DNS queries for it return NXDOMAIN or something benign, meaning the browser can’t use it. - Pi-hole (or local DNS resolver): Many on Reddit reported that blocking
cloudflare-ech.comin Pi-hole fixed their situation. Reddit
Also important: ensure your local DNS is fully authoritative/local for hostnames you own, and avoid forwarding upstream for internal names (especially AAAA records if IPv6 is involved) that might cause conflicts. Reddit
Steps to fix in your environment
Putting it all together, here’s a recommended procedure:
| Step | Description |
|---|---|
| A. Identify | Confirm you’re getting ERR_ECH_FALLBACK_CERTIFICATE_INVALID errors across browsers/devices accessing services via your Traefik / wildcard certificates. Check whether the issue is DNS resolution-related (internal vs external), or whether everything is failing. |
| B. DNS Inspection | Using tools like nslookup / dig see how cloudflare-ech.com resolves (if at all) from within your network. Also check if local hostnames are being forwarded upstream accidentally. |
| C. Add block for cloudflare-ech.com | On your DNS resolver / network, block cloudflare-ech.com. Examples: Clash rule, AdGuard Home blocklist, Pi-hole blacklist, etc. |
| D. Verify | Clear your browser cache / name resolution, try accessing the service again. The error should no longer appear if the ECH fallback path that triggers it has been cut off. |
| E. (Optional) Adjust TLS / Traefik if needed | Ensure your certificates actually match the hostnames used. If you’re generating the same wildcard certificate on multiple hosts, make sure they’re identical or that they don’t conflict. Also check your Traefik entrypoints and the host header matches the certificate CN/SAN. |
Caveats & Considerations
- Blocking
cloudflare-ech.commight have side effects for sites legitimately using Cloudflare’s ECH capabilities. You may lose some ECH features or performance/security improvements for those sites. But if you’re mainly using this for internal services, the trade-off is acceptable in many cases. - Be sure IPv6 is handled properly. Sometimes DNS resolvers forward AAAA records upstream or mix local vs public resolution paths, which can cause mismatch or conflict. Ensuring that local domain resolution is consistent is key. The Reddit user noted that after upgrading to Pi-hole v6, local AAAA records were forwarded in some cases, which contributed to the problem. Reddit
- In future, changes in browser support or TLS/ECH specs might change how fallback certificates work. This workaround is effective now, but might need revisiting later.
Summary
Because modern Chrome has removed the ability to disable ECH through flags, when internal services + DNS resolution + TLS certificates are misaligned, you can see ERR_ECH_FALLBACK_CERTIFICATE_INVALID. To avoid this, block or reject access to cloudflare-ech.com at the DNS or network layer (via Clash rule, AdGuard Home, Pi-hole, etc.). By doing so, you stop Chrome from engaging the problematic ECH fallback path, avoiding the certificate mismatch.