Вместо сайта открывается заглушка FASTPANEL после смены DNS

Почему после смены DNS открывается страница FASTPANEL, а не сайт

Заглушка FASTPANEL чаще говорит не о полном отказе DNS, а о том, что HTTP- или HTTPS-запрос уже дошёл до какого-то веб-сервера, который выбрал не тот сайт. Этим сервером может быть новый VPS, старая машина после миграции или origin за CDN. Поэтому сам факт появления страницы FASTPANEL ещё не подтверждает, что домен уже направлен правильно.

Цепочка запроса состоит из нескольких независимых этапов. DNS возвращает адрес сервера. Клиент устанавливает соединение с этим адресом. Для HTTP браузер передаёт имя сайта в заголовке Host, а для HTTPS имя участвует ещё и в TLS через SNI. Затем Nginx или Apache ищет virtual host, которому принадлежит это имя.

Если подходящего имени нет, запрос может попасть в виртуальный хост по умолчанию. Отсюда и типичная картина: на одном IP размещено несколько сайтов, site-a.example работает, site-b.example тоже работает, а недавно перенесённый домен показывает служебную страницу FASTPANEL.

До сервера мы уже достучались. Теперь нужно понять — до какого именно и почему он отдал не тот vhost.

Как проверить, на какой IP сейчас действительно указывает домен

A-запись в кабинете регистратора уже новая, а dig всё ещё показывает старый IP. В такой ситуации бесполезно сразу перебирать настройки FASTPANEL: сначала нужно понять, какая DNS-зона действительно обслуживает домен и на каком уровне осталось старое значение.

Для Linux и macOS базовую проверку удобно начать так:

dig example.com A
dig www.example.com A
dig example.com NS

На Windows:

nslookup example.com
nslookup www.example.com

Или через PowerShell:

Resolve-DnsName example.com -Type A
Resolve-DnsName example.com -Type NS

Если A уже возвращает старый сервер, новый VPS пока можно оставить в покое. Но есть важный вопрос: старый ответ пришёл непосредственно от DNS-серверов зоны или из кеша рекурсивного резолвера?

Как проверить authoritative DNS без кеша публичного резолвера

Сначала получите NS домена:

dig example.com NS

Предположим, в ответе указан ns1.example-dns.net. Запросите A-запись непосредственно у него:

dig @ns1.example-dns.net example.com A

Такой запрос позволяет сравнить источник зоны с тем, что видят рекурсивные DNS 1.1.1.1 и 8.8.8.8:

dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

Вот здесь уже можно предметно говорить о TTL. В выводе dig A-запись содержит число оставшегося времени кеширования. Например:

example.com.    300    IN    A    203.0.113.10

300 означает TTL 300 секунд для показанного ответа. Но сам по себе TTL не говорит, что нужно «ждать 48 часов». Сначала сравните authoritative DNS и рекурсивный сервер. Если первый уже отдаёт новый IP, а второй ещё старый, ожидание кеша действительно имеет смысл. Если authoritative NS продолжает возвращать старую машину, проблема находится в зоне.

При подозрении на неправильное делегирование можно посмотреть цепочку DNS:

dig +trace example.com

+trace полезен, когда NS недавно менялись, часть серверов отвечает неожиданно или непонятно, откуда вообще берётся конкретная зона. Разбирать каждую строку не обязательно: основная задача — убедиться, к каким NS в итоге приходит запрос.

Может ли неправильная AAAA-запись отправлять посетителей на другой сервер

Да. A уже может указывать на новый VPS, а AAAA — всё ещё на старый IPv6. Тогда проблема выглядит странно: один пользователь видит сайт, другой FASTPANEL, а у администратора результат меняется при переходе с домашней сети на мобильную.

Проверьте наличие AAAA:

dig example.com AAAA

Затем принудительно сравните два сетевых стека:

curl -4 -I https://example.com
curl -6 -I https://example.com

Типовая диагностическая картина может выглядеть так:

curl -4 -I https://example.com
HTTP/2 200

curl -6 -I https://example.com
HTTP/1.1 200 OK
server: nginx

