Python Nginx 和 uWSGI：连接被拒绝和 502 Bad Gateway 错误
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/21190394/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Nginx and uWSGI: Connection refused and 502 Bad Gateway error
提问by
Trying to set up Nginx and uWSGI on Ubuntu 13.10.
尝试在 Ubuntu 13.10 上设置 Nginx 和 uWSGI。
When I try to access the website, all I get is "502 Bad Gateway".
当我尝试访问该网站时，我得到的只是“502 Bad Gateway”。
Ran apt-get install nginx uwsgi uwsgi-plugin-python3to install nginx/uwsgi.
跑去apt-get install nginx uwsgi uwsgi-plugin-python3安装nginx/uwsgi。
/etc/nginx/sites-enabled/webpage.com:
/etc/nginx/sites-enabled/webpage.com：
server {
listen 80;
server_name webpage.com;
access_log /var/log/nginx/webpage.com_access.log;
error_log /var/log/nginx/webpage.com_error.log;
location / {
uwsgi_pass /var/run/webpage.com.uwsgi.socket;
include uwsgi_params;
uwsgi_param Host $host;
uwsgi_param X-Real-IP $remote_addr;
uwsgi_param UWSGI_SCHEME $scheme;
uwsgi_param SERVER_SOFTWARE nginx/$nginx_version;
}
}
/etc/uwsgi/apps-enabled/webpage.com
/etc/uwsgi/apps-enabled/webpage.com
[uwsgi]
vhost = true
plugin = python3
socket = /tmp/webpage.com.sock
master = true
enable-threads = true
processes = 2
home = /var/www/webpage.com/env
wsgi-file = /var/www/webpage.com/env/hello.py
virtualenv = /var/www/webpage.com/env
chdir = /var/www/webpage.com/env
touch-reload = /var/www/webpage.com/reload
/var/log/nginx/webpage.com_error.log
/var/log/nginx/webpage.com_error.log
2014/01/17 16:28:58 [error] 25073#0: *13 connect() to unix:///var/run/webpage.com.uwsgi.socket failed (111: Connection refused) while connecting to upstream, client: 83.109.132.224, server: webpage.com, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///var/run/webpage.com.uwsgi.socket:", host: "webpage.com"
hello.pyis just a simple hello world app.
hello.py只是一个简单的 hello world 应用程序。
Have been struggling with this for several hours... Now I need help :)
已经为此苦苦挣扎了几个小时......现在我需要帮助:)
回答by Paolo Casciello
Looking at the config files posted here you reference the socket in nginx as:
查看此处发布的配置文件，您将 nginx 中的套接字引用为：
uwsgi_pass /var/run/webpage.com.uwsgi.socket;
and in uwsgi as
在 uwsgi 中
socket = /tmp/webpage.com.sock
回答by jstaab
This doesn't answer the OP's original question, but I had the same error in nginx, connect() to unix:///tmp/uwsgi_dev.sock failed (13: Permission denied) while connecting to upstream, and I was able to fix it by just restarting the uwsgi process completely. It's a production server, so I was hesitant to do a hard restart, but just reloading the uwsgi process didn't do the trick. Hope that helps someone.
这并没有回答 OP 的原始问题，但是我在 nginx 中遇到了同样的错误connect() to unix:///tmp/uwsgi_dev.sock failed (13: Permission denied) while connecting to upstream，并且我能够通过完全重新启动 uwsgi 进程来修复它。这是一个生产服务器，所以我犹豫要不要硬重启，但只是重新加载 uwsgi 进程并没有解决问题。希望能帮助某人。
回答by jcomeau_ictx
I realize this doesn't have anything to do with the OP's problem, but since this is the top hit for that error message in Google, I would like to note what fixed the problem for me.
我意识到这与 OP 的问题没有任何关系，但由于这是 Google 中该错误消息的首要问题，我想说明是什么为我解决了问题。
I was following a tutorial which advised to put uwsgi_pass 127.0.0.1:9090;into the nginxconfiguration for a Python script that had been set up in the uwsgiconfiguration with http-socket = :9090. the error log /var/log/nginx/error.logshowed the problem: 2015/08/13 02:16:04 [error] 12566#12566: *2 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: ~^(www\.)?(.+)$, request: "GET /hello/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:9090", host: "kybyz"the browser, meanwhile, was giving me the 502 Bad Gateway error.
我正在关注一个教程，该教程建议将已uwsgi_pass 127.0.0.1:9090;在nginx配置中设置的 Python 脚本放入uwsgi配置中http-socket = :9090。错误日志/var/log/nginx/error.log显示了问题：2015/08/13 02:16:04 [error] 12566#12566: *2 upstream prematurely closed connection while reading response header from upstream, client: ::1, server: ~^(www\.)?(.+)$, request: "GET /hello/ HTTP/1.1", upstream: "uwsgi://127.0.0.1:9090", host: "kybyz"同时，浏览器给了我 502 Bad Gateway 错误。
there were two ways (at least) to fix it. the first was to change http-socketin the uwsgiconfiguration to simply socket(as, it turned out, the tutorialrecommended; I just hadn't read it carefully enough). however, that would no longer allow me to test the script directly by pointing my browser at http://127.0.0.1:9090/, since the script now spoke uwsgiprotocol instead of http. so I changed back to http-socketand changed, in the nginxconfiguration, the uwsgi_passline to proxy_pass http://127.0.0.1:9090;.
有两种方法（至少）可以修复它。第一个是http-socket将uwsgi配置更改为简单socket（因为，结果是教程推荐的；我只是没有足够仔细地阅读它）。但是，这将不再允许我通过将浏览器指向 来直接测试脚本http://127.0.0.1:9090/，因为脚本现在使用uwsgi协议而不是http. 所以我改回http-socket并在nginx配置中将uwsgi_pass行更改为proxy_pass http://127.0.0.1:9090;.
回答by Cyker
Typically this is a file permission problem, i.e. the uwsgi socket file is not readable by the nginx process. Check the socket file's permission and its parent folder and its grandparent folder, etc. You can do this with one command (suppose your nginx process is running by user nginx):
通常这是一个文件权限问题，即 nginx 进程无法读取 uwsgi 套接字文件。检查套接字文件的权限及其父文件夹和祖父文件夹等。您可以使用一个命令执行此操作（假设您的 nginx 进程由用户运行nginx）：
su nginx -c "[[ -r sockfile ]] && echo ok"
回答by PHZ.fi-Pharazon
For my Python Django app on AWS, it's just overloaded.
对于我在 AWS 上的 Python Django 应用程序，它只是过载了。
First I added more servers and noticed that C-instances (compute) are better than general purpose (M) -instances since the M -instances had 66% of CPU load running as steal (used by some other customers) after running out the CPU credits.
首先，我添加了更多服务器并注意到 C 实例（计算）比通用 (M) 实例更好，因为 M 实例在 CPU 耗尽后有 66% 的 CPU 负载以窃取方式运行（由其他一些客户使用）学分。
But after running the app for some time (and after having the number of incoming requests grown 5x in short time period), I also checked the database performance (RDS), and it was running at 100%. I also grew the Database instance size from 4 CPU to 8 CPU and now it works again without errors.
但是在运行应用程序一段时间后（并且在短时间内传入请求的数量增长了 5 倍之后），我还检查了数据库性能 (RDS)，它以 100% 的速度运行。我还将数据库实例大小从 4 个 CPU 增加到 8 个 CPU，现在它再次正常工作，没有错误。
