Настройка веб-сервера для 1С-Битрикс: PHP-FPM, Nginx и проверка

Работающий index.php ещё не означает готовность окружения Битрикс. Администратору нужно проверить совместимость ядра и модулей, ограничения загрузки, маршрутизацию ЧПУ, права каталогов, сессии, задания cron и закрытие служебных файлов. Ниже — пример отдельного лабораторного сайта на Debian 13, Nginx и PHP-FPM 8.4, с процедурой применения и возврата.

1. Сверьте требования продукта и существующего сайта

Как проходит запрос в Битрикс

Браузер устанавливает TLS-соединение с Nginx. Статический CSS или изображение Nginx читает с диска; запрос к PHP передаётся через FastCGI в отдельный pool FPM. PHP подключает пролог ядра, конфигурацию базы, модули, компоненты и шаблон, выполняет SQL-запросы и формирует ответ. Для виртуального ЧПУ-адреса файлового объекта может не быть: запрос должен попасть в bitrix/urlrewrite.php, где правила приложения выбирают обработчик.

Отдельно работают фоновые задания, отправка писем и обмен с внешними системами. Не вся операция проходит через браузер: CLI PHP из cron имеет свой php.ini, окружение, лимиты и пользователя. Если каталог сессий закрыт для FPM, вход будет теряться; если CLI работает с другой версией PHP, сайт может открываться, а агенты падать. Поэтому собираем и проверяем весь путь, а не только ответ 200 от главной.

Когда выбирать BitrixEnv или BitrixVM

BitrixEnv — устанавливаемое в чистую поддерживаемую ОС окружение с управляемой конфигурацией. BitrixVM — образ виртуальной машины с готовым окружением; повторная установка BitrixEnv внутрь такого образа не нужна. В актуальной инструкции производителя указаны CentOS Stream 9, Rocky Linux 9, AlmaLinux 9 и Oracle Linux 9. Окружение включает Nginx, Apache, PHP, СУБД и вспомогательные сервисы; управление выполняется через menu.sh. Установщик меняет системную конфигурацию, поэтому его не запускают поверх обслуживающего другие сайты сервера.

Штатное окружение удобно, если приоритет — стандартная поддерживаемая конфигурация, быстрый запуск и минимум собственной разработки инфраструктуры. Самостоятельный сервер оправдан при корпоративном стандарте Debian, централизованном управлении конфигурацией, отдельной базе, обязательной изоляции сайтов и существующем мониторинге. Это выбор эксплуатационной команды: исчезает часть готовых инструментов окружения, зато все параметры и обновления находятся под её контролем.

Для первого обычного сайта без специальных требований разумно начать со штатного варианта. Собственный сервер не становится быстрее только потому, что в нём нет Apache: нагрузка SQL, шаблоны, кеш и число PHP-процессов часто важнее. Ниже выбираем собственный стек осознанно и не переносим его конфигурацию в BitrixEnv.

Исходные условия лаборатории

Веб-VM: Debian 13, адрес 10.77.30.20, Nginx, PHP-FPM 8.4, домен bitrix-lab.example. База: отдельная Ubuntu 24.04 VM 10.77.30.10 со штатным MySQL 8.0. Это пример двух изолированных ролей, не реальные адреса AVG IT. Минимальный стартовый стенд веба — 4 vCPU/8 GiB, затем ресурсы определяются измерениями; это не гарантия производительности каталога любого размера. У базы отдельный диск, резервирование и доступ TCP 3306 только с веб-VM.

Нужны sudo, доступ к консоли обеих VM, лицензия/дистрибутив либо проверенный backup сайта, свободное место для распаковки и возможность восстановить снимок. До восстановления production-копии блокируют исходящую почту, платежи и webhooks; лучше выполнять первое восстановление в сети без доступа к рабочим интеграциям. Публичное переключение DNS выполняется после испытаний, вне этого лабораторного рецепта.

На момент проверки официальные требования указывают PHP минимум 8.2 и MySQL минимум 8.0. PostgreSQL доступен для соответствующей Enterprise-лицензии. Выбор новой версии PHP дополнительно согласуется с ядром, шаблоном, модулями Marketplace и собственным кодом. Минимум продукта не означает, что любое старое расширение совместимо с PHP 8.4.

