У вас есть virtual shared hosting и в рамках него часть клиентов получают контент не из своего servername, а из общего servername. Почему?

Диагностика проблемы «пересечения» контента на виртуальном хостинге

Проблема, когда клиенты виртуального хостинга получают контент не из своего servername, а из общего (например, default или первого в списке виртуального хоста), является классической для веб-серверов, работающих в режиме общего хостинга. Я, как DevOps-инженер с опытом развертывания и обслуживания таких платформ, могу выделить несколько основных причин этой ситуации. Давайте разберем их системно.

1. Конфигурация веб-сервера (Nginx/Apache)

Основная причина почти всегда кроется в конфигурации виртуальных хостов (VirtualHosts) на веб-сервере.

Для Nginx:

В Nginx виртуальные хосты определяются блоками server. Проблема возникает, если:

• Отсутствует или неправильно настроен блок server для servername клиента.
• Запрос приходит на IP-адрес сервера или домен, не совпадающий ни с одним server_name, и обрабатывается блоком default_server, который может быть общим или принадлежать другому клиенту.

Пример проблемной конфигурации Nginx:

# Общий/дефолтный сервер, который ловит "лишние" запросы
server {
    listen 80 default_server; # Ключевая директива!
    server_name _;
    root /var/www/default; # Клиенты могут получать контент отсюда
    ...
}

# Блок для клиента example.com, но без директивы default_server
server {
    listen 80;
    server_name example.com;
    root /var/www/example;
    ...
}

Если запрос приходит, например, по IP-адресу, он будет обработан первым блоком (default_server), а не блоком для example.com.

Для Apache:

В Apache аналогичная логика: первый объявленный VirtualHost может стать дефолтным, если запрос не соответствует ни одному ServerName или ServerAlias.

Пример проблемной конфигурации Apache:

<VirtualHost *:80>
    # Этот хост может стать получателем "чужих" запросов,
    # если он первый в конфигурации и нет явного дефолта
    ServerName general.host
    DocumentRoot /var/www/general
</VirtualHost>

<VirtualHost *:80>
    ServerName client-site.com
    DocumentRoot /var/www/client
</VirtualHost>

2. DNS и сетевая маршрутизация

Проблема может быть не на сервере, а на пути к нему:

• DNS-кеширование или неправильные A/AAAA записи: DNS клиентского домена может по-прежнему указывать на старый или общий IP-адрес, особенно если недавно менялась инфраструктура. Необходима проверка dig client-domain.com.
• Общий IP-адрес: На одном IP-адресе обслуживается множество сайтов (SNI - Server Name Indication). Если клиент делает запрос не по имени, а по IP, или если используется устаревшее ПО без поддержки SNI, веб-сервер не сможет определить нужный виртуальный хост и отдаст контент дефолтного.
• Неправильные записи в /etc/hosts на клиентской или тестовой машине.

3. Кэширование на разных уровнях

• Кэш веб-сервера или FastCGI (например, fastcgi_cache в Nginx): Если кэш сконфигурирован без учета host заголовка, он может отдавать закэшированный ответ от одного сайта для запросов к другому.
• Кэш CDN или обратного прокси: Промежуточные прокси-серверы (Cloudflare, Varnish, корпоративный прокси) могут некорректно кэшировать и подменять контент.
• Браузерный кэш: Иногда старые файлы (CSS, JS) могут подгружаться из кэша браузера, если пути к ресурсам на разных сайтах совпадают, но это редко является корневой причиной.

4. Проблемы на уровне приложения или файловой системы

• Симлинки или общие точки монтирования: Внутри DocumentRoot клиента могут существовать символические ссылки, ведущие в каталоги другого клиента или общую папку.
• Некорректная логика CMS: Некоторые CMS (например, WordPress) могут жестко прописывать URL сайта в базе данных или конфигурационных файлах. При копировании базы с одного сайта на другой без замены этих URL, сайт может пытаться загружать ресурсы (изображения, стили) с оригинального домена.
• Ошибки прав доступа: Скрипты одного клиента могут получить доступ к файлам другого из-за некорректно настроенных пользователей и групп (например, все сайты работают от одного пользователя www-data).

План диагностики и решения

Как DevOps, я бы действовал по следующему алгоритму:

1. Воспроизведение и изоляция:

    *   Использовать `curl` с явным указанием заголовка `Host` для проверки.

```bash
curl -H "Host: client-domain.com" http://SERVER_IP/
curl -H "Host: general-host.com" http://SERVER_IP/
```

    Это сразу покажет, корректно ли веб-сервер различает хосты.

1. Аудит конфигурации веб-сервера:

    *   Проверить наличие и порядок объявления блоков `server` (Nginx) или `VirtualHost` (Apache).
    *   Убедиться, что у **каждого** клиентского сайта есть свой корректный блок конфигурации с правильным `server_name`.
    *   Назначить явный и контролируемый блок `default_server` (в Nginx) или `_default_` (в Apache), который, например, возвращает ошибку 444 (Nginx) или перенаправляет.
    *   Перечитать конфигурацию (`nginx -t && systemctl reload nginx`).

1. Проверка системных логов:

    *   `tail -f /var/log/nginx/access.log` — посмотреть, с каким `Host` заголовком приходят запросы.
    *   `tail -f /var/log/nginx/error.log` — найти ошибки конфигурации.

1. Проверка окружения:

    *   Верификация DNS-записей клиентских доменов.
    *   Проверка отсутствия неочевидных прокси или правил iptables, которые могут модифицировать трафик.
    *   Анализ дерева каталогов и прав доступа к файлам `DocumentRoot`.

Заключение: Наиболее вероятная причина в контексте виртуального shared-хостинга — отсутствие или неправильный приоритет виртуального хоста для конкретного домена клиента в конфигурации веб-сервера, что приводит к обработке запросов дефолтным (общим) виртуальным хостом. Решение лежит в области корректной настройки default_server и проверки уникальности и полноты блоков конфигурации для каждого server_name.