If I create a secondary config as you are suggesting, wouldn’t it create a conflict with the server blocks of default.conf

No, you can have multiple server blocks with the same listen directive. They just need to differ by their server_name and only one server block can contain default_server; Reference

NGINX will use the server_name directives to differentiate the different backend services. This is a class virtual host configuration model.

There was an uncaught exception to boot gunicorn workers

That’s odd that it didn’t cause the Docker container to immediately exit.

What now? So now that it looks like everything is working. What is the best practice for the nginx.conf? Leave it all in /etc/nginx/nginx.conf (with user as root), reestablish the out box nginx.conf and /etc/nginx/conf.d/default.conf

My suggestion would be to create /etc/nginx/conf.d/mycooldjangoapp.conf. Compared to conf.d/default.conf, this is more intuitive if you start hosting multiple apps. Keep it out of the nginx.conf because apt-get or other package managers will usually patch that with new version changes and again it gets confusing if you have multiple apps.

First the basics. Connection refused means that nothing is running on “http://192.168.0.2:8020/”

1. Is 192.168.0.2 the IP address of the Django container? If it’s the host’s IP, does docker ps show that the port is bound to the host? e.g. 0.0.0.0/8082->8082

Confirmed upstream block container is running and on the right exposed port

What steps did you do to confirm that this is running?