Похоже, DoS-атака на Nginx uWSGI возвращает 100% загрузку ЦП с Nginx 502, 504, 500. Подделка IP распространена в DoS-атаке. Исключить, проверив логи.

людаю странную ситуацию, когда Nginx или uwsgi, похоже, создают длинную очередь входящих запросов и пытаются обработать их через много времени после истечения времени ожидания клиентского соединения. Я хотел бы понять и остановить это поведение. Вот больше информации:

Моя настройка

Мой сервер использует Nginx для передачи запросов HTTPS POST в uWSGI и Flask через файловый сокет Unix. У меня есть в основном конфигурации по умолчанию на все.

У меня есть клиент Python, отправляющий 3 запроса в секунду на этот сервер.

Эта проблема

После запуска клиента в течение примерно 4 часов клиентский компьютер начал сообщать о том, что для всех соединений истекло время ожидания. (Он использует библиотеку запросов Python с 7-секундным таймаутом.) Примерно через 10 минут поведение изменилось: соединения начали обрываться с 502 Bad Gateway.

Я выключил клиент. Но в течение примерно 10 минут ПОСЛЕ выключения клиента журналы uWSGI на стороне сервера показывали, что uWSGI пытается ответить на запросы от этого клиента! А такжеtop показал uWSGI, используя 100% ЦП (25% на одного работника).

В течение этих 10 минут каждыйuwsgi.log запись выглядела так:

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)

И Nginxerror.log показывает многое из этого:

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 выдает одну и ту же ошибку «запись в закрытую трубу» при каждом запросе, как будто он каким-то образом не работает. Перезапуск Docker-контейнера веб-сервера не устраняет проблему, но перезагрузка хост-машины устраняет ее.

Теории

В конфигурации по умолчанию Nginx -> socket -> uWSGI есть длинная очередь запросов без тайм-аута? Я просмотрел документы uWSGI и увидел множество настраиваемых тайм-аутов, но все они по умолчанию составляют около 60 секунд, поэтому я не могу понять, как я вижу запросы 10-минутной давности. Я не изменил никаких настроек времени ожидания по умолчанию.

Приложение использует почти все 1 ГБ ОЗУ на моем маленьком dev-сервере, поэтому я думаю, что ограничение ресурсов может быть причиной такого поведения.

В любом случае, я бы хотел изменить свою конфигурацию так, чтобы запросы старше 30 секунд сбрасывались с ошибкой 500, а не обрабатывались uWSGI. Буду признателен за любые советы о том, как это сделать, и теории о том, что происходит.

Ответы на вопрос(2)

Ваш ответ на вопрос