DEV Community: Locahl

Fix Permission denied when editing /etc/hosts

Locahl — Thu, 16 Jul 2026 22:38:26 +0000

You open the hosts file, change one line, hit save, and get Permission denied.

That is normal. The system hosts file is protected on purpose.

Why it happens

On macOS and Linux, /etc/hosts is owned by root.

On Windows, C:\Windows\System32\drivers\etc\hosts needs Administrator rights.

A normal editor process cannot overwrite it.

macOS / Linux fix

Edit with elevated rights:

sudo nano /etc/hosts

Or open your editor as root:

sudo code /etc/hosts
# or
sudo vim /etc/hosts

Safer pattern: edit a copy you own, then install it:

cp /etc/hosts ~/hosts.work
# edit ~/hosts.work
sudo cp /etc/hosts "/etc/hosts.bak.$(date +%Y%m%d-%H%M%S)"
sudo cp ~/hosts.work /etc/hosts

Then flush DNS.

Windows fix

Start Notepad as Administrator
File → Open
Go to C:\Windows\System32\drivers\etc\
Set the filter to All Files
Open hosts
Save

If Notepad was not elevated, Windows often lets you open the file and then fails on save.

PowerShell alternative:

Start-Process notepad C:\Windows\System32\drivers\etc\hosts -Verb RunAs

Then:

ipconfig /flushdns

"I can edit but nothing changes"

That is a different bug:

you saved a copy in Downloads / Desktop
the line is still commented with #
DNS cache was not flushed
another line for the same hostname wins

Verify the live file:

grep -n "myapp.test" /etc/hosts

Avoid fighting permissions every day

Keep project hosts snippets in your repo or home folder. Copy them into place with one sudo command when needed.

That keeps the protected system file boring, and your editable copy easy to version.

Quick recovery if you break hosts

You should still be able to reach the machine by IP and local loopback. Restore from your backup:

sudo cp /etc/hosts.bak.YYYYMMDD-HHMMSS /etc/hosts

If you did not make a backup, most OS installs still have a minimal localhost block you can recreate. Do that before you go hunting for network bugs.

If you switch hosts a lot, a small desktop manager helps keep profiles and DNS flush in one place: Locahl.

DNS not updating after hosts file change? Fix it in order

Locahl — Thu, 16 Jul 2026 22:32:35 +0000

You edited the hosts file. The line looks correct. The browser still opens the old site.

Do not rewrite the hosts file again yet. Walk the stack in order.

1. Confirm the file that actually loaded

macOS / Linux:

grep -n "example.com" /etc/hosts

Windows (Admin PowerShell):

Select-String -Path C:\Windows\System32\drivers\etc\hosts -Pattern "example.com"

Check for:

a # commenting the line out
a second line for the same hostname later in the file
a typo in the hostname

If the terminal cannot see the line, the browser will not either.

2. Flush the OS DNS cache

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Windows (Admin):

ipconfig /flushdns

Linux with systemd-resolved:

sudo resolvectl flush-caches

3. Ask the OS, not the browser

# macOS / Linux
ping -c 1 example.com
getent hosts example.com

Windows:

ping example.com
nslookup example.com

If the terminal shows the wrong IP, stop. Fix hosts or flush again. Do not debug the app yet.

On some systems nslookup talks to a DNS server and can ignore hosts. Prefer ping / getent for hosts checks.

4. Clear browser DNS

Browsers cache names too.

Quit the browser fully (not just the tab)
Reopen and retry
Chrome: chrome://net-internals/#dns → Clear host cache
Try a private window once, to rule out extensions

5. Watch for HTTPS and HSTS traps

Hosts can point www.client.com at staging, while the browser still forces HTTPS and an old certificate story.

Symptoms:

certificate warnings
redirects back to production
cookies scoped to the real domain behaving oddly

For local-only work, prefer .test names. For cutover tests, expect TLS quirks and test with curl too:

curl -vI https://www.client.com

6. Docker and VPN layers

If the browser is on the host but the service is in Docker, your laptop hosts file may not be what the container uses.

If a VPN or corporate DNS is active, flush again after connect/disconnect. Some agents re-inject resolvers.

Short checklist

Line present and uncommented in the real hosts file
One active mapping per hostname
OS DNS flushed
Terminal resolves the expected IP
Browser DNS cleared
Only then debug the app, proxy, or TLS

Most "hosts is broken" reports die at step 3 or 4.

If you switch hosts a lot, a small desktop manager helps keep profiles and DNS flush in one place: Locahl.

Use a custom local domain instead of localhost:3000

Locahl — Thu, 16 Jul 2026 22:28:29 +0000

