Сколько сайтов на этой машине: ищем проекты, о которых вам не сказали

MAATRIX

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

Почему на сервере всегда больше сайтов, чем в описании

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

Тестовый лендинг под рекламную кампанию поднимают за вечер, кампания заканчивается через месяц, а лендинг остаётся — его никто не выключал, просто перестали упоминать. Подрядчик разворачивает промо-страницу для клиента клиента и забывает про неё сразу после сдачи работы. Второй домен — старое написание бренда, региональная версия, домен, купленный «про запас» — вешают на тот же сервер, потому что зачем платить за отдельный, и через пару лет о нём помнит только DNS-запись. Стейджинг-копия основного сайта живёт на поддомене staging. или test. годами, потому что «а вдруг понадобится сравнить с продакшеном».

К этому добавляется человеческий фактор передачи дел: если сервер администрировал один человек, а сейчас его нет, знание «что где лежит» ушло вместе с ним. Документация либо не велась, либо велась в голове. В результате единственный надёжный источник правды — сама машина: конфиги, файлы на диске и DNS-записи, указывающие на её IP. Идти стоит по всем трём источникам сразу, потому что каждый закрывает свой слепой участок: конфиг покажет, что сервер обслуживает прямо сейчас, файловая система — что физически лежит на диске (включая выключенное), а DNS — что указывает на этот сервер снаружи, независимо от того, знает ли об этом сама машина.

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

Конфиги веб-сервера: nginx и Apache говорят правду о том, что запущено

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

Для nginx смотрите на структуру sites-available и sites-enabled (в Debian/Ubuntu) или прямо на conf.d (в CentOS/AlmaLinux и на большинстве панелей):

ls -la /etc/nginx/sites-enabled/
ls -la /etc/nginx/conf.d/

Дальше вытащите все директивы server_name из активных конфигов одной командой — это даёт список доменов, которые сервер реально отвечает:

grep -rh "server_name" /etc/nginx/sites-enabled/ /etc/nginx/conf.d/ 2>/dev/null \
  | sed 's/#.*//' | awk '{$1=""; print}' | tr -s ' ' '\n' | sed 's/;//' | sort -u

Три нюанса, о которые здесь обычно спотыкаются. Во-первых, sites-available — не то же самое, что sites-enabled: в первом каталоге может лежать отключённый конфиг (нет симлинка) от сайта, который физически всё ещё существует и может быть включён обратно в любой момент. Во-вторых, один server блок может обслуживать сразу несколько доменов через server_name site1.ru site2.ru www.site1.ru; — не путайте число блоков с числом доменов. В-третьих, server_name _; или default_server — блок по умолчанию, ловящий все запросы без совпадения по имени; если он отдаёт реальный контент, а не заглушку, за ним может прятаться сайт, вообще не упомянутый по имени в конфиге.

Для Apache логика похожа, но синтаксис другой — ищите ServerName и ServerAlias внутри VirtualHost:

ls -la /etc/apache2/sites-enabled/
grep -rhE "ServerName|ServerAlias" /etc/apache2/sites-enabled/ 2>/dev/null \
  | awk '{$1=""; print}' | tr -s ' ' '\n' | sort -u

Если на сервере стоит панель управления (aaPanel, FastPanel, ISPmanager, cPanel), она генерирует конфиги автоматически из своей внутренней базы сайтов — быстрее и надёжнее посмотреть список прямо в панели, а grep по конфигам использовать как перепроверку: панель иногда хранит записи, которые ещё не применены, или наоборот — конфиг остаётся от сайта, удалённого с ошибкой очистки.

Отдельный случай — обратный прокси перед контейнерами (Traefik, Nginx Proxy Manager, Caddy с автоконфигурацией). Там список доменов может лежать не в текстовом конфиге, а в лейблах Docker Compose или в собственной базе прокси:

grep -r "Host(" docker-compose*.yml 2>/dev/null
grep -rE "traefik.http.routers" docker-compose*.yml 2>/dev/null

Если на сервере используется Caddy вместо nginx, список доменов там читается ещё проще — Caddy указывает домен прямо как первую строку блока в Caddyfile, без отдельной директивы.

Файловая система: каталоги, о которых забыл даже конфиг

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

Начните с типовых мест, где живут сайты:

