Вот, убрали все proxy_*, и уже стало заметно лучше (ещё бы один proxy_set_header убрать для приличия). Можно еще почистить, как минимум, убрав дублирующиеся директивы. Директивы в nginx наследуются с предыдущего уровня, если не переопределены на текущем. Поэтому нет смысла явно указывать gzip on на уровне location, если у вас с уровня http и так унаследуется данное значение (то же касается access_log off). Практически все директивы fastcgi_param присутствуют в файле fastcgi_params, который поставляет с nginx-ом, и достаточно его включит в конфигурацию директивой include. А если ещё выкинуть из конфигурации кучу других настроек, которые не относятся непосредственно к делу, а просто сделаны вами на свой вкус, то конфигурация станет гораздо лаконичнее и за счет этого легче читаться.
Начните с того, что не трогайте настройки, которые вы до конца не понимаете как работают. Вот с какой целью вы выключили proxy_buffering? Это требуется в очень редких случаях, а в остальных ведет только к снижению производительности и расходу ресурсов. Зачем включили multi_accept? Зачем вообще трогали keepalive_timeout? Зачем спиливаете заголовки Range? Хотели защитить Apache, для этого есть директива max_ranges, хотя эта уязвимость была исправлена более 5 лет назад и если вы с тех пор не обновлялись, то у вас в любом случае проблемы. Вы также неправильно понимаете что содержится в переменной $proxy_add_x_forwarded_for. Указание localhost в директиве proxy_pass вместо явного IP-адреса, может приводить к тому, что он будет резолвиться в IPv4 и IPv6, при этом Apache у вас слушает только на IPv4. Остальные настройки тоже вызывают вопросы. К примеру, вы зачем-то зарезервировали место под хранение 10 000 файловых дескрипторов в каждом рабочем процессе на 3 минуты. Иными словами вы предполагаете, что ваш сервер будет практически непрерывно раздавать одновременно до 10 тысяч различных файлов. И это учитывая, что при этом вы установили максимально 1024 соединения на рабочий процесс.
В чем была цель написания данного материала? Статьи тут пишут для того, чтобы делиться знанием, а не незнанием. А вопросы в стиле "помогите разобраться, исправьте мои ошибки" — для этого существуют другие ресурсы. Те же списки рассылки, например. Существует платная поддержка, люди платят деньги, чтобы кто-то их консультировал, исправлял ошибки и обучал.
посмотрел у вас тоже всё начиналось с минусовой кармы ))
Ждать он будет когда попытается открыть другую страницу. Использовать недокументированную директиву, которая недокументирована по той причине, что её лучше не использовать — это плохая идея.
Вы автор коммерческого модуля с закрытым исходным кодом хотите собрать свой модуль для коммерческой версии NGINX Plus;
Когда нужно в репозитории поставлять nginx с разным набором модулей. В первую очередь это интересно, когда некоторые модули требуют внешние зависимости и вы не хотите пользователей заставлять их устанавливать, если они им не нужны. В таком случае, вместо сборки множества разных пакетов nginx с разными комбинациями модулей, достаточно собрать один пакет с nginx и дополнительные пакеты с отдельными модулями.
Большинству же обычных пользователей никакой особой пользы от самостоятельной сборки динамических модулей нет.
Забавно наблюдать старательно сконфигурированный A+ в ssllabs и дырку в безопасности в виде:
Тема всплывала много раз в рассылке, Игорь возражает:
Планами делились на nginx.conf. Можно посмотреть на нашем youtube-канале.
Также на прошлом HL++ был доклад и в этом году будет.
Всё верно. Резолвит указанный server в upstream в фоновом режиме с TTL интервалом.
Вы просто никогда не настраивали sendmail. =)
Посмотрите хотя бы сколько страниц в книге по sendmail:
http://shop.oreilly.com/product/9780596510299.do
Да, Игорь оговорился. В первом случае речь шла о
sendmail, во втором обif.Это не так. В обоих версиях директива может быть задана на уровне location.
Вот, убрали все proxy_*, и уже стало заметно лучше (ещё бы один
proxy_set_headerубрать для приличия). Можно еще почистить, как минимум, убрав дублирующиеся директивы. Директивы в nginx наследуются с предыдущего уровня, если не переопределены на текущем. Поэтому нет смысла явно указыватьgzip onна уровнеlocation, если у вас с уровняhttpи так унаследуется данное значение (то же касаетсяaccess_log off). Практически все директивыfastcgi_paramприсутствуют в файлеfastcgi_params, который поставляет с nginx-ом, и достаточно его включит в конфигурацию директивойinclude. А если ещё выкинуть из конфигурации кучу других настроек, которые не относятся непосредственно к делу, а просто сделаны вами на свой вкус, то конфигурация станет гораздо лаконичнее и за счет этого легче читаться.Практически обо всех, что вы бездумно накрутили. Больше половины директив в данной конфигурации nginx лишено смысла.
Начните с того, что не трогайте настройки, которые вы до конца не понимаете как работают. Вот с какой целью вы выключили
proxy_buffering? Это требуется в очень редких случаях, а в остальных ведет только к снижению производительности и расходу ресурсов. Зачем включилиmulti_accept? Зачем вообще трогалиkeepalive_timeout? Зачем спиливаете заголовкиRange? Хотели защитить Apache, для этого есть директиваmax_ranges, хотя эта уязвимость была исправлена более 5 лет назад и если вы с тех пор не обновлялись, то у вас в любом случае проблемы. Вы также неправильно понимаете что содержится в переменной$proxy_add_x_forwarded_for. Указаниеlocalhostв директивеproxy_passвместо явного IP-адреса, может приводить к тому, что он будет резолвиться в IPv4 и IPv6, при этом Apache у вас слушает только на IPv4. Остальные настройки тоже вызывают вопросы. К примеру, вы зачем-то зарезервировали место под хранение 10 000 файловых дескрипторов в каждом рабочем процессе на 3 минуты. Иными словами вы предполагаете, что ваш сервер будет практически непрерывно раздавать одновременно до 10 тысяч различных файлов. И это учитывая, что при этом вы установили максимально 1024 соединения на рабочий процесс.В чем была цель написания данного материала? Статьи тут пишут для того, чтобы делиться знанием, а не незнанием. А вопросы в стиле "помогите разобраться, исправьте мои ошибки" — для этого существуют другие ресурсы. Те же списки рассылки, например. Существует платная поддержка, люди платят деньги, чтобы кто-то их консультировал, исправлял ошибки и обучал.
Вы меня с кем-то путаете.
Целый ряд вредных советов по настройке nginx, ни чем не обоснованных значений директив.
Нельзя его отключить без правки исходников. Или собрать nginx вообще без поддержки http.
Это здорово, рассказывать в статье про A+ и при этом упоминать настройку, которая может привести к спуфингу. Рекомендации тут мало.
Ждать он будет когда попытается открыть другую страницу. Использовать недокументированную директиву, которая недокументирована по той причине, что её лучше не использовать — это плохая идея.
Этот файл конфигурирует утилиты командной строки, а не библиотеку.
Напишите в поддержку, им видно и ваш аккаунт, и что происходит.
Чтобы иметь 5 директив, которые невозможно настроить правильно в сколь угодно сложном окружении, которым является интернет?
Если очень хочется, то можно уменьшить
ssl_buffer_sizeдо 6-8k и этого более чем достаточно для обеспечения минимального TTFB в большинстве случаев.Динамические модули нужны в двух случаях:
Большинству же обычных пользователей никакой особой пользы от самостоятельной сборки динамических модулей нет.
У автора в статье эта проблема тоже никак не решена. Модули, собранные с другой версией nginx, не загрузятся в новую.