When developing multiple web services locally, we often run into port conflicts or end up with a mess of localhost:8080, localhost:8081, and so on. While reverse proxies are a common solution, there’s a simpler, more “native” way to handle this using the loopback address range and your /etc/hosts file.
Beyond 127.0.0.1
Most developers are familiar with 127.0.0.1, but the entire 127.0.0.0/8 range is actually reserved for loopback. This means you can use any address from 127.0.0.1 all the way to 127.255.255.254.
On Linux, 127.0.0.1 is often used for the static hostname of the machine, but you can freely use other addresses in the range to isolate your services, with 127.0.1.0/24 being the range I personally adopted for this technique.
Mapping Domains in /etc/hosts
By assigning different loopback addresses to different domain names in your /etc/hosts file, you can run multiple services on the same port (e.g., 80 or 443) without them interfering with each other—as long as they bind to specific IPs rather than 0.0.0.0.
127.0.1.10 api.project.local
127.0.1.11 web.project.local
127.0.1.12 admin.project.localNow, you can configure your services to bind specifically to these addresses:
- API Service: Binds to
127.0.1.10:80 - Web Frontend: Binds to
127.0.1.11:80
When you visit api.project.local in your browser, it routes to 127.0.1.10, and your OS knows exactly which service should receive the traffic.
Loading diagram...
Local HTTPS with Wildcard Certificates
If your local domains share a common root (like .project.local in the example above), you can take things a step further and enable HTTPS for all of them using a single wildcard certificate.
Generating a Locally Trusted Cert
Tools like mkcert make this incredibly easy. mkcert creates a local Certificate Authority (CA) and installs it into your system’s trust store.
To create a wildcard certificate for your local project:
mkcert "*.project.local"This generates two files: _wildcard.project.local.pem and _wildcard.project.local-key.pem.
Loading diagram...
Using the Certificate
You can now point your local web servers or reverse proxies (like Nginx, Caddy, or Traefik) to these files. Because they are wildcard certificates, they will be valid for:
api.project.localweb.project.localadmin.project.local
Your browser will show a green lock icon, and you won’t have to deal with “Your connection is not private” warnings for every new service you spin up.
Limitations
This approach is great for accessing resources on your local machine; however, it does start to fall apart if you need to test on other devices in your network (e.g. testing on real devices, etc.). In those cases I use CloudFlare Tunnels; but there are a wide range of competing solutions that are worth exploring.
Summary
By combining the flexibility of the 127.0.1.X range with /etc/hosts and mkcert, you can create a local development environment that closely mirrors production. No more port-hunting—just clean domains and valid HTTPS.
