Question Adguard DNS is extremely slow today

Please provide comments and solutions that are helpful to the author of this topic.
Divine_Barakah

Divine_Barakah

Level 41
Thread author
Verified
Top Poster
Well-known
Forum Veteran
May 10, 2019
3,073
12,711
3,969
Gaza Strip
As the title says, today I have been experiencing extreme slow down (especially in browsing speed ) when Adguard DNS is activated.

I am using Adguard DNS over HTTPs in Win11 settings. Disabling adguard DNS fixes the issue.
 
  • Like
Reactions: Khushal and Parkinsond
Divine_Barakah said:
@Bot is there a way to ping Adguard DNS?
Click to expand...
You can *ICMP ping* AdGuard’s IPs/hostname, but that doesn’t really “ping DoH DNS” in a meaningful way (DoH is DNS over HTTPS on port 443, and Windows is sending HTTPS requests, not ICMP). The best way is to test:

1) basic reachability (ICMP ping)
2) HTTPS reachability (TCP 443)
3) actual DNS query latency (real DNS lookups)

1) ICMP ping (basic reachability / packet loss)
If you’re using AdGuard Public DNS, you can ping the resolver IPs (this only checks network reachability):

  • Default AdGuard DNS: 94.140.14.14 and 94.140.15.15
  • Family: 94.140.14.15 and 94.140.15.16

In Windows Terminal / CMD:
  • ping 94.140.14.14
  • ping 94.140.15.15

If you’re on IPv6, also test IPv6 (if configured on your system). If ping shows loss/high latency, you’ve found a likely network routing issue to the anycast node you’re hitting.

2) Test DoH connectivity properly (TCP 443)
This is closer to what DoH actually needs (HTTPS on port 443):

In PowerShell:
  • Test-NetConnection dns.adguard-dns.com -Port 443
  • Test-NetConnection 94.140.14.14 -Port 443

If this is slow/failing/intermittent while your normal browsing is fine, something on-path (ISP, VPN, firewall, HTTPS inspection, etc.) may be interfering with that specific destination.

3) “Real” DNS latency test (recommended)
This measures how quickly the resolver answers actual DNS queries (much more useful than ping).

PowerShell examples:
  • Resolve-DnsName example.com -Server 94.140.14.14
  • Resolve-DnsName cloudflare.com -Server 94.140.14.14

To time it:
  • Measure-Command { Resolve-DnsName example.com -Server 94.140.14.14 | Out-Null }

Run it a few times and compare against another resolver (e.g., your ISP DNS, Cloudflare 1.1.1.1, Google 8.8.8.8). If AdGuard is consistently much slower, it’s either routing to a distant anycast node, or there’s network interference.

If browsing is “extremely slow” only when AdGuard DoH is enabled
A few common culprits to check (low-risk first):

  • Try a different AdGuard endpoint (Default vs Family vs Non-filtering) or temporarily switch from DoH to plain DNS just to isolate “DoH-specific” problems.
  • Check IPv6: sometimes Windows prefers a problematic IPv6 path. As a test, disable IPv6 temporarily (or ensure your IPv6 DNS is set correctly) and re-test.
  • VPN / security software / firewall: some products inspect/redirect DNS or interfere with DoH over 443.
  • MTU / fragmentation issues: can cause “web feels slow” symptoms with HTTPS-based services.

If you tell me which exact AdGuard DNS profile you selected in Windows (Default/Family/Non-filtering) and whether you’re on IPv6 or using a VPN, I can suggest the most targeted next test steps.
 
Bot said:
You can *ICMP ping* AdGuard’s IPs/hostname, but that doesn’t really “ping DoH DNS” in a meaningful way (DoH is DNS over HTTPS on port 443, and Windows is sending HTTPS requests, not ICMP). The best way is to test:

1) basic reachability (ICMP ping)
2) HTTPS reachability (TCP 443)
3) actual DNS query latency (real DNS lookups)

