This is unsurprising, you're asking the DNS resolver of your web browser, an arbitrary program on your local host likely using the system resolver and which has no knowledge of Docker containers, to somehow figure out which Docker container IP to resolve that name to.

Application-level configuration

A nice approach I've seen in the past is to attach a container running an SSH daemon to the Docker bridge network of your target services. You can then use SSH's dynamic application-level port forwarding feature and configure your browser to use a SOCKS proxy set up by the SSH client on a port of your choice and which tunnels inside the Docker network. If you configure your browser to also resolve DNS queries via the proxy you should be able to reach the Docker embedded DNS server, which will by default answer appropriately to queries for domain names that correspond to the container names.

What's nice about this is that:

• You can ask the Docker engine to set up aliases, so you can use completely arbitrary domain names (even under ICANN-controlled TLDs, like your production domains) which sometimes comes in handy to debug X.509 certificate issues and the like.
• If you start the SSH proxy automatically when you boot your machine and for example use a browser extension to easily enable/disable/switch proxies, it all works out-of-the-box for all new containers without additional configuration. Of course this assumes all containers are attached to a single Docker bridge network, you will need to reconfigure things if you're playing with multiple Docker bridge networks (which is in fact likely if you're using tools like Docker Compose). This feels like this can be fully automated (with cooperating browser extensions) so some tools might already exist (or you can write them). A nice UX I can think of would have a browser extension allow you to quickly select a Docker network to "connect to" (remember that unrelated containers in different Docker networks may expect to use the same name).

You don't need SSH for this approach of course, just something that talks SOCKS and that can interface with an arbitrary virtual network interface. It's just that the SSH client and server combo makes it very easy to set up and experiment with today without writing any code. Disclaimer: I've never tried the approach personally but I see no reason it wouldn't work.

System-wide configuration

You can add an entry in your local hosts file for every container as you already found. This is obviously more straightforward, but tooling to automate that approach might be more involved. In effect, you would need to write a DNS resolver or server that integrates with Docker, perhaps with UI to disambiguate between names claimed by different containers in different Docker networks. Again some tools might already exist but I have personally not heard of any.

Alternatively you can imagine a non-ambiguous scheme like $container_name.$network_name.localhost, though you're now requiring some containers (like HTTP servers that do virtual hosting as in your setup) to know about system-level concerns (which network they're in) where you'd rather want it to be transparent (different developers on your team might use different network names, maybe they're even testing multiple branches of the same codebase at once on different networks). You might use things like environment substitution in docker-compose to have this still run without any configuration (assuming you can always pass these settings down to the container processes through environment variables/configuration file templating), but this might be trickier in practice.

If you do this you can have your default system resolver target that DNS server (and fallback to your normal servers), which can either be a good or a bad thing depending on what you want to do. Note that in my experience I don't know of many programs that allow you to pick an arbitrary name resolver or even arbitrary DNS servers (as most rely on the system resolver). So, if you want application-level configuration this is probably not the best approach (SOCKS support is more common).