The Scenario
You open Chrome, type a URL, and get hit with:
This site can't be reached.
example.com's server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN
The domain doesn't resolve. Four likely culprits: stale DNS cache, broken DNS server, the domain genuinely doesn't exist, or a rogue /etc/hosts entry is overriding it. Let's figure out which one.
Quick Analysis
NXDOMAIN stands for Non-Existent Domain — your DNS resolver returned a hard "this domain does not exist" response. First, verify the problem is actually on your end, not the site itself:
# Linux / macOS
nslookup example.com 8.8.8.8
# Windows (PowerShell)
Resolve-DnsName example.com -Server 8.8.8.8
If that resolves fine but the browser still fails, the problem is local — your system's DNS cache or config. If nslookup also returns NXDOMAIN, the domain might be down, or your DNS server is lying to you.
Quick sanity check: pull out your phone, switch to mobile data, and try the URL. Loads fine? The issue is on your machine or local network, not the site.
Fix 1 — Flush Your DNS Cache
Stale cache is the most common culprit. DNS records carry a TTL (time-to-live) — typically 300 to 86400 seconds. If your system cached an old NXDOMAIN response, it keeps serving that bad answer until the TTL expires or you flush it manually.
Windows
ipconfig /flushdns
macOS
# macOS 12+ (Monterey and later)
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
Linux (systemd-resolved)
sudo systemd-resolve --flush-caches
# Verify
sudo systemd-resolve --statistics | grep "Current Cache Size"
Chrome internal DNS cache
Chrome maintains its own DNS cache, completely separate from the OS. Open a new tab and visit:
chrome://net-internals/#dns
Click Clear host cache. Then head to chrome://net-internals/#sockets and click Flush socket pools. Both steps matter — skipping the socket flush sometimes leaves Chrome stuck.
Fix 2 — Switch to a Reliable DNS Server
Your ISP's DNS can drop queries, return wrong answers, or just be slow. Switching to Cloudflare (1.1.1.1) or Google (8.8.8.8) takes two minutes and often fixes the problem immediately.
Windows
# Find your adapter name first
Get-NetAdapter
# Set DNS (replace "Wi-Fi" with your adapter name)
Set-DnsClientServerAddress -InterfaceAlias "Wi-Fi" -ServerAddresses ("1.1.1.1", "8.8.8.8")
macOS
System Settings → Network → your connection → Details → DNS → add 1.1.1.1 and 8.8.8.8, then remove the old ISP entries.
Linux (NetworkManager)
# Check current connection name
nmcli connection show
# Set DNS
nmcli connection modify "Your-Connection-Name" ipv4.dns "1.1.1.1 8.8.8.8"
nmcli connection up "Your-Connection-Name"
Linux (/etc/resolv.conf)
sudo nano /etc/resolv.conf
# Add or replace nameserver lines:
nameserver 1.1.1.1
nameserver 8.8.8.8
On systems running systemd-resolved, resolv.conf is a symlink — edits won't stick. Edit /etc/systemd/resolved.conf instead, then run sudo systemctl restart systemd-resolved.
Fix 3 — Check the Hosts File
The hosts file overrides DNS entirely. A bad entry here means no amount of DNS flushing will help. Dev machines are especially prone to this — Docker projects, tools like Laravel Valet, and local SSL configs all tend to add entries to this file.
Windows
notepad C:\Windows\System32\drivers\etc\hosts
macOS / Linux
cat /etc/hosts
Look for any line referencing the domain you're trying to reach. Entries like these will block it:
0.0.0.0 example.com
127.0.0.1 example.com
Comment out the offending line by adding # at the start, save the file, then flush DNS again.
Fix 4 — Renew DHCP Lease
Your router hands out DNS server addresses via DHCP. If that lease goes stale or the router pushed a wrong address, your system ends up querying a DNS server that doesn't work.
Windows
ipconfig /release
ipconfig /renew
macOS / Linux
# Disable and re-enable the network interface
sudo ifconfig en0 down && sudo ifconfig en0 up
# Or via NetworkManager
nmcli networking off && nmcli networking on
Fix 5 — Check VPN or Proxy
VPN clients push their own DNS servers. When the VPN is half-connected or glitching, DNS queries fail silently — no error, just NXDOMAIN for everything. Disconnect the VPN, test the URL, then reconnect. Works without VPN? The issue is your VPN's DNS config, not your system.
For proxy issues: in Chrome, go to Settings → System → Open your computer's proxy settings. On Windows this lands in Internet Properties → Connections → LAN Settings. Make sure nothing is configured there that shouldn't be — a leftover proxy entry from a previous work setup is a surprisingly common cause.
Verification
Before testing in the browser, confirm DNS resolution is actually working at the system level:
# Confirm the domain resolves
nslookup example.com
# Or with dig (Linux/macOS)
dig example.com +short
# Trace the full DNS resolution path
dig example.com +trace
You should see an IP address come back. If the DNS lookup succeeds but the browser still shows NXDOMAIN, hit Ctrl+Shift+R (or Cmd+Shift+R on Mac) to hard-refresh and bypass the browser cache.
If None of the Above Works
At this point, the domain itself may not exist or may have expired. Check whether it has valid DNS records at all:
# Check if the domain has NS records
dig NS example.com @8.8.8.8
# Check WHOIS to confirm registration
whois example.com
No NS records and WHOIS shows unregistered or expired? That's not on you — the site is simply gone.
Prevention
Set 1.1.1.1 and 8.8.8.8 at the router level rather than per machine. Every device on your network benefits automatically, and you won't have to repeat this fix every time a new device joins.
If you're working with static IPs, custom subnets, or local DNS setups, the Subnet Calculator on ToolCraft is useful for verifying CIDR ranges and confirming your DNS server IPs actually fall within the right subnet — I've caught misconfigurations this way before.