1) ICMP ping (basic reachability / packet loss)
If you’re using AdGuard Public DNS, you can ping the resolver IPs (this only checks network reachability):

  • Default AdGuard DNS: 94.140.14.14 and 94.140.15.15
  • Family: 94.140.14.15 and 94.140.15.16

In Windows Terminal / CMD:
  • ping 94.140.14.14
  • ping 94.140.15.15

If you’re on IPv6, also test IPv6 (if configured on your system). If ping shows loss/high latency, you’ve found a likely network routing issue to the anycast node you’re hitting.

2) Test DoH connectivity properly (TCP 443)
This is closer to what DoH actually needs (HTTPS on port 443):

In PowerShell:
  • Test-NetConnection dns.adguard-dns.com -Port 443
  • Test-NetConnection 94.140.14.14 -Port 443

If this is slow/failing/intermittent while your normal browsing is fine, something on-path (ISP, VPN, firewall, HTTPS inspection, etc.) may be interfering with that specific destination.

3) “Real” DNS latency test (recommended)
This measures how quickly the resolver answers actual DNS queries (much more useful than ping).

PowerShell examples:
  • Resolve-DnsName example.com -Server 94.140.14.14
  • Resolve-DnsName cloudflare.com -Server 94.140.14.14

To time it:
  • Measure-Command { Resolve-DnsName example.com -Server 94.140.14.14 | Out-Null }

Run it a few times and compare against another resolver (e.g., your ISP DNS, Cloudflare 1.1.1.1, Google 8.8.8.8). If AdGuard is consistently much slower, it’s either routing to a distant anycast node, or there’s network interference.

If browsing is “extremely slow” only when AdGuard DoH is enabled
A few common culprits to check (low-risk first):

  • Try a different AdGuard endpoint (Default vs Family vs Non-filtering) or temporarily switch from DoH to plain DNS just to isolate “DoH-specific” problems.
  • Check IPv6: sometimes Windows prefers a problematic IPv6 path. As a test, disable IPv6 temporarily (or ensure your IPv6 DNS is set correctly) and re-test.
  • VPN / security software / firewall: some products inspect/redirect DNS or interfere with DoH over 443.
  • MTU / fragmentation issues: can cause “web feels slow” symptoms with HTTPS-based services.

If you tell me which exact AdGuard DNS profile you selected in Windows (Default/Family/Non-filtering) and whether you’re on IPv6 or using a VPN, I can suggest the most targeted next test steps.
Click to expand...
Ran the recommended latency test against cloudflare com and the TTL ranged from 125 to 215
 
  • Like
Reactions: SeriousHoax and Khushal
Divine_Barakah said:
Ran the recommended latency test against cloudflare com and the TTL ranged from 125 to 215
Click to expand...
What you’re seeing there is almost certainly DNS record TTL (time-to-live), not “latency.”

TTL ≠ query speed
In `Resolve-DnsName`, the TTL value is how long that DNS answer may be cached (typically in seconds). A TTL of 125–215 just means the record you received had ~2–3.5 minutes of cache lifetime left (or you hit different records/CDN answers with different TTLs). It does not indicate how fast the DNS lookup was.

How to measure DNS lookup latency on Windows (simple + meaningful)

1) Clear your local DNS client cache (so you’re not measuring a cached answer):
Code: 
ipconfig /flushdns

2) Time the lookup (run several times and compare resolvers):
Code: 
Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.14.14 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 1.1.1.1 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 8.8.8.8 -DnsOnly -NoHostsFile | Out-Null }

Look at the TotalMilliseconds. That’s your practical “DNS latency” for that query.

If the slowdown only happens with DoH enabled
Since DoH is HTTPS, also test whether connectivity to the DoH endpoint is unstable (loss/routing issues), which can feel like “browsing is slow”:

  • Packet loss check (bigger sample)
    Code: 
    ping -n 50 94.140.14.14
  • Route/quality check
    Code: 
    pathping 94.140.14.14
  • Port 443 reachability (DoH depends on this)
    Code: 
    Test-NetConnection dns.adguard-dns.com -Port 443

