#Симптом и границы применимости
После смены доменного имени HTML открывается по новому адресу, но стили, сценарии или изображения продолжают загружаться с прежнего домена. Это может быть содержимое страницы, заголовки от backend или кэш, а не настройка server_name.
#Возможные причины и как их отличить
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Абсолютные ссылки в шаблонеNginx не переписывает все адреса внутри HTML автоматически. | В исходном HTML встречается старый домен | Найти место формирования URL |
| Кэш CDN/браузераСтарый HTML может храниться после переноса. | Старые адреса приходят только через часть узлов | Сравнить ответы по разным маршрутам |
| Неверный URL на backendПриложение собирает адреса из Host и базового URL. | Location и ссылки зависят от исходного Host | Сверить proxy_set_header и настройки CMS |
#Пошаговая диагностика и исправление
- Выясните источник адреса в браузереНа странице нового домена нажмите F12, откройте вкладку «Сеть» и обновите страницу с отключённым кэшем (если такой переключатель есть). Выберите файл CSS/JS с прежним доменом; в поле Initiator/«Инициатор» посмотрите, из HTML, CSS или сценария возник запрос. Если F12 недоступна, используйте «Посмотреть код страницы» и поиск по старому домену.
- Сравните содержимое без браузерного кэшаНа компьютере откройте Терминал. Скачайте только заголовки HTML; проверьте Content-Type и Location. Для анализа тела страницы сохраните HTML локально через браузер и выполните поиск по старому домену. Не публикуйте страницу, если в ней есть приватные данные.
- Команда не ищет домен в теле HTML; для этого нужен просмотр исходного кодаLinux · Терминал (Bash)КомандаКоманда не ищет домен в теле HTML; для этого нужен просмотр исходного кода.
curl -I https://new.example.com/
- Проверьте базовый адрес в приложенииВ административной панели CMS найдите адрес сайта или адрес медиафайлов. Если в базе хранятся абсолютные ссылки, сначала сделайте резервную копию базы, затем используйте штатный инструмент замены URL с поддержкой сериализованных данных. Простая массовая SQL-замена может повредить данные WordPress и другие структуры.
- Проверьте конфигурацию обратного проксиПо SSH найдите server_name, proxy_set_header Host и proxy_redirect. Если upstream получает внутреннее имя вместо нового домена, проверьте правильность передачи Host. Не копируйте конфигурационный пример как готовый: на сервере может быть несколько доверенных прокси.
- Не пересылайте полную конфигурацию; там могут быть секретыLinux · Терминал (Bash)КомандаНужен sudoНе пересылайте полную конфигурацию; там могут быть секреты.
sudo nginx -T 2>&1 | grep -nE "server_name|proxy_set_header Host|proxy_redirect|sub_filter"
- Проверьте переадресацию со старого доменаЕсли старый домен принадлежит вам, оставьте корректный 301 на новый адрес, чтобы не ломать ссылки, но не считайте это исправлением шаблона. Если старый домен уже недоступен, абсолютные URL нужно убрать в источнике контента. Сравните ссылки в CSS-файлах и пользовательских загрузках отдельно.
- Очистите только подтверждённый кэшПосле изменения первоисточника очистите кэш нужного сайта в CMS/CDN; не очищайте всё хранилище без необходимости. В приватном окне снова откройте страницу и проверьте адреса сетевых запросов. Если в старом домене остались только внешние ссылки, убедитесь, что они не являются требуемыми ресурсами.
#Как проверить результат
Во вкладке «Сеть» больше не должно быть запросов за собственными CSS, JS и изображениями к старому домену. Пройдите по внутренним страницам: шапка, каталог и карточки могут иметь разные шаблоны.
#Если проблема не устранена
Если старые ссылки приходят только через CDN, сравните HTTP-ответ origin и CDN; если внутри тела CSS — исправьте сборку стилей. Не пытайтесь переписать весь HTML на лету с помощью sub_filter без анализа нагрузки и кодировок.