Let's break down how to troubleshoot your Nginx Connection Refused (Error 111) and Bad Gateway issues step by step—these are super common when setting up a Python app with Nginx and systemd, so don't stress too much!

1. First, confirm your systemd service is actually running #

• Run sudo systemctl status myproject.service to check if the service is active and healthy. Look for a line that says active (running)—if it's failed or inactive, pull the logs with sudo journalctl -u myproject.service -f to see why it crashed (common culprits: wrong virtual environment path, missing Python dependencies, or typos in your wsgi.py reference).
• Double-check your systemd service file's ExecStart line. It should point to your venv's Python binary and the correct wsgi.py with an absolute path, like this:

  ExecStart=/home/your-user/myproject/venv/bin/gunicorn --workers 3 --bind unix:/home/your-user/myproject/myproject.sock wsgi:application
  

  Typos in paths here are one of the most frequent causes of this exact problem.

2. Check permissions on your Unix socket (myproject.sock) #

• Error 111 usually means Nginx can't access the socket file. Run ls -l myproject.sock to see its owner and group.
• Fix this by either:
  • Setting User=www-data in your systemd service file (so the socket is owned by the user Nginx runs as by default), or
  • Adding Nginx's user to your project's group with sudo usermod -aG your-user www-data, then restart both the service and Nginx.
• Also, make sure the parent directory of the socket has read/execute permissions for Nginx—run chmod 755 /path/to/your/project/directory if needed.

3. Validate your Nginx site configuration #

• Even if you fixed it, run sudo nginx -t to test for syntax errors—this will catch typos you might have missed in your /etc/nginx/sites-available/myproject file.
• In your Nginx config, confirm the proxy_pass line points to the correct absolute path of your socket:

  location / {
      proxy_pass http://unix:/path/to/your/myproject.sock;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
  }
  

• Don't forget about your duplicate wsgi.py files—make sure your systemd service is pointing to the right one (the one in your project root, not a random duplicate elsewhere).

4. Make sure the socket is being created at all #

• If myproject.sock doesn't exist in your working directory, that means your systemd service isn't starting properly (Gunicorn creates the socket when it runs). Go back to step 1 and dig into the service logs—this usually points to a Python error or missing dependencies in your venv.

5. Rule out process conflicts #

• Run sudo lsof -i :80 (replace 80 with your custom port if needed) to check if another process is using the port Nginx is trying to listen on. If something else is there, stop that process or adjust Nginx's listen port.
• Also, did you reload systemd after editing your service file? Run sudo systemctl daemon-reload before restarting the service—I've forgotten this more times than I'd like to admit!

6. Double-check firewall and network settings #

• You ran sudo ufw allow 'Nginx Full', but confirm with sudo ufw status that the rule is active (look for lines allowing 80/tcp and 443/tcp).
• If you're accessing from a remote machine, make sure your server's cloud provider (AWS, DigitalOcean, etc.) has a security group that allows inbound traffic on your port—this is an easy oversight!

After working through these steps, restart both services to apply changes:

sudo systemctl restart myproject.service
sudo systemctl restart nginx

If you're still stuck, share the output of sudo systemctl status myproject.service and sudo nginx -t—that will help narrow things down further.

内容的提问来源于stack exchange，提问作者John