Next step
Post the TotalMilliseconds results from the `Measure-Command` runs for AdGuard vs Cloudflare/Google (and say whether you were testing AdGuard or ControlD at that moment). With those numbers it’s usually obvious whether it’s (a) a slow resolver path, (b) intermittent loss, or (c) something local interfering with DoH.
 

AdGuard Status

Welcome to AdGuard's home for real-time and historical data on system performance.
status.adguard.com status.adguard.com
Divine_Barakah said:
As the title says, today I have been experiencing extreme slow down (especially in browsing speed ) when Adguard DNS is activated.
Click to expand...
Sadly, Adguard does not have it's own servers, so it might be caused by ISP in your area. Mine uses Germany ISP and it works just fine.

capture_12312025_184942.jpg
 
  • Like
  • Thanks
Reactions: SeriousHoax, Miravi, Khushal and 2 others
Bot said:
What you’re seeing there is almost certainly DNS record TTL (time-to-live), not “latency.”

TTL ≠ query speed
In `Resolve-DnsName`, the TTL value is how long that DNS answer may be cached (typically in seconds). A TTL of 125–215 just means the record you received had ~2–3.5 minutes of cache lifetime left (or you hit different records/CDN answers with different TTLs). It does not indicate how fast the DNS lookup was.

How to measure DNS lookup latency on Windows (simple + meaningful)

1) Clear your local DNS client cache (so you’re not measuring a cached answer):
Code: 
ipconfig /flushdns

2) Time the lookup (run several times and compare resolvers):
Code: 
Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.14.14 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 1.1.1.1 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 8.8.8.8 -DnsOnly -NoHostsFile | Out-Null }

Look at the TotalMilliseconds. That’s your practical “DNS latency” for that query.

If the slowdown only happens with DoH enabled
Since DoH is HTTPS, also test whether connectivity to the DoH endpoint is unstable (loss/routing issues), which can feel like “browsing is slow”:

  • Packet loss check (bigger sample)
    Code: 
    ping -n 50 94.140.14.14
  • Route/quality check
    Code: 
    pathping 94.140.14.14
  • Port 443 reachability (DoH depends on this)
    Code: 
    Test-NetConnection dns.adguard-dns.com -Port 443

Next step
Post the TotalMilliseconds results from the `Measure-Command` runs for AdGuard vs Cloudflare/Google (and say whether you were testing AdGuard or ControlD at that moment). With those numbers it’s usually obvious whether it’s (a) a slow resolver path, (b) intermittent loss, or (c) something local interfering with DoH.
Click to expand...
The total millisecs 385
 
  • Wow
  • Like
Reactions: Khushal and Parkinsond
Divine_Barakah said:
The total millisecs 385
Click to expand...
385 ms for a single DNS lookup is high and absolutely can translate into “web browsing feels broken/slow,” because a typical page load triggers multiple DNS lookups (especially with CDNs, ads/trackers being blocked, third‑party domains, etc.).

How to interpret 385 ms
  • In general, “good” DNS response time is often in the ~10–50 ms range if you’re reaching a nearby anycast node.
  • ~100 ms can still be usable.
  • 300+ ms repeatedly usually points to routing/peering issues, congestion, packet loss, or Windows having trouble reaching the DoH endpoint (sometimes via IPv6).

Do this next (to isolate the cause)

1) Compare against another resolver the same way
After `ipconfig /flushdns`, run:

Code: 
Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.14.14 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 1.1.1.1 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 8.8.8.8 -DnsOnly -NoHostsFile | Out-Null }

If AdGuard is ~385 ms while Cloudflare/Google are, say, 20–60 ms, then it’s almost certainly path/peering (ISP/region routing) rather than your browser.

2) Check for packet loss / bad route to the resolver
Code: 
ping -n 50 94.140.14.14
pathping 94.140.14.14

Any loss, or big latency jumps at certain hops, supports an ISP routing problem.

3) Rule out IPv6 weirdness (common with “only slow on encrypted DNS” symptoms)
  • If you have IPv6 enabled, test whether the issue disappears when IPv6 is temporarily disabled on the adapter (for testing only), or ensure the IPv6 DNS entries are set correctly too (not just IPv4).

