VPN on and localhost stops working: name, proxy or bind?

Your development server answered a minute ago, and now that the tunnel is up the request times out with a hostname you never typed. Two mechanisms account for almost every case, and from the outside they look identical. A search suffix turns a short name into a corporate one, while a proxy sends loopback traffic to a host that cannot reach it. Separating the two costs one query and saves the firewall rule you were about to write.

When localhost resolves into the corporate zone

Check what the name resolves to while the tunnel is up, then run the same query with it down and compare the two answers. The giveaway is an address in the corporate range where you expected 127.0.0.1. A record such as localhost.mycompany.corp wins over the loopback entry once the client adds that suffix to the search list, and the request travels to a private host with nothing listening on that port. Read the search list instead of guessing at it, because a client can add more than one domain and the order decides which candidate is tried first:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Replace the hostname with the literal address in the application, the database client or the notebook URL, then repeat the request. If the failure disappears, you had a naming problem and the tunnel was only the trigger. If it persists, the listener or the route is the next suspect and the name was a red herring.

Proxy settings that capture loopback

A system proxy applied when the tunnel comes up will accept a request for 127.0.0.1 and forward it to a remote proxy that has no idea what you meant. An empty bypass list turns a local request into a remote one, and the error message rarely says so. Add the loopback addresses to the bypass list for the whole session rather than for a single command, then confirm the tool honours it before concluding anything about the network.

Application frameworks read their own environment variables and sometimes their own configuration file, so a bypass that works for one tool proves nothing for the next. Browsers add a wrinkle: Chromium-based browsers bypass the proxy for loopback implicitly, and a bypass token can remove that behaviour. Check the effective proxy decision rather than assuming the operating-system setting is the whole story. Two commands settle it for anything launched from a shell:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Bind address decides who can connect

A server started on 127.0.0.1 accepts connections from that machine only, which is usually the right default for development. A server on 0.0.0.0 answers on every interface, the VPN adapter included, which is more exposure than most people intend. When the literal loopback address fails, check the bind before anything else.

Look at the listening socket and note the address it is bound to, not just the port. If another device or a container must reach the service through the tunnel, bind to the specific interface it will use and allow that port deliberately. If only your own machine needs it, keep the narrow bind and fix the client instead of widening the server. A port forward or a tunnels layer can bridge the two, but each adds a component that will need its own debugging later.

Where a debugging tool expects the LAN

Debugging tools carry assumptions that a tunnel breaks quietly. A phone debugging bridge loses its device when the VPN captures the device's subnet, so reconnecting through the LAN address or a cable avoids the conflict. A browser automation hub times out when the hub is reachable only through the proxy, or when a local firewall drops its control port. A remote debugger may demand elevation and a loopback address where the client rewrote the route.

Identify the control port and the data port separately, since one often survives while the other does not. Then decide whether the fix belongs in the tool's configuration, in a route for that subnet, or in a split-tunnel rule. Editing a hosts file on every developer machine scales worst and is forgotten first. Prefer the setting that lives with the profile and can be reviewed by whoever owns the tunnel.

Stop at the first stage that fails

Work down three stages: resolve the name, open a socket to the literal address, then let the tool make its own connection. Each stage eliminates one layer, so the first failure names the layer to fix and everything after it stays untested. Write the result down before changing anything, because a fix applied before the measurement cannot be distinguished from luck. If the first attempt fails and a retry works, the tunnel was probably not ready when the tool started.

Replace the fixed sleep with a bounded readiness check that waits for the route, and keep the failing stage in the log so the next person sees where it stopped. A tool that recovers on its own is not fixed, it is lucky, and the luck runs out on someone else's machine. Change the tunnel last, and only for the stage that actually failed. That order is also the shortest path back to a working build, because it stops you rebuilding a component that was never involved.