Django站点POST请求502错误排查：Nginx报upstream连接提前关闭

Hey there! Let's break down why you're seeing that 502 Bad Gateway error when sending POST requests to your Django site—even though the domain loads fine. That "upstream prematurely closed connection" log message almost always means Nginx lost its connection to Gunicorn before getting a full response. Let's go through the most common issues in your config files and how to fix them.

Common Issues in simplesol.conf (Nginx Config) #

1. Timeout Settings Are Too Short #

POST requests often take longer to process (like form submissions, file uploads) than GET requests. If Nginx waits too little time for Gunicorn to send a response, it'll drop the connection. Add these lines inside your location / block:

proxy_connect_timeout 300s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;

Adjust the 300s (5 minutes) to whatever makes sense for your app's processing time.

2. Request Size Limit Is Too Low #

If your POST request includes large data (like uploads), Nginx's default client_max_body_size (usually 1MB) will block it, triggering an error that can cascade into the upstream disconnect. Add this line inside your server block:

client_max_body_size 10M; # Adjust based on your needs (e.g., 100M for large files)

3. Upstream Socket/Address Mismatch or Permissions #

Double-check that your proxy_pass directive points to the exact same address/socket that Gunicorn is using:

• If you're using a Unix socket: Make sure the path matches (e.g., unix:/var/www/simplesol/socket.sock), and that the socket file has the right permissions. The Nginx user (www-data) needs read/write access to it. You can fix permissions by either:
  • Running Gunicorn as the www-data user, or
  • Setting the socket's permissions to 775 and adding www-data to Gunicorn's group.
• If you're using a TCP port (like http://127.0.0.1:8000), confirm Gunicorn is actually listening on that port with netstat -tulpn | grep gunicorn.

Common Issues in gunicorn_start.bash (Gunicorn Startup Script) #

1. Worker Timeout Is Too Low #

Gunicorn's default worker timeout is 30 seconds. If your Django app takes longer than that to process a POST request, the worker will die and close the connection to Nginx. Add the --timeout flag to your Gunicorn command:

gunicorn --timeout 300 your_project.wsgi:application ...

2. Not Enough Worker Processes #

If you're getting a lot of concurrent POST requests, too few Gunicorn workers can lead to backlogs and dropped connections. A good rule of thumb is 2 * number_of_CPU_cores + 1. For example, on a 2-core server:

gunicorn --workers 5 your_project.wsgi:application ...

3. Missing Logging for Debugging #

Add Gunicorn logging to your startup script so you can see if the issue is actually in your Django app (like an unhandled exception crashing the worker):

gunicorn --access-logfile /var/log/gunicorn/access.log --error-logfile /var/log/gunicorn/error.log your_project.wsgi:application ...

Make sure the /var/log/gunicorn directory exists and is writable by the user running Gunicorn.

Quick Troubleshooting Steps #

1. Check if Gunicorn is running: Run ps aux | grep gunicorn to confirm the process is active.
2. Test Gunicorn directly: Send a POST request to Gunicorn's address (e.g., curl -X POST http://127.0.0.1:8000/your-post-endpoint -d "test=data"). If this fails, the problem is in Django or Gunicorn, not Nginx.
3. Restart services: After making config changes, restart Nginx (sudo systemctl restart nginx) and Gunicorn (either via systemd or by killing the process and re-running your startup script).

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