Сначала сохраните резервную копию базы и файлов приложения штатным способом, проверьте восстановление на стенде и запишите текущие версии. На сервере прочитайте:

cat /etc/os-release
nginx -v
php -v
php --ini
systemctl list-units --type=service --all 'php*-fpm.service'

CLI php может отличаться от FPM сайта. В BitrixEnv/BitrixVM конфигурацию обслуживают инструменты окружения: приведённый самостоятельный vhost не заменяет их генерируемые файлы. Для такого сервера используйте поддерживаемые настройки окружения, а этот пример — для отдельной лаборатории.

2. Подготовьте PHP 8.4 и изолированный пользовательский контекст

В примере используются штатные пакеты Debian 13. Проверьте их доступность через apt-cache policy до установки. Состав расширений зависит от функций сайта; LDAP, AMQP и PostgreSQL подключают, если их требует конкретный модуль.

apt-cache policy php8.4-fpm php8.4-mysql nginx
sudo apt-get update
sudo apt-get install nginx php8.4-fpm php8.4-cli php8.4-mysql php8.4-gd php8.4-xml php8.4-mbstring php8.4-curl php8.4-zip
getent passwd bitrix-lab

Если bitrix-lab отсутствует и лабораторная учётная запись ещё не создана, создайте системного пользователя без интерактивного входа: sudo useradd --system --user-group --home-dir /srv/bitrix-lab --shell /usr/sbin/nologin bitrix-lab. Не выполняйте повторное создание поверх существующего пользователя и не меняйте ему UID ради примера.

Копия приложения располагается в /srv/bitrix-lab/public. Не скачивайте неизвестную сборку CMS. Базе стенда нужна отдельная учётная запись и отдельная база; отправка писем, платежи, webhooks и интеграция 1С на стенде должны быть отключены или направлены в тестовые системы.

Подготовьте каталоги приложения

После создания пользователя командами выше создайте document root. Разделяем право публикации файлов и право выполнения PHP: root или процесс развёртывания управляет исходниками, bitrix-lab выполняет приложение, www-data читает публичную статику.

sudo install -d -o root -g bitrix-lab -m 750 /srv/bitrix-lab
sudo install -d -o root -g www-data -m 755 /srv/bitrix-lab/public
sudo chmod 755 /srv/bitrix-lab
id bitrix-lab
getent passwd www-data

Первый каталог после проверки проходим для Nginx; файлы с секретами далее закрываются отдельно. Режим 755 не разрешает запись посторонним, но позволяет проход по пути. Нельзя закрыть весь родительский каталог 700 и ожидать чтения статических файлов пользователем www-data.

Установите отдельную MySQL VM

Следующие команды выполняются на VM базы Ubuntu 24.04, не на Debian веб-сервера:

sudo apt-get update
apt-cache policy mysql-server
sudo apt-get install mysql-server
systemctl is-active mysql
sudo mysql -e 'SELECT VERSION();'
sudo ss -lntp 'sport = :3306'

Проверьте выбранную APT версию до установки. В /etc/mysql/mysql.conf.d/mysqld.cnf задайте bind-address = 10.77.30.10 только для этой частной сети. Перед перезапуском сохраните исходный файл. После sudo systemctl restart mysql снова проверьте listener. Порт не публикуют в Интернет; сетевой ACL разрешает соединение только от 10.77.30.20. Адрес MySQL X Protocol 33060 не нужен обычному подключению mysqli.

Откройте sudo mysql интерактивно и выполните SQL. Строка REPLACE_WITH_UNIQUE_SECRET — явный шаблон, заменяемый сгенерированным значением из хранилища секретов; не оставляйте её паролем. Секреты не помещают в общий журнал выполнения или статью.

CREATE DATABASE bitrix_lab CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'bitrix_lab'@'10.77.30.20' IDENTIFIED BY 'REPLACE_WITH_UNIQUE_SECRET';
GRANT ALL PRIVILEGES ON bitrix_lab.* TO 'bitrix_lab'@'10.77.30.20';
SHOW GRANTS FOR 'bitrix_lab'@'10.77.30.20';

