我目前在用户正在进行的查询中总是得到 502...这通常返回 872 行，在 MySQL 中运行需要 2.07。然而，它返回了大量信息。 （每一行包含很多东西）。有什么想法吗？
运行 Django (tastypie Rest API)、Nginx 和 uWSGI 堆栈。
使用 NGINX 进行服务器配置
# the upstream component nginx needs to connect to
upstream django {
server unix:///srv/www/poka/app/poka/nginx/poka.sock; # for a file socket
}
# configuration of the server
server {
# the port your site will be served on
listen 443;
# the domain name it will serve for
server_name xxxx; # substitute your machine's IP address or FQDN
charset utf-8;
# max upload size
client_max_body_size 750M; # adjust to taste
# Finally, send all non-media requests to the Django server.
location / {
uwsgi_pass django;
include /srv/www/poka/app/poka/nginx/uwsgi_params; # the uwsgi_params file you installed
}
}
UWSGI 配置
# process-related settings
# master
master = true
# maximum number of worker processes
processes = 2
# the socket (use the full path to be safe
socket = /srv/www/poka/app/poka/nginx/poka.sock
# ... with appropriate permissions - may be needed
chmod-socket = 666
# clear environment on exit
vacuum = true
pidfile = /tmp/project-master.pid # create a pidfile
harakiri = 120 # respawn processes taking more than 20 seconds
max-requests = 5000 # respawn processes after serving 5000 requests
daemonize = /var/log/uwsgi/poka.log # background the process & log
log-maxsize = 10000000
#http://uwsgi-docs.readthedocs.org/en/latest/Options.html#post-buffering
post-buffering=1
logto = /var/log/uwsgi/poka.log # background the process & log
这不太可能是 nginx 配置问题。
几乎可以肯定的是，后端实际上正在崩溃（或只是终止连接），而不是给出格式错误的响应。即错误消息告诉您问题是什么，但您正在寻找错误的位置来解决它。
您没有提供足够的信息来允许用户找出确切的问题是什么，但如果我不得不猜测：
通常返回 872 行，在 MySQL 中运行需要 2.07。然而，它返回了大量信息。
要么是某个地方超时，要么是内存不足。
我遇到了同样的问题，为我解决的方法是将我的域添加到 settings.py 例如：
ALLOWED_HOSTS = ['.mydomain.com', '127.0.0.1', 'localhost']
对于同样的问题，我的意思是我什至无法加载页面，nginx 会返回 502，而不提供任何可能导致应用程序崩溃的页面。
nginx 日志包含：
Error: upstream prematurely closed connection while reading response header from upstream
在您的@django位置块中，您可以尝试添加一些代理读取和连接超时属性。例如
location @django {
proxy_read_timeout 300;
proxy_connect_timeout 300;
proxy_redirect off;
# proxy header definitions
...
proxy_pass http://django;
}
有时可能是权限问题。检查项目目录的权限。
这可能是 uwsgi 配置问题，而不是 Nginx 的问题。我看到你有 uwsgi 进程 = 2 和 harakiri = 120，你是否尝试过一一更改这些以及其他字段？
我遇到了同样的问题，但这不是我的 NGINX 配置，而是我的 UWSGI 进程在我将 JSON 从客户端发布到服务器时导致超时错误。我的进程为 5，我将其更改为 1，它解决了问题。对于我的应用程序，我只需要一次运行 1 个进程。
这里是工作的 UWSGI 配置自动启动 ini 文件，它解决了超时问题，从而解决了 502 网关问题（上游过早关闭）。
autoboot.ini
#!/bin/bash
[uwsgi]
socket = /tmp/app.sock
master = true
chmod-socket = 660
module = app.wsgi
chdir = home/app
close-on-exec = true # Allow linux shell via uWSGI
processes = 1
threads = 2
vacuum = true
die-on-term = true
希望有帮助。
尝试这个 uwsgi 配置（uwsgi.ini）：
[uwsgi]
master = true
socket = /home/ubuntu/uwsgi.sock
chmod-socket = 666
chdir = /home/ubuntu/project
wsgi-file = /home/ubuntu/project/project/wsgi.py
virtualenv = /home/ubuntu/virtual
vacuum = true
enable-threads = true
daemonize = /home/ubuntu/logs/uwsgi.log
并运行 uwsgi --ini uwsgi.ini
并更新 nginx 配置以连接到创建的套接字
server {
listen 80;
server_name www.domain.com;
location /static {
alias /home/ubuntu/project/static;
}
location /media {
alias /home/ubuntu/project/media;
}
location / {
uwsgi_pass unix:///home/ubuntu/uwsgi.sock;
include uwsgi_params;
}
}
我也遇到了这个问题，间歇性且明显随机的“502上游过早关闭......”。我能够将其追踪到 Cheaper Subsystem：nginx 日志中的“502”条目与 uWsgi 日志中显示的最近生成的工作者的廉价化相匹配：
uwsgi.log
[19/Feb/2024:05:38:11 +0100] "GET ..."
[busyness] 10s average busyness is at 62%, will spawn 1 new worker(s)
Respawned uWSGI worker 3 (new pid: 230651)
[busyness] 10s average busyness is at 5%, cheap one of 3 running workers
worker 2 killed successfully (pid: 229735)
uWSGI worker 2 cheaped.
[19/Feb/2024:05:40:48 +0100] "GET ...]
nginx.log
2024/02/19 05:40:31 [error] 220739#220739: *528254 upstream prematurely closed connection while reading response header from upstream,
05:37 左右出现峰值，导致 uWsgi 产生额外的工作线程。但在 05:40 的某个时刻，峰值消失了，一名工人被便宜了（即被杀），并以某种方式带走了该请求。
我目前正在尝试调整廉价参数：更高的廉价超载值（~30）以避免过早廉价，并启用更便宜的繁忙详细信息以获得有关更便宜的处理的更多信息。
关键是uwsgi一直在杀死和重生工人，无论是通过Cheap还是通过Harakiri。有时，他们会把这个请求带到坟墓里。