我看到一个奇怪的情况，Nginx或者uwsgi似乎正在build立一个长长的传入请求队列，并在客户端连接超时后尝试处理它们。 我想了解并制止这种行为。 以下是更多信息：
我的设置
我的服务器使用Nginx通过Unix文件套接字将HTTPS POST请求传递给uWsgi和Flask。 我基本上都是默认configuration。
读取上游时，Nginx权限被拒绝 – 即使以root身份运行
错误安装烧瓶在windows下virutalenv – 系统找不到指定的文件
在docker上通过Nginx和gunicorn服务烧瓶
问题
运行客户端大约4小时后，客户端机器开始报告所有连接超时。 （它使用Python请求库，超时时间为7秒）大约10分钟后，行为发生了变化：连接开始失败，出现502 Bad Gateway。
我关掉了客户端。 但是在closures客户端电源大约10分钟后，服务器端uWsgi日志显示uWsgi试图回应来自该客户端的请求！ top显示uWsgi使用100％的cpu（每个工人25％）。
Thu May 25 07:36:37 2017 - SIGPIPE: writing to a closed pipe/socket/fd (probably the client disconnected) on request /api/polldata (ip 98.210.18.212) !!! Thu May 25 07:36:37 2017 - uwsgi_response_writev_headers_and_body_do(): broken pipe [core/writer.c line 296] during POST /api/polldata (98.210.18.212) IOError: write error [pid: 34|app: 0|req: 645/12472] 98.210.18.212 () {42 vars in 588 bytes} [Thu May 25 07:36:08 2017] POST /api/polldata => generated 0 bytes in 28345 msecs (HTTP/1.1 200) 2 headers in 0 bytes (0 switches on core 0)
2017/05/25 08:10:29 [error] 36#36: *35037 connect() to unix:/srv/my_server/myproject.sock Failed (11: Resource temporarily unavailable) while connecting to upstream,client: 98.210.18.212,server: example.com,request: "POST /api/polldata HTTP/1.1",upstream: "uwsgi://unix:/srv/my_server/myproject.sock:",host: "example.com:5000"
大约10分钟后，uWsgi活动停止。 当我重新打开客户端时，Nginx很高兴地接受POST请求，但是uWsgi在每个请求中都给出了“写入一个closures的pipe道”的错误，就好像它永久地被破坏了一样。 重新启动Web服务器的docker容器不能解决问题，但重新启动主机修复它。
理论
在默认的Nginx – > socket – > uWsgiconfiguration中，有没有超时请求的长队列？ 我查看了uWsgi文档，看到了一些可configuration的超时时间，但是所有的默认时间都在60秒左右，所以我不明白我是如何处理10分钟的请求的。 我没有改变任何默认的超时设置。
该应用程序几乎所有的1GB RAM在我的小开发服务器，所以我认为资源限制可能会触发行为。
无论哪种方式，我想改变我的configuration，使得> 30秒的请求被删除500错误，而不是由uWsgi处理。 我会很感激有关如何做到这一点的任何build议，以及有关发生的事情的理论。
如何阅读从Nginx传递的python / flask中的UWsgi参数
Python，在Windows 7上使用Flask应用程序configurationmod_wsgi
捕获通过gunicorn运行的python标准输出
我的Python打印在uWsgi下用Nginx部署在Flask的哪里？
这听起来像你的后端代码可能是错误的，因为它需要太长的时间来处理请求，没有实现任何类型的速率限制的请求，并没有正确捕获，如果任何底层连接已经终止（因此，你收到代码尝试写入封闭管道的错误，甚至可能在底层连接终止很久之后开始处理新的请求。
根据http://lists.unbit.it/pipermail/uwsgi/2013-February/005362.html ， if not uwsgi.is_connected(uwsgi.connection_fd()) ，您可能想在您的后端中止处理。
您可能需要探索https://uwsgi-docs.readthedocs.io/en/latest/Options.html#harakiri 。
作为最后的手段，按照Re：了解“proxy_ignore_client_abort”功能（2014） ，您可能希望将uwsgi_ignore_client_abort从off更改为on ，以便不丢弃正在传递给上游的正在进行的uWsgi连接（即使客户端然后断开连接），以便不接收来自uWsgi的封闭的管道错误，并且在Nginx本身内强制执行任何可能的并发连接限制（否则，如果客户端断开连接，则uWsgi的连接将被Nginx丢弃，并且Nginx将不会提示在uWsgi中有多少个请求正在排队以供后续处理）。
似乎对Nginx uWsgi的DoS攻击使用Nginx 502,504,500返回100％的cpu使用率.IP欺骗在DoS攻击中很常见。 排除通过检查日志。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
