Python生产环境中Django + Nginx + uWSGI部署出现Internal Server Error，如何排查connect() failed错误？

奇怪的是今天早上起来。发现还是提示：Internal Server Error 但是错误日志一直不更新了，
还是显示昨天晚上的那些。

2017/08/29 01:39:12 [error] 1739#0: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 111.11.111.111, server: cccc.com, request: “GET / HTTP/1.1”, upstream: “uwsgi://127.0.0.1:8006”, host: “www.cccc.com”


我的配配置: uwsgi.ini

# cccc_uwsgi.ini file
[uwsgi]
socket = 127.0.0.1:8006
chdir = /var/wwwroot/html/cccc
module = cccc.wsgi:application
env = DJANGO_SETTINGS_MODULE = cccc.settings
master = true
processes = 8
vacuum = true

nginx.conf
server {
listen 80;
server_name www.cccc.com;
charset UTF-8;
access_log /var/log/nginx/cccc_access.log;
error_log /var/log/nginx/cccc_error.log;

client_max_body_size 75M;

location / {
include uwsgi_params;
uwsgi_pass 127.0.0.1:8006;
uwsgi_read_timeout 2;
}
location /static {
expires 30d;
autoindex on;
add_header Cache-Control private;
alias /var/wwwroot/html/cccc/static;
}
}


看这错误提示不知是哪里配置的不对？
另外错误日志不更新了是怎么回事？
Python生产环境中Django + Nginx + uWSGI部署出现Internal Server Error，如何排查connect() failed错误？


1 回复

先看Nginx的error log，位置通常是/var/log/nginx/error.log。关键错误信息是connect() to unix:/path/to/your.sock failed或连接127.0.0.1:端口失败。

问题基本出在uWSGI和Nginx的通信上。按这个顺序查：

  1. 检查uWSGI是否在运行

    ps aux | grep uwsgi

    如果没进程，启动你的uWSGI。用systemctl的话：

    sudo systemctl status your-uwsgi-service

  2. 核对socket文件或端口 对比Nginx配置和uWSGI配置里的socket路径或端口号是否完全一致。一个拼写错误就全断了。 Nginx配置示例：

    location / {
    include uwsgi_params;
    uwsgi_pass unix:/path/to/your_project.sock; # 这里
    # 或者 uwsgi_pass 127.0.0.1:8000;
}

    uWSGI配置（比如uwsgi.ini）示例：

    [uwsgi]
socket = /path/to/your_project.sock # 必须和上面一样
# 或者 socket = 127.0.0.1:8000
chdir = /path/to/your/project
module = your_project.wsgi:application
master = true
processes = 4

    改完配置要重启两者。

  3. 检查socket文件权限 如果用的是.sock文件，运行uWSGI的用户（比如www-data）必须有这个文件所在目录的写权限。常见权限问题。

    ls -la /path/to/your_project.sock

    确保Nginx用户（也常是www-data）能访问。可以粗暴点测试：

    sudo chmod 666 /path/to/your_project.sock

    然后重试，如果好了就说明是权限问题，再回头设好安全权限（比如775，用户组一致）。

  4. 直接测uWSGI 停掉Nginx，让uWSGI直接HTTP模式运行，看应用本身是否正常。

    uwsgi --http :8000 --module your_project.wsgi

    浏览器访问服务器IP:8000，如果还500，那就是Django应用的问题，查Django的log。

  5. 看uWSGI自己的log 在uWSGI配置里设好logto或daemonize，看它启动有没有报错。

    [uwsgi]
...
daemonize = /var/log/uwsgi/your_project.log

总结：九成是配置对不上、权限不够或者uWSGI根本没跑起来。

回到顶部