Код состояния 460 в Application Load Balancer

Я вижу некоторое количество 460 кодов состояния в журналах моего Application Load Balancer. Я не вижу в этих кодах никаких закономерностей в отношении времени, серверов или URL-адресов запросов. Согласно этому сообщению на форуме, 460 означает:

Клиент закрыл соединение с ALB до того, как истечет тайм-аут простоя на внешнем или внутреннем подключении.

Я вижу, как запрос поступает на внутренний сервер, а сервер обрабатывает запрос без проблем и очень быстро. Почему возникают эти ошибки? Этот ALB выполняет значительный объем трафика с 6-8 внутренними серверами.

Пример журнала ALB:

https 2017-01-30T22:46:27.451363Z app/LOAD-BALANCER/bbab458ad0b80d X.X.X.X:55999 10.5.X.X:80 0.000 -1 -1 460 - 132 0 "GET https://www.website.com:443/app/page HTTP/1.1" "-" ECDHE-RSA-AES128-SHA TLSv1 arn:aws:elasticloadbalancing:us-west-2:743462462234:targetgroup/TARGET-GROUP/e6120e5adr245b79107e "Root=1-588fc23e-77aea5adf4534af3de09659d13a08"

Пример журнала NGINX из бэкэнда:

X.X.X.X 1485807955.048 www.website.com /app/page - GET 200 - 0.056 24 text/html; charset=UTF-8 -


http nginx amazon-web-services amazon-ec2 elastic-load-balancer
person gkrizek    schedule 01.02.2017    source источник
comment
Как вы это исправили? В принятом ответе говорится об изменении тайм-аута клиента, что невозможно, когда клиент является браузером ... Вы нашли что-нибудь еще, имеющее отношение к проблеме?   -  person comfytoday    schedule 22.03.2018

Ответы (2)


arrow_upward
19
arrow_downward

Документация для кода состояния 460 обновлена ​​для балансировщиков нагрузки приложений.

Эта ошибка возникает, когда балансировщик нагрузки получил запрос от клиента, но клиент закрыл соединение с балансировщиком нагрузки до истечения периода тайм-аута простоя.

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

Вы можете прочитать полный документ здесь: http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-troubleshooting.html#http-460-issues

person Atharva Johri    schedule 02.05.2017
comment
Является ли «клиент» в данном случае браузером пользователя? В какой ситуации браузер пользователя разорвет соединение? - person comfytoday; 05.01.2018
comment
это может быть что угодно, даже запрос на завиток. Если это браузер, вы можете увидеть это: stackoverflow.com/questions/5798707/browser-timeouts - person Atharva Johri; 02.02.2018
comment
Если клиент закрыл соединение, кто получит ответ 460? - person tusharmath; 18.09.2020
comment
Никто его не получит. Он просто отображается в журналах ALB. - person mbbush; 11.05.2021

arrow_upward
7
arrow_downward

Вероятно, в этой последовательности есть разгадка:

0.000 -1 -1 460 -

Поля: request_processing_time, target_processing_time, response_processing_time, elb_status_code, target_status_code.

Поля target_processing_time и response_processing_time, равные -1, предполагают, что возникла проблема с отправкой запроса на целевой хост согласно http://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer.-access-logs.html

Убедитесь, что ваша цель получает запрос, возможно, возникла проблема с конфигурацией или сетью между ALB и целью. ALB вставляет заголовок трассировки X-Amzn-Trace-Id в запрос, когда он отправляет его на цель, возможно, зарегистрируйте их на своем сервере NGINX и посмотрите, получаете ли вы конкретные запросы, которые не работают.

Я столкнулся с аналогичной проблемой, и, похоже, это связано с тем, что наши хосты отбрасывают TCP-пакеты из-за разгрузки TCP на наших хостах Windows.

person AaronH    schedule 29.03.2017