Права ограничены одной базой. Это учётная запись приложения, не mysql root; она не получает глобальные административные привилегии и не может создавать произвольных пользователей. Для существующей базы сохраняют исходную кодировку/сравнение до подготовленной миграции, а не меняют все таблицы на utf8mb4 одной командой.

На Debian веб-VM установите клиент sudo apt-get install default-mysql-client. Проверьте вход mysql -h 10.77.30.10 -u bitrix_lab -p bitrix_lab: ключ -p без значения запрашивает пароль. Выполните SELECT CURRENT_USER(), DATABASE(), @@character_set_database;. Ожидаются bitrix_lab@10.77.30.20, bitrix_lab и utf8mb4. Если Access denied, различайте неверный секрет и не совпавший host в учётной записи. Connection refused означает иной слой — listener/маршрут/firewall.

MariaDB из Debian — отдельная вариация, требующая проверки совместимости именно вашего ядра и модулей. В этом руководстве её не объявляем взаимозаменяемой заменой выбранной MySQL. Перенос физического каталога данных между разными версиями/движками не заменяет логический backup и восстановление.

3. Настройте отдельный pool PHP-FPM

Создайте /etc/php/8.4/fpm/pool.d/bitrix-lab.conf, предварительно убедившись, что такого pool нет. Параметры ниже — стартовый лабораторный профиль. Число процессов выбирают по замерам, а не по числу ядер сервера.

[bitrix-lab]
user = bitrix-lab
group = bitrix-lab
listen = /run/php/bitrix-lab.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660
pm = dynamic
pm.max_children = 8
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500
request_slowlog_timeout = 10s
slowlog = /var/log/php8.4-fpm-bitrix-lab-slow.log
php_admin_flag[display_errors] = off
php_admin_flag[log_errors] = on
php_admin_value[error_log] = /var/log/bitrix-lab/php-error.log
php_admin_value[session.save_path] = /var/lib/bitrix-lab/sessions
php_admin_value[upload_tmp_dir] = /var/lib/bitrix-lab/upload-tmp

Подготовьте закрытые каталоги для записывающего пользователя:

sudo install -d -o bitrix-lab -g bitrix-lab -m 700 /var/lib/bitrix-lab/sessions /var/lib/bitrix-lab/upload-tmp /var/log/bitrix-lab
sudo php-fpm8.4 -t

Сокет позволяет Nginx передавать запросы в этот pool. Ошибка permission denied требует проверки владельца сокета и пользователя worker-процесса, а не chmod 777. Pool использует отдельные сессии; смешивать их с другим сайтом под общей учётной записью не следует. Документация PHP-FPM описывает назначение pm и listen.

Зачем нужен отдельный pool и как посчитать число процессов

Каждый FPM child обрабатывает один PHP-запрос в конкретный момент. Если свободных children нет, запрос ожидает в очереди: рост max_children может уменьшить очередь, но одновременно увеличивает память и число соединений с БД. На VM с 8 GiB нельзя отдавать весь объём PHP: память нужна ОС, Nginx, OPcache и резерву для всплесков.

Допустим, после прогрева измеренный PSS одного процесса составляет 180 MiB, а для children выделено 2 GiB. Деление даёт около 11 процессов; стартовать с 8 и измерить очередь разумнее, чем поставить 100. PSS учитывает долю разделяемых страниц, RSS часто завышает суммарный расход. Это расчёт для конкретного замера, не норматив Битрикс. Посмотреть процессы можно так:

ps -eo pid,user,rss,args --sort=-rss | head -n 20
sudo journalctl -u php8.4-fpm --since '-30 minutes' --no-pager
sudo ss -xlpn | grep bitrix-lab.sock

RSS в ps приведён в KiB. В журнале предупреждение server reached pm.max_children означает достижение предела pool; сначала выясните, почему запросы долго занимают процессы. pm.max_requests=500 периодически заменяет child и может сдерживать накопление памяти расширениями; это не лечение утечки в приложении. Slowlog фиксирует стек долгого PHP-запроса, поэтому его доступ ограничивают и включают ротацию.

