Клиент и контекст проекта
Заказчик — российская компания с нагруженным сайтом на 1С-Битрикс, имеющим несколько поддоменов под различные направления бизнеса. Сайт эксплуатируется на собственном виртуальном сервере под управлением Bitrix Virtual Appliance. На момент обращения владельцы бизнеса регулярно получали жалобы от пользователей на недоступность сайта и явно ощущали снижение конверсии в моменты падений.
Все работы по диагностике, перенастройке серверного стека и защите от атак я выполнил лично за 5 рабочих дней. Обезличивание: домен сайта, названия поддоменов, название юрлица, название компании-провайдера сервера и контактные данные в публичной версии кейса не приводятся. Я базируюсь в Москве и работаю с заказчиками из любого региона РФ, СНГ и за рубежом — в данном случае все работы были выполнены удалённо.
Конфигурация сервера и сайта до работ
Перед началом работ я зафиксировал точную конфигурацию программного стека, чтобы понимать, с чем работаю, и какие компоненты требуют обновления. Это критично для выбора стратегии оптимизации: настройки PHP 7.4 и MySQL 5.7 отличаются от более свежих версий, а Bitrix Virtual Appliance 7.5.2 имеет собственные ограничения по сравнению с версией 9.
| Компонент | Версия / состояние |
| ОС | CentOS Linux 7.9.2009 (устарела, рекомендован апгрейд) |
| Веб-сервер | Bitrix Virtual Appliance 7.5.2 |
| Reverse proxy | Nginx 1.20.2 |
| Application | Apache 2.4.6 |
| СУБД | MySQL 5.7.42 |
| PHP | 7.4.33 |
| OPCache | Установлен и настроен |
| Memcached | Переустановлен, настроен |
| CMS | 1С-Битрикс 23.300.100 |
| Шаблон | Custom, на PHP 7.4 (требует миграции на PHP 8.2) |
Проблема
Сайт клиента регулярно зависал, пользователи получали ошибку 502 Bad Gateway. Падения происходили периодически, без видимой закономерности, но с нарастающей частотой. Стандартная перезагрузка сервера помогала временно, но через несколько часов проблема возвращалась. Бизнес терял заявки и репутацию.
Первичная диагностика, проведённая мной в первые часы после обращения, выявила сразу несколько корневых причин, действующих одновременно. Ни одна из них по отдельности не приводила к падению, но их сочетание создавало «эффект домино» — стоило одной подсистеме дрогнуть, и весь стек разваливался.
Причина 1. Массовые атаки на порт SSH
Сервер подвергался постоянным автоматизированным атакам brute-force на порт SSH. Боты перебирали пароли по словарям, создавая лишнюю нагрузку на систему аутентификации и логирование. Параллельно фиксировались попытки поиска уязвимостей на основном домене и поддоменах — сканирование известных админок, попытки доступа к wp-admin (несмотря на то, что сайт на Битриксе), поиск открытых файлов конфигурации.
Причина 2. Неоптимальная конфигурация сервера под нагрузку
Стандартные настройки Nginx, Apache и PHP из дистрибутива Bitrix Virtual Appliance не соответствовали реальной нагрузке клиента. Количество процессов Apache не было согласовано с количеством ядер CPU (4 ядра), лимиты оперативной памяти PHP-процессов не были подкручены под доступные 4 ГБ RAM, время выполнения скриптов и таймауты соединений были оставлены по умолчанию, что приводило к зависанию процессов и накоплению зомби.
Причина 3. Установлены инструменты для отладки PHP
На production-сервере были активированы Xdebug и GNU Debugger — инструменты, которые должны использоваться только в dev-окружении. Они создавали накладные расходы на каждый запуск PHP-скрипта, что на нагруженном сайте выливалось в постоянную потерю 15–25% производительности и ускоренное исчерпание памяти.
Причина 4. Утечка оперативной памяти
Совокупность предыдущих факторов приводила к постепенной утечке оперативной памяти: PHP-процессы не завершались корректно, Apache держал открытые соединения дольше необходимого, Memcached был настроен неоптимально. Через несколько часов работы свободная память заканчивалась, OOM-killer начинал «убивать» процессы, и в первую очередь страдал PHP-FPM — что и проявлялось внешне как ошибка 502.
Решение
Работа была организована в шесть последовательных этапов, каждый из которых я выполнял лично. Подход — максимально осторожный: изменения вносились поэтапно, с мониторингом состояния между шагами, чтобы иметь возможность откатить конкретное изменение, если оно ухудшит ситуацию.
Этап 1. Защита от атак на SSH и сканирования уязвимостей
- Установлен и настроен Fail2Ban для автоматической блокировки IP-адресов, замеченных в массовых попытках подбора пароля к SSH.
- Настроены jail-правила для Nginx: автоматическая блокировка IP, сканирующих известные уязвимые URL (wp-admin, .env, .git и т.п.).
- После установки Fail2Ban поток паразитного трафика перестал создавать нагрузку на систему аутентификации и логирование.
Этап 2. Увеличение оперативной памяти
- Оперативная память сервера увеличена с 4 ГБ до 6 ГБ.
- Согласовано с компанией-провайдером сервера — реакция на запрос была оперативной, что позволило продолжить работы без задержек.
- Увеличение RAM дало «подушку безопасности» и позволило более гибко настроить лимиты PHP и Apache без риска немедленного исчерпания памяти.
Этап 3. Оптимизация Nginx
- Изменены настройки входящего сервера и портов под фактическую схему трафика клиента.
- Согласованы таймауты Nginx с таймаутами Apache и PHP, чтобы исключить ситуации, когда Nginx держит соединение дольше, чем Apache способен его обслужить.
Этап 4. Оптимизация Apache
- Сконфигурировано оптимальное количество процессов Apache при текущем CPU (4 ядра) — чтобы сервер не создавал больше процессов, чем способен эффективно обрабатывать.
- Согласовано потребление памяти: лимиты Apache подкручены под 6 ГБ RAM с учётом других подсистем.
- Настроено оптимальное количество одновременных соединений, исходя из реального паттерна трафика клиента.
- Настроены таймауты для соединений и выгрузки зависших процессов — теперь Apache автоматически закрывает «зависшие» соединения, не давая им накапливаться.
Этап 5. Оптимизация PHP и кеширования
- Сконфигурировано оптимальное потребление оперативной памяти на PHP-процесс, исходя из реальных размеров скриптов клиента.
- Настроено оптимальное количество одновременных соединений с MySQL — чтобы пул соединений не исчерпывался под нагрузкой.
- Настроено оптимальное время выполнения скриптов: достаточно для тяжёлых операций Битрикса, но не бесконечное — чтобы зависший скрипт гарантированно завершался.
- Установлен и настроен OPCache с оптимальной конфигурацией кеширования.
- Для минимальной нагрузки и повышения скорости отключена постоянная проверка времени создания PHP-файлов (validate_timestamps) — это даёт заметный прирост на production, где код меняется редко.
- Полностью переустановлен и настроен Memcached с оптимальной конфигурацией кеширования.
Этап 6. Оптимизация на стороне сайта и отключение отладочных инструментов
- На стороне 1С-Битрикс настроено кеширование через Memcached (включая кеширование блоков и композитный сайт).
- Проведена оптимизация таблиц базы данных — очистка, переиндексация, дефрагментация.
- Отключён Xdebug — инструмент создавал паразитную нагрузку на сервер при каждом выполнении скриптов.
- Отключён GNU Debugger — аналогично, создавал паразитную нагрузку при каждом выполнении скриптов.
- Оба инструмента могут быть включены локально разработчиками в dev-окружении, но на production им не место.
Результаты
Все работы выполнены за 5 рабочих дней. При мониторинге проблем с постоянным падением сайта не выявлено — ошибка 502 больше не повторялась, пользователи получили стабильный доступ к сайту. Сочетание защитных мер (Fail2Ban), оптимизации конфигурации серверного стека и отключения паразитных отладочных инструментов позволило кардинально повысить стабильность работы без радикального изменения архитектуры.
| Показатель | Результат |
| Срок выполнения работ | 5 рабочих дней (с 8 по 12 декабря) |
| Симптом до работ | периодические зависания, ошибка 502 |
| Симптом после работ | 0 падений за период мониторинга |
| Платформа сайта | 1С-Битрикс 23.300.100 |
| Веб-стек | Nginx 1.20.2 + Apache 2.4.6 + PHP 7.4.33 + MySQL 5.7.42 |
| ОЗУ сервера | увеличено с 4 ГБ до 6 ГБ |
| CPU сервера | 4 ядра (Apache/PHP оптимизированы под это) |
| Атак на SSH за период мониторинга | блокируются Fail2Ban автоматически |
| Кеширование | OPCache + Memcached (переустановлен и настроен) |
Дополнительно клиенту был передан подробный отчёт с рекомендациями по долгосрочной стратегии обновления серверного стека. Текущая конфигурация стабильно работает, но несколько её компонентов уже достигли конца поддержки, и в перспективе 6–12 месяцев требует планового апгрейда — иначе накопительный технический долг снова приведёт к проблемам.
Рекомендации по дальнейшему развитию
В рамках того же контракта я передал клиенту детальный план обновления серверного стека. Эти работы не были выполнены в указанный период — задача стояла «поднять сайт здесь и сейчас», — но рекомендации зафиксированы для будущего планирования.
- Обновить ОС: CentOS 7.9 больше не поддерживается (EOL с 30 июня 2024 года), рекомендуется миграция на CentOS Stream 9 или совместимый дистрибутив (AlmaLinux 9, Rocky Linux 9).
- Обновить Bitrix Virtual Appliance с версии 7.5.2 до версии 9 — это даст актуальные преднастройки под современные версии PHP и MySQL.
- Обновить MySQL с версии 5.7 до версии 8 — версия 5.7 также достигла EOL.
- Обновить PHP с версии 7.4 до версии 8.2 — PHP 7.4 уже не получает обновлений безопасности.
- Обновить ядро 1С-Битрикс до последней актуальной версии.
- Переписать шаблон сайта под PHP 8.2 — текущий шаблон написан под PHP 7.4 и при обновлении PHP потребует адаптации.
Эти работы рекомендуется выполнять комплексно, одним проектом, поскольку компоненты связаны: обновление PHP без переписывания шаблона сломает сайт, обновление MySQL без обновления Битрикса может вызвать несовместимость, а обновление ОС без обновления Bitrix Virtual Appliance лишено смысла. Ориентировочный срок такого проекта — 2–3 недели с учётом тестирования.
Технологический стек
1С-Битрикс 23.300.100 Bitrix Virtual Appliance 7.5.2 CentOS 7.9 Nginx 1.20.2 Apache 2.4.6 PHP 7.4.33 MySQL 5.7.42 OPCache Memcached Fail2Ban SSH hardening