ls -la /var/www/
ls -la /var/www/html/
ls -la /home/*/public_html/ 2>/dev/null
ls -la /srv/

На серверах с панелями структура обычно предсказуема — у каждого сайта свой каталог с именем, совпадающим с доменом (/var/www/site.ru/, /home/site_ru/public_html/), что упрощает сверку: сравните список каталогов со списком server_name, найденным на предыдущем шаге, и любое расхождение — кандидат на разбор.

comm -23 <(ls /var/www/ | sort) <(grep -rh "server_name" /etc/nginx/sites-enabled/ 2>/dev/null | awk '{print $2}' | tr -d ';' | sort -u)

Эта команда покажет каталоги в /var/www/, для которых не нашлось соответствующего server_name — именно такие каталоги чаще всего оказываются «сайтами, о которых не сказали»: либо отключёнными от веб-сервера, либо обслуживаемыми через какой-то нестандартный путь, который стоит выяснить отдельно.

Не забудьте про признаки, что каталог — это заброшенный, а не активный проект: дата последнего изменения файлов, наличие .git с давним последним коммитом, файлы вида backup_2023.zip или site_old/ прямо рядом с текущей версией. Команда find с сортировкой по времени модификации быстро покажет, что не трогали дольше всего:

find /var/www/ -maxdepth 1 -type d -exec sh -c 'echo "$(stat -c %Y "$1") $1"' _ {} \; | sort -n

Отдельно проверьте контейнерные volumes, если на сервере используется Docker — иногда сайт живёт не в файловой системе хоста, а в томе, примонтированном к контейнеру, и обычный ls /var/www/ его просто не покажет:

docker volume ls
docker ps -a --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}"

Контейнер со статусом Exited несколько месяцев назад, но с портом 80 или 443 в проброске — признак сайта, который формально существует, но не отдаёт трафик, потому что забыли перезапустить после ребута сервера.

DNS: какие домены вообще указывают на этот IP

Конфиг и файловая система расскажут, что сервер *готов* обслуживать. Но остаётся обратный вопрос — какие домены *снаружи* указывают именно на этот IP. Иногда домен настроен во внешнем DNS, но забыли добавить server_name — тогда запрос падает на default_server и либо отдаёт неправильный сайт, либо 444/403.

Прямого способа «спросить у интернета все домены, указывающие на IP X» не существует — обратный DNS (PTR-запись) даёт максимум одно имя, и то не обязательно совпадающее с реальными сайтами:

dig -x 203.0.113.10 +short

Рабочий подход — пройти по доменам, которые вы точно знаете за собой (из регистратора, из панели DNS, из счетов), и для каждого проверить, куда он указывает сейчас:

for domain in site1.ru site2.ru old-brand.ru; do
  echo -n "$domain: "; dig +short A "$domain"
done

Если в списке регистратора есть домен, который резолвится именно на IP этого сервера, а среди найденных ранее server_name его нет — это либо забытый и висящий «в воздухе» домен, либо сайт, обслуживаемый через тот самый server_name _; по умолчанию, который стоит проверить отдельно.

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

curl -s "https://crt.sh/?q=203.0.113.10&output=json" | head -c 2000

Учтите ограничение: такие сервисы показывают домены, чей сертификат когда-либо был выпущен для этого IP или связанного имени — если у сайта никогда не было TLS-сертификата (чистый HTTP или закрытый только по IP), passive DNS его не увидит. Это ориентировочный, а не исчерпывающий метод — он находит кандидатов, а не гарантированно полный список.

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

Заброшенные поддомены: отдельная категория риска

Поддомены заслуживают отдельного шага: они плодятся быстрее полноценных доменов, потому что не нужно ничего регистрировать и оплачивать отдельно — достаточно одной A-записи в существующей зоне. test., old., staging., demo-client., promo2023. — типичные префиксы, за которыми часто скрывается давно не обновляемый движок с известными уязвимостями. Способы найти такие поддомены:

Certificate Transparency. Если для поддомена хоть раз выпускали TLS-сертификат (в том числе автоматически через Let's Encrypt), он почти наверняка попал в публичные CT-логи:

curl -s "https://crt.sh/?q=%25.example.com&output=json" | grep -o '"name_value":"[^"]*"' | sort -u

Брутфорс по словарю распространённых префиксов — быстрый способ проверить типовые варианты, если через CT-логи ничего интересного не всплыло:

for sub in test staging dev old demo backup admin api beta preview; do
  ip=$(dig +short "$sub.example.com" A)
  [ -n "$ip" ] && echo "$sub.example.com -> $ip"
done

Экспорт зоны из своей DNS-панели — самый надёжный источник, если домен управляется через BIND, PowerDNS или панель регистратора: там видно все A/CNAME записи разом, включая те, что никто давно не открывал в браузере. Зонный трансфер (dig axfr) в большинстве случаев закрыт снаружи и это правильно с точки зрения безопасности — но изнутри, из панели управления, тот же список обычно доступен через обычный экспорт в текстовом виде.

Найденный забытый поддомен со старым движком — это не просто цифровой мусор, а реальная точка входа для атаки: подробный разбор, почему так происходит и что делать с находкой, — в статье «Старый поддомен со сломанной CMS: его нашли раньше вас». А если поддомен указывает на IP, который вам уже не принадлежит (сменили сервер, а запись не убрали) — это отдельный и более опасный сценарий перехвата, разобранный в статье «Поддомен угнали через забытую запись DNS».

Как разобраться с находками: три корзины вместо одного списка

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

Для «непонятной» корзины полезно проверить логи веб-сервера за последние недели — если у сайта есть хоть какой-то живой трафик от реальных пользователей (не от сканеров), это сильный аргумент за то, что он кому-то нужен, даже если внутри компании о нём забыли:

grep "site-in-question.ru" /var/log/nginx/access.log* | awk '{print $1}' | sort -u | wc -l

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

Как зафиксировать результат, чтобы не искать заново через год

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

Домен              | Каталог/конфиг              | Статус     | Владелец   | Проверено
example.ru         | /var/www/example.ru          | активен    | маркетинг  | 2026-08
old-brand.ru        | /var/www/old-brand (отключ.) | архив      | -          | 2026-08
staging.example.ru  | /var/www/example.ru-stage    | под вопрос | разработка | 2026-08

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

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