Конфигурация ниже, для стримов Собственно, именно из-за него возникло требование использовать TRANSPARENT -- обязательно нужно знать IP-адрес клиента. Возможно есть другой вариант, но я его, к сожалению, не знаю

Ну и "чтоб два раза не вставать" так же сделано по остальным приложениям (для HTTPS). Тут еще небольшой ньюанс -- производитель приложения явным образом не поддерживает правки server.xml (в частности, добавления org.apache.catalina.valves.RemoteIpValve) и восстанавливает его из своих ранее сгенеренных шаблонов перед каждым запуском. Можно прописать его в этих шаблонах, но при любой модификации через управлялку или апгрейда приложения они перегенерятся и придется прописывать по-полной. Ничего сложного, но можно и забыть. С TRANSPARENT-proxy такой проблемы вовсе нет

И как я уже говорил, озвученные проблемы стреляют что через обычный, что через TRANSPARENT прокси.

Андрей ПанфиловВячеслав Любомудров,

тогда все равно смысл использования nginx в борьбе за ip-адрес клиента не ясен:
от клиента http-трафик и не http-трафик может идти по разным путям, поэтому ожидание что на входе у вас будут одинаковые source ip несколько неправильное
Не очень понятно про мои ожидания и смесь HTTP и не HTTP траффика
Андрей Панфиловсам nginx в случае не-HTTP трафика у вас никакой полезной функции не выполняет (ну вот в случае HTTP можно получить профиты в виде кеширования, офлоада SSL и пр., а у вас он даже не балансирует) - можно же просто обычным NAT обойтись если так уж нужен source ip
Именно для балансировки (пока в UPSTREAM указан один сервер, но это не значит, что он всегда будет один)

Андрей, вот честно, Вы используете/использовали nginx?
Теорию я ведь и сам неплохо знаю

Спасибо, будем посмотреть

Возможно
Смотрю пока по HAProxy, примерно то же самое, со своими минусами (нет кэширования и буферизации) и плюсами (возможность кластеризации). Собственно, он рассматривался в дальнейшем как балансировщик двух nginx-ов
Но, оказывается он умеет и как transparent reverse proxy, так что наверное, есть смысл с ним попробовать (хрен с ним, с кэшированием, но буферизации, в терминах nginx, жалко)
Тем более что да, статистика там не в пример богаче

По поводу RP_FILTER -- там один интерфейс, какой reverse path

Вот про net.ipv4.ip_nonlocal_bind мне непонятно, root и так может биндить нелокальные адреса, а HAProxy, насколько понимаю, работает только от рута.

Спасибо
Посмотрел по статистикам netstat -s / nstat -asz, ReversePathFilter по нулям, отрубать пока не стал (я в отпуске и что-то ломать сейчас нежелательно)
Логирование "марсиан" включил, но скорее всего это тоже пустой номер

PS. Вот только к озвученным в первом посте вопросам это не имеет отношения

Basil A. SidorovВячеслав ЛюбомудровКонфигурация ниже, для стримов9094 кто слушает? Тоже котяра или отдельная прикладуха?Tomcat
Приложение закрытое
Basil A. SidorovP.S. Отвыкайте править server.xml - читайте документацию на вашу версию .Это относилось только к org.apache.catalina.valves.RemoteIpValve , т.е. к HTTP(S). Это рекомендация поставщика приложения
В случае TRANSPARENT reverse proxy (а его все-равно приходится использовать) это не нужно вовсе.

Basil A. SidorovЯ умываю руки ...Чище будут
Basil A. SidorovРазработчик, что - открывает сокеты прямо в собственном приложении или, всё-таки, использует сконфигурированные коннекторы?Естественно, описан коннектор <ля-ля-ля port=9094 protocol=...ibtp..> (не очень хочется светить разработчика). Общается клиентское Java standalone приложение (или сервлет) с сервером, со своим шифрованием и т.д.
Но то, что там не ходят HTTP заголовки -- однозначно
Basil A. SidorovЗа каким вообще лешим, вам приспичило делать странное, полностью игнорируя документированную штатную возможность?Что здесь странного: использование NGINX в принципе или возможность его работы как TRANSPARENT reverse proxy?
Дык использование NGINX широко освещается (и рекомендуется) в "этих ваших интернетах" как пример быстрого и легкого в том числе балансировщика, в отличии от "более ресурсоемкого и неповоротливого" апача? И именно NGINX ставится впререди апача, а не наоборот. И по статистике (врут, конечно) число таких конфигураций весьма велико
TRANSPARENT можно не обсуждать, с этим проблем пока нет
Basil A. SidorovЕсли вы не можете (уж не знаю почему) использовать AJP-коннекторыНаверное, потому, что разработчик решил использовать свой протоколBasil A. Sidorovвозьмите индейца, mod_proxy, mod_proxy_balancer, mod_proxy_http.Скажем так, "сварщик я ненастоящий", поэтому глубоко возможностей апача я не знаю
Но, опять же в терминах "легкий/ресурсоемкий" NGINX выигрывает
Вот подсказали альтернативу -- HAProxy, но вроде как с функциональностью NGINX-а разница небольшая.

Я вообще просто спросил, сталкивался ли кто-нибудь с подобными граблями при работе с NGINX-ом
Нет, так нет