Тайм-аут соединения nginx и проблема закрытого соединения клиента

21

У меня есть этот сервер nginx, работающий на AWS, и он работал нормально до недавнего времени, когда несколько пользователей начали жаловаться на то, что веб-сайт не открывается, пока они не сделали около 10 попыток получить к нему доступ.

Я никогда не был в состоянии повторить проблему со своей стороны. Я использую гугл днс т.е. 8.8.8.8 и когда я изменил то же самое для одного из пользователей, сайт работал нормально. Теперь это может быть причиной, или это может быть просто совпадением.

Я нашел это в журнале ошибок - 

2014/05/29 13:46:15 [info] 6940#0: *150649 client timed out (110: Connection timed out) while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150670 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150653 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:20 [info] 6940#0: *150652 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80

И в некоторых местах даже это - 

2014/05/29 13:46:53 [info] 6940#0: *150665 client closed connection while waiting for request, client: xx.xxx.xxx.xx, server: 0.0.0.0:80
2014/05/29 13:46:53 [info] 6940#0: *150660 client xx.xxx.xxx.xx closed keepalive connection

Примечание - разместили xx.xxx.xxx.xx для IP-адреса клиента

Вот конфиг nginx - 

server {
    listen       80;
    server_name  somedomain.com  www.somedomain.com;

    #charset koi8-r;
    #access_log  /var/log/nginx/log/host.access.log  main;

    root        /var/www/somedomain/current/app/webroot;
    index       index.php index.html index.htm;

    ... couple of location rules ...
}

Я был бы очень признателен за любую помощь.

Благодарность

nginx timeout keepalive Нитиш Дхар
источник
1
Это может быть проблемой с подключением разработчиков к серверу, а не к серверу. Поскольку вы не можете воссоздать проблему, а сам сервер регистрирует тайм-аут соединения с клиентом, мы должны подозревать, что разработчик может находиться за брандмауэром, и у них есть внутренние проблемы с сетью, которые вызывают это.
Эндрю С.
Вы можете попробовать отключить Keep-Alive только в качестве теста для этой проблемы. Я не уверен, что трафик попадает на ваш веб-сервер, но Keep-Alive может привести к тому, что вы достигнете предела одновременности в вашей конфигурации nginx. Вот больше информации: nginx.com/blog/http-keepalives-and-web-performance
Альфонсо
1
@NitishDhar Вам удалось решить эту проблему? Я тоже сталкиваюсь с той же проблемой и просто не знаю. Буду рад, если вы сможете поделиться решением.
Итан Коллинз
2
Вопросы: сервер находится за балансировщиком нагрузки или межсетевым экраном? NAT задействован? Существует ли какой-либо туннель между сервером и Интернетом? Причина, по которой я спрашиваю, заключается в том, что это похоже на то, что происходит, когда в пути есть туннель, и кто-то заблокировал все ICMP, что нарушает обнаружение Path MTU.
GeorgeB
Кроме того, каков вывод команды cat / proc / sys / net / ipv4 / tcp_mtu_probing
GeorgeB

Ответы:

6

Судя по журналу, предоставленному вами Nginx, соединения между вашим сервером и пользователями нестабильны или медленны. Пожалуйста, попробуйте tracerouteваш IP-адрес клиента или его / ее шлюз с вашего сервера. Кроме того, pingваш клиент IP-адрес в течение длительного времени, чтобы увидеть скорость потери пакетов и время отклика. MTU может быть еще одним источником этой проблемы. Проверьте, можете ли вы связаться со своим клиентом с MTU = 1500 (Mac:) ping -D -s 1472 xx.xx.xx.xx.

Кстати: если ваш сервер или клиент находится в Китае, эта проблема обычно не ваша вина. Известно, что GFW случайным образом отбрасывает пакеты между границами, чтобы преднамеренно ухудшить качество международной связи.

Линфэн Сюн
источник
К вашему сведению, GFW = Великий брандмауэр Китая.
Рошан
0

Как предполагается в этом комментарии, это, вероятно, ошибка пользователя, и они закрывают соединение (умышленно или нет). Попробуйте надежно воспроизвести проблему. Исключите это в другом месте, и если это будет только это место, они должны будут устранить неполадки на их конце. Попробуйте из разных браузеров / компьютеров, а затем проверьте надежность сети.

Питер
источник
0

Эти записи журнала похожи на записи, которые появляются, когда я использую такие инструменты, как OpenVAS, для сканирования сервера. Эти инструменты создают плохие соединения, работают медленно или иным образом плохо работают; nginx просто сообщает, что какое-то соединение не воспроизводилось нормально. Если весь трафик поступает из одного и того же источника, и он быстрый и не имеет других законных запросов для сопоставления в журнале доступа, скорее всего, это всего лишь бот-сканер.

Эти сканеры также могут загружать ваше приложение, что может замедлить работу другого легитимного трафика.

edoceo
источник