Для редко используемого стенда возможен pm=ondemand с pm.process_idle_timeout=30s; в этом режиме убирают настройки start/min/max_spare_servers. Dynamic держит несколько готовых процессов и уменьшает задержку первого запроса. Static использует фиксированное количество children и требует заранее выделенной памяти.

4. Примените параметры PHP к правильному SAPI

Для стенда создайте отдельный ini-файл в /etc/php/8.4/fpm/conf.d/99-bitrix-lab.ini. Общий файл FPM повлияет на все pools этой версии; на многосайтовом сервере параметры переносите в pool либо согласуйте общий профиль. На стенде из примера других сайтов не должно быть.

memory_limit = 256M
max_input_vars = 10000
max_file_uploads = 100
max_execution_time = 300
upload_max_filesize = 128M
post_max_size = 160M
pcre.backtrack_limit = 1000000
pcre.recursion_limit = 14000
realpath_cache_size = 4096K
default_charset = UTF-8
short_open_tag = On
expose_php = Off
display_errors = Off
log_errors = On
session.cookie_httponly = On
session.cookie_samesite = Lax
session.cookie_secure = On

Здесь лимит загрузки сознательно выбран для файлов до 128M. Рекомендации Битрикс содержат более крупные значения; фактический профиль определяется задачами сайта и ёмкостью временного диска. post_max_size должен покрывать файл и остальные данные формы, а лимит Nginx — весь запрос.

Cookie Secure требует HTTPS: локальный HTTP-тест ниже проверяет маршрутизацию, но не заменяет проверку входа через TLS. Не добавляйте mbstring.func_overload в PHP 8: устаревшая настройка из старых инструкций не подходит современному окружению. Перезапуск или reload FPM необходим для применения файлов настроек.

Проверьте расширения и настройте кеш байткода

php8.4 -m
php8.4 --ini
sudo php-fpm8.4 -tt

В CLI должны присутствовать mysqli, mbstring, curl, dom, SimpleXML, zip и используемый image extension. Но CLI-список не подтверждает FPM: настройку HTTP-процесса проверяют из административного раздела или временного диагностического обработчика. В выводе -tt видны эффективные pool-параметры; файл диагностики может содержать инфраструктурные пути, его не публикуют.

OPcache хранит скомпилированный PHP-байткод, сокращая повторный разбор исходников. Добавьте в лабораторный ini и проверьте наличие установленного модуля:

opcache.enable = 1
opcache.memory_consumption = 256
opcache.interned_strings_buffer = 16
opcache.max_accelerated_files = 100000
opcache.validate_timestamps = 1
opcache.revalidate_freq = 2

256 MiB — начальная ёмкость кеша, выбираемая по заполнению; это не лимит памяти каждого child. validate_timestamps=1 позволяет заметить обновление файлов. Отключение проверки времени требует явной процедуры сброса кеша после каждого deploy. opcache_reset() из CLI не сбрасывает автоматически кеш всех FPM workers. Назначение параметров приведено в документации OPcache.

Для большого импорта учитывайте отдельно memory_limit процесса, время PHP, fastcgi_read_timeout и место upload_tmp_dir. Увеличение всех лимитов до бесконечности делает зависший запрос долгоживущим потребителем ресурсов. Фоновый импорт лучше дробить и выполнять через управляемую очередь.

5. Создайте лабораторный vhost Nginx

Конфигурация ниже слушает только loopback 127.0.0.1:8080. Она предназначена для проверки отдельной копии приложения и не публикует сайт в Интернет. Сохраните её в /etc/nginx/sites-available/bitrix-lab; root должен содержать index.php и bitrix/urlrewrite.php.