http://localhost:3000 works. It also breaks a few real-world checks early:

cookies scoped to a real-looking host
absolute URLs in emails and webhooks
multi-app setups (app, api, admin)
OAuth redirect allowlists that hate bare localhost quirks

A local hostname like myapp.test is often cleaner.

1. Add the hostname

In /etc/hosts (macOS/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows):

127.0.0.1   myapp.test
127.0.0.1   api.myapp.test

Prefer .test. It is reserved for testing. Avoid inventing fake .com names you might later need for real DNS.

Flush DNS after saving.

2. Point your app at it

Many stacks already bind 0.0.0.0 or 127.0.0.1. You only change the URL you open:

http://myapp.test:3000

If the framework reads HOST / APP_URL:

APP_URL=http://myapp.test:3000

Keep the port unless you put a reverse proxy in front.

3. Optional: drop the port with a proxy

Caddy example:

myapp.test {
  reverse_proxy localhost:3000
}

Then open http://myapp.test. Same idea with nginx or Traefik.

4. HTTPS locally

Some features need secure cookies or HTTPS redirects.

Options:

Caddy or mkcert for a local cert on myapp.test
Your framework's built-in HTTPS in development

Do not fight browser warnings with a public domain pointed at 127.0.0.1 unless you control that name.

5. Frontend and API on sibling hosts

127.0.0.1   app.myapp.test
127.0.0.1   api.myapp.test

Frontend on :3000, API on :4000. CORS and cookie domains become closer to production:

Domain=.myapp.test

That is often the whole reason to stop using plain localhost.

Checklist when it "does not work"

Hosts line exists and is not commented
DNS cache flushed
App is listening on the port you typed
You opened myapp.test, not localhost
Proxy config matches the hostname if you use one

Terminal check:

ping -c 1 myapp.test
# should show 127.0.0.1

When to skip this

Throwaway demos and single-file experiments are fine on localhost.

Reach for a custom local domain when cookies, redirects, or multiple services start fighting you. One hosts line usually ends the fight.

If you switch hosts a lot, a small desktop manager helps keep profiles and DNS flush in one place: Locahl.

How to block websites with the hosts file

Locahl — Thu, 16 Jul 2026 22:14:24 +0000

You can block a domain on your machine without installing another browser extension.

Point the hostname at a dead address in the hosts file. The OS resolves it locally and the site never loads.

This is blunt. It works for distraction sites, telemetry hosts you do not need, and quick local tests.

The pattern

0.0.0.0   www.example.com
0.0.0.0   example.com

0.0.0.0 is the usual choice. Some people use 127.0.0.1. Both stop the real site from loading. 0.0.0.0 avoids sending traffic to a local server you might already run.

Block both apex and www if the site uses both.

macOS and Linux

Edit hosts:

sudo nano /etc/hosts

Add your lines, save, then flush DNS:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux (systemd-resolved)
sudo resolvectl flush-caches

Windows

Open Notepad as Administrator, open:

C:\Windows\System32\drivers\etc\hosts

Add the same style of lines, save, then:

ipconfig /flushdns

Verify

ping -c 1 www.example.com

You should see 0.0.0.0 or a failed route, not the real public IP.

Browser still loading the site? Quit it fully and reopen. Chrome also has its own DNS cache under chrome://net-internals/#dns.

What this does not block

Apps that hardcode IPs
Sites reached through a VPN or proxy that ignores your hosts file
HTTPS hosts you only blocked under the wrong name (example.com vs www vs a CDN host)
Mobile apps on another device (hosts is local to that machine)

For team-wide or network-wide blocking you need DNS or firewall rules, not a laptop hosts file.

Keep it tidy

Group blocks under a comment:

# focus mode
0.0.0.0   www.reddit.com
0.0.0.0   reddit.com
0.0.0.0   www.youtube.com
0.0.0.0   youtube.com

When you need the site again, comment the lines or delete them and flush DNS.

Safety note

Do not block domains your OS or package manager needs unless you know what you are doing. A bad block looks like "the internet is broken" until you remember last night's edit.

Start with one domain, verify, then add more.

If you switch hosts a lot, a small desktop manager helps keep profiles and DNS flush in one place: Locahl.

Where is the hosts file on Mac, Windows, and Linux?

Locahl — Thu, 16 Jul 2026 22:01:29 +0000

You need to open the hosts file. You already know why. You just cannot remember the path.

Here it is for each OS, plus how to open it without fighting permissions.

Paths

OS	Path
macOS	`/etc/hosts`
Linux	`/etc/hosts`
Windows	`C:\Windows\System32\drivers\etc\hosts`

On Unix systems /etc/hosts is often a symlink into the real file. Edit the path above. Do not hunt for a second copy in your home folder.

Open it on macOS

Terminal:

sudo nano /etc/hosts

Or open it in your editor with elevated rights:

sudo code /etc/hosts
# or
sudo vim /etc/hosts

Save, then flush DNS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Finder will not let you edit /etc casually. Use the terminal or an editor launched with sudo.

Open it on Windows

Open Notepad as Administrator
File → Open
Go to C:\Windows\System32\drivers\etc\
Change the file type filter to All Files
Open hosts

Without admin rights Windows will open the file but refuse to save.

Then flush DNS:

ipconfig /flushdns

Open it on Linux

sudo nano /etc/hosts
# or
sudo vim /etc/hosts

Flush depends on the stack. Common options:

sudo resolvectl flush-caches
# or
sudo systemd-resolve --flush-caches

What a normal line looks like

127.0.0.1   localhost
127.0.0.1   myapp.test
# 203.0.113.10  staging.example.com

Rules that save time:

IP first, hostname second
Spaces or tabs both work
# comments out the rest of the line
One hostname per line is easier to read than a long list

Quick check after editing

# macOS / Linux
ping -c 1 myapp.test
# or
getent hosts myapp.test

Windows:

ping myapp.test

If the IP in the reply is wrong, the hosts line did not apply yet. Flush DNS and try again before changing the app.

Common mistakes

Editing a copy in Downloads instead of the system file
Saving without admin rights (Windows especially)
Leaving a # in front of the line you meant to enable
Forgetting the DNS flush
Using a real public TLD like .com for local names when .test would avoid surprises

Bookmark the path for your OS. You will need it again.

If you switch hosts a lot, a small desktop manager helps keep profiles and DNS flush in one place: Locahl.

How to switch local and staging domains with the hosts file

Locahl — Thu, 16 Jul 2026 21:53:52 +0000

You want shop.test on localhost during the day, then the real client domain pointed at staging, then maybe the same domain pointed at a new server before DNS moves.

You do not need dnsmasq for that. You need a clean way to switch mappings without leaving three conflicting lines in /etc/hosts.

Why one big hosts file fails

After a few months it often looks like this:

127.0.0.1   shop.test
127.0.0.1   api.shop.test
# 203.0.113.10  www.client.com
10.0.0.5    www.client.com
127.0.0.1   www.client.com

Same hostname, several intentions. The browser will not tell you which line won. It just resolves something.

Comments help for a day. They do not help when you are tired and switching contexts.

Use profiles instead of comments

Keep separate files. Only one is active at a time for a given hostname.

Example layout:

~/dev/hosts-profiles/
  local
  staging
  cutover

local

127.0.0.1   shop.test
127.0.0.1   api.shop.test
127.0.0.1   admin.shop.test

staging

203.0.113.40   www.client.com
203.0.113.40   api.client.com

cutover (pre-DNS migration test)

198.51.100.20   www.client.com
198.51.100.20   api.client.com

Apply a profile

macOS / Linux:

PROFILE=staging
sudo cp /etc/hosts "/etc/hosts.bak.$(date +%Y%m%d-%H%M%S)"
sudo cp ~/dev/hosts-profiles/$PROFILE /etc/hosts

Then flush DNS for your OS.

Windows: same idea. Keep profile files, back up the live hosts file, copy the profile over:

C:\Windows\System32\drivers\etc\hosts

Then:

ipconfig /flushdns

Small bash helper

#!/usr/bin/env bash
set -euo pipefail
PROFILE="${1:?usage: hosts-use <profile>}"
SRC="$HOME/dev/hosts-profiles/$PROFILE"
[[ -f "$SRC" ]] || { echo "missing $SRC"; exit 1; }

sudo cp /etc/hosts "/etc/hosts.bak.$(date +%Y%m%d-%H%M%S)"
sudo cp "$SRC" /etc/hosts

# macOS. Swap this block on Windows/Linux.
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
echo "Active hosts profile: $PROFILE"

Usage:

./hosts-use local
./hosts-use staging

Optional: base file + project overlay

If you want personal localhost names plus project-specific domains:

~/dev/hosts-profiles/
  _base
  project-shop-local
  project-shop-staging

Apply with:

cat ~/dev/hosts-profiles/_base \
    ~/dev/hosts-profiles/project-shop-staging \
  | sudo tee /etc/hosts >/dev/null

Keep _base small. Put production hostnames only in the project overlay so they are easy to turn off.

Pre-DNS cutover checklist

This is one of the best uses of hosts:

Put the production hostnames on the new server IP in a cutover profile
Apply the profile and flush DNS
Test login, cookies, HTTPS, redirects, anything that depends on the Host header
Switch back when you are done

Write the rollback next to the migration checklist. You will want it on cutover night.

Docker caveat

Hosts on your laptop affect the browser on your laptop.

Processes inside containers usually use Docker DNS, not your host /etc/hosts.

Browser to shop.test on the host: host hosts file
Container to another container: Compose service names or extra_hosts

Do not debug the wrong layer.

After every switch

# What does the OS resolve?
getent hosts www.client.com
# macOS alternative:
# dscacheutil -q host -a name www.client.com

# What is in the file?
grep -n "www.client.com" /etc/hosts

If the terminal IP is wrong, fix hosts first. Do not dig into the app yet.

When hosts profiles stop being enough

Move to dnsmasq, CoreDNS, or company DNS when you need:

lots of wildcards
many services added every week
one shared dynamic map for a whole team

Until then, separate profile files beat a single commented hosts file.

Start with three files

local for your .test domains
staging for client staging IPs
cutover left empty until migration week

Switch the whole file, flush DNS, verify in the terminal. That is the whole method.

How to edit /etc/hosts without breaking your local setup

Locahl — Thu, 16 Jul 2026 21:49:08 +0000

Most people open /etc/hosts, change one line, refresh the browser, and hope.

That works until it does not. Then you spend twenty minutes on Permission denied, a forgotten DNS flush, or a commented line from last week that is still active.

This is a simple workflow that keeps hosts edits boring.

What the hosts file does

When your machine resolves a name like myapp.test, it can use a local override before public DNS.

Common cases:

Point myapp.test to 127.0.0.1 for local work
Point a real domain at a staging IP before DNS cutover
Temporarily block a host with 0.0.0.0
Give services readable names instead of raw IPs

The idea is simple. The mess comes from how people edit and apply it.

A workflow that holds up

1. Do not treat `/etc/hosts` as your only copy

Keep a file you own:

~/dev/hosts/personal.hosts

Or one file per project / client. Edit that. Apply it on purpose.

2. Edit the copy, then copy it into place

macOS / Linux:

code ~/dev/hosts/personal.hosts
sudo cp /etc/hosts "/etc/hosts.bak.$(date +%Y%m%d-%H%M%S)"
sudo cp ~/dev/hosts/personal.hosts /etc/hosts

Windows: edit your copy, back up the live file, then replace:

C:\Windows\System32\drivers\etc\hosts

You need admin rights for the live file. That is normal.

3. Flush DNS every time you apply

Make this part of the apply step, not a later panic search.

macOS

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Windows (Admin)

ipconfig /flushdns

Linux (systemd-resolved)

sudo resolvectl flush-caches

4. Verify in the terminal before the browser

ping -c 1 myapp.test
# Linux:
getent hosts myapp.test

Right IP in the terminal, wrong page in the browser? Stop rewriting hosts. Look at browser DNS, HTTPS, redirects, or HSTS.

5. Avoid two active lines for the same hostname

This breaks people constantly:

10.0.0.5    www.client.com
127.0.0.1   www.client.com

Pick one. Comment the other, or better, keep separate profile files and swap the whole file.

Example: local frontend + API

127.0.0.1   shop.test
127.0.0.1   api.shop.test

Frontend env:

NEXT_PUBLIC_API_URL=http://api.shop.test

API env:

APP_URL=http://api.shop.test

Then:

Apply hosts
Flush DNS
Confirm with ping / getent
Open the browser
Only then debug CORS, cookies, or TLS

Hosts bugs and app bugs look the same in a tab. Split them.

Team onboarding

If your README says “paste these 12 lines into hosts,” configs will drift.

Better:

Commit a hosts.example
Add a short apply script
Say which environment the file is for (local, stEgin`, etc.)

Goal: new laptop works in a few minutes, not after three Slack threads.

Short version

Edit a file you own
Back up, then copy into the system hosts path
Flush DNS
Check resolution in the terminal
Keep one active mapping per hostname

That is enough for most local and staging work. If you are changing hosts several times a day across clients, automate the swap with a script or a small hosts manager. The process above still matters either way.

How to flush DNS on Mac, Windows, and Linux

Locahl — Thu, 16 Jul 2026 21:28:55 +0000

How to flush DNS on Mac, Windows, and Linux

You changed your hosts file. The line looks right. The browser still loads the old IP.

That is usually DNS cache, not a bad hosts entry.

Flush the OS cache first. Check with a terminal command. Only then blame the browser.

macOS

Works on recent macOS (Sequoia, Sonoma, Ventura, and neighbors):

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Enter your password. No output is normal.

Still wrong after that?

Quit the browser fully and reopen it
In Chrome, open chrome://net-internals/#dns and click Clear host cache
Re-check the hosts line (typo, or a # that comments it out)

Windows 10 and 11

Open Command Prompt or PowerShell as Administrator:

ipconfig /flushdns

Or in PowerShell:

Clear-DnsClientCache

Hosts file location if you need it:

C:\Windows\System32\drivers\etc\hosts

Linux

It depends which resolver is caching.

systemd-resolved (common on Ubuntu and Fedora)

sudo resolvectl flush-caches

On older setups:

sudo systemd-resolve --flush-caches

nscd

sudo systemctl restart nscd

dnsmasq

sudo systemctl restart dnsmasq

Hosts file:

/etc/hosts

Check the result outside the browser

Do this before you keep refreshing Chrome.

macOS

dscacheutil -q host -a name myapp.test
ping -c 1 myapp.test

Linux

getent hosts myapp.test
ping -c 1 myapp.test

Windows

ping myapp.test
nslookup myapp.test

If the terminal shows the right IP and the browser does not, the OS hosts file is probably fine. Clear browser DNS, or check HTTPS / HSTS / Secure DNS (DoH).

If you flushed DNS and it still fails

Browser wrong, terminal correct

Browser cache, Secure DNS, or a certificate / redirect issue.

Terminal wrong too

Typo in hosts, wrong file, line commented with #, or you edited a copy that never got applied.

Works, then breaks after reboot

Something rewrites hosts, or a VPN / DNS tool takes over.

Only one browser fails

That browser has its own DNS settings.

Works on normal Wi-Fi, fails on VPN

VPN DNS is ignoring or overriding local hosts.

Also check AdGuard, NextDNS, Cloudflare WARP, Pi-hole, and Tailscale MagicDNS. They can make a correct hosts change look like it did nothing.

Hosts syntax worth double-checking

127.0.0.1   myapp.test
127.0.0.1   api.myapp.test
# 10.0.0.5  staging.myapp.test

IP first, then hostname(s)
A # disables the rest of the line
Keep the line clean (no random trailing junk)
IPv6 localhost is ::1 when you need it

Copy-paste

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Windows (Admin)
ipconfig /flushdns

# Linux (systemd-resolved)
sudo resolvectl flush-caches

Edit hosts, flush DNS, verify in the terminal. That order fixes most of these tickets.

DEV Community: Locahl

Fix Permission denied when editing /etc/hosts

Why it happens

macOS / Linux fix

Windows fix

"I can edit but nothing changes"

Avoid fighting permissions every day

Quick recovery if you break hosts

DNS not updating after hosts file change? Fix it in order

1. Confirm the file that actually loaded

2. Flush the OS DNS cache

3. Ask the OS, not the browser

4. Clear browser DNS

5. Watch for HTTPS and HSTS traps

6. Docker and VPN layers

Short checklist

Use a custom local domain instead of localhost:3000

1. Add the hostname

2. Point your app at it

3. Optional: drop the port with a proxy

4. HTTPS locally

5. Frontend and API on sibling hosts

Checklist when it "does not work"

When to skip this

How to block websites with the hosts file

The pattern

macOS and Linux

Windows

Verify

What this does not block

Keep it tidy

Safety note

Where is the hosts file on Mac, Windows, and Linux?

Paths

Open it on macOS

Open it on Windows

Open it on Linux

What a normal line looks like

Quick check after editing

Common mistakes

How to switch local and staging domains with the hosts file

Why one big hosts file fails

Use profiles instead of comments

Apply a profile

Small bash helper

Optional: base file + project overlay

Pre-DNS cutover checklist

Docker caveat

After every switch

When hosts profiles stop being enough

Start with three files

How to edit /etc/hosts without breaking your local setup

What the hosts file does

A workflow that holds up

1. Do not treat /etc/hosts as your only copy

2. Edit the copy, then copy it into place

3. Flush DNS every time you apply

4. Verify in the terminal before the browser

5. Avoid two active lines for the same hostname

Example: local frontend + API

Team onboarding

Short version

How to flush DNS on Mac, Windows, and Linux

How to flush DNS on Mac, Windows, and Linux

macOS

Windows 10 and 11

Linux

systemd-resolved (common on Ubuntu and Fedora)

nscd

dnsmasq

Check the result outside the browser

If you flushed DNS and it still fails

Hosts syntax worth double-checking

Copy-paste

1. Do not treat `/etc/hosts` as your only copy