Настройка Nginx, Apache и PHP-FPM для 1С-Битрикс

Веб-стек — это связка программ, которые принимают запрос браузера и возвращают страницу: веб-сервер (nginx или apache), интерпретатор PHP (через PHP-FPM) и кеши байт-кода. Для 1С-Битрикс эта связка определяет, насколько быстро отдаётся первый байт ответа и сколько одновременных посетителей выдержит площадка, прежде чем начнёт тормозить. Настройка Nginx, Apache и PHP-FPM под Битрикс — это тюнинг каждого слоя так, чтобы статика отдавалась мгновенно из кеша браузера и сервера, динамика считалась минимальным числом процессов, а ядро не тратило время на повторную компиляцию кода.

Чаще всего сервер настроен по умолчанию или собран мастером установки и ни разу не пересматривался под реальную нагрузку. На дефолтных настройках nginx не сжимает ответы, не отдаёт статику с длинным сроком кеширования и не использует HTTP/2; PHP-FPM держит мало процессов и упирается в очередь в часы пик; opcache либо выключен, либо настроен на маленький объём памяти и постоянно сбрасывает кеш. В итоге сервер выполняет уйму лишней работы на каждый запрос, TTFB растёт, а в распродажи и рассылки площадка ложится при том запасе мощности, который железо в принципе позволяет.

Что входит в настройку веб-стека

Тюнинг идёт по слоям, и каждый слой снимает свой кусок лишней работы. На фронте nginx мы включаем gzip и brotli для текстовых ответов, отдаём статику (картинки, скрипты, стили, шрифты) с длинными заголовками кеширования и поддержкой HTTP/2, выставляем разумные таймауты и размеры буферов под особенности Битрикс. Для динамики настраиваем fastcgi_cache — микрокеш ответов прямо на nginx, который в пиковые часы отдаёт готовую страницу, не дёргая PHP. Слой PHP-FPM мы перебираем целиком: подбираем модель процессов и число воркеров под объём памяти сервера, выставляем лимиты, добавляем медленный лог для поиска тяжёлых запросов.

Главные направления настройки:

• nginx: кеш статики, gzip и brotli, HTTP/2, таймауты и буферы под Битрикс;
• fastcgi_cache: микрокеш динамических ответов на уровне веб-сервера;
• PHP-FPM: модель и число процессов, лимиты, медленный лог, защита от перегрузки;
• opcache и preload: кеш байт-кода и предзагрузка ядра вместо повторной компиляции;
• лимиты памяти и времени: согласование memory_limit, времени выполнения и размеров загрузок;
• отдача upload и статики напрямую через nginx в обход PHP;
• связка nginx и apache либо перевод на чистый PHP-FPM без apache.

Зачем настраивать opcache и preload

PHP по умолчанию заново читает и компилирует исходники на каждый запрос — для ядра Битрикс это сотни файлов. Opcache хранит уже скомпилированный байт-код в памяти, поэтому интерпретатор не тратит время на повторную работу, а ответ отдаётся быстрее. Preload идёт дальше: он один раз загружает ядро при старте PHP-FPM и держит его в памяти всех процессов. Правильно настроенные opcache и preload заметно снижают время генерации страницы и нагрузку на процессор, особенно на крупных каталогах и сложных шаблонах, где код объёмный.

Зачем нужна связка nginx и apache

Исторически многие площадки Битрикс работают на apache, потому что он понимает файлы .htaccess, которые активно использует CMS. Но apache тяжело отдаёт статику и плохо держит много одновременных соединений. Поэтому классическая схема — поставить nginx фронтом: он принимает все запросы, сам отдаёт статику и загрузки, сжимает ответы и держит HTTP/2, а динамику передаёт apache. Так каждый сервер занимается тем, что у него выходит лучше. Альтернатива — перевести проект на чистый PHP-FPM без apache, перенеся правила из .htaccess в конфиг nginx; это даёт ещё меньший расход памяти, но требует аккуратной миграции правил.

Зачем настраивать лимиты памяти и времени