server {
    listen 127.0.0.1:8080;
    server_name bitrix-lab.example;
    root /srv/bitrix-lab/public;
    index index.php;
    client_max_body_size 160m;
    access_log /var/log/nginx/bitrix-lab-access.log;
    error_log /var/log/nginx/bitrix-lab-error.log;

    location ~ /\.(?!well-known(?:/|$)) { deny all; }
    location ~* ^/(?:bitrix/(?:php_interface|backup)|local/php_interface)(?:/|$) {
        deny all;
    }
    location ~* ^/(?:composer\.(?:json|lock)|package-lock\.json)$ {
        deny all;
    }
    location ~* ^/upload/.*\.(?:php[0-9]?|phtml|phar)(?:/|$) {
        deny all;
    }
    location /upload/ { try_files $uri =404; }
    location / { try_files $uri $uri/ /bitrix/urlrewrite.php?$query_string; }
    location ~ \.php$ {
        try_files $uri =404;
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php/bitrix-lab.sock;
        fastcgi_read_timeout 300s;
    }
}

Порядок regex-locations важен: запрет PHP в upload стоит раньше общего обработчика. Настройки не содержат специальных оптимизаций композитного кеша, push-сервера, multisite и нестандартных download handlers. Эти функции подключаются отдельно по конфигурации вашего проекта. Nginx не читает .htaccess: правила Apache автоматически сюда не переносятся.

Документация Nginx FastCGI описывает SCRIPT_FILENAME и передачу запроса. Ошибочный root или путь к сокету дают другой результат, чем ошибка CMS; сначала проверяют инфраструктурные пути.

Поднимите HTTPS, прежде чем проверять вход

Локальный HTTP listener нужен для начальной диагностики. Для браузерной проверки cookie Secure добавим отдельный HTTPS listener 8443, также на loopback. Создаём самоподписанный сертификат только для лаборатории, с SAN имени bitrix-lab.example; закрытый ключ остаётся root-only:

sudo install -d -o root -g root -m 700 /etc/nginx/ssl/bitrix-lab
sudo openssl req -x509 -newkey rsa:3072 -sha256 -nodes -days 30 -keyout /etc/nginx/ssl/bitrix-lab/key.pem -out /etc/nginx/ssl/bitrix-lab/cert.pem -subj '/CN=bitrix-lab.example' -addext 'subjectAltName=DNS:bitrix-lab.example'
sudo chmod 600 /etc/nginx/ssl/bitrix-lab/key.pem
sudo openssl x509 -in /etc/nginx/ssl/bitrix-lab/cert.pem -noout -dates -ext subjectAltName

В тот же server block после listen 8080 добавьте:

listen 127.0.0.1:8443 ssl;
ssl_certificate /etc/nginx/ssl/bitrix-lab/cert.pem;
ssl_certificate_key /etc/nginx/ssl/bitrix-lab/key.pem;
ssl_protocols TLSv1.2 TLSv1.3;

После nginx -t и reload проверяйте TLS с конкретным доверенным сертификатом, не отключая проверку через -k. Для доступа браузером с рабочего компьютера создайте SSH-forward ssh -L 8443:127.0.0.1:8443 WEB_ADMIN@10.77.30.20, добавьте bitrix-lab.example в локальный hosts на 127.0.0.1 и организуйте доверие к лабораторному сертификату только по политике своей организации. Откройте https://bitrix-lab.example:8443/. Public production использует настоящий домен, сертификат доверенного CA и контролируемый listener 443; самоподписанный lab-сертификат туда не переносят.

Разберите маршрут запроса