Key takeaway
A consistent 385 ms DNS response time is enough to cause major browsing slowdowns; the most useful next step is posting your side-by-side timings (AdGuard vs 1.1.1.1/8.8.8.8) and whether `ping/pathping` shows loss. That will tell you quickly if it’s an ISP routing/peering issue or something local interfering with DoH.
 
Bot said:
385 ms for a single DNS lookup is high and absolutely can translate into “web browsing feels broken/slow,” because a typical page load triggers multiple DNS lookups (especially with CDNs, ads/trackers being blocked, third‑party domains, etc.).

How to interpret 385 ms
  • In general, “good” DNS response time is often in the ~10–50 ms range if you’re reaching a nearby anycast node.
  • ~100 ms can still be usable.
  • 300+ ms repeatedly usually points to routing/peering issues, congestion, packet loss, or Windows having trouble reaching the DoH endpoint (sometimes via IPv6).

Do this next (to isolate the cause)

1) Compare against another resolver the same way
After `ipconfig /flushdns`, run:

Code: 
Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.14.14 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 1.1.1.1 -DnsOnly -NoHostsFile | Out-Null }
Measure-Command { Resolve-DnsName cloudflare.com -Server 8.8.8.8 -DnsOnly -NoHostsFile | Out-Null }

If AdGuard is ~385 ms while Cloudflare/Google are, say, 20–60 ms, then it’s almost certainly path/peering (ISP/region routing) rather than your browser.

2) Check for packet loss / bad route to the resolver
Code: 
ping -n 50 94.140.14.14
pathping 94.140.14.14

Any loss, or big latency jumps at certain hops, supports an ISP routing problem.

3) Rule out IPv6 weirdness (common with “only slow on encrypted DNS” symptoms)
  • If you have IPv6 enabled, test whether the issue disappears when IPv6 is temporarily disabled on the adapter (for testing only), or ensure the IPv6 DNS entries are set correctly too (not just IPv4).

Key takeaway
A consistent 385 ms DNS response time is enough to cause major browsing slowdowns; the most useful next step is posting your side-by-side timings (AdGuard vs 1.1.1.1/8.8.8.8) and whether `ping/pathping` shows loss. That will tell you quickly if it’s an ISP routing/peering issue or something local interfering with DoH.
Click to expand...
Reran the test using 1.1.1.1 instead of Adguard DNS and the total millisecs 87
 
  • Like
Reactions: Khushal and Parkinsond
Divine_Barakah said:
Reran the test using 1.1.1.1 instead of Adguard DNS and the total millisecs 87
Click to expand...
That comparison is very telling: ~385 ms (AdGuard) vs ~87 ms (Cloudflare) strongly suggests the slowdown is path/peering to AdGuard from your network (or the specific anycast node you’re being routed to), not a general ISP “internet is slow” problem.

87 ms isn’t “amazing,” but it’s typically usable; 300–400 ms DNS lookups will noticeably drag browsing.

What to do next (low-risk, useful isolation)

  • Confirm it’s repeatable: run each test 5–10 times (flush DNS once beforehand), and note averages.
  • Check for loss/jitter to AdGuard:
    Code: 
    ping -n 50 94.140.14.14
pathping 94.140.14.14
    If you see packet loss or big jumps at certain hops, it supports a routing issue.
  • Try AdGuard’s other IP (same service):
    Code: 
    Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.15.15 -DnsOnly -NoHostsFile | Out-Null }
    If one IP is much better than the other, you may be hitting different anycast paths.
  • Check IPv6: if you have IPv6 enabled, make sure you’re not accidentally using a problematic IPv6 route/resolver. For testing, you can temporarily disable IPv6 on the adapter and re-run the measurements (then re-enable it).

Practical takeaway
Given the numbers, switching away from AdGuard (as you did to ControlD / or using 1.1.1.1) is a reasonable workaround until routing improves. If you want to pursue it, posting `pathping` results (with your public IP redacted) is usually enough for others to see where the latency is being introduced.
 
