我将Puma作为上游应用服务器运行,将Riak作为后台数据库集群运行.当我发送一个请求map - 减少大约25K用户的数据块并将其从Riak返回给应用程序时,我在Nginx日志中收到错误:
上游超时(110:连接超时),同时从上游读取响应头
如果我在没有nginx代理的情况下直接查询我的上游,使用相同的请求,我会得到所需的数据.
一旦放入代理,就会发生Nginx超时.
**nginx.conf**
http {
keepalive_timeout 10m;
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
include /etc/nginx/sites-enabled/*.conf;
}
**virtual host conf**
upstream ss_api {
server 127.0.0.1:3000 max_fails=0 fail_timeout=600;
}
server {
listen 81;
server_name xxxxx.com; # change to match your URL
location / {
# match the name of upstream directive which is defined above
proxy_pass http://ss_api;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache cloud;
proxy_cache_valid 200 302 60m;
proxy_cache_valid 404 …nginx 开源中的上游块允许您启用与反向代理服务器的保持活动连接（文档：http : //nginx.org/en/docs/http/ngx_http_upstream_module.html#keepalive）。
Run Code Online (Sandbox Code Playgroud)Syntax: keepalive connections; Default: — Context: upstream激活缓存以连接到上游服务器。
连接参数设置保留在每个工作进程的缓存中的上游服务器的空闲保持连接的最大数量。
但是，在 nginx 开源中使用上游块有一些警告，特别是：DNS 会被缓存，直到重新启动或重新加载，而不管 TTL。这意味着，如果您使用带有 keepalive 的上游块来反向代理到 AWS 负载均衡器，当负载均衡器 IP 更改时，您将遇到停机时间，除非人员/服务重新加载或重新启动 nginx。“在变量中设置域名”（见下文），允许以 TTL 间隔或任何其他所需的间隔重新解析 DNS，但似乎不允许您启用保持连接。
是否可以在nginx开源中通过域名反向代理到另一台服务器的同时启用keepalive连接，并根据TTL重新解析DNS（无需服务器重新加载/重启）？（Nginx Plus 支持在上游块中重新解析 DNS）。如果单独使用 nginx 开源无法做到这一点，最好将 DNS 解析移动到 HAProxy 等另一层并指向 nginx 上游块中的该层？
nginx keepalive 和 dns 解析器几乎是相同的问题，但有以下区别：在这里，如果无法在 nginx 本身中完成，使用插件或不同的层是可以的。该问题的一个答案提到使用https://github.com/wdaike/ngx_upstream_jdomain，但这个插件似乎多年来没有改变，所以我怀疑将 DNS 解析移到另一层会更容易维护。
在以下对相关问题的评论中出现了类似的问题：Why does nginx proxy_pass close my connection?
在https://www.nginx.com/blog/dns-service-discovery-nginx-plus/ 中，提到了 nginx 的三种 DNS 服务发现方法，看起来它们都不允许重新解析 DNS nginx 重启/重新加载并使用上游参数，例如keepalive：
在 proxy_pass 指令中使用域名 …
在nginx.org中，keepalive config的默认值为-，但是我不太明白这是什么意思。
Syntax: keepalive connections;
Default: —
Context: upstream
This directive appeared in version 1.1.4.
当 Nginxupstream prematurely closed connection while reading response header from upstream尝试通过 HTTP 反向代理到本地 Django 实例（没有 WSGI 中间件）时记录日志时，会发生什么 http/tcp 现象？
冒着激怒社区的风险，我不会包含任何配置，因为虽然我确信它是相关的，但我正在尝试理解这种现象背后的理论。
我和一些队友维护一个网络服务器供内部使用。在/我们的内部工具世界中，事物永远不会产品化。我们通常会尽一切努力为我们的同事提供一些价值。风险和可用资源都很低。
因此，我们在独立建立 Python 2 Django 服务器时犯了一个大罪。没有 WSGI 中间件，没有额外的进程。我已经看到了警告，但我们已经做了我们已经做的事情。
我最近在这个令人讨厌的东西面前建立了一个 Nginx 实例，使我们能够以零停机时间“热交换”我们的 Web 应用程序实例。我仍然没有在中间插入任何东西。Nginx 只是反向代理，通过本地主机 http 到侦听本地主机非标准端口的 Django 实例。
进行此更改后，我们开始看到来自 Nginx 的 502 突发。有几个页面是“实时”的，因为它们会进行一些轮询来检查事物的更新。因此，对于我们拥有的用户数量来说，有“大量”的流量。
我实际上认为无论什么问题在引入 Nginx 之前就已经存在了，但是由于浏览器直接收到错误，它只是重试并且用户看不到问题，而现在他们收到了丑陋的 502 错误消息。
现在的问题是：如果我在 Nginx error.log 中看到upstream prematurely closed connection while reading response header from upstream这实际上意味着什么？我在这个网站上看到了很多关于配置更改建议的线程，这些建议似乎都不适合我，但我正在寻找的是理论。
这个错误是什么意思？当 Nginx 尝试将请求代理给 Django 时，它到底经历了什么？Django 拒绝连接吗？Django 会在连接完成之前关闭连接吗？
如果 Django 正在做这些事情，为什么？是否内存不足、线程不足、是否有某种原因限制线程数量等？
作为临时的周末修复的盲目尝试，我建立了应用程序的第二个实例，并将 Nginx 配置为对它们进行循环负载平衡。它似乎有效，但直到周一早上高峰负载到来时我才能确定。 …