try_files $uri $uri/ ... сначала проверяет физический файл и каталог. Только отсутствующий путь передаётся urlrewrite.php. В FastCGI SCRIPT_FILENAME должен указывать существующий локальный файл, а QUERY_STRING сохранять параметры. Запрет /upload/*.php стоит выше обработчика PHP, иначе загруженный файл может быть исполнен. .htaccess не выполняется: нестандартные redirects, AccessControl и handlers из него перечисляют и переносят вручную до миграции.

Композитный кеш Битрикс — отдельный слой; не добавляйте общий fastcgi_cache для всех страниц. Без корректной привязки к cookies авторизации такой кеш может показать личную страницу другому посетителю. Сначала подтвердите штатную динамическую маршрутизацию и только потом подключайте кеширование по документации конкретного продукта.

6. Проверьте права и закройте лишние файлы

Пользователь FPM должен читать приложение и записывать только предусмотренные задачей каталоги. Nginx должен читать публичную статику и проходить по родительским каталогам. На лабораторной копии проверьте реальные права:

namei -l /srv/bitrix-lab/public/index.php
sudo -u bitrix-lab test -r /srv/bitrix-lab/public/index.php
sudo -u www-data test -r /srv/bitrix-lab/public/index.php
sudo -u bitrix-lab test -w /srv/bitrix-lab/public/upload

Не выполняйте рекурсивный chown/chmod всего production-каталога ради устранения одной ошибки. Bitrix может требовать запись для обновлений ядра: настраивается отдельный управляемый процесс обновления, а не постоянное разрешение веб-процессу менять любые системные файлы.

Архивы backup хранят вне document root, даже если URL закрыт. Файл .settings.php содержит параметры подключения к базе; его нельзя отдавать как текст при сбое обработчика PHP. Отдельно проверяют нестандартные папки резервирования и копии конфигураций с суффиксами .bak. Запрет перечисленных путей — часть защиты, а не универсальный поиск всех возможных секретов.

Установите CMS или восстановите проверенную копию

Для новой установки используйте официальный дистрибутив/установщик из раздела загрузки Битрикс. Сохраните его в подготовленный document root, временно предоставьте пользователю bitrix-lab запись только в каталог стенда и выполните мастер через HTTPS. Укажите отдельную базу bitrix_lab на 10.77.30.10 и её пользователя. Установщик и restore.php после успешного завершения удаляются из публичного каталога, а не просто забываются в закладке.

Для переноса сначала восстановите проверенный backup в изолированную копию. В этой лабораторной VM, после проверки фактического пути, временное предоставление прав можно выполнить так:

sudo chown -R bitrix-lab:bitrix-lab /srv/bitrix-lab/public
sudo find /srv/bitrix-lab/public -type d -exec chmod 755 {} +
sudo find /srv/bitrix-lab/public -type f -exec chmod 644 {} +
sudo chmod 640 /srv/bitrix-lab/public/bitrix/.settings.php

Последнюю команду выполняют после появления файла конфигурации. Это bootstrap только собственной стендовой копии, не универсальная правка production. После установки задают модель deploy: какие каталоги обновляет приложение, какие публикует администратор. Закрытый конфигурационный файл FPM читает как bitrix-lab, Nginx не обязан его читать как статику.

Проверьте, что конфигурация действительно смотрит в новую БД и не содержит рабочие SMTP/API-учётные записи. Изолированная сеть защищает от случайного внешнего вызова даже при забытом обработчике. Снимок VM не заменяет согласованный backup БД и файлов: одновременность копии и проверка восстановления остаются обязательными.

7. Примените конфигурацию и проверьте маршруты

До изменений сохраните затронутые файлы в root-only каталоге. Затем активируйте лабораторный vhost, если симлинка ещё нет, проверьте обе конфигурации и примените их только при успешном результате:

sudo ln -s /etc/nginx/sites-available/bitrix-lab /etc/nginx/sites-enabled/bitrix-lab
sudo php-fpm8.4 -t
sudo nginx -t
sudo systemctl reload php8.4-fpm
sudo systemctl reload nginx
curl -I -H 'Host: bitrix-lab.example' http://127.0.0.1:8080/
curl -I -H 'Host: bitrix-lab.example' http://127.0.0.1:8080/bitrix/.settings.php
curl -I -H 'Host: bitrix-lab.example' http://127.0.0.1:8080/upload/test.php

Закрытые пути должны возвращать отказ, не содержимое файла. Главная может давать redirect в зависимости от приложения; исследуйте Location вместо слепого следования на рабочий домен. Проверьте известный ЧПУ-адрес и действительно отсутствующую страницу: ошибка не должна превращаться в 200 с текстом «не найдено».

Production-вход проверяют через доверенный TLS-терминатор, корректные сертификаты и заголовки HTTPS. Если TLS завершается на reverse proxy, PHP должен получать подтверждённый признак HTTPS только от доверенного proxy. Нельзя принимать любой клиентский X-Forwarded-Proto как доказательство защищённого соединения.

Выполните проверочную матрицу HTTP и HTTPS

sudo curl --cacert /etc/nginx/ssl/bitrix-lab/cert.pem --resolve bitrix-lab.example:8443:127.0.0.1 -I https://bitrix-lab.example:8443/
curl -I -H 'Host: bitrix-lab.example' http://127.0.0.1:8080/__avg_missing_page__
curl -I -H 'Host: bitrix-lab.example' http://127.0.0.1:8080/upload/__avg_missing__.jpg
sudo tail -n 30 /var/log/nginx/bitrix-lab-error.log

Для TLS curl должен подтвердить сертификат и получить ожидаемый код приложения. Для отсутствующей статики ожидается 404. Несуществующая ЧПУ-страница должна давать согласованную страницу 404 приложения, а не всегда 200; это влияет на SEO. Закрытая конфигурация должна давать 403/404 без содержимого. Проверьте в браузере, что вход сохраняется после перехода между страницами и Secure cookie передаётся только по HTTPS.

Перезагрузка сервиса с успешным nginx -t не гарантирует чтение страницы PHP. Следующие уровни проверки — socket FPM, HTTP-ответ, база, авторизация, запись upload и конкретный бизнес-сценарий. В протоколе приёмки фиксируют результат каждого уровня.

8. Проверьте настройки из самого приложения

В административной части Битрикс откройте Настройки → Инструменты → Проверка системы. Этот тест проверяет контекст веб-запроса, чего не делает php --ini из терминала. Сохраните результат, выполните тест загрузки разрешённого файла, вход и выход из сессии, создание и чтение данных на стенде.

Не оставляйте публичный phpinfo.php: он раскрывает детали окружения. Для временной диагностики используйте закрытый доступ или локальный тест и удалите диагностический файл после проверки. Пароль базы в PHP-командах и журналах не выводят.

Для фоновых заданий сверяют версии CLI и FPM, пользователя cron, пути приложения и назначение штатного скрипта агентов. Не добавляйте второй cron поверх существующего: можно получить параллельные задания и двойные отправки. Конкретный режим агентов выбирают по документации Битрикс об агентах и текущей настройке сайта.

Настройте фоновые задачи без скрытого запуска на хитах

Агенты Битрикс по умолчанию могут исполняться при посещениях: на редко посещаемом сайте задача задерживается, а тяжёлое исполнение увеличивает время ответа. Есть частичный и полный перевод на cron; это разные настройки. Для начала приведём частичный вариант производителя, без самостоятельной переписи ядра.

В административной командной PHP-строке стенда выполните:

COption::SetOptionString('main', 'agents_use_crontab', 'Y');
echo COption::GetOptionString('main', 'agents_use_crontab', 'Z');

Ожидается Y. Создайте /etc/cron.d/bitrix-lab для уже настроенного приложения:

*/10 * * * * bitrix-lab /usr/bin/php8.4 -f /srv/bitrix-lab/public/bitrix/modules/main/tools/cron_events.php >> /var/log/bitrix-lab/cron.log 2>&1

