To test whether DNS over HTTPS is actually working, you need proof that your lookups are leaving your device encrypted and reaching the resolver you chose, rather than silently falling back to plaintext. Flipping the switch in your browser is not enough, because DoH quietly downgrades to unencrypted DNS whenever the encrypted path fails. This guide shows the concrete signals that confirm DoH is live, how to test both your browser and your operating system, and how to catch the silent fallback that leaves you thinking you are protected when you are not.
What DNS over HTTPS does and does not do
DNS over HTTPS (DoH) wraps your DNS queries inside ordinary HTTPS traffic so the network between you and your resolver cannot read or tamper with them. It protects the confidentiality and integrity of your lookups on the local path. It does not hide your browsing from the resolver you send queries to, and it does not authenticate the answers about a domain the way DNSSEC does. For the full concept, the guide on encrypted DNS compares DoH and DNS over TLS.
The key practical risk is fallback. When a browser or OS cannot reach its DoH server, many configurations silently revert to plaintext DNS so that browsing keeps working. That is convenient and dangerous: you lose the protection without any warning. Testing is how you catch it.
Browser DoH versus operating system DoH
| Aspect | Browser-level DoH | OS-level DoH |
|---|---|---|
| Scope | Only that browser's traffic | Every app on the device |
| Where you set it | Browser security settings | Operating system network settings |
| Other apps protected | No | Yes |
| Common fallback behavior | Reverts to system resolver | Reverts to plaintext on the network |
| Easiest way to verify | Resolver test page plus network capture | Resolver test page plus network capture |
Because the two operate at different layers, enabling DoH in your browser does nothing for your email client or any other application. If you want device-wide protection, configure it at the OS level and test there too.
How to test DoH step by step
- Identify your intended DoH resolver. Know which provider you configured, so you can confirm your queries are actually reaching it rather than your ISP's default resolver.
- Visit your resolver's connection test page. Most DoH providers publish a page that reports whether your current queries arrived over their encrypted endpoint.
- Check the resolver identity. Confirm the resolver answering you is the one you chose. If it reports your ISP instead, DoH is not in effect.
- Watch the network for plaintext DNS. A packet capture should show HTTPS to your resolver and no plaintext queries on port 53. Any port 53 traffic to a DNS server means something is bypassing DoH.
- Force a failure to test fallback. Temporarily block the DoH endpoint and see whether lookups stop (good, no silent downgrade) or keep working over plaintext (a silent fallback you should harden against).
To see which public IP and resolver the wider internet associates with you during the test, the Valla what is my IP tool gives you a quick, neutral reference point to compare against your resolver's report.
Signals that prove DoH is active
Three signals together give confidence. First, your resolver's own test page confirms queries arrived over its encrypted endpoint. Second, a network capture shows HTTPS to the resolver and an absence of plaintext port 53 queries. Third, the resolver identity matches the provider you configured rather than your ISP. Any one signal alone can mislead, so look for all three.
Catching and preventing silent fallback
Silent fallback is the main reason DoH appears to work but does not protect you. In strict or secure modes, a browser or OS refuses to downgrade: if the encrypted path fails, lookups fail rather than revert to plaintext. That is the setting you want when privacy matters, because it turns an invisible failure into a visible one you can fix. The tradeoff is that a flaky DoH endpoint will break browsing instead of limping along. Choose a reliable resolver, then enable the strict mode so you are never silently unprotected. Re-test after any network change, because captive portals and some corporate networks actively block DoH.
Frequently asked questions
How do I check if DNS over HTTPS is working?
Visit your DoH provider's connection test page to confirm your queries arrived encrypted, verify the resolver identity matches the one you configured, and run a network capture to confirm there is no plaintext port 53 traffic. All three signals together confirm DoH is active.
Why does DoH look enabled but my queries are still in plaintext?
This is silent fallback. When the encrypted endpoint is unreachable, many browsers and operating systems revert to plaintext DNS so browsing keeps working. Enabling a strict or secure mode makes lookups fail instead of downgrading silently.
Does enabling DoH in my browser protect my whole computer?
No. Browser-level DoH covers only that browser's traffic. Email clients, updaters, and other apps still use the system resolver. For device-wide protection you must enable DoH at the operating system level and test it separately.
Can my network block DNS over HTTPS?
Yes. Captive portals, some corporate networks, and certain ISPs block known DoH endpoints to enforce their own DNS. When that happens, a strict configuration fails lookups while a permissive one falls back to plaintext, which is why testing after a network change matters.
Is DoH the same as using a VPN for DNS privacy?
No. DoH encrypts only your DNS lookups between you and the resolver. A VPN tunnels all traffic through a remote server. They solve overlapping but different problems, and DoH does not hide the rest of your connection the way a VPN aims to.
Want a quick reference point while you test? Open the Valla what is my IP tool to see the public address and resolver the internet sees for you.