Re: Иногда в логах проскакивает SSL write() failed
У меня такое то же иногда проскакивает, был бы признателен, если бы кто-то подсказал из-за чего это Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285121,285460#msg-285460 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
rewrite
Всем привет Прошу помочь перенести редирект с IIS на NGINX Помогите плиз. как он должен выглядеть? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285459,285459#msg-285459 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Количество одновременно ипользуемых proxy pass в в нескольких location
Hello!
On Wed, Aug 21, 2019 at 01:57:10AM -0400, glareboa wrote:
> Приветствую.
>
> Использую такую конструкцию.
>
> http {
> ...
> server {
> listen 80 default_server;
> ...
> location /qwe/
> {
>proxy_pass "http://192.168.1.2:9000";;
> }
>
> location /qwe/
> {
>proxy_pass "http://192.168.1.2:9001";;
> }
>
> location /rty/
> {
>proxy_pass "http://192.168.1.2:9002";;
> }
>
> ...
>
> location /uio/
> {
>proxy_pass "http://192.168.1.2:9012";;
> }
>
>
> }
> }
> Но в браузере отображаются только для 6 или меньше
> источников(http://192.168.1.2:90хх).
> Если вставить адреса http://192.168.1.2:9012 непосредственно в html-файл,
> отображаются все источники.
>
> Получается, что есть ограничение в nginx?
Нет, в nginx ограничений нет. А вот в браузерах - есть
ограничение на максимум 6 соединений к одному доменному имени в
рамках HTTP/1.x, так что если речь идёт про какие-то потоки
данных - то скорее всего вы просто упёрлись в ограничение
бразуера. Обычно это обходят, используя на html-странице
несколько доменных имён, указывающих на один и тот же сервер.
--
Maxim Dounin
http://mdounin.ru/
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Как записать ключи pre-master от tls-соединений, обрабатываемых nginx?
Hello! On Tue, Aug 27, 2019 at 11:50:18PM +0300, Pavel wrote: > Мы состоим в реестре организаторов распространения информации и > поэтому обязаны предоставлять в надзорный орган ключи tls сессий. > > Для таких случаев существует механизм по перехвату вызовов библиотеки > openssl: https://git.lekensteyn.nl/peter/wireshark-notes/tree/src/ > Суть простая - перед запуском демона, обрабатывающего TLS-соединения > клиентов, через LD_PRELOAD подгружается эта библиотека и она > сбрасывает в текстовый файл, указанный в переменой SSLKEYLOGFILE, ключи > pre-master. > > Эта схема срабатывает с апачем, но с энжинксом ключи не пишутся. Нет > ли идей или подсказок из-за чего это может быть и как вообще можно записать > эти самые pre-master keys в энжинксе? [...] > [Service] > Environment=SSLKEYLOGFILE=/tmp/premaster.txt > Environment=LD_PRELOAD=/usr/local/lib/libsslkeylog.so [...] > но тем не менее ключи в файл при обращении к энжинксу по https не > пишутся. Скорее всего причина в том, что переменные окружения очищаются при запуске, подробнее тут: http://nginx.org/r/env -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx полностью загружает весь процессор при reload'e
Hello! On Wed, Aug 28, 2019 at 09:18:44PM +0500, Dmitry Sergeev wrote: > Вообще мне это конечно помогло, но не полностью. На версии 1.0.2g во > время reload'а проц грузит полностью около 5-10 секунд (вместо 40-300 > секунд на 1.0.1u), теперь просто оно особо проблем не вызывает у > клиентов. Но в целом проблема осталась, просто теперь она не так сильно > беспокоит. > > Сейчас задача замедлилась, но в итоге буду поднимать тестовый стенд с > нагрузкой, и смотреть можно ли как-то повлиять на это. > Если конечно тут не подскажут, что еще можно подкрутить. Судя по perf top, проблема в том, что клиенты после reload'а переустанавливают соединения, и это выливается в полный SSL handshake - что и приводит к потреблению CPU. Посмотреть стоит на: - ssl_session_cache - в конфиге его, судя по всему, нет (или соответствующие части конфига не показаны); - сертификаты, в частности - их битность (just in case, RSA более 2048 использовать не надо, это тупо очень дорого с точки зрения процессора) и тип (лучше использовать ECDSA, но тут уже может встать вопрос совместимости; при желании можно использовать и RSA и ECDSA одновременно); - используемые шифры, особенно - шифры с классическим DH для обмена ключами (по умолчанию эти шифры не используются начиная с nginx 1.11.0, но некоторые любят указывать ssl_dhparam в конфиге, да ещё и с параметрами большой битности; не надо так); > Насчет старых клиентов, точно не могу сказать, но есть такой кейс > http://mailman.nginx.org/pipermail/nginx-ru/2019-April/062014.html. Я > хорошо не изучал этот вопрос, но факт остается, на старой версии openssl > ошибок у клиентов в 3-4 раза было меньше. В итоге решили что это клиенты > с очень старым ssl. Как уже говорилось в треде по ссылке, использование OpenSSL 1.0.1u автоматически означет, что HTTP/2 с большинством клиентов работать не будет. С учётом "listen ... http2" в конфиге - обновление до 1.0.2 могло "помочь" просто за счёт того, что HTTP/2 заработал, и количество устанавливаемых соединений соответственно уменьшилось. -- Maxim Dounin http://mdounin.ru/ ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
