ToggleHosts
Buy ToggleHosts
Hosts File Not Working After Edit on Mac (2026 Fix Guide)

Hosts File Not Working After Edit on Mac (2026 Fix Guide)

Updated 10 min read

Hosts file not working after edit on Mac? Fix DNS cache, browser cache, permissions, syntax errors, and VPN overrides — with flush commands and a GUI path.

Manage hosts files without the terminal

ToggleHosts helps you manage environments visually on Windows, macOS, and Linux, with automatic DNS flush and backups.

Direct answer: If your hosts file is not working after an edit on Mac, the file often saved correctly — but DNS cache, browser host cache, permissions, or a VPN/DNS blocker still serves the old IP. Flush DNS, hard-refresh the browser, verify /etc/hosts syntax, then rule out AdGuard/NextDNS/WARP/MagicDNS.

You've edited /etc/hosts, the line looks right, and the domain still opens production (or fails entirely). That after-edit failure is one of the most common Mac developer traps.

Why is my hosts file not working after edit on Mac?

If hosts changes aren't taking effect on Mac, start with stale DNS cache. Run:

BASH
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

Then confirm each line is IP<space>hostname (no http://, paths, or ports), clear the browser DNS cache, and disable any VPN that overrides DNS.

Version-specific flush guides: Sequoia · Sonoma · Tahoe · hub: Flush DNS on Mac.

On Windows or Linux? See /etc/hosts not working on Windows, Mac and Linux. Prefer a GUI apply+flush loop? See edit hosts without Terminal or ToggleHosts.

Understanding how the hosts file works

Before diving into troubleshooting, it's essential to understand the DNS resolution hierarchy on macOS. When your Mac tries to resolve a domain name, it checks in this order:

  1. Hosts file (/etc/hosts) - checked first
  2. DNS cache - macOS caches previous DNS lookups
  3. DNS servers - configured via Network settings or DHCP

If your hosts file entry isn't working, something in this chain is likely interfering. Let's identify and fix each potential issue.

Issue #1: DNS cache not flushed (most common)

This is by far the most common reason hosts file changes don't work. macOS aggressively caches DNS lookups to improve performance, but this means your hosts file changes won't take effect until the cache is cleared.

Why DNS cache matters

When you first visit a domain, macOS stores the resolved IP address in its DNS cache. Subsequent requests use this cached value instead of checking the hosts file again. This is why your changes seem to be ignored.

Solution: Flush DNS cache

For macOS Sierra and later:

BASH
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder

For macOS versions before Sierra:

BASH
sudo killall -HUP mDNSResponder

For macOS Big Sur and later (additional step):

BASH
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
sudo killall mDNSResponderHelper

Verify DNS cache flush

After running the command, verify it worked:

BASH
ping yourdomain.local

You should see it resolving to the IP address specified in your hosts file.

Sources and further reading

Also readComplete DNS cache flush guide for all macOS versions

Issue #2: Browser DNS cache

Even after flushing system DNS cache, browsers maintain their own separate DNS cache. This is why your hosts file might work in Terminal (ping, curl) but not in your browser.

Chrome/Chromium browsers

  1. Open chrome://net-internals/#dns in the address bar
  2. Click "Clear host cache"
  3. Close and restart Chrome completely

Alternatively, restart Chrome with cache disabled:

BASH
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --dns-prefetch-disable

Firefox

  1. Open about:networking#dns in the address bar
  2. Click "Clear DNS Cache"
  3. Restart Firefox

Safari

Safari uses the system DNS cache, so flushing system DNS should be sufficient. However, if issues persist:

  1. Safari menu > Preferences > Advanced
  2. Check "Show Develop menu"
  3. Develop menu > Empty Caches
  4. Restart Safari

Edge and other Chromium browsers

Follow the same steps as Chrome, using edge://net-internals/#dns for Edge.

Issue #3: File permissions

Incorrect file permissions can cause macOS to ignore the hosts file entirely. The hosts file must have specific ownership and permissions to function correctly.

Check current permissions

BASH
ls -la /etc/hosts

You should see something like:

-rw-r--r--  1 root  wheel  1234 Feb  6 10:30 /etc/hosts

Correct permissions

  • Owner: root
  • Group: wheel
  • Permissions: 644 (rw-r--r--)

Fix permissions

If permissions are incorrect:

BASH
sudo chmod 644 /etc/hosts
sudo chown root:wheel /etc/hosts

Verify permissions fix

After fixing permissions, flush DNS cache again and test:

BASH
sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder
ping yourdomain.local

Issue #4: Syntax errors

Even a small syntax error can prevent the entire hosts file from working correctly. macOS is strict about hosts file format.

Correct format

Each entry must follow this exact format:

BASH
IP_ADDRESS    DOMAIN_NAME
  • Use a single tab or multiple spaces between IP and domain
  • Each entry on a single line
  • No trailing spaces
  • Comments start with #

Common syntax mistakes

Wrong: Multiple domains on one line

BASH
# ❌ Wrong
127.0.0.1    domain1.com domain2.com

Correct: One domain per line

BASH
# ✅ Correct
127.0.0.1    domain1.com
127.0.0.1    domain2.com

Wrong: Missing separator

BASH
# ❌ Wrong
127.0.0.1domain.com

Correct: Tab or spaces

BASH
# ✅ Correct
127.0.0.1    domain.com

Wrong: Extra spaces

BASH
# ❌ Wrong
127.0.0.1     domain.com   

Correct: Clean format

BASH
# ✅ Correct
127.0.0.1    domain.com

Validate syntax

Check your hosts file for syntax errors:

BASH
cat /etc/hosts | grep -v "^#" | grep -v "^$" | awk '{print $1, $2}'

This shows all active entries. Each line should have exactly two fields: IP and domain.

Issue #5: File encoding problems

The hosts file must be in UTF-8 encoding without BOM (Byte Order Mark). Some text editors save files with incorrect encoding, which can cause macOS to ignore entries.

Check encoding

BASH
file /etc/hosts

Should show: ASCII text or UTF-8 Unicode text

Fix encoding issues

If encoding is wrong, recreate the file:

BASH
# Backup first
sudo cp /etc/hosts /etc/hosts.backup

# Edit and save as UTF-8 without BOM
sudo nano /etc/hosts

When saving in nano, ensure you're not adding any special characters. For GUI editors, check encoding settings before saving.

Issue #6: System Integrity Protection (SIP)

While SIP shouldn't prevent hosts file edits, it can interfere in rare cases. SIP protects system files, but the hosts file is designed to be editable.

Check SIP status

BASH
csrutil status

If SIP is enabled (normal), it shouldn't affect hosts file functionality. Only disable SIP if absolutely necessary and you understand the security implications.

Issue #7: Network location or VPN interference

Sometimes network configurations or VPNs can override hosts file entries by using their own DNS servers.

Check active DNS servers

BASH
scutil --dns | grep nameserver

VPN DNS override

If you're using a VPN, it might be routing DNS queries through VPN servers, bypassing the hosts file. Try:

  1. Disconnect VPN temporarily
  2. Flush DNS cache
  3. Test hosts file entries
  4. If it works, configure VPN to use local DNS

Network location

macOS Network Locations can have different DNS settings:

  1. Apple menu > System Preferences > Network
  2. Location dropdown (if multiple locations exist)
  3. Check DNS settings for each location

Issue #8: IPv6 vs IPv4 conflicts

If you're only adding IPv4 entries but your system prefers IPv6, resolution might fail or use the wrong address.

Add IPv6 entries

For localhost entries, include both IPv4 and IPv6:

BASH
127.0.0.1       yourdomain.local
::1             yourdomain.local

Disable IPv6 (if needed)

If you want to force IPv4 only:

BASH
networksetup -setv6off Wi-Fi
networksetup -setv6off Ethernet

Re-enable with:

BASH
networksetup -setv6automatic Wi-Fi
networksetup -setv6automatic Ethernet

Issue #9: mDNSResponder not responding

The mDNSResponder daemon handles DNS resolution on macOS. If it's not working correctly, hosts file changes won't take effect.

Restart mDNSResponder

BASH
sudo killall mDNSResponder
sudo killall mDNSResponderHelper

The system will automatically restart these services.

Check mDNSResponder status

BASH
ps aux | grep mDNSResponder

You should see the process running.

Complete troubleshooting checklist

Follow this checklist in order:

  1. Verify hosts file syntax - Check for errors
  2. Check file permissions - Should be 644, owned by root:wheel
  3. Flush DNS cache - Run the flush command for your macOS version
  4. Restart browser - Close completely and reopen
  5. Clear browser DNS cache - Use browser-specific methods
  6. Test with Terminal - Use ping or curl to verify
  7. Check for VPN interference - Disconnect VPN if active
  8. Verify encoding - Ensure UTF-8 without BOM
  9. Restart mDNSResponder - If all else fails
  10. Check network location - Verify DNS settings

Testing your hosts file

After applying fixes, test systematically:

Step 1: Terminal test

BASH
ping -c 3 yourdomain.local

Should show your hosts file IP address.

Step 2: DNS lookup test

BASH
dscacheutil -q host -a name yourdomain.local

Should return your hosts file IP.

Step 3: Browser test

  1. Clear browser cache completely
  2. Open in incognito/private mode
  3. Navigate to your domain
  4. Check browser developer tools Network tab for resolved IP

Step 4: curl test

BASH
curl -v http://yourdomain.local

Check the resolved IP address in the output.

Prevention: Best practices

To avoid hosts file issues in the future:

Use a GUI tool

GUI applications like ToggleHosts automatically handle:

  • Syntax validation
  • Permission management
  • DNS cache flushing
  • Backup creation
  • Encoding verification

Regular backups

Always backup before editing:

BASH
sudo cp /etc/hosts /etc/hosts.backup.$(date +%Y%m%d)

Test incrementally

Add one entry at a time and test immediately. This makes it easier to identify problematic entries.

Document entries

Use comments to document your entries:

BASH
# Local development - Project Alpha
127.0.0.1    alpha.local
127.0.0.1    api.alpha.local

# Local development - Project Beta
127.0.0.1    beta.local

Advanced: Debugging DNS resolution

For persistent issues, enable detailed DNS logging:

BASH
sudo log config --subsystem com.apple.network.dns --mode level:debug

Then check logs:

BASH
log show --predicate 'subsystem == "com.apple.network.dns"' --last 5m

This shows exactly how macOS is resolving domains.

When to seek help

If you've tried all troubleshooting steps and hosts file still isn't working:

  1. Check system logs - Look for DNS-related errors
  2. Try safe mode - Boot into safe mode and test
  3. Check for conflicting software - VPNs, firewalls, security software
  4. Verify macOS version - Some older versions have known DNS issues

Conclusion

Hosts file not working after editing is frustrating, but it's almost always fixable. The most common issues are DNS cache not being flushed and browser DNS cache. By following this guide systematically, you should be able to identify and resolve the problem.

Remember: flush DNS cache, restart browser, check syntax, verify permissions. These four steps solve 90% of hosts file issues.

For a hassle-free experience managing your hosts file with automatic validation, DNS flushing, and backup management, consider using ToggleHosts. At just 4.99 €, it eliminates the common pitfalls that cause hosts file problems and saves you time troubleshooting.

Ready to streamline your local development workflow? Start with our complete edit host file guide (Windows, Mac and Linux), Mac-specific tutorial, or hosts file reference guide.

Share this article

Frequently Asked Questions

Most often DNS cache still serves the old IP. Flush with sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder, hard-refresh the browser, then retest. Also check syntax, permissions, and VPN/DNS blockers.

Usually no. Flush DNS and restart or hard-refresh the browser first. Reboot only if a VPN or security agent keeps an old resolver state.

Run: sudo dscacheutil -flushcache && sudo killall -HUP mDNSResponder. Same command on Sequoia, Sonoma, and Tahoe — see the version guides linked in this article.

Browsers keep their own host cache. Clear chrome://net-internals/#dns (Chrome) or about:networking#dns (Firefox), or fully quit the browser after the system flush.

Yes. /etc/hosts should be owned by root:wheel with mode 644. Fix with sudo chmod 644 /etc/hosts && sudo chown root:wheel /etc/hosts, then re-edit with sudo.

Yes. A hosts file manager like ToggleHosts can Apply with backup and flush DNS so you do not repeat Terminal flush steps after every change.

Related Articles