Вебмастеры и владельцы сайтов иногда сталкиваются с неожиданной ситуацией: их сайт становится доступен не только по собственному домену, но и по чужому адресу, к которому они не имеют отношения. Разберём, почему так происходит, чем это опасно, и как грамотно закрыть дыру на сервере.
Проблема: сайт открывается по чужому домену
Суть проблемы — кто-то направил чужой домен (например, через A-запись или CNAME) на ваш серверный IP. Если веб-сервер (чаще всего nginx или apache) не настроен корректно, он может отдавать содержимое вашего сайта для любого домена, который указывает на ваш IP-адрес.
Чем это опасно?
- SEO-дубли: поисковые системы могут увидеть несколько копий сайта на разных доменах, что негативно влияет на позиции.
- Риск фишинга: злоумышленники могут выдать ваш сервис за свой или сделать фейк-страницы на вашем движке.
- Безопасность авторизации: возможны уязвимости с cookies и сессиями.
- Снижение доверия поисковых систем: зеркала и клоны могут привести к фильтрам и санкциям.
Почему так происходит?
Когда nginx (или другой веб-сервер) принимает запрос, он определяет, какой сайт отдавать, по следующим параметрам:
- IP и порт (listen 80, listen 443 ssl и т.д.)
- server_name (имя домена)
Если нет явной привязки домена к конкретному блокy server, nginx может отдать сайт по первому подходящему блоку или по default_server. В результате сайт становится доступен для любого домена, который смотрит на ваш IP.
Как настроить защиту?
1. Разделите рабочие блоки и заглушки
- Заглушка — блок, который отдает ошибку 444 или 403 для всех доменов, кроме ваших.
- Рабочий блок — блок только для ваших доменов (например, example.com и www.example.com).
2. Используйте явные IP в директивах listen
Пропишите явный IP вашего сервера, чтобы рабочий блок не перехватывал все запросы на любой IP.
Пример правильной схемы для nginx:
# Заглушка (default_server)
server {
listen 80 default_server;
server_name _;
return 444;
}
server {
listen 443 ssl default_server;
server_name _;
ssl_certificate /etc/ssl/certs/fake.crt;
ssl_certificate_key /etc/ssl/private/fake.key;
return 444;
}
# Рабочий блок (только для своего сайта)
server {
listen XXX.XXX.XXX.XXX:80;
server_name example.com www.example.com;
root /var/www/example.com;
# Другие настройки
}
server {
listen XXX.XXX.XXX.XXX:443 ssl;
server_name example.com www.example.com;
ssl_certificate /etc/ssl/certs/example.com.crt;
ssl_certificate_key /etc/ssl/private/example.com.key;
root /var/www/example.com;
# Другие настройки
}
3. Убедитесь, что нет лишних listen без IP
Запрещено использовать просто listen 80; или listen 443 ssl; в рабочих блоках — это приведёт к тому, что сайт будет доступен по всем доменам на сервере!
Диагностика и типовые ошибки
- Случайно оставили listen 80 или listen 443 ssl в рабочем блоке — сайт будет доступен по любому домену.
- Рабочий блок с default_server — конфликт и предупреждение “duplicate default server”.
- Дефолтный блок server_name localhost или _ без return 444 — nginx будет использовать его как запасной, и он отдаст что угодно.
- Забыли про IPv6 (listen [::]:80 и listen [::]:443 ssl) — чужие домены могут открываться через IPv6.
Пошаговое решение
- Проверьте, какие блоки слушают ваши порты:
nginx -T | grep listen
nginx -T | grep server_name
- Оставьте default_server только для заглушки (с return 444).
- В рабочих блоках используйте listen только с IP и без default_server.
- Удалите или исправьте все listen 80; и listen 443 ssl; без указания IP.
- Перезагрузите nginx:
nginx -t
systemctl reload nginx
- роверьте доступность сайта с чужого домена через curl:
curl -I http://chuzhoidomen.ru --resolve chuzhoidomen.ru:80:ВАШ_IP
curl -Ik https://chuzhoidomen.ru --resolve chuzhoidomen.ru:443:ВАШ_IP
Вы должны получить ошибку или отсутствие ответа (444).
Результат
После правильной настройки:
- Ваш сайт работает только на ваших доменах.
- Любой чужой домен, который “указывает” на ваш IP, получает отказ (код 444 или 403).
- Проблем с SEO-дублированием и безопасностью больше не возникает.
Совет
Если nginx всё равно отдаёт сайт по чужому домену, проверьте весь конфиг на лишние блоки listen 80 и listen 443 ssl без IP, и внимательно посмотрите, нет ли дефолтных блоков, которые могут перехватывать трафик.
Такая ситуация встречается часто у начинающих вебмастеров и на “стандартных” сборках nginx в Ubuntu/Debian. Исправляется за 10 минут, главное — понять принцип работы директив listen и server_name.
Берегите свои сайты и конфиги!