Сам статус 200 ещё ничего не доказывает: второй ответ может содержать HTML заглушки FASTPANEL или обслуживаться другим сертификатом. Поэтому при сомнениях полезен подробный режим:

curl -4 -vk https://example.com/
curl -6 -vk https://example.com/

Если по IPv4 приходит нужный сайт, а по IPv6 — другой сертификат, другой контент или FASTPANEL, DNS здесь уже почти локализован до одной записи. A исправлен. AAAA — нет.

При этом современные браузеры и операционные системы не обязаны жёстко выбирать IPv6 и всегда ждать его до конца. Клиенты могут параллельно или с небольшой задержкой пробовать IPv4 и IPv6 и использовать маршрут, который быстрее установит соединение. Поэтому плохая AAAA иногда проявляется не одинаково: в одной сети пользователь стабильно видит заглушку, в другой сайт открывается нормально.

Возможные причины:

• AAAA осталась от старого VPS после переноса;
• IPv6 относится к новому серверу, но сайт не привязан к этому адресу;
• Nginx принимает домен на IPv4, но не слушает нужный IPv6;
• сервер вообще не использует IPv6, хотя AAAA опубликована;
• CDN самостоятельно публикует IPv6, поэтому прямое сравнение A и AAAA требует учитывать проксирование.

Удалять AAAA «для проверки» без фиксации исходного результата не стоит. Сначала сравните curl -4 и curl -6. Если IPv6 действительно ведёт на неправильную машину и не используется, запись можно временно убрать или исправить. Если AAAA корректна, искать причину нужно дальше.

Как понять: DNS ведёт не туда или FASTPANEL не распознаёт домен

Самая полезная проверка после смены DNS — отправить запрос на нужный IP принудительно, сохранив правильное доменное имя. Для этого подходит curl --resolve. Команда практически сразу разделяет две ситуации: проблема остаётся в DNS или уже находится на стороне FASTPANEL/Nginx/Apache.

Предположим, новый сервер имеет IP 203.0.113.10. Для HTTP:

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Для HTTPS:

curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

--resolve заставляет curl соединиться именно с указанным IP, но запрос остаётся запросом к example.com. Для HTTPS передаётся и нужное имя SNI. Это принципиально отличается от открытия https://203.0.113.10/, где сервер получает запрос к IP и вполне законно может выбрать default vhost.

Обычный запрос показывает FASTPANEL, а --resolve на новый IP — сайт. Значит, заново создавать сайт в панели не нужно: сервер уже умеет его обслуживать. Проверяйте реальный DNS-маршрут.

Если --resolve на заведомо правильный IP тоже возвращает заглушку, DNS в этом тесте вообще не участвовал. DNS здесь уже исключён. Дальше смотрим FASTPANEL и vhost.

Что проверить в FASTPANEL, если запрос приходит на правильный сервер

dig показывает новый VPS, а curl --resolve всё равно возвращает FASTPANEL. Это уже не похоже на «распространение DNS». Сервер получил запрос к правильному hostname, но нужный сайт не был выбран.

В FASTPANEL проверьте не только наличие сайта как такового. Важна вся привязка:

• домен добавлен именно к нужному сайту;
• сайт включён;
• example.com указан как основной домен или допустимое имя сайта;
• www.example.com добавлен как алиас, если используется;
• сайт привязан к ожидаемому IP, если на сервере несколько адресов;
• для IPv6 нет отдельной старой или неполной привязки;
• после изменения параметров конфигурация веб-сервера была применена без ошибки.

Отдельно проверьте ситуацию, когда на VPS несколько IP. Домен может правильно резолвиться в 203.0.113.10, а сайт в панели обслуживаться только на другом адресе. Тогда нужный hostname существует, но запрос приходит не на тот listener.

Что делать, если домен есть в FASTPANEL, но заглушка не исчезла

Наличие домена в интерфейсе ещё не доказывает, что он попал в активную конфигурацию веб-сервера. После сохранения настроек выполните:

nginx -t

При корректной конфигурации Nginx обычно сообщает, что синтаксис проверен успешно. Если вместо этого выводится ошибка с именем файла и строкой, не перезапускайте сервис вслепую. Сначала нужно исправить причину ошибки.

Затем найдите домен в фактически загруженной конфигурации:

nginx -T 2>&1 | grep -n "example.com"

Три результата дают три разных направления:

• домен найден в нужном server block — проверяйте listen, HTTPS и фактический ответ;
• домен найден в конфигурации другого сайта — проверяйте конфликт или неправильную привязку в FASTPANEL;
• домен не найден вообще — интерфейс и активная конфигурация расходятся, нужно проверить сохранение настроек и состояние веб-сервера.

Проверка становится особенно полезной после миграций и переименования сайтов. В панели владелец видит нужный домен и предполагает, что вопрос закрыт. А nginx -T показывает другое. Сервер ориентируется именно на загруженный конфиг.

Почему www.example.com и example.com могут открывать разные сайты

example.com и www.example.com — два разных hostname. Даже если пользователь воспринимает их как один сайт, DNS и веб-сервер обрабатывают их отдельно.

dig example.com A
dig www.example.com A

curl -I https://example.com/
curl -I https://www.example.com/

CNAME для www решает только DNS-часть. После соединения Nginx или Apache всё равно должен принимать имя www.example.com. Если его нет среди алиасов или в server_name, www может попасть в default vhost и показать FASTPANEL.

Почему открытие сайта по IP не подтверждает правильность настройки

Адрес вида http://203.0.113.10/ не сообщает серверу, какой из размещённых сайтов пользователь хотел увидеть. В HTTP Host будет IP, а не example.com. Сервер вполне может показать default site.

curl -I http://203.0.113.10/

curl -I --resolve example.com:80:203.0.113.10 http://example.com/

Первый запрос проверяет поведение сервера по IP. Второй — реальный доменный virtual host. Для перенесённого сайта нужен второй тест.

Как проверить конфигурацию Nginx или Apache без изменения DNS

Если FASTPANEL показывает правильный домен, а сервер продолжает отдавать заглушку, смотрите активный virtual host. Панель формирует настройки, но окончательное решение о том, какой сайт ответит на запрос, принимает Nginx или Apache.

Как выглядит неправильный default virtual host в конфигурации

Упрощённый default block Nginx может выглядеть так:

server {
    listen 80 default_server;
    server_name _;
}

А конфигурация нужного сайта — так:

server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example;
}

Сами пути и структура на конкретном сервере могут отличаться. Здесь важен принцип: запрос к example.com должен встретить server block, который принимает это имя. Если такого блока нет, запрос способен достаться default_server.

Проверьте синтаксис:

nginx -t

Выведите активную конфигурацию:

nginx -T

И найдите нужное имя:

nginx -T 2>&1 | grep -n "example.com"

Если example.com отсутствует полностью, искать причину в браузерном кеше уже нет смысла. Nginx просто не знает такого hostname в активном конфиге.

Если домен встречается дважды, не делайте автоматический вывод о конфликте: одно имя может присутствовать в связанных HTTP/HTTPS-блоках или служебных конструкциях. Посмотрите контекст вокруг каждой строки и выясните, к какому listen и сайту относится совпадение.

Для Apache:

apachectl configtest
apachectl -S

apachectl -S показывает VirtualHost, ServerName, ServerAlias и помогает увидеть, какой vhost будет использоваться для конкретного адреса. Если конкретная схема FASTPANEL обслуживает сайт только через Nginx, проверять Apache ради галочки не нужно.

Проверьте и слушающие порты:

ss -lntp | grep -E ':80|:443'

Если 80 или 443 отсутствует в выводе, проблема уже шире неправильного server_name: соответствующий сервис не слушает порт на сервере.

Что смотреть, если Nginx не применил изменения

После изменения сайта в панели nginx -t должен проходить без ошибок. Если тест конфигурации неуспешен, состояние сервиса можно проверить так:

systemctl status nginx

Если нужен контекст последнего запуска или перечитывания конфигурации:

journalctl -u nginx

Смотреть нужно на конкретное сообщение: ошибку синтаксиса, конфликт параметров, недоступный файл сертификата, невозможность привязаться к порту. Не нужно перезапускать весь VPS в надежде, что проблема исчезнет.

Почему по HTTP сайт работает, а по HTTPS снова появляется заглушка FASTPANEL

Рабочий сайт на 80 порту не доказывает, что 443 настроен так же. HTTP и HTTPS могут обслуживаться разными server blocks, а на HTTPS дополнительно участвуют TLS, SNI и сертификат.

Проверьте оба маршрута:

curl -I http://example.com/
curl -vkI https://example.com/

Если HTTP отдаёт сайт, а HTTPS — FASTPANEL, A-запись уже не первый подозреваемый. 80-й порт выбирает правильный vhost, а 443-й — нет. Смотрите HTTPS-конфигурацию.

TLS можно проверить напрямую:

openssl s_client -connect 203.0.113.10:443 -servername example.com

Параметр -servername передаёт SNI. Без него сервер с несколькими HTTPS-сайтами может показать сертификат default vhost, и тест будет вводить в заблуждение.

Не пропускайте редиректы. http://example.com может отдавать нормальный 301, но вести на https://www.example.com. Если www не добавлен в FASTPANEL или его DNS отличается, пользователь увидит проблему уже после перенаправления.

Посмотрите заголовок Location:

curl -I http://example.com/

Например:

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/

Сам 301 — нормален. Вопрос в том, куда он ведёт.

С выпуском Let's Encrypt тоже лучше не спешить, пока не подтверждена базовая маршрутизация. Домен сначала должен попадать на правильный сервер и в правильный vhost. Иначе повторный выпуск сертификата лечит не тот уровень проблемы.

Как Cloudflare или другой прокси может скрыть реальную причину

При включённом проксировании Cloudflare публичный DNS обычно показывает адреса edge-инфраструктуры, а не IP FASTPANEL-сервера. Поэтому обычный nslookup уже не отвечает на вопрос, куда Cloudflare ходит за сайтом.

Сразу сравните два запроса.

Через обычный публичный маршрут:

curl -I https://example.com/

Напрямую на origin:

curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

Если origin напрямую работает, не меняйте FASTPANEL одновременно с Cloudflare. Серверная часть уже доказала работоспособность. Смотрите DNS-зону Cloudflare, актуальность origin IP, состояние проксирования и HTTPS между edge и origin.

Ответ через Cloudflare часто содержит характерные HTTP-заголовки, например server: cloudflare или служебный идентификатор запроса. Они помогают понять, что ответ прошёл через edge, но по одному заголовку нельзя делать вывод, какой контент реально отдал origin: прокси может изменить часть ответа.

Проверьте и NS:

dig example.com NS

Если домен делегирован на Cloudflare, рабочая DNS-зона находится именно там. Изменение A-записи в неиспользуемой зоне регистратора не повлияет на трафик.

Не забывайте проверять example.com и www.example.com отдельно. Один hostname может быть проксирован, а другой — находиться в состоянии DNS only или вообще указывать на другой origin. В браузере это легко маскируется редиректом.

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

На телефоне сайт уже новый, а на рабочем ПК всё ещё FASTPANEL. Это не обязательно означает, что FASTPANEL настроен нестабильно. Два устройства могут получать разные DNS-ответы, использовать разные протоколы и даже разные DNS-резолверы.

На Windows сначала зафиксируйте текущий ответ:

nslookup example.com

После этого при необходимости очистите системный DNS-кеш:

ipconfig /flushdns

И повторите nslookup. Если IP остался старым, очистка кеша проблему не решила. Значение приходит от вышестоящего DNS или из другой зоны.

Проверьте файл hosts:

C:\Windows\System32\drivers\etc\hosts

После миграции там иногда остаётся ручная запись для тестирования сайта. В этом случае конкретный компьютер вообще не использует обычный DNS для указанного имени.

На Linux:

getent hosts example.com

Почему nslookup показывает новый IP, а браузер всё ещё открывает старый сервер

Браузер и операционная система не всегда используют один и тот же путь резолвинга. В браузере может работать собственный DNS-кеш или DNS over HTTPS. Тогда nslookup спрашивает системный резолвер и уже видит новый IP, а браузер получает ответ через другой DNS.

Это хорошо объясняет симптом:

nslookup example.com
Address: 203.0.113.10

а в браузере всё ещё отображается контент старого сервера.

В таком случае сравните сайт:

• в другом браузере;
• в приватном окне, если браузерное состояние влияет на тест;
• с временно отключённым DoH или Secure DNS для диагностики;
• через curl, который можно заставить использовать конкретный адрес через --resolve;
• в другой сети.

Не путайте DNS-кеш с HSTS. HSTS не меняет IP домена, но может заставить браузер сразу переходить на HTTPS. Поэтому пользователь говорит «по HTTP всё исправили, а браузер всё равно показывает старую страницу», хотя браузер фактически проверяет только 443-й порт. curl -I http://example.com и curl -vkI https://example.com быстро разделяют эти случаи.

Есть и IPv4/IPv6. Один интернет-провайдер может нормально использовать IPv6, другой фактически ходит только по IPv4. Поэтому при старой AAAA один и тот же ноутбук дома показывает FASTPANEL, а через точку доступа телефона — правильный сайт.

Не переделывайте сервер только потому, что один браузер показывает старую страницу. Сначала зафиксируйте, какой IP и какой протокол использует проблемный клиент.

В каком порядке диагностировать заглушку FASTPANEL после смены DNS

Лучший способ не запутаться — проверять цепочку сверху вниз и переходить дальше только после понятного результата предыдущего шага. Перезапускать VPS, удалять AAAA, менять сертификат и переключать Cloudflare одновременно не нужно.

Быстрый тест, который отделяет DNS от веб-сервера

Если IP нового сервера известен:

curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

Нужный сайт появился — origin и HTTPS-vhost уже в основном работоспособны. Проверяйте DNS, AAAA, кеш и CDN.

Снова появилась FASTPANEL — публичный DNS в этом тесте не участвовал. Проверяйте домен в FASTPANEL, server_name и HTTPS-vhost.

Какая команда проверяет какой уровень

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

Заглушка исчезла в браузере — это хороший признак, но не финальная проверка. После переноса может остаться старый ответ у отдельного DNS, неверная AAAA, неработающий www или другой virtual host на 443 порту.

Проверьте authoritative и публичный DNS:

dig example.com NS
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A

dig @1.1.1.1 example.com AAAA
dig @8.8.8.8 example.com AAAA

Если используется www:

dig www.example.com A
curl -I https://www.example.com/

Сравните IPv4 и IPv6:

curl -4 -I https://example.com/
curl -6 -I https://example.com/

Если AAAA вообще не опубликована, ошибка curl -6 сама по себе не указывает на неисправность сайта. Проблемой был бы опубликованный IPv6, который ведёт не туда.

Проверьте HTTP и HTTPS отдельно:

curl -I http://example.com/
curl -I https://example.com/

Для HTTP нормальным ответом может быть:

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

Проверьте именно Location: редирект должен вести на hostname, который тоже корректно настроен.

После этого ещё раз исключите DNS и обратитесь непосредственно к origin:

curl -vk --resolve example.com:443:203.0.113.10 https://example.com/

Финальная картина должна быть непротиворечивой:

• NS ведут к рабочей DNS-зоне;
• authoritative DNS содержит ожидаемый A;
• публичные DNS постепенно возвращают тот же адрес;
• AAAA корректна либо отсутствует, если IPv6 не используется;
• example.com открывает нужный сайт;
• www.example.com открывает тот же сайт или корректно перенаправляется;
• HTTP ведёт на ожидаемый HTTPS-hostname;
• HTTPS отдаёт сертификат нужного домена;
• curl --resolve на origin больше не показывает FASTPANEL;
• при использовании Cloudflare прямой origin и публичный маршрут дают ожидаемые результаты;
• проверка из другой сети не возвращает старый сервер.

Считать проблему закрытой можно не тогда, когда сайт один раз открылся после очистки кеша, а когда DNS, IPv4/IPv6, FASTPANEL, virtual host и HTTPS показывают согласованный результат. Тогда понятно не только то, что заглушка исчезла, но и почему запрос теперь стабильно приходит именно к нужному сайту.