When you say “local VM”, do you mean using something like VirtualBox or VMWare? Or are you talking about Windows WSL? There’s a difference between the two.
If you’re talking about a full VM (VB or VMWare), then that VM is not localhost relative to your host system. Depending upon how you’ve got networking configured, it’s going to get one or more different IP addresses assigned to it.
That’s fine for your app - it shouldn’t be visible to the outside world.
You want to configure nginx to listen on all addresses. You’re going to point your browser to nginx, and it’s nginx that is going to forward the requests to your app. (That connection is through localhost.)
After you’ve got nginx configured, the ifconfig command will show you what IP address(es) are assigned to your VM. It’s that address you will use in your browser. And since nginx is typically listening on port 80, you won’t need to specify the port in the address bar.
For example, one of my VB networks uses the subnet 192.168.56.0/24. My host is 192.168.56.1. My runtime image is 192.168.56.101. When I want to connect to my runtime image, that’s what I use.
You have one IP address - 10.0.2.15 (subnet 10.0.2.0), and a subnet broadcast (brd) address - 10.0.2.255.
Also, since you have gunicorn listening on a unix socket, it’s not going to respond to an ip address request.
Again, in this configuration, based upon what you’re showing here, your host system will not be talking to your Django app directly. It’s communicating to nginx, which forwards the HTTP request to Django, and returns the reply.
That’s correct - assuming you have nginx listening on port 80, and all the routing and network configurations between your host and VM are right.
Have you tested any network connectivity between your host and VM?
(Can you ping from the host to the VM?)
Do you have any firewalls that might need to be opened?
Have you verified that nginx is configured to listen on that interface?
Have you tried running curl from within the VM to talk to nginx instead of gunicorn?
There are a lot of variables here, and unfortunately, it’s not going to be something easily diagnosed remotely. I can only suggest that you break this larger issue down into the smaller component issues and follow what’s happening from end to end.
The bigger picture is that this probably isn’t a Django issue, especially if you can curl from within the VM to nginx and get the appropriate reply. Being able to do so would indicate that this is more of a “SysAdmin” type issue, and perhaps more appropriately discussed in a different forum.
That depends upon your nginx configuration. Somewhere you would have a location directive that tells nginx to forward your requests to gunicorn. Step 8 in the tutorial you referenced in your original post covers it.
If Nginx displays the default page instead of proxying to your application, it usually means that you need to adjust the server_name within the /etc/nginx/sites-available/myproject file to point to your server’s IP address or domain name.
But everything is set up perfectly (the VM’s IP adress changed because I reinstalled Debian) :