that’s only an issue if you’re telling nginx the internal IP of the container container names

Oh how naive I thought so to. Nope.

If you have an nginx container (swag) that is inside the docker network, without a resolver 127... configuration line. Upon initial loading of the container it will resolve all upstreams. In this case yours are sab and sonarr. These resolve to 127.99.99.1 and 127.99.99.2 respectively (for example purposes). These are kept inside memory, and are not resolved again until a reload happens on the container.

Lets say sab was a service that could scale out to multiple containers. You would now have two containers called sab and one sonarr. The IP resolutions are 127.99.99.1 (sab), 127.99.99.2 (sonarr), 127.99.99.3 (sab).
Nginx will never forward a packet to 127.99.99.3, because as far as nginx is concerned the hostname sab only resolves to 127.99.99.1. Thus, the 2nd sab container will never get any traffic.

Of course this wouldn’t matter in your usecase, as sab and sonarr are not able to have high availability. BUT, lets say your two containers were restarted/crashed at the same time and they swapped ips/got new IPs because docker decided the old ones were still inuse.

Swag thinks sab = 127.99.99.1, and sonarr = 127.99.99.2. In reality, sonarr is now 127.99.99.3 and sab is 127.99.99.4 So you launch http://sonarr.local and get greeted with a sonarr is down message. That is why the resolver lines around the web say to have the ttl=5s to enforce a always updating dns name.

This issue is exactly what happened here: https://reddthat.com/comment/1853904

I know nginx

Oh don’t get me wrong, nginx/Swag/NPM are all great! I’ve been trialing out NPM myself. But the more I use nginx with docker the more I think maybe I should look into this k8s or k3s thing, as the amount of networking issues I end up getting and hours I spend dealing with it… It just might just be worth-it in the end :D

/rant