# Чиним BitrixVM после ручных правок конфигов

> Портал открывается, но показывает чужой сайт, сертификат перестал обновляться, swap исчез. Разбираем, почему правка конфигов мимо меню BitrixVM ломает больше, чем чинит.

2 сентября 2026 · Заря · 10 минут

Досталась виртуалка с BitrixVM после администратора, который правил конфиги руками. Сайты открываются, но портал показывает содержимое магазина, сертификат больше не продлевается, а swap исчез. Разбираем, почему так вышло и как приводить такую машину в порядок, ничего не уронив.

## Как на самом деле устроена BitrixVM

Половина проблем начинается с того, что администратор считает BitrixVM обычным сервером с nginx и Apache. Формально так и есть, но конфигурация здесь не написана руками, а сгенерирована. Запрос идёт по цепочке:

- nginx принимает 443 и отдаёт статику
- Динамику он проксирует на Apache — но не «на localhost», а на конкретный порт конкретного виртхоста: 8888, 8887 и так далее
- Каждому сайту соответствует свой виртхост Apache со своим DocumentRoot в /home/bitrix/www или /home/bitrix/ext_www/<домен>
- Список сайтов и их ролей хранится отдельно — в реестре, с которым работает меню BitrixVM

Ключевая деталь: в мультисайтовой конфигурации один сайт держит ядро, а остальные ссылаются на него симлинками. Каталог `bitrix` и каталог загрузок у них общие, база тоже одна. Именно поэтому сломанная маршрутизация даёт такой обманчивый симптом — об этом дальше.

Состояние BitrixVM живёт в двух местах сразу: в конфигах nginx и Apache и в реестре сайтов, по которому меню строит своё представление о машине. Меню меняет оба. Ручной `sed` — только первое. С этого расхождения и начинается вся история.

## Симптом: портал открывается, но показывает чужой сайт

Заходишь на адрес портала — отдаётся форма входа. Логин проходит, но внутри вместо портала пусто, а часть разделов отвечает ошибкой «не найден шаблон». Выглядит как поломка портала, а на деле это ошибка одной строки.

_Находим рассинхрон между nginx и Apache_

```bash
# Куда nginx на самом деле шлёт динамику для этого домена
grep -r 'proxyserver' /etc/nginx/bx/site_available/ | grep portal

# bx_ext_ssl_portal.example.ru.conf:
#   set $proxyserver "http://127.0.0.1:8888";   ← виртхост ДРУГОГО сайта

# А на каком порту слушает виртхост самого портала
grep -A2 'VirtualHost' /etc/httpd/bx/conf/bx_ext_portal.example.ru.conf
# <VirtualHost 127.0.0.1:8887>
#   DocumentRoot /home/bitrix/ext_www/portal.example.ru
```

То есть HTTPS-запросы к порталу уходили на виртхост магазина. А поскольку ядро в такой конфигурации общее, авторизация при этом честно работала — что и сбивало с толку. Ломался не вход, а то, чей `DocumentRoot` обслуживает запрос.

Причина рассинхрона типовая: администратор чинил «502 Bad Gateway», создавал и удалял виртхосты на портах 8080, 8888, 8887, 8895, а конфиг nginx правил отдельным `sed`. В какой-то момент Apache уехал на новый порт, а nginx остался на старом.

## Порядок диагностики

Прежде чем что-то менять, стоит выписать реальную картину: какие сайты есть, кто из них держит ядро, какой домен на какой порт и в какой каталог ведёт. На это уходит десять минут, и оно экономит часы.

| Что выяснить | Чем |
| --- | --- |
| Список сайтов и их роли | меню BitrixVM, пункт со списком сайтов |
| Куда nginx шлёт домен | grep proxyserver в /etc/nginx/bx/site_available/ |
| Где слушает Apache | grep VirtualHost в /etc/httpd/bx/conf/ |
| Кто держит ядро | ls -l на каталог bitrix — симлинк или настоящая папка |
| Что отдаётся на самом деле | curl -I к каждому домену, сравнить размеры ответов |

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

## Как чинить, чтобы не уронить работающее

Правильный путь — меню BitrixVM: оно меняет и конфиги, и реестр, то есть не создаёт нового расхождения. Точечную правку конфига руками мы применяем только когда меню недоступно или его действие шире, чем нужно, — и тогда обязательно с бэкапом.

_Пять шагов вместо одного_

```bash
# 1. Снимок конфигов целиком — точка отката на всю сессию
tar czf /root/etc-backup-$(date +%Y%m%d_%H%M%S).tgz \
  /etc/nginx /etc/httpd /etc/ansible /etc/php.d /etc/cron.d

# 2. Бэкап конкретного файла рядом с ним
cp bx_ext_ssl_portal.example.ru.conf{,.bak-$(date +%Y%m%d_%H%M%S)}

# 3. Правка
sed -i 's|8888|8887|' bx_ext_ssl_portal.example.ru.conf

# 4. Проверка ДО применения — иначе reload положит все сайты сразу
nginx -t

# 5. Мягкое применение: текущие соединения не рвутся
systemctl reload nginx
```

Шаг с `nginx -t` пропускают чаще всего, а он здесь важнее остальных: на этой машине один nginx обслуживает все сайты, и синтаксическая ошибка в одном конфиге уронит вообще всё.

## Что ломают тем же способом

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

- Сертификат выпускали вручную через certbot и dehydrated вместо меню. Текущий ещё валиден, но задание на автопродление не создано — сертификат просто истечёт в тихий день
- swap отключили, пересоздали и прописали в fstab UUID корневого раздела. Итог: swap нет вообще, а запись в fstab выглядит правдоподобно
- Параметр ядра для гибернации правили дважды, хотя без рабочего раздела подкачки он ни на что не влияет
- В реестре остался сайт, у которого нет каталога с ядром, — меню на нём показывает ошибку и мешает штатным операциям
- После прерванного обновления ядра осталась папка-двойник модуля на 211 МБ, из-за которой вход в админку падал с фатальной ошибкой

_Проверка swap за одну минуту_

```bash
# Проверка, которая занимает секунду и ловит «мнимый» swap
swapon --show          # пусто — значит swap нет, что бы ни было в fstab
free -h | grep -i swap # Swap: 0B 0B 0B

# Сверяем UUID из fstab с реальными разделами
grep swap /etc/fstab
blkid | grep -E 'sda[0-9]'
# если UUID из fstab совпадает с корневым разделом — запись битая
```

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

## Что забрать себе

- В BitrixVM конфиги генерируемые. Меняете через меню — и конфиги, и реестр остаются согласованными; правите руками — расходятся
- Симптом «сайт показывает чужое содержимое» на мультисайте почти всегда означает не поломку CMS, а неверный порт в проксировании
- Общее ядро маскирует проблему: авторизация и часть страниц продолжают работать, поэтому диагноз ставят неверно
- Перед любой правкой — снимок конфигов, после правки — проверка синтаксиса, только потом мягкое применение
- Сертификаты, swap и обновления ядра ломаются тихо. Их состояние проверяется тремя короткими командами, и это стоит делать при приёмке любого чужого сервера

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

## Досталась такая машина

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

[Посмотреть услугу: серверы и инфраструктура](https://it-zarya.ru/services/servers/) [Обсудить задачу](https://it-zarya.ru/contacts/)

---

Источник: https://it-zarya.ru/blog/bitrixvm-broken-configs/ · IT-агентство «Заря» · itzarya@mail.ru
Markdown-версия любой страницы сайта — тот же адрес с `.md` на конце. Индекс для ассистентов: https://it-zarya.ru/llms.txt