# Админка грузится 17 секунд, а виноват DNS

> Профайлер показывает 99,9% времени в Прологе, запросы к базе — 19 миллисекунд. Разбираем, почему страница грузится 17 секунд и при чём тут резолвер.

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

Клиент жалуется: каталог в админке открывается «вечность». Под анонимом та же страница — сто миллисекунд. База не нагружена, диск свободен, процессор скучает. Разбираем случай, где причина нашлась не в коде и не в базе, а в том, что сервер перестал резолвить имена.

## Что показывал профайлер

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

| Что | Время |
| --- | --- |
| Страница целиком | 17,47 с |
| Из них Пролог | 99,91 % |
| Запросы к базе | 0,019 с |
| Работа компонентов | 0,015 с |
| Та же страница под анонимом | 0,1 с |

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

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

## Почему пролог может занимать 17 секунд

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

Проверяется это одной командой — и проверять надо не «интернет вообще», а именно исходящие запросы с самого сервера:

_Проверка исходящих запросов_

```bash
# Сколько на самом деле занимает обращение наружу
curl -o /dev/null -s -w 'код %{http_code}, время %{time_total}\n' \
  https://www.1c-bitrix.ru/

# было: код 000, время 20.001   ← ровно таймаут, ответа нет
# стало: код 200, время 0.213
```

Двадцать секунд ровно — это не «медленно», это таймаут. Число, подозрительно похожее на круглое, почти всегда означает не нагрузку, а ожидание того, чего не будет.

## Где именно рвалось

Дальше вопрос простой: сеть не работает вообще или не работает разрешение имён? Это разные диагнозы с разной ценой.

_Отделяем сеть от разрешения имён_

```bash
# Резолв через DNS-сервер, прописанный на машине
dig www.1c-bitrix.ru
# ;; connection timed out; no servers could be reached

# Тот же запрос, но мимо него — к публичному резолверу
dig @8.8.8.8 www.1c-bitrix.ru +short
# 178.248.233.117        ← 50 мс

# Что вообще прописано в системе
cat /etc/resolv.conf
# nameserver 192.168.137.1     ← он и не отвечает
```

Картина сложилась: TCP-трафик через шлюз идёт, а DNS-запросы к нему уходят в никуда. Сервер — виртуальная машина, адрес резолвера ей выдавал по DHCP хост, и в какой-то момент хост перестал отвечать на запросы имён, продолжая маршрутизировать остальное. Снаружи это выглядит как «сайт работает, но админка тормозит».

В журнале ошибок самой CMS нашлась запись, сделанная за четыре дня до обращения клиента: «getaddrinfo failed: Name or service not known». Проблема была старше жалобы почти на неделю.

## Почему это заметили только сейчас

Самая поучительная часть истории. До нашего появления вход в админку падал с фатальной ошибкой — после прерванного обновления ядра на диске осталась папка-двойник модуля. Никто не мог войти, а значит никто и не видел, что после входа всё медленно.

- Мёртвый резолвер существовал минимум четыре дня и никого не беспокоил
- Вход в админку был сломан грубее — до фатальной ошибки
- Мы починили фатальную ошибку, вход заработал, проверка обновлений начала реально ходить наружу
- И только тогда «тормоза» стали видимыми — хотя существовали и раньше

Отсюда практическое правило: после починки крупной поломки проверяйте систему заново целиком. Грубая ошибка часто работает как заглушка и прячет за собой вторую, более тихую. Клиенту при этом кажется, что «после вашей правки стало хуже».

## Починка, и почему одной команды мало

Предыдущий администратор уже пытался прописать рабочие резолверы и решил, что не помогает. Команда была правильной, но применялась к соединению с именем `eth0`, а в системе соединение называлось иначе — «Wired connection 1». Команда отрабатывала вхолостую.

_Правка резолверов, которая переживёт перезагрузку_

```bash
# Сначала смотрим, как соединение называется на самом деле
nmcli -g NAME,DEVICE con show
# Wired connection 1:eth0     ← имя соединения ≠ имя устройства

nmcli con mod "Wired connection 1" ipv4.dns "8.8.8.8 1.1.1.1"

# Ключевая строка: без неё DHCP при обновлении аренды
# вернёт мёртвый резолвер обратно, и всё повторится
nmcli con mod "Wired connection 1" ipv4.ignore-auto-dns yes

# Применяем без разрыва SSH-сессии
nmcli device reapply eth0
```

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

Результат проверяется теми же командами, которыми ставился диагноз. Разрешение имён — 50 мс вместо таймаута, обращение наружу — 0,21 с вместо двадцати секунд, страница админки открывается нормально.

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

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

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

## Похожая история

Если «иногда тормозит» никто не может объяснить уже месяцами — это чинится. Расскажите, что происходит, и мы посмотрим, где именно уходит время.

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

---

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