Bot said:
That comparison is very telling: ~385 ms (AdGuard) vs ~87 ms (Cloudflare) strongly suggests the slowdown is path/peering to AdGuard from your network (or the specific anycast node you’re being routed to), not a general ISP “internet is slow” problem.

87 ms isn’t “amazing,” but it’s typically usable; 300–400 ms DNS lookups will noticeably drag browsing.

What to do next (low-risk, useful isolation)

  • Confirm it’s repeatable: run each test 5–10 times (flush DNS once beforehand), and note averages.
  • Check for loss/jitter to AdGuard:
    Code: 
    ping -n 50 94.140.14.14
pathping 94.140.14.14
    If you see packet loss or big jumps at certain hops, it supports a routing issue.
  • Try AdGuard’s other IP (same service):
    Code: 
    Measure-Command { Resolve-DnsName cloudflare.com -Server 94.140.15.15 -DnsOnly -NoHostsFile | Out-Null }
    If one IP is much better than the other, you may be hitting different anycast paths.
  • Check IPv6: if you have IPv6 enabled, make sure you’re not accidentally using a problematic IPv6 route/resolver. For testing, you can temporarily disable IPv6 on the adapter and re-run the measurements (then re-enable it).

Practical takeaway
Given the numbers, switching away from AdGuard (as you did to ControlD / or using 1.1.1.1) is a reasonable workaround until routing improves. If you want to pursue it, posting `pathping` results (with your public IP redacted) is usually enough for others to see where the latency is being introduced.
Click to expand...
So it is Adguard DNS causing the slowdown. Ran the same test using NextDNS and the total millisecs are much lower than that of Adguard
 
  • Like
Reactions: Khushal and Parkinsond
Divine_Barakah said:
So it is Adguard DNS causing the slowdown. Ran the same test using NextDNS and the total millisecs are much lower than that of Adguard
Click to expand...
Yes—based on your measurements, it’s reasonable to conclude the slowdown is specifically tied to reaching AdGuard’s resolvers from your network (routing/peering/anycast node selection), not a general “your ISP is slow” problem.

Your numbers line up with that:
  • AdGuard: ~385 ms (problematic)
  • Cloudflare: ~87 ms (better)
  • NextDNS: lower than AdGuard (better)

That said, it’s usually not “AdGuard is bad globally,” but rather the path your ISP is taking to the AdGuard endpoint you’re landing on is currently suboptimal (or intermittently degraded).

What to do
  • Use the faster resolver for now (NextDNS / ControlD / 1.1.1.1). That’s the most practical fix.
  • Optional: confirm it’s routing by running:
    Code: 
    pathping 94.140.14.14
pathping 94.140.15.15
    If those show higher latency/loss compared to `pathping 1.1.1.1`, it supports the routing/peering explanation.
  • If you want AdGuard specifically, try the alternate AdGuard IP (94.140.15.15) or a different protocol/endpoint (sometimes DoH vs DoT behaves differently depending on the network), but only keep it if your timings improve.

Next step
If you post the `pathping` output to AdGuard vs Cloudflare (redact your public IP), the community can usually pinpoint whether the delay starts inside your ISP or farther upstream.
 
Parkinsond said:
If looking for the fastest in Egypt, it's Quad9, then Cloudflare, then Google, then the rest.
Click to expand...
I'm not looking for the fastest, but the slowdown caused by Adguard is so irritating. I mainly use private DNS for adblocking capability. It seems it is time to go back to NextDNS. So disappointed with Adguard.
 
  • Like
Reactions: Parkinsond and Khushal
Divine_Barakah said:
I'm not looking for the fastest, but the slowdown caused by Adguard is so irritating. I mainly use private DNS for adblocking capability. It seems it is time to go back to NextDNS. So disappointed with Adguard.
Click to expand...
NextDNS response is decent, equal to ControlD, with few night-time delays occasionally.
I have tried AG dns because of such delays, but it proved to be worst on the long-term.
 
  • Thanks
  • Like
Reactions: Divine_Barakah and Khushal

You may also like...