Комментарии 68
Вопрос не в nginx, а в openssl, с которым он собирается.
Комментарием выше в общем то я также, как и Вы, указал на openssl.
Я так и сделал на Debian Jessie:)
Я для сentos7, кстати, делал скрипт автоматической сборки правильного nginx 1.11.3 с патчами от CloudFlare (даёт ALPN http/1.1/spdy/h2), OpenSSL 1.0.2i, ngx_pagespeed, brotli, ngx_small_light, njs и echo-nginx-module.
Не стоит эти патчи от CloudFlare использовать. Почему не стоит я давал подробное разъяснение у нас в багтрекере: http://trac.nginx.org/nginx/ticket/1029#comment:2
Появление этих патчей было актом самопиара CloudFlare, а не попыткой сделать что-то полезное для общества.
Installing with make install...
========================= Installation results ===========================
make -f objs/Makefile install
make[1]: Entering directory '/opt/nginx-1.11.5'
test -d '/etc/nginx' || mkdir -p '/etc/nginx'
test -d '/usr/sbin' \
|| mkdir -p '/usr/sbin'
test ! -f '/usr/sbin/nginx' \
|| mv '/usr/sbin/nginx' \
'/usr/sbin/nginx.old'
cp objs/nginx '/usr/sbin/nginx'
test -d '/etc/nginx' \
|| mkdir -p '/etc/nginx'
cp conf/koi-win '/etc/nginx'
cp conf/koi-utf '/etc/nginx'
cp conf/win-utf '/etc/nginx'
test -f '/etc/nginx/mime.types' \
|| cp conf/mime.types '/etc/nginx'
cp conf/mime.types '/etc/nginx/mime.types.default'
test -f '/etc/nginx/fastcgi_params' \
|| cp conf/fastcgi_params '/etc/nginx'
cp conf/fastcgi_params \
'/etc/nginx/fastcgi_params.default'
test -f '/etc/nginx/fastcgi.conf' \
|| cp conf/fastcgi.conf '/etc/nginx'
cp conf/fastcgi.conf '/etc/nginx/fastcgi.conf.default'
test -f '/etc/nginx/uwsgi_params' \
|| cp conf/uwsgi_params '/etc/nginx'
cp conf/uwsgi_params \
'/etc/nginx/uwsgi_params.default'
test -f '/etc/nginx/scgi_params' \
|| cp conf/scgi_params '/etc/nginx'
cp conf/scgi_params \
'/etc/nginx/scgi_params.default'
test -f '/etc/nginx/nginx.conf' \
|| cp conf/nginx.conf '/etc/nginx/nginx.conf'
cp conf/nginx.conf '/etc/nginx/nginx.conf.default'
test -d '/var/run' \
|| mkdir -p '/var/run'
test -d '/var/log/nginx' \
|| mkdir -p '/var/log/nginx'
test -d '/etc/nginx/html' \
|| cp -R html '/etc/nginx'
test -d '/var/log/nginx' \
|| mkdir -p '/var/log/nginx'
make[1]: Leaving directory '/opt/nginx-1.11.5'
======================== Installation successful ==========================
Copying files to the temporary directory...OK
Stripping ELF binaries and libraries...OK
Compressing man pages...OK
Building file list...OK
Building Debian package...OK
Installing Debian package...OK
Erasing temporary files...OK
Writing backup package...OK
OK
Deleting temp dir...OK
**********************************************************************
Done. The new package has been installed and saved to
/opt/nginx-1.11.5/nginx_1.11.5-1_amd64.deb
You can remove it from your system anytime using:
dpkg -r nginx
**********************************************************************

Всё должно работать без проблем, если правильно настроить. Реальный IP передается через proxy protocol.
URI никогда не передается по proxy protocol, это уже часть HTTP запроса, которых может быть много в одном соединении. Спецификация тут: http://www.haproxy.org/download/1.5/doc/proxy-protocol.txt
SSL или не SSL, а также детали соединения — не являются частью URI.
Типичный HTTP/1.1-запрос выглядит так:
GET /blog HTTP/1.1
Host: example.com
User-Agent: Mozilla...
Accept: text/html
и он так выглядит вне зависимости от того, по SSL/TLS он сделан или поверх голого TCP.
URI в данном случае /blog
. POST-запросы с этой точки зрения выглядят точно также, только еще содержат тело. Так что ваша фраза:
На стороне nginx не реально воссоздать GET запрос и реальный IP-адрес клиента (какие данные точно не передаются сейчас не скажу). С телом POST и т. п. запросов проблем как раз не заметил
вообще лишена смысла.
Если вам обязательно знать, используется ли SSL/TLS или нет на соединении с клиентом с haproxy, так разнесите также эти соединения по разным портам. Пусть haproxy проксирует либо на один порт, либо на другой. В чем проблема?
Либо можно выкинуть haproxy, поставить nginx на его место — и тогда будет счастье. Всю информацию можно будет передавать в заголовках.
Проблема в том, это сильно усложнит настройку, нужно будет в конфиги haproxy передавать не просто пару хост: порт, и даже не несколько таких пар, а тройку хост: порт: схема и прописывать в разные места конфига для разных схем. Ну и выкинуть haproxy нельзя — корпстандарт.
Docker в nginx:
docker run nginx
и никаких комплиляций
Забавно наблюдать старательно сконфигурированный A+ в ssllabs и дырку в безопасности в виде:
resolver 8.8.4.4 8.8.8.8;
Процитирую документацию:
Для предотвращения DNS-спуфинга рекомендуется использовать DNS-серверы в защищённой доверенной локальной сети.Встроенный резолвер заточен на производительность, для чего пришлось несколько пожертвовать безопасностью. Он не рассчитан на применение в незащищенных сетях. Не говоря уж о том, что задержка при обращении к гугловому серверу может сказаться на скорости обработки запроса, а его недоступность или неправильная работа и вовсе привести к недоступности вашего сервиса.
Правильно использовать собственный DNS-сервер. Например, установленный на той же машине:
resolver 127.0.0.1;
$ cat /etc/resolv.conf
nameserver some.ip
а потом через тот ip любой реальный домен проверь.
И еще вопрос. А certbot теперь делает service nginx reload, после обновления сертификата? А то через 3 месяца может ждать сюрприз. 100% раньше не делал и в кроне приходилось дописывать эту строчку.
$ cat /etc/cron.d/certbot
# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc. Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
0 */12 * * * root test -x /usr/bin/certbot -a \! -d /run/systemd/system && perl -e 'sleep int(rand(3600))' && certbot -q renew
Даже статья на Хабре уже была полгода назад конкретно про эту особенность… Если дублируете, то хотя бы пишите полностью причины.
apt-get source nginx
dpkg build-package -b
dpkg -i our-built-package.deb
apt-mark hold our-built-package
Сам развлекался тем что собирал nginx + ngx_pagespeed + ngx_brotli :)
пример можно посмотреть на https://escapeteams.ru — позаходить под разными браузерами и посмотреть что он подставляет вместо картинок и стилей.
в целом довольно прикольно, единственное — есть некоторые сложности с кэшем, иногда проблемы с его инвалидацией при деплое новой версии. Но впринципе решается rm -rf /tmp/ngx_pagespeed && /etc/init.d/nginx restart :).
Но когда я сравнил нагрузку на проц (через apache benchmark) с включенным pagespeed и выключенным, то прям как-то призадумался.
Я еще тогда экспериментировал с Google PageSpeed Insights и пытался понять, на сколько вообще возможно получить там 100 в скорости для мобил. Самое интересное, что даже на выделенном сервере, с одним сайтом, который в разработке, Google PageSpeed Insights часто ругался на то, что время ответа больше 0.2с. Кстати, у вас такая же проблема иногда появляется.
100 баллов легкой кровью так и не получилось получить из-за ошибки:
Удалите код JavaScript и CSS, блокирующий отображение верхней части страницы
+ ошибок на малое время кеширование сторонних скриптов (яндекс метрика, фейсбук и т.д.)
Не то, что бы я считал Google PageSpeed Insights эталонным измерителем производительности.
Но в целом с точки зрения открытия сайта — на мой взгляд стало лучше. Всё-таки ngx_pagespeed делает всякие полезные вещи типа минификации/конвертации картинок под конкретные браузеры и прочее, это точно не то, о чем хотелось бы постоянно думать :).
Меня тоже долго останавливало перенос js в днище сайта, но оказалась проблема больше психологическая чем технологическая — большая часть завелась практически без проблем.
Никогда не делайте make install на debian подобных дистрибутивах, вы потом заколебетесь вычищать систему от разного рода говна.
Все гораздо проще:
mkdir /opt/nginx && cd /opt/nginx
wget https://www.openssl.org/source/openssl-1.0.2j.tar.gz && tar -vzxf openssl-1.0.2j.tar.gz && rm openssl-1.0.2j.tar.gz
apt-get source nginx && apt-get build-dep nginx
cd nginx-1.11.5
Открываем файл debian/rules
в секцию config.status.nginx: config.env.nginx в параметр CFLAGS=
после --with-stream_ssl_preread_module
добавляем --with-openssl=/opt/nginx/openssl-1.0.2j
в секцию config.status.nginx_debug: config.env.nginx_debug в параметр CFLAGS=
после --with-stream_ssl_preread_module
добавляем --with-openssl=/opt/nginx/openssl-1.0.2j
Собираем nginx и модули:
dpkg-buildpackage -b
Устанавливаем nginx:
dpkg -i nginx_1.11.5-1~jessie_amd64.deb
Profit.
Получаем:
nginx version: nginx/1.9.10
built with OpenSSL 1.0.2j 26 Sep 2016
TLS SNI support enabled
configure arguments: --with-cc-opt='-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2' --with-ld-opt='-fPIE -pie -Wl,-z,relro -Wl,-z,now' --prefix=/usr/share/nginx --conf-path=/etc/nginx/nginx.conf --http-log-path=/var/log/nginx/access.log --error-log-path=/var/log/nginx/error.log --lock-path=/var/lock/nginx.lock --pid-path=/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --with-debug --with-pcre-jit --with-ipv6 --with-http_ssl_module --with-http_stub_status_module --with-http_realip_module --with-http_auth_request_module --with-http_addition_module --with-http_dav_module --with-http_geoip_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_v2_module --with-http_sub_module --with-http_xslt_module --with-stream --with-stream_ssl_module --with-mail --with-mail_ssl_module --with-threads --add-module=/build/nginx-1.9.10/debian/modules/nginx-auth-pam --add-module=/build/nginx-1.9.10/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-1.9.10/debian/modules/nginx-echo --add-module=/build/nginx-1.9.10/debian/modules/nginx-upstream-fair --add-module=/build/nginx-1.9.10/debian/modules/ngx_http_substitutions_filter_module
SPDY индикатор в google chrome после этих процедур становится вполне себе синеньким, и рассказывает нам про HTTP/2 enabled.
Как использовать backports (если кто не знает) — написано в Debian wiki
Как я пытался включить http2 у себя на проекте с nginx