Лимиты — это тонкое место, на котором часто спотыкаются неопытные настройки. Memory_limit ограничивает память на один запрос PHP, время выполнения задаёт предел на длительность скрипта, а максимальный размер запроса определяет, какой файл можно загрузить. Если эти значения рассогласованы между nginx и PHP-FPM, пользователь ловит обрыв на большой выгрузке или невнятную ошибку при загрузке документа. Мы выставляем лимиты единым согласованным набором под реальные сценарии работы площадки и требования Битрикс, чтобы не было ни обрывов, ни перегрузки сервера несколькими тяжёлыми запросами одновременно.

Что в итоге

Результат настройки веб-стека — стабильно низкий TTFB, заметный запас по числу одновременных посетителей и предсказуемое поведение под нагрузкой. Площадка перестаёт ложиться в распродажи и рассылки, ускоряется отдача страниц и файлов, а сервер выполняет ровно ту работу, которая нужна, без лишней компиляции и пересчёта. Всё это достигается на текущем железе, без апгрейда тарифа: правильная конфигурация часто высвобождает кратный запас мощности, который раньше съедали неоптимальные настройки. А чтобы результат не деградировал со временем, мы передаём документацию по конфигам и при необходимости ставим мониторинг, который заранее предупреждает о росте нагрузки.

Когда площадка на 1С-Битрикс начинает тормозить или падать под нагрузкой, первый порыв — взять сервер помощнее. Это понятное, но дорогое решение, которое часто лечит симптом, а не причину. В большинстве случаев текущее железо уже способно держать нагрузку — его мощность просто съедают неоптимальные настройки веб-стека. Ниже разбираем, где именно теряется производительность, что даёт тюнинг конфигурации и когда апгрейд сервера действительно оправдан.

Почему быстрый сервер всё равно тормозит

TTFB — время до первого байта ответа — складывается из работы веб-сервера, интерпретатора PHP и базы данных. Если nginx или apache настроены по умолчанию, сервер делает массу лишнего: не сжимает текстовые ответы, отдаёт статику без кеша, перечитывает и компилирует код PHP на каждый запрос. Каждое из этих действий по отдельности кажется мелочью, но в сумме они растягивают ответ и расходуют процессор. На дефолтных настройках даже мощный сервер тратит большую часть мощности на работу, которой можно избежать.

Отдельная история — поведение под нагрузкой. PHP-FPM обрабатывает запросы фиксированным числом процессов. Если их слишком мало, в часы пик запросы выстраиваются в очередь и ответ замедляется для всех; если слишком много, сервер исчерпывает память и начинает уходить в своп, что ещё хуже. Подобрать модель и число процессов под фактический объём памяти — отдельная задача, которую мастер установки за вас не решает. Именно поэтому площадки, спокойно работающие в будни, ложатся в распродажу или массовую рассылку.

Что даёт правильная настройка nginx

Nginx на фронте — это рабочая лошадка, которая берёт на себя всё, что не требует PHP. Он отдаёт статику (картинки, скрипты, стили, шрифты) с длинными заголовками кеширования, поэтому повторные визиты грузятся из кеша браузера. Он сжимает текстовые ответы через gzip и brotli, уменьшая объём передаваемых данных. Он держит HTTP/2, который параллелит загрузку ресурсов. И он умеет fastcgi_cache — микрокеш динамических ответов: в пиковые часы готовая страница отдаётся прямо с nginx, не доходя до PHP вообще. Этот слой кеширования хорошо сочетается с настройкой кеширования на стороне Битрикс: вместе они снимают с PHP основную массу повторяющейся работы.

Не менее важна отдача загрузок. По умолчанию файлы из каталога загрузок Битрикс могут проходить через PHP, что нагружает процессы на каждой выгрузке документа или картинки. Мы настраиваем nginx так, чтобы статика и upload отдавались напрямую, в обход PHP. Процессы PHP-FPM при этом освобождаются для динамики, а тяжёлые файлы уходят клиенту быстрее.

Зачем перебирать PHP-FPM, opcache и preload

