Запрос POST повторяется с nginx loadbalanced сервер (состояние 499)
У меня нет всей своей ссылки на эту систему, но я знаю, что объектами USERS можно управлять через PHP и много других вещей. Но существует важный фактор. Активный каталог не позволит Вам изменять что-либо о паролях через LDAP, если SSL не будет включен. Это означает, что необходимо было установить сертификат SSL DomainController на DC, и это может означать, что необходимо установить инфраструктуру CA.
- PHP изменение Пароля AD.
Из этой темы форума мы узнали, что виновником может быть SPDY. Для этого пользователя это кажется решением отключить его, и у нас не было двойных сообщений с момента его отключения.
Точная проблема, кроме «SPDY сделал это», на данный момент неизвестна, побочные эффекты предложенного решение (отключить SPDY), очевидно, «больше не SPDY», но мы можем жить с этим.
Пока ошибка не выскочит снова, я называю это «исправлением» (или, по крайней мере, решением проблемы).
] edit: (25-02-2014) мы больше не видели, чтобы эта проблема возникала, так что это действительно похоже на долгосрочное решение.
Краткий ответ: попробуйте это для вашего блока локации:
location / {
proxy_read_timeout 120;
proxy_next_upstream error;
proxy_pass http://$backend;
}
Более подробное объяснение:
Думаю, я только что столкнулся именно с описанной вами проблемой:
- Я использую обратный прокси nginx в качестве балансировщика нагрузки
- для длительных запросов, бэкенд получает один и тот же запрос несколько раз
- Журналы доступа nginx в узлах upstream показывают
499статус для этих запросов, и один и тот же запрос появляется в разных версиях апстрима
Оказывается, что на самом деле это поведение по умолчанию для nginx как обратного прокси, и поэтому обновление до более высоких версий не решит эту проблему, хотя и было дано в качестве возможного решения здесь, но это решает другую проблему.
Это происходит потому, что nginx как балансировщик нагрузки выбирает восходящий узел в round-robin моды . Когда выбранный узел заканчивается неудачей, запрос посылается на следующий узел. Здесь важно отметить, что отказ узла по умолчанию классифицируется как ошибка или таймаут . Так как вы не установили proxy_read_timeout, то по умолчанию это 60 секунд. Поэтому после 60 секунд ожидания nginx выбирает следующий узел и посылает тот же самый запрос.
Поэтому одним из решений является увеличение этого таймаута, чтобы ваша долгосрочная операция могла завершиться, например, следующим образом установив proxy_read_timeout 120; (или любой другой лимит, соответствующий вашим требованиям).
Другой вариант - остановить реверсивный прокси от попыток использовать следующий узел, в случае таймаута, установив ошибку proxy_next_upstream;. Или вы можете установить обе эти опции, как предлагалось выше.