AdGuard Home на сервере: частые ошибки и решения

MAATRIX

AdGuard Home ставится за пять минут, но именно в эти пять минут чаще всего и ломается: порт 53 занят системным резолвером, панель админки не открывается снаружи, фильтры вроде подключены, а реклама всё равно проходит. Ниже — разбор конкретных симптомов AdGuard Home на сервере по схеме «что видите — почему это происходит — что делать», без теории, только рабочие команды.

Установка не запускается: порт 53 уже занят

Самая частая ошибка при первом запуске AdGuard Home на Ubuntu/Debian — сообщение вида bind: address already in use при попытке поднять DNS-сервер. Причина почти всегда одна: systemd-resolved уже слушает 53-й порт.

Проверьте, кто держит порт:

sudo ss -tulnp | grep ':53'

Если видите systemd-resolve, отключите его встроенный резолвер (не сам сервис, а именно DNS-стаб):

sudo mkdir -p /etc/systemd/resolved.conf.d
sudo tee /etc/systemd/resolved.conf.d/adguardhome.conf <<'EOF'
[Resolve]
DNS=127.0.0.1
DNSStubListener=no
EOF
sudo systemctl restart systemd-resolved

После этого /etc/resolv.conf может остаться симлинком на stub-resolv.conf с адресом 127.0.0.53 — пропишите резолвер вручную, иначе сама система потеряет DNS ещё до старта AdGuard Home:

sudo rm /etc/resolv.conf
sudo tee /etc/resolv.conf <<'EOF'
nameserver 127.0.0.1
EOF
sudo chattr +i /etc/resolv.conf

Флаг +i защищает файл от перезаписи при следующей загрузке — иначе systemd-resolved снова подменит его при рестарте. Только после этого запускайте установщик:

curl -s -S -L https://raw.githubusercontent.com/AdguardTeam/AdGuardHome/master/scripts/install.sh | sh -s -- -v

Если поднимаете AdGuard Home в Docker, конфликт решается проще — контейнеру не важно, что творится с systemd-resolved хоста, порт пробрасывается напрямую:

services:
  adguardhome:
    image: adguard/adguardhome:latest
    restart: unless-stopped
    ports:
      - "53:53/tcp"
      - "53:53/udp"
      - "3000:3000/tcp"   # первичная настройка
      - "80:80/tcp"       # веб-панель после установки
    volumes:
      - ./work:/opt/adguardhome/work
      - ./conf:/opt/adguardhome/conf

Такой подход снимает проблему конфликта портов с хостовыми сервисами разом — детали работы с Compose на сервере разобраны в статье про Docker Compose для продакшена.

Веб-панель 3000/80 недоступна снаружи

Установщик поднимает временную панель настройки на порту 3000, а после мастера — рабочую на порту, который вы указали (обычно 80 или 3001). Если панель открывается по localhost на самом сервере, но не открывается по внешнему IP из браузера — дело почти всегда в фаерволе.

Проверьте правила UFW:

sudo ufw status verbose

Откройте нужные порты явно, а не общим правилом на весь диапазон:

sudo ufw allow 3000/tcp comment 'AdGuard Home setup'
sudo ufw allow 80/tcp comment 'AdGuard Home web'
sudo ufw allow 53 comment 'AdGuard Home DNS'

Если фаервол ни при чём и порт открыт, но соединение всё равно сбрасывается — проверьте, на каком интерфейсе слушает сам AdGuard Home. В AdGuardHome.yaml за это отвечает секция http:

http:
  address: 0.0.0.0:80

Значение 127.0.0.1:80 вместо 0.0.0.0:80 — вторая по частоте причина недоступности панели снаружи: сервис слушает только локальный интерфейс и снаружи сервера попросту не виден, при этом никакой ошибки в логах не будет. Полный разбор похожих граблей с UFW — в статье про частые ошибки фаервола на сервере.

Блокировки не применяются: клиент резолвит мимо AdGuard Home

Панель показывает, что фильтры загружены, статистика по запросам растёт, а реклама на сайтах всё равно показывается. В девяти случаях из десяти это означает, что устройство не использует ваш AdGuard Home как DNS-сервер, а резолвит запросы другим путём.

Первое, что стоит проверить — какой DNS реально видит браузер:

nslookup adguardhome-test.com

AdGuard Home отвечает на этот тестовый домен собственной меткой, если резолвинг действительно идёт через него. Если ответа нет или домен не резолвится через ваш сервер — DNS на клиенте прописан неправильно, либо роутер раздаёт по DHCP свой DNS поверх вашего.

Второе и куда более коварное — браузерный DoH (DNS over HTTPS). Chrome, Firefox и Edge в последних версиях по умолчанию используют собственные DoH-резолверы (Cloudflare, Google) в обход системных настроек DNS, а значит и в обход AdGuard Home. Проверить это можно через chrome://settings/security — секция «Использовать безопасный DNS». Если она включена с резолвером не от AdGuard Home, все ваши блокировки на уровне сети браузер просто игнорирует. Механизм этого обхода детально разобран в статье про DNS over HTTPS — там же способ вернуть DNS-запросы под контроль системного резолвера.

Третья причина — DNS-кеш на самом устройстве. Старые записи могли закешироваться до того, как вы переключили резолвер:

# Windows
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache

# Linux (systemd-resolved)
sudo resolvectl flush-caches

Ошибка при добавлении DoH/DoT upstream-сервера

AdGuard Home умеет ходить к вышестоящим DNS не по обычному 53-му порту, а по зашифрованным DoH/DoT — это одно из главных отличий от классического Pi-hole, у которого шифрованные upstream'ы «из коробки» не поддерживались так же гладко. В настройках Upstream DNS servers добавляете строку вида:

https://dns.cloudflare.com/dns-query
tls://1.1.1.1

Частая ошибка — сервер сообщает upstream dns не отвечает или таймаут при тестировании. Причины обычно две:

1. Исходящий трафик на 443/853 порт блокируется фаерволом провайдера или самого сервера. Проверьте, что исходящие соединения разрешены:

curl -v https://dns.cloudflare.com/dns-query

Если curl тоже не достучался — проблема не в AdGuard Home, а в сетевом окружении сервера (это особенно актуально для серверов в России, где часть DoH-провайдеров может резаться на уровне магистрали).

1. Неверный формат upstream-строки. DoT (DNS over TLS) требует префикс tls://, DoH — https:// с суффиксом /dns-query для большинства провайдеров. Без префикса AdGuard Home пытается трактовать адрес как обычный DNS на 53-м порту и получает отказ.

Если протестировать upstream через встроенную кнопку «Test upstreams» в панели, AdGuard Home покажет конкретную причину отказа по каждому серверу отдельно — с этого стоит начинать диагностику, а не с логов.

Панель админки просит логин, но пароль не подходит

Если вы потеряли доступ к веб-панели (забыли пароль, сбросили сервер, унаследовали чужую установку), пароль сбрасывается напрямую через конфигурационный файл — веб-интерфейса для сброса пароля в AdGuard Home нет.

Остановите сервис, удалите блок users в AdGuardHome.yaml:

sudo systemctl stop AdGuardHome
sudo nano /opt/AdGuardHome/AdGuardHome.yaml

Найдите и удалите секцию:

users:
    - name: admin
      password: $2a$10$...

Сохраните файл и запустите сервис заново — мастер первичной настройки откроется снова и попросит создать нового пользователя:

sudo systemctl start AdGuardHome

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

Высокая нагрузка на CPU или память при большом числе клиентов

На серверах, которые обслуживают DNS для десятков устройств (домашняя сеть, офис, VPN-клиенты), AdGuard Home иногда начинает заметно грузить CPU. Прежде чем winить это утечкой памяти, проверьте три типичные причины:

• Слишком частое логирование запросов. По умолчанию AdGuard Home пишет полный лог всех DNS-запросов. На активной сети это десятки тысяч записей в час. В разделе Settings → General settings ограничьте время хранения логов (Query log retention) или отключите его вовсе, если аналитика не нужна.
• Слишком много подключённых списков блокировки. Каждый дополнительный фильтр — это лишняя память под таблицу правил и время на её пересборку при обновлении. Список из 8-10 крупных фильтров (AdGuard Base + несколько трекер-листов) обычно достаточен; десятки списков «на всякий случай» ощутимо утяжеляют процесс без пропорционального выигрыша в блокировке.
• Rewrites и DNS-кеш занижены под нагрузку. Если TTL кеша слишком мал, сервер вынужден заново резолвить одни и те же домены слишком часто. В Settings → DNS settings увеличьте Cache size (по умолчанию 4 МБ — для активной сети стоит поднять до 32-64 МБ) — это ориентировочные значения, конкретную цифру стоит подбирать под свою нагрузку.

Для машины, которая тянет только DNS-фильтрацию на семью или небольшой офис, обычно хватает 1 vCPU и 512 МБ-1 ГБ RAM с большим запасом — тяжёлой нагрузкой AdGuard Home сам по себе не считается, проблемы почти всегда упираются в перечисленные настройки, а не в железо.

AdGuard Home vs Pi-hole: когда что выбирать

Оба решения решают одну задачу — блокировку рекламы и трекеров на уровне DNS для всей сети сразу, но по-разному:

Если вам важен упор именно на DoH/DoT и гибкие правила фильтрации — AdGuard Home логичнее. Если нужен максимально простой инструмент «поставил и забыл» — стоит посмотреть установку Pi-hole на VPS и сравнить на практике, какой интерфейс вам удобнее.

Частые вопросы