Слой PHP — обычно главный источник высокого TTFB. Первое, что мы включаем и настраиваем, — opcache: кеш скомпилированного байт-кода. Без него интерпретатор перечитывает и компилирует сотни файлов ядра на каждый запрос; с ним — берёт готовый код из памяти. Preload идёт дальше и держит ядро Битрикс предзагруженным в памяти всех процессов, что ещё сильнее снижает время генерации страницы. Затем мы перебираем пулы PHP-FPM: выбираем модель процессов, число воркеров и лимиты так, чтобы сервер держал нужное число одновременных запросов, не исчерпывая память. Добавляем медленный лог, чтобы видеть, какие именно скрипты тормозят, и подключаем результаты к более широкой серверной и инфраструктурной оптимизации, если узкое место лежит глубже конфигурации.

Лимиты — отдельная тонкость, на которой часто спотыкаются. Memory_limit, время выполнения и максимальный размер загружаемого файла должны быть согласованы между nginx, PHP-FPM и требованиями самого Битрикс. Если лимиты nginx и PHP расходятся, пользователь ловит обрыв на большой выгрузке или загрузке файла, а в логах — невнятную ошибку. Мы выставляем лимиты единым набором, под реальные сценарии работы площадки.

Связка nginx и apache или переход на чистый PHP-FPM

Многие проекты Битрикс работают на apache из-за поддержки файлов htaccess, которыми CMS правит маршрутизацию и кеш. У такой схемы есть два пути ускорения. Первый, щадящий, — поставить nginx фронтом перед apache: nginx принимает все запросы, отдаёт статику и загрузки, сжимает ответы и держит HTTP/2, а динамику передаёт apache. Это даёт основной выигрыш по скорости и почти не требует переделок. Второй путь, более радикальный, — отказаться от apache и перевести проект на чистый PHP-FPM, перенеся правила из htaccess в конфиг nginx. Это снижает расход памяти и убирает лишний слой, но требует аккуратной миграции правил, чтобы ничего не сломать в маршрутизации.

Какой путь выбрать, зависит от того, насколько проект завязан на htaccess и сколько в нём нестандартных правил. Если правил немного и они типовые, переход на чистый nginx оправдан. Если htaccess активно используется кастомными модулями, безопаснее оставить связку. На аудите мы разбираем конфигурацию и прямо говорим, какой вариант даст лучший результат с меньшим риском.

Когда тюнинга достаточно, а когда нужен апгрейд

Мы не уговариваем менять сервер ради галочки и не делаем вид, что тюнинг решает всё. Правильная настройка конфигурации почти всегда даёт кратный запас по нагрузке на текущем железе — этого хватает большинству площадок. Но если каталог разросся до сотен тысяч товаров, база данных не помещается в память, а трафик стабильно высокий, одной конфигурацией не обойтись: тогда к тюнингу добавляется работа с базой и инфраструктурой. На бесплатном аудите конфигурации мы замеряем TTFB и поведение под нагрузкой и честно говорим, что выгоднее в вашем случае — настройка стека, оптимизация базы или всё-таки апгрейд. Решение принимаем по замерам, а не по тому, что нам интереснее продать.

Как мы ведём работу без простоя

Веб-стек — это прод, поэтому к изменениям мы относимся аккуратно. Старт — аудит: снимаем текущие конфиги nginx, apache и PHP-FPM, замеряем TTFB и поведение под нагрузкой, фиксируем узкие места. Перед любой правкой делаем бэкап конфигурации и согласуем точки отката, чтобы вернуть прод в исходное состояние за минуты, если что-то пойдёт не так. Дальше правим слой за слоем: сначала nginx, потом PHP-FPM, opcache и preload, затем связку серверов. Каждое изменение проверяем замером и при необходимости нагрузочным тестом, поэтому к концу работы у вас есть цифры до и после, а не обещания.

По завершении передаём документацию по всем изменениям конфигов и доступы, ставим мониторинг TTFB и нагрузки и какое-то время наблюдаем за поведением под реальным трафиком. Если всплывают нюансы, донастраиваем. Площадка остаётся под вашим контролем, без привязки к подрядчику: развивать конфигурацию сможет как наша команда, так и любой другой админ.

Возражения, которые мы слышим чаще всего

«У нас сложный сервер, боюсь что-нибудь сломать настройкой». Именно поэтому мы работаем с бэкапом и точками отката: любое изменение можно откатить за минуты, а прод не остаётся без присмотра. Все правки идут по плану, согласованному заранее, а не наугад.

