后端服务器设置nginx + uwsgi + django/flask需要注意的问题 - ACE开发者 https://acejoy.com/2018/09/09/547/
后端开发应用中，除了Nginx + php-fpm + PHP这个组合之外，还有一个常用组合是：Nginx + uwsgi + Python组合。这个组合中，经常使用的Python框架是Django和Flask。它们都遵循Python标准的网关协议，所以运行的设置基本是一致的。
这个模式下: 静态资源交给nginx提供服务，其它的请求，转给uwsgi，由python进行处理后返回结果，这与php-fpm是一样的。
uwsgi支持的选项非常多，但是要跟nginx的配置相互匹配，否则就会报错，一般是连不上、502超时错误。这时打开nginx的错误日志可以查看具体原因。
这里面很重要的一点是：确定uwsgi使用的操作模式，就是接口形式是什么类型。
1、如果uwsgi使用http模式，nginx必须用proxy_pass 指令传递。
uwsgi –http :8002
nginx 配置必须是: proxy_pass 指令
例如：
proxy_pass http://127.0.0.1:8002
比如，你用pycharm等IDE跟nginx对接调试，那么就应该使用http的proxy_pass模式，否则就会出现错误，无法使用。
2、如果uwsgi使用socket模式，那么必须使用对应的ip:port 或者 unix socket方式
与之对应的socket，也分成ip:port 和 unix socket，推荐后者。
uwsgi –socket /dev/shm/django.sock –wsgi-file myapp/wsgi.py
nginx配置是：
upstream django {
server unix:/dev/shm/django.sock;
}
必须保持一致！
但是，它同时带来另外一个问题：权限。这个django.sock如果创建的权限与nginx运行时使用的用户权限不匹配，就无法使用，会报告502错误。
在Nginx出现502错误要怎么处理呢？
502错误一般都是nginx后面脚本解析器的错误，不是nginx的错误。比如连接不上就报告502.
第一先把nginx的配置修改成记录错误：
error_log /home/wwwlogs/error_nginx.log error; #crit;
然后查看日志：
2018/05/11 09:47:00 [crit] 5843#0: *2 connect() to unix:/dev/shm/django.sock failed (13: Permission denied) while connecting to upstream, client: 10.1.1.103, server: test.test.com, request: “GET / HTTP/1.1”, upstream: “uwsgi://unix:/dev/shm/django.sock:”, host: “test.test.com”
日志里面的记录说明，原因非常明显。
还有可以参考这里面的说明：
http://uwsgi-docs.readthedocs.io/en/latest/tutorials/Django_and_nginx.html
选项文档：
http://uwsgi-docs-zh.readthedocs.io/zh_CN/latest/Options.html?highlight=chmod-socket
这里的知识，希望能对大家有所帮助。
Web服务器集成 — uWSGI 2.0 文档 https://uwsgi-docs-zh.readthedocs.io/zh_CN/latest/WebServers.html
uWSGI支持多种集成web服务器的方法。它自己也能够为HTTP请求服务。
Web服务器集成
uWSGI支持多种集成web服务器的方法。它自己也能够为HTTP请求服务。
Nginx
参见
自Nginx官方发行版本0.8.40起就包含了uWSGI模块。uWSGI包里维护了一个支持Nginx 0.7.x的版本。
这是一个稳定的处理程序，由Unbit提供商业支持。
Apache
参见
Apache2 mod_uwsgi 模块式第一个为uWSGI开发的web服务器集成模块。它稳定，但可以更好地与Apache API集成。
由Unbit提供商业支持。
自uWSGI 0.9.6-dev起，包含了一个名为 mod_Ruwsgi 的第二个Apache2模块。它更加Apache API友好。 Unbit未对mod_Ruwsgi提供商业支持。
在1.2开发周期中，添加了另一个名为 mod_proxy_uwsgi 模块。不久，这应该是基于Apache部署的最好的选择。
Lighttpd (试验性)
该模块是最新开发的，但是在官方的inclusion发布版本中其包含已经被拒了，因为主作者认为 uwsgi protocol 是“重复发明轮子” ，而建议使用一个FastCGI方法。我们尊重这种态度。这个模块会继续存在uWSGI源代码树中，但是当前未对其进行维护。
对于这个处理程序，当前并无商业支持。我们认为这个模块是“试验性的”。
Twisted
这是一个”商用”处理程序，主要在不安装一个完整的web服务器的情况下测试应用的时候有用。如果你想要开发一个uWSGI服务器，那么看看这个模块。 Twisted.
Tomcat
可以使用包含的服务小程序来从Tomcat转发请求到uWSGI服务器。它稳定，但当前缺乏文档。
对于这个处理程序，当前并无商业支持。
CGI
CGI处理程序是用于“偷懒”安装的。不鼓励在生产环境上使用它们。
Cherokee (废弃)
参见
Cherokee web服务器官方支持uWSGI。 Cherokee是快而且轻量的，拥有一个漂亮的admin界面，以及一个不错的社区。从一开始，他们对uWSGI的支持就很棒，在大多数的情况下，我们都推荐使用它。 Cherokee uWSGI处理程序的用户群可能是最大的。Cherokee uWSGI处理程序由Unbit提供商业支持。
Mongrel2 (废弃)
自0.9.8-dev起，对 Mongrel2 Project 的支持通过 ZeroMQ 协议插件可用。
在我们的测试中，Mongrel2几乎通过了我们发送的所有负载。
非常棒和稳定的项目。试试吧 :)