Это системный cron-файл с полем пользователя; в личном crontab такое поле лишнее. Интервал 10 минут взят для выбранного варианта, а не обещание точности каждой бизнес-задачи. На Debian проверьте установленный и активный cron (sudo apt-get install cron, systemctl is-active cron). Файл принадлежит root, режим 644, содержит завершающий перевод строки. CLI ini отдельно согласуют с расширениями и настройками сайта.

Перед включением проверьте sudo -u bitrix-lab php8.4 -l /srv/bitrix-lab/public/bitrix/modules/main/tools/cron_events.php, затем один ручной запуск только на изолированном стенде и журнал. Синтаксическая проверка не запускает задачи; запуск -f уже выполняет их. Полный перевод требует другого набора опций и подготовленного обработчика — следуйте актуальному руководству по агентам, не смешивайте два режима. При возврате сначала остановите cron, затем восстановите ранее зафиксированные настройки агента.

9. Разберите 413, 502, timeout и медленные ответы

413 на upload обычно требует согласовать client_max_body_size, post_max_size и upload_max_filesize, а также проверить лимит переднего proxy. 502 требует проверки FPM: активен ли service, существует ли сокет, верны ли права. 504 может означать очередь pool, медленный SQL или внешнее API; увеличение timeout не устраняет первопричину.

systemctl status php8.4-fpm nginx --no-pager
sudo journalctl -u php8.4-fpm --since '-10 minutes' --no-pager
sudo tail -n 50 /var/log/nginx/bitrix-lab-error.log
sudo tail -n 50 /var/log/php8.4-fpm-bitrix-lab-slow.log

Планируя pm.max_children, оставьте бюджет памяти базе, ОС и кешам. Например, выделенные pool 1.5 ГиБ при измеренном тяжёлом worker 180 МиБ дают ориентир около восьми процессов, а не 64. RSS общих страниц не является точным расходом каждого процесса; для серьёзной оценки используйте PSS и измерения под типовой нагрузкой.

Диагностируйте по слоям, не увеличивая лимиты вслепую

413 от Nginx возникает до передачи в PHP: проверьте client_max_body_size в эффективном vhost. Пустые POST/FILES при ответе PHP могут означать превышение post_max_size; warning о загрузке — upload_max_filesize или upload_tmp_dir. Разрешение папки проверяют от имени bitrix-lab, объём — df -h, inodes — df -i. Каталог может иметь свободные гигабайты и одновременно исчерпанные inode.

502 и connect() to unix:... failed разделяйте: No such file — неверный сокет или остановленный FPM; Permission denied — права; Connection refused — сервис не слушает. 504/timeout исследуйте через slowlog и длительность SQL. Если увеличенный таймаут держит весь pool занятым, остальные посетители будут ждать ещё дольше.

sudo nginx -T
sudo systemctl status php8.4-fpm --no-pager
sudo tail -n 50 /var/log/php8.4-fpm-bitrix-lab-slow.log
sudo tail -n 50 /var/log/bitrix-lab/php-error.log
df -h /srv/bitrix-lab /var/lib/bitrix-lab
df -i /srv/bitrix-lab

nginx -T показывает все подключённые файлы, поэтому ищите именно server_name стенда и не публикуйте полный вывод с инфраструктурными данными. Если медленный запрос ждёт базу, на DB VM смотрят активные запросы, блокировки и slow query log, затем анализируют конкретный SQL через EXPLAIN. Увеличение PHP workers без ограничения соединений может перегрузить БД, особенно при тяжёлом каталоге.

10. Приёмка и возврат

Проверьте HTTPS-вход, страницы каталога, поиск, формы, upload, выгрузку, интеграции на тестовых endpoints, cron и недоступность служебных файлов. После этого сравните ошибки и время ответа с baseline. Тест nginx -t подтверждает синтаксис и доступность части файлов, но не совместимость CMS с выбранной версией PHP.

Для возврата восстановите только изменённые vhost, pool и ini-файлы, повторите проверки конфигурации и reload. Если обновляли ядро или базу, возврат PHP-настроек не отменяет миграции данных: нужен согласованный восстановительный комплект приложения. Сохраните версии, параметры, результаты проверки системы и план последующего сопровождения окружения.

Зафиксируйте воспроизводимый результат и порядок отката

Проверенная конфигурация должна включать версии пакетов, vhost, pool, ini, cron, модель прав, backup базы/файлов и перечень интеграций. Приёмка сайта: главная, ЧПУ, 404, вход/выход, форма, upload, поиск, админка, запланированное событие. Нагрузочный тест проводят после функционального; сравнивают latency, ошибки, очередь FPM, память и SQL, а не только requests/sec.

При ошибке нового vhost сначала отключите только его симлинк и проверьте nginx -t; затем верните предыдущие файлы pool/ini и перечитайте FPM. Остановите собственный cron до возврата опций агента. Изменения базы откатывают восстановлением согласованной копии, а не только возвратом nginx.conf. Не удаляйте автоматически пользователя и БД, пока не сохранены данные и причина ошибки.

Эта статья готовит самостоятельное лабораторное окружение. Production дополнительно требует резервирования, обновлений, мониторинга, сетевых ACL, настоящего TLS, ротации журналов и проверки восстановления. Конфигурацию лаборатории публикуют в рабочую среду только после устранения известных различий проекта: нестандартных handlers, композита, push, multisite и интеграций.