«Нам уже настраивал админ, что вы сделаете иначе». Админ-универсал настраивает сервер в целом, но редко знает специфику Битрикс: композит, агенты, требования к лимитам, особенности htaccess. Мы тюним стек именно под эту CMS и подтверждаем результат замерами TTFB и нагрузочным тестом, а не общими словами.

«Проще купить сервер помощнее». Иногда — да, но чаще апгрейд лишь отодвигает проблему: неоптимальные настройки съедят и новую мощность. Сначала имеет смысл выжать максимум из текущего железа тюнингом, а к апгрейду переходить, только когда упёрлись в реальный потолок по замерам.

Чем тюнинг конфигурации выгоднее альтернатив

У владельца медленной площадки на Битрикс обычно три пути ускориться: купить сервер помощнее, переехать на чужое готовое окружение или настроить текущий веб-стек под себя. Апгрейд сервера решает проблему деньгами и почти всегда лишь отодвигает её: неоптимальные настройки съедят и новую мощность, а через полгода роста трафика всё повторится. Готовое окружение в облаке стартует быстро, но навязывает свои версии PHP и nginx, чужие лимиты и помесячную плату, которая растёт вместе с нагрузкой, и плохо ложится на нестандартные правила htaccess конкретного проекта.

Тонкая настройка собственного веб-стека лишена этих ограничений. Она делается под вашу площадку, ваше железо и ваш характер нагрузки, разворачивается на вашей инфраструктуре и не требует помесячной аренды. Вы платите за настройку один раз и получаете кратный запас мощности на текущем сервере, а документация по конфигам остаётся у вас, поэтому развивать стек сможет любой админ. Когда трафик и каталог растут, именно этот путь оказывается и дешевле в долгую, и гибче по возможностям, чем гонка за всё более мощным сервером.

Этапы работы по шагам

Чтобы тюнинг был предсказуемым и безопасным для прода, мы разбиваем его на понятные этапы с результатом на каждом. Первый этап — аудит: снимаем текущие конфиги nginx, apache и PHP-FPM, замеряем TTFB и поведение под нагрузкой, фиксируем узкие места и составляем перечень изменений. Второй этап — подготовка: делаем бэкап конфигурации, согласуем план правок и точки отката, чтобы прод можно было вернуть за минуты. Третий этап — настройка nginx: кеш статики, gzip и brotli, HTTP/2, fastcgi_cache и отдача загрузок напрямую, мимо PHP.

Четвёртый этап — тюнинг слоя PHP: подбираем пулы и число процессов PHP-FPM под память сервера, выставляем согласованные лимиты, включаем opcache и preload, добавляем медленный лог для поиска тяжёлых скриптов. Пятый этап — связка и проверка: настраиваем nginx с apache либо переводим проект на чистый PHP-FPM с переносом правил из htaccess, после чего прогоняем нагрузочный тест и сверяем TTFB до и после. Финальный этап — передача документации по конфигам, установка мониторинга и наблюдение за поведением под реальным трафиком с донастройкой по факту. На каждом шаге вы видите цифры, а не обещания.

Ещё несколько частых вопросов

«Что будет с текущими настройками, которые нам важны». Перед любой правкой мы делаем бэкап конфигурации и не трогаем то, что работает и не мешает скорости. Все изменения идут по согласованному плану, а спорные правила обсуждаем заранее. «Сколько одновременных посетителей выдержит сервер после тюнинга». Точную цифру даёт нагрузочный тест: мы прогоняем его до и после и показываем фактический запас, который обычно вырастает в несколько раз на том же железе. «Можно ли настраивать постепенно». Да, тюнинг разбивается на этапы, и вы видите эффект уже после настройки nginx и opcache, а более глубокие работы добавляются по мере необходимости.

С чего начать

Начните с аудита конфигурации. Расскажите о вашем сервере, CMS-окружении и характере нагрузки — мы снимем текущие настройки nginx, apache и PHP-FPM, замерим TTFB и покажем, где теряется скорость. По итогам пришлём план тюнинга с перечнем изменений, ожидаемым эффектом и сметой. Аудит бесплатный, а правки делаем без простоя, с бэкапом и откатом. Обсудим ваш проект — и превратим веб-стек в быстрый и стабильный фундамент, который держит трафик в пики.