Trace the network path from your device to CleanBrowsing's DNS servers. Identify routing issues, ISP interception, and latency problems that affect DNS filtering.
When DNS filtering isn't working as expected, the problem isn't always DNS itself. Sometimes the issue is network routing — your queries may be taking an unexpected path, hitting the wrong server, or getting dropped entirely.
Traceroute maps the route that network packets take from your computer to a destination server. It lists every router (hop) along the way, along with the round-trip time to reach each one. This helps you see:
Before running a traceroute, you need to know which CleanBrowsing servers to test against:
| Filter | Primary (IPv4) | Secondary (IPv4) |
|---|---|---|
| Family | 185.228.168.168 |
185.228.169.168 |
| Adult | 185.228.168.10 |
185.228.169.11 |
| Security | 185.228.168.9 |
185.228.169.9 |
If you're using a paid plan with custom DNS IPs, use those instead.
Windows uses tracert (note: no "route" at the end). Open Command Prompt or PowerShell and run:
tracert 185.228.168.168You'll see output like this:
Tracing route to 185.228.168.168 over a maximum of 30 hops
1 1 ms 1 ms 1 ms 192.168.1.1
2 8 ms 7 ms 8 ms 10.0.0.1
3 12 ms 11 ms 12 ms 72.14.215.85
4 15 ms 14 ms 15 ms 108.170.252.1
5 18 ms 17 ms 18 ms 185.228.168.168
Trace complete.Each line is a hop. The three columns of millisecond values show the round-trip time for three separate probes. Lower numbers are better.
Asterisks (* * *) mean that hop didn't respond, which is common for routers configured to ignore traceroute packets — it doesn't necessarily indicate a problem.
On macOS and Linux, the command is traceroute:
traceroute 185.228.168.168The output format is similar to Windows. On macOS, you can also use the Network Utility app (Spotlight → "Network Utility" → Traceroute tab) for a graphical interface.
# Skip reverse DNS lookups (faster)
traceroute -n 185.228.168.168
# Send only one probe per hop (faster)
traceroute -n -q 1 185.228.168.168
# Use ICMP instead of UDP (matches Windows behavior)
sudo traceroute -I 185.228.168.168MTR (My Traceroute) combines traceroute and ping into a single tool that continuously updates. It's excellent for spotting intermittent packet loss that a single traceroute might miss.
# Linux (Debian/Ubuntu)
sudo apt install mtr
# Linux (CentOS/RHEL)
sudo yum install mtr
# macOS (Homebrew)
brew install mtrmtr 185.228.168.168On Windows, download WinMTR for the same functionality with a graphical interface.
MTR shows you packet loss percentage and jitter at each hop in real time. Let it run for 30–60 seconds to get meaningful data. If you see consistent packet loss at a specific hop and all subsequent hops, that's likely the source of the problem.
When analyzing traceroute results, focus on these scenarios:
The final hop shows 185.228.168.x or 185.228.169.x. Your network can reach CleanBrowsing. If DNS filtering still isn't working, the issue is likely configuration, not routing. Check your DNS configuration.
If the trace ends with * * * at every hop after a certain point, something is blocking the connection. This could be a firewall, your ISP intercepting DNS traffic on port 53, or a network policy. Consider switching to DNS over HTTPS (DoH) or DNS over TLS (DoT) to bypass this.
If one hop shows significantly higher latency (e.g., 200ms when surrounding hops are 15ms), that router is a bottleneck. If it's within your local network (first 1–2 hops), check your router or modem. If it's further out, it's likely your ISP's infrastructure.
Some ISPs intercept DNS queries on port 53 and redirect them to their own servers (transparent DNS proxying). If your traceroute to 185.228.168.168 arrives at an IP that doesn't belong to CleanBrowsing, your ISP may be doing this. The solution is encrypted DNS — DoH or DoT — which ISPs cannot intercept.
Run a DNS leak test first. If your ISP's DNS appears instead of CleanBrowsing, your DNS configuration isn't sticking. Check your device, router, or DHCP settings. Traceroute can confirm whether CleanBrowsing is reachable from your network at all.
Run tracert 185.228.168.168 and look at the latency at each hop. CleanBrowsing uses Anycast routing, so your queries should be routed to the nearest server. If you're seeing high latency (50ms+), the issue may be your ISP's routing, not CleanBrowsing.
Run traceroute from each device. If one device can reach 185.228.168.168 and another can't, the problem is device-specific — check for VPN software, proxy settings, or per-device DNS overrides (common in browsers with built-in DoH settings).
Run traceroute and compare with what you'd expect. If the route suddenly changes or stops, your ISP may have changed their routing, or a network device configuration changed. Run MTR for 60 seconds to check for intermittent issues.
If you need help troubleshooting, share the following with our support team at support@cleanbrowsing.org:
This gives us everything we need to diagnose routing and DNS issues quickly.
Traceroute tells you about routing, but it's most useful alongside other DNS diagnostic tools:
ping 185.228.168.168