Pi-hole на сервере: частые ошибки и решения

MAATRIX

Pi-hole на Raspberry Pi дома и Pi-hole на удалённом сервере — два разных мира. Дома всё работает «из коробки», потому что нет конкуренции за порт 53, нет docker-сети и нет вопроса «а как достучаться до DNS снаружи». На VPS вылезают ровно те грабли, которые проектировщики Pi-hole не закладывали как основной сценарий. Ниже — конкретные симптомы и рабочие решения, без «просто переустановите».

Порт 53 занят: конфликт с systemd-resolved

Самая частая причина, по которой установщик Pi-hole падает с ошибкой Port 53 is already in use или FTL не стартует после установки — на Ubuntu (20.04 и новее) порт 53 занят системным systemd-resolved, который слушает на 127.0.0.53.

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

sudo ss -tulpn | grep :53

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

sudo nano /etc/systemd/resolved.conf

Раскомментируйте и измените строку:

[Resolve]
DNSStubListener=no

Дальше переключаем /etc/resolv.conf на реальный резолвер вместо стаба и перезапускаем сервис:

sudo rm /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
sudo systemctl restart systemd-resolved
sudo systemctl restart pihole-FTL

После этого ss -tulpn | grep :53 должен показывать pihole-FTL, а не systemd-resolve. Если ставите Pi-hole сразу «набело» на новый сервер, эту правку стоит сделать до запуска установщика — тогда curl -sSL https://install.pi-hole.net | bash пройдёт без ошибок с первого раза.

Web-интерфейс не открывается или lighttpd не стартует

Вторая по частоте проблема на арендованном сервере — порт 80 уже занят nginx или Apache, которые вы держите для других сайтов и панелей. lighttpd, который Pi-hole использует для админки, тихо falls back или конфликтует, и http://ваш-ip/admin не открывается.

Решение — либо освободить порт, либо перевести Pi-hole на другой:

sudo pihole -a -p

Команда спросит новый порт (например, 8080) и, если нужно, включит SSL на своём порту. После смены админка будет доступна по http://ваш-ip:8080/admin. Если перед сервером стоит nginx как reverse proxy для других сервисов, можно прокинуть отдельный поддомен на 127.0.0.1:8080 — так интерфейс Pi-hole не будет торчать на публичном порту напрямую.

DNS резолвится локально, но не отвечает с других устройств

Вот здесь и кроется главное отличие сервера от Raspberry Pi дома. По умолчанию (начиная с Pi-hole v5.7+) режим прослушивания — «Allow only local requests»: FTL отвечает только на запросы из тех подсетей, что указаны как локальные для интерфейса. С внешнего IP клиента запрос просто получает REFUSED, хотя dig @127.0.0.1 google.com на самом сервере работает идеально.

Меняется это в веб-интерфейсе: Settings → DNS → Interface listening behavior → Listen on all interfaces, permit all origins. Либо через CLI:

pihole-FTL --config dns.listeningMode ALL

(в версиях до Pi-hole v6 то же самое правится в /etc/pihole/pihole-FTL.conf параметром LISTENING_MODE=ALL, после чего нужен pihole restartdns).

Важный нюанс безопасности. Открывать порт 53 на весь интернет без ограничений — плохая идея: публичный DNS-резолвер становится инструментом DNS-амплификации в чужих DDoS-атаках, и провайдер вправе заблокировать сервер за такой трафик. Ограничивайте доступ файрволом до конкретных IP или подсети VPN:

sudo ufw allow from 10.8.0.0/24 to any port 53 proto udp
sudo ufw allow from 10.8.0.0/24 to any port 53 proto tcp
sudo ufw deny 53

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

Docker: сеть, петля DNS и health check

При установке Pi-hole через docker-compose типичная ошибка — контейнер вроде бы стартует, но DNS не отвечает или сам контейнер не может резолвить upstream-серверы. Причина обычно в режиме сети: bridge с явным пробросом портов 53/tcp и 53/udp работает, но тогда встроенный DNS docker (127.0.0.11) может конфликтовать с тем, что Pi-hole сам пытается быть DNS для хоста. Проще и надёжнее — network_mode: host:

services:
  pihole:
    container_name: pihole
    image: pihole/pihole:latest
    network_mode: "host"
    environment:
      TZ: 'Europe/Moscow'
      FTLCONF_webserver_api_password: 'смените_на_свой_пароль'
    volumes:
      - './etc-pihole:/etc/pihole'
      - './etc-dnsmasq.d:/etc/dnsmasq.d'
    restart: unless-stopped

В режиме host контейнер напрямую занимает порты хоста — а значит, тот же конфликт с systemd-resolved из первого раздела актуален и здесь, чиним его так же на уровне хост-системы. Если контейнер после docker compose up -d сразу падает или перезапускается по кругу — прогоните диагностику из статьи про контейнер, который не запускается: чаще всего дело в правах на volume /etc/pihole или в занятом порту.

Для контроля состояния имеет смысл добавить healthcheck в compose-файл, чтобы оркестратор перезапускал FTL при зависании, а не оставлял «мёртвый» DNS висеть часами — как это сделать, подробно разобрано в статье про настройку docker healthcheck.

Gravity не обновляется, блок-листы не применяются

Если pihole -g зависает, завершается с ошибками или блокировка рекламы просто перестала работать после апдейта, смотрите лог:

tail -n 50 /var/log/pihole/pihole_updateGravity.log

Частые причины на сервере:

• Нет исходящего доступа — сервер за жёстким файрволом не может достучаться до источников блок-листов (firebog.net и подобные). Проверьте curl -I https://raw.githubusercontent.com/... вручную.
• Список отдаёт 403/404 — источники периодически переезжают или блокируют массовые запросы по User-Agent. Удалите нерабочий URL в Settings → Adlists и добавьте актуальную замену.
• Слишком много списков одновременно — gravity собирает миллионы доменов, база gravity.db раздувается, обновление занимает минуты вместо секунд на слабом VPS. Не гонитесь за количеством листов: 3–5 качественных (например, из подборки OISD или StevenBlack) работают лучше десятка пересекающихся.

Если Pi-hole в Docker, команда выполняется через docker exec:

docker exec -it pihole pihole -g -v

Флаг -v даёт подробный вывод — полезно, чтобы увидеть, на каком конкретно списке процесс встал.

FTL падает, база растёт, не хватает памяти

На минимальных тарифах (512 МБ–1 ГБ RAM) под нагрузкой FTL иногда падает по OOM — особенно если домашняя сеть большая или включено логирование запросов по умолчанию. Проверка причины:

journalctl -u pihole-FTL -n 100 --no-pager
dmesg | grep -i "oom\|killed process"

Если видите Out of memory: Killed process ... pihole-FTL — вариантов два: добавить своп или уменьшить объём хранимых данных. Своп на VPS с SSD добавляется быстро:

sudo fallocate -l 1G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Уменьшить нагрузку на базу можно через ограничение срока хранения истории запросов — в веб-интерфейсе Settings → Long-term data → Query database → Maximum DB age, по умолчанию 365 дней, для маленького сервера разумно поставить 7–30. Это не влияет на саму блокировку, только на объём хранимой статистики.

Если проблема не в памяти, а в общей производительности сервера под несколькими сервисами сразу, стоит сверить общую картину нагрузки — иногда дело не в Pi-hole, а в соседнем контейнере, который съедает CPU в фоне.

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