ERR_NAME_NOT_RESOLVED on Mac: 8 quick fixes (2026)

"This site can't be reached", "ERR_NAME_NOT_RESOLVED", "DNS_PROBE_FINISHED_NXDOMAIN"... These error messages are frustrating, especially when the Internet works for other sites. This guide will help you resolve these DNS issues on Mac.

How to fix ERR_NAME_NOT_RESOLVED on Mac

To fix ERR_NAME_NOT_RESOLVED (or DNS_PROBE_FINISHED_NXDOMAIN) on Mac, flush the DNS cache with `sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder`, then reload the page. If it persists, switch to a public DNS (1.1.1.1 or 8.8.8.8), disable any VPN or proxy, and check that the domain is not blocked in /etc/hosts.

Work through the eight fixes below in order, from fastest to most thorough.

Understanding the error

What's happening?

When you type "google.com" in your browser: 1. Your Mac asks for google.com's IP address 2. DNS servers respond with the IP (e.g., 142.250.185.78) 3. Your browser connects to that IP

ERR_NAME_NOT_RESOLVED means step 2 failed.

Possible causes

• Corrupted or stale DNS cache
• Unreachable or slow DNS servers
• Misconfigured hosts file
• Problematic VPN or proxy
• Firewall blocking DNS requests
• The site is actually down
• Internet connection problem

Solution #1: Flush DNS cache

This is the quickest solution and resolves 50% of cases.

sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Test immediately by reloading the page.

Solution #2: Check the hosts file

A domain blocked in your hosts file will cause this error.

cat /etc/hosts | grep "problem-domain.com"

If the domain appears with 0.0.0.0 or 127.0.0.1, it's blocked.

Unblock the domain

sudo nano /etc/hosts

Delete or comment out (#) the concerned line, then flush DNS cache.

Solution #3: Change DNS servers

Your ISP's DNS may be slow or failing.

Recommended DNS

Cloudflare (fast, private)

• 1.1.1.1
• 1.0.0.1

Google (reliable)

• 8.8.8.8
• 8.8.4.4

Quad9 (secure)

• 9.9.9.9
• 149.112.112.112

Change DNS on Mac

1. System Settings > Network 2. Select your connection (Wi-Fi or Ethernet) 3. Details... > DNS 4. Remove existing servers, add new ones 5. Click OK

Via Terminal

# Show current DNS
scutil --dns | grep "nameserver"

# Configure Cloudflare DNS (Wi-Fi)
networksetup -setdnsservers Wi-Fi 1.1.1.1 1.0.0.1

Solution #4: Disable VPN/Proxy

VPNs change your DNS servers and can cause problems.

Quick test

1. Disconnect your VPN 2. Flush DNS cache 3. Test the site

If it works, the problem is the VPN. Contact their support or switch VPN servers.

Check proxies

System Settings > Network > Wi-Fi > Details... > Proxies

Disable any configured proxy to test.

Solution #5: Restart network services

Disable/re-enable Wi-Fi

Click Wi-Fi icon > Turn Wi-Fi Off > Wait 10 seconds > Turn back on

Via Terminal

# Restart mDNSResponder
sudo killall -HUP mDNSResponder

# Restart network interface
sudo ifconfig en0 down && sudo ifconfig en0 up

Solution #6: Check the firewall

Mac firewall or security applications can block DNS requests.

Check macOS firewall

System Settings > Network > Firewall

Temporarily disable to test.

Third-party applications

Little Snitch, Lulu, or antiviruses can block DNS. Check their rules.

Solution #7: Renew IP address

# Release current IP
sudo ipconfig set en0 DHCP

# Or force renewal
sudo ipconfig set en0 BOOTP && sudo ipconfig set en0 DHCP

Solution #8: Check if the site is down

Maybe the problem isn't on your end.

Verification tools

• downforeveryoneorjustme.com
• isitdown.site

Test from another device

Try accessing the site from your phone on cellular (not Wi-Fi).

Advanced diagnosis

Check DNS resolution

# With nslookup
nslookup google.com

# With dig
dig google.com

# With host
host google.com

Expected result: an IP address.

Test with a specific DNS

# Test with Cloudflare DNS
nslookup google.com 1.1.1.1

# Test with Google DNS
nslookup google.com 8.8.8.8

If it works with an external DNS but not yours, change your DNS.

Check Internet connection

# Ping Google DNS
ping -c 4 8.8.8.8

# Ping by name (tests DNS)
ping -c 4 google.com

If ping by IP works but not by name, it's a DNS problem.

Decision tree

Use this order when you need a fast diagnosis.

One website fails, other websites work

Likely causes:

• Site DNS is misconfigured.
• Your local DNS cache is stale.
• The domain is blocked in /etc/hosts.
• The browser has cached an old result.

Start with:

dscacheutil -q host -a name example.com
dig example.com
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

If Chrome is the only browser affected, clear Chrome DNS cache:

All websites fail by name, but IP addresses work

Likely causes:

• DNS server outage.
• VPN DNS issue.
• Router DNS problem.
• Firewall blocking port 53 or encrypted DNS.

Test:

ping -c 4 1.1.1.1
ping -c 4 google.com
scutil --dns | grep nameserver

If the IP ping works and domain ping fails, switch DNS servers temporarily.

Only local domains fail

Likely causes:

• Hosts file syntax issue.
• Wrong local server port.
• .local conflict with Bonjour.
• Missing IPv6 mapping.

Check:

cat /etc/hosts
dscacheutil -q host -a name myproject.test
curl -I http://myproject.test

For local projects, prefer .test over .local.

Common developer scenarios

After editing /etc/hosts

If you mapped a staging domain and Chrome still opens production, do this:

1. Confirm the hosts line. 2. Flush macOS DNS. 3. Clear Chrome DNS cache. 4. Test with curl -I. 5. Verify the web server accepts that hostname.

Example hosts line:

203.0.113.10 staging.example.com

After switching VPN

VPNs often push their own DNS servers. If the error appears only while the VPN is active:

• Disconnect and test again.
• Switch VPN region.
• Disable "use VPN DNS" if your provider allows it.
• Ask whether internal domains require split DNS.

After changing Wi-Fi networks

Captive portals, hotel Wi-Fi and office networks can hijack DNS. Test with another network or your phone hotspot. If the hotspot works, the problem is network-specific.

After installing security tools

Little Snitch, LuLu, antivirus tools and corporate endpoint agents can block DNS or browser traffic. Temporarily disable rules for the browser and resolver services to test.

Local development checklist

For local domains, verify each layer:

• Hosts entry exists.
• DNS cache is flushed.
• Browser DNS cache is clear.
• Local server is running.
• Server listens on the expected port.
• HTTPS certificate covers the hostname.
• The app router accepts the hostname.

If the issue appears after adding HTTPS locally, read the mkcert certificate error guide.

When the site is actually down

Sometimes your Mac is fine. If dig returns no records from multiple public DNS providers, the domain itself may be misconfigured.

Test with:

dig example.com @1.1.1.1
dig example.com @8.8.8.8
dig example.com @9.9.9.9

If all providers return NXDOMAIN, the domain does not resolve publicly. If only one provider fails, it may be DNS propagation or resolver-specific caching.

Similar errors

Prevention

Use reliable DNS

Configure Cloudflare (1.1.1.1) or Google (8.8.8.8) as primary DNS.

Avoid bulky hosts files

Too many entries can slow resolution. Use a tool like Locahl to manage cleanly.

Restart regularly

An occasional restart clears caches and resolves latent issues.

Conclusion

The ERR_NAME_NOT_RESOLVED error is almost always related to DNS cache or configured DNS servers. In 90% of cases, flushing DNS cache or changing DNS servers solves the problem.

If the problem persists on only one site, the site itself is probably the cause.