#Что происходит и когда применима инструкция
Новый сертификат установлен, но сайт по HTTPS продолжает открываться из другого виртуального узла — попадает на чужую стартовую страницу, видит неверный корень каталога или не тот сертификат. Важно отличить выбор TLS-сервера по SNI от маршрутизации HTTP по Host.
#Основные причины и их признаки
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Не совпадает server_nameДля входящего запроса сервер выбрал виртуальный узел по умолчанию. | Нужный HTTPS-блок не выбран по доменному имени | Проверьте имя и listen на конечном TLS-сервере. |
| Отсутствует listen для нужного адресаБлок обслуживает только часть интерфейсов или отдельный балансировщик. | IPv4 работает, а IPv6 или другой IP отдаёт чужой сайт | Проверьте все listen 443. |
| Прокси передаёт иной HostПосле TLS маршрутизацию запроса меняет Host на обратном прокси. | Сертификат верный, но содержимое чужого приложения | Проверьте заголовок Host и маршрут upstream. |
#Пошаговая диагностика и устранение
- Разделите две проверкиИз внешнего браузера запишите, какой именно сертификат приходит и какая страница открывается. Если сертификат чужой — исследуйте TLS/SNI; если сертификат правильный, но сайт чужой — вероятнее блок location или Host на внутреннем прокси.
- Проверьте внешний ответ без отключения TLSПодключитесь по имени с curl и посмотрите HTTP-код, серверные заголовки и перенаправления. Не используйте
curl -k, поскольку тогда неверный сертификат может остаться незамеченным.Linux · Терминал (Bash)КомандаТерминал c curl, замените домен. Для содержимого выполните отдельный GET-запрос и не публикуйте данные авторизации.curl -Iv https://example.com/
- Определите действительный публичный адресЗапросите A/AAAA и проверьте, нет ли CDN/балансировщика перед VPS. Если сертификат завершает CDN, правка локального виртуального узла может не влиять на внешний TLS. Запишите путь запроса до конечного приложения.
- Найдите все блоки HTTPSНа сервере Nginx с административным доступом посмотрите итоговую конфигурацию
nginx -T: отыщитеlisten 443 ssl,server_name,ssl_certificate, директивыrootиproxy_pass. Команда может показывать чувствительные пути и заголовки — не отправляйте вывод целиком публично.Linux · Терминал (Bash)КомандаНужен sudoLinux с Nginx; только вывод итоговой конфигурации. Проверьте, кто имеет доступ к нему.sudo nginx -T
- Проверьте совпадение имени и интерфейсаНужный блок должен принимать именно тот IP/порт, который получает запрос, и иметь имя домена в
server_name. Для Apache сравнитеapachectl -Sи VirtualHost. Отдельный блокdefault_serverможет законно отвечать на обращения без SNI.
- Сверьте проксирование HTTPЕсли Nginx отдаёт правильный сертификат, а приложение ошибочно считает другой домен, проверьте передаваемый
Hostи маршрутproxy_pass. Правьте конфигурацию только после сохранения текущей версии; не пропускайте произвольный недоверенный Host к чувствительным внутренним сервисам.
- Проверьте синтаксис и примените точечную правкуПосле изменения одного блока выполните
nginx -tи, если ошибок нет, мягко перечитайте конфигурацию штатным способом. Не удаляйте чужой виртуальный хост ради своего домена — это может отключить другие сайты.Linux · Терминал (Bash)КомандаНужен sudoLinux/Nginx. Безопасная проверка конфигурации до разрешённого администратором reload.sudo nginx -t
- Проверьте оба слоя отдельноПовторите проверку сертификата по SNI и HTTP-запроса по имени. Убедитесь, что сертификат, конечный URL, содержимое страницы и журналы совпадают с нужным сайтом и что соседний сайт на том же IP по-прежнему работает.
#Проверка результата
По HTTPS отображается нужный сертификат и именно нужный сайт, запросы не уходят на чужой каталог или upstream; соседние виртуальные узлы продолжили обслуживать свои имена.
#Если решить проблему не удалось
Если ошибка проявляется только в одном протоколе, сравните раздельные listen для IPv4/IPv6 и активные адреса CDN. Сохраните пример curl и обезличенную конфигурацию соответствующих блоков для администратора.