Comments 18
server {
listen 443 ssl;
server_name yourdomain.com;ssl on;
из статьи в статью наблюдаю это: ssl on. Однако, вот тут https://nginx.org/ru/docs/http/ngx_http_ssl_module.html#ssl написано:
Эта директива устарела в версии 1.15.0 и была удалена в версии 1.25.1. Вместо неё следует использовать параметр
sslдирективы listen.
У вас в примере кстати уже в listen этот параметр указан (я бы туда и http2 добавил ещё).
Действительно, ssl on уже не нужно, поправлю.
Я ещё вторую часть хочу выпустить, там как раз и про http2 будет с кратким пояснением, а зачем вообще это нужно
Было бы неплохо про http3 - как включить, и какие настройки и для чего при этом нужны (и нужно ли его включать и когда?)
Про http2 в nginx на хабре есть вроде бы статьи, но не очень-то новые (правда, на разных сайтах таких тоже хватает). А вот про http3 статей уже меньше, и судя по всему, при стандартном использовании nginx + openssl есть проблемы с протоколом quic, и не всё просто с этим...
я пару месяцев назад поднимал хттп3, правда nginx брал не из хаба готовый, а компилил с добавлением поддержки. в целом все завелось без особых сложностей, если не считать поиск докерфайла на гитхабе готового.
есть еще вариант от команды в рф - форк angie - там хттп3 из коробки, но конфиг чуть не совместим из-за названия nginx в директивах)
Много спорного, неточных и вовсе неверных формулировок. Путаете абсолютные пути с относительными, например. Видно не вполне полное понимание, как работают префиксные локейшены. А за такой набор TLS-протоколов в 2024 году любой айтисек душу вынет :)
опердили, тоже хотел написать
@RostislavDuginследует познать хотя бы сей сервис: ssllabs.com/ssltest/
Я, честно говоря, не уверен, что веб-разработчикам стоит вникать в такие дебри как градации крутости настройки SSL, да и вообще настройки ингресса тоже :) Предлагаю оставить Кесарю кесарево - то есть админам админское.
Но если уж прямо сильно хочется, то есть дружелюбная страничка с крыжиками, доступная любому фуллстеку - https://ssl-config.mozilla.org/
На самом деле я согласен на 100%. Однако встречаю в своей практике приложения которые неистово требуют иметь доступ к сертификату, хотят знать имя домена, список белых ip, ругаются когда порт который они слушают отличается от порта который виден клиентам по ту сторону ингреса.. В общем требуют того на что нормальным приложениям должно быть плевать так как это не их головняк.
Я тоже так думал. Но найти адекватного девопса для настройки всего огорода порой ой как не просто и приходится самому вникать будучи фуллстек разработчиком и в докер и в настройки nginx и настройки elk, registry, mongodb. В идеальных условиях конечно разработчик не должен касаться этих вопросов.
access_log on;
Эту глупость уже лет 15 таскают по интернетам. Прочитать два абзаца документации, и убедится, что глупость - видимо, очень сложно.
Если переадресация временная, то стоит использовать 302 вместо 301. При 301 браузеры навсегда (до очистки данных сайтов) запоминают переадресацию и больше на оригинальный сайт не ходят
nginxconfig.io уже не торт?
Уже нет, сайт помер и переарресация идет на www.digitalocean.com и притом давно, пару лет как минимум судя по web.archive.org
У nginx кстати есть свой бесплатный проверятор, правда он по другому работает - nginx amplify
Если пишешь про ssl_stapling, то напиши и про resolver, который потребуется для его работы.
ssl_session_cache shared:SSL:50m;
Это для какой посещаемости и для какой нагрузки такие настройки? Это настройка примерно на 200000 сессий, не сильно ли много?
Nginx: шпаргалка