Nginx не перенаправляет при ошибке 404
Есть nginx, и есть два узла, на каждом из которых стоит WildFly10 (один - "железный", другой - в докер-контейнере). На каждом флае установлено приложение. В приложении настроена репликация сессий (они хранятся во внешнем хранилище). Нужно настроить в nginx балансировку round-robin так, чтобы при отказе одного узла осуществлялось перенаправление на второй. Вроде бы ничего сложного. Описываю апстрим так:
upstream my-upstream {
server 111.222.333.444:8082 max_fails=3;
server 111.222.333.444:18082 max_fails=3;
}
Вот так настраиваю проксирование:
location /my_cool_app {
proxy_pass http://my-upstream/my_cool_app;
proxy_next_upstream error timeout http_404 http_500;
proxy_redirect off;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header Host $host:$server_port;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
В итоге получается следующая ситуация: если полностью погасить один флай и дернуть балансируемый URL - nginx перенаправляет на оставшийся рабочий узел, все в порядке. Но если флай не гасить, а просто положить приложение на нем, перенаправления не происходит, а вместо этого видим 404 ошибку - хотя в настройке вроде бы указано, что при 404 ошибке должна происходить передача запроса следующему серверу.
Балансируемый URL: http://111.222.333.444/my_cool_app/
Пример лога при такой ситуации:
[04/Feb/2020:09:40:34 +0300] xxx.xxx.xxx.xxx - - - localhost to: 111.222.333.444:18082, 111.222.333.444:8082: GET /my_cool_app/images/layouts/css/dashboard-icons-28.png HTTP/1.1 [-] upstream_response_t
ime:0.001, 0.010 msec 1580798434.555 request_time:0.011 304 0 "http://111.222.333.444/my_cool_app/css/app.css" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chr
ome/63.0.3239.108 Safari/537.36" "-"
[04/Feb/2020:09:40:34 +0300] xxx.xxx.xxx.xxx - - - localhost to: 111.222.333.444:8082: POST /my_cool_app/getProgress?moduleName=tratata&locale=ru&componentId=progress&methodName=pampampam
HTTP/1.1 [-] upstream_response_time:0.194 msec 1580798434.760 request_time:0.195 200 2320 "http://111.222.333.444/my_cool_app/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTM
L, like Gecko) Chrome/63.0.3239.108 Safari/537.36" "-"
[04/Feb/2020:09:40:35 +0300] xxx.xxx.xxx.xxx - - - localhost to: 111.222.333.444:18082: POST /my_cool_app/getProgress?moduleName=tratata&locale=ru&componentId=progress&methodName=pampampam
d HTTP/1.1 [-] upstream_response_time:0.002 msec 1580798435.817 request_time:0.003 404 74 "http://111.222.333.444/my_cool_app/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML
, like Gecko) Chrome/63.0.3239.108 Safari/537.36" "-"
Почему так происходит - не понимаю (я не админ, но вот довелось столкнуться с задачей). Буду благодарен за любую рекомендацию по поводу того, как это победить.
Ответы (1 шт):
Проблему удалось решить путем добавления в директиву proxy_next_upstream дополнительного свойства non_idempotent, разрешающего повторную отправку запросов с неидемпотентным методом (в том числе POST). Но, разумеется, устанавливая это свойство, нужно понимать, что это может привести к разного рода рискам. Конкретно в нашем случае это делать можно, однако так бывает не всегда и не везде.