DNS настроен, но сайт не работает: где искать проблему

DNS отвечает, но это только адрес

Когда DNS настроен, но сайт не работает, важно не возвращаться к правке записей автоматически. DNS отвечает на вопрос, куда указывает имя. Он не гарантирует, что на этом IP запущен веб-сервер, настроен нужный virtual host, открыт порт, выпущен правильный сертификат и приложение отдаёт страницу. Поэтому фраза «DNS правильный» не завершает диагностику, а переводит её на следующий слой.

Первый шаг — убедиться, что домен действительно резолвится в ожидаемый IP или CNAME. Если ответ правильный, дальше проверяют соединение с сервером: открыты ли 80 и 443, кто отвечает на HTTP-запрос, какой сертификат отдаётся по HTTPS, нет ли CDN-прокси между пользователем и хостингом. Ошибка может быть в Nginx, Apache, приложении, firewall или SSL, хотя DNS уже исправен.

Соседний материал ошибки при настройке DNS: как найти причину без паники полезен для первого слоя. Здесь же разбор начинается после того, как адрес уже найден.

Проверьте, кто отвечает на HTTP и HTTPS

Если домен ведёт на правильный IP, нужно понять, что отдаёт веб-сервер. Частая ситуация: сервер существует, но виртуальный хост для домена не создан. Тогда пользователь может увидеть страницу по умолчанию, ошибку 404, чужой сайт на том же сервере или сертификат от другого имени. DNS в такой ситуации не виноват: он честно привёл запрос на IP, а дальше запрос не был сопоставлен с нужным сайтом.

Для HTTP смотрят код ответа, заголовки, редиректы и содержимое. Для HTTPS дополнительно проверяют SNI и сертификат. Если сервер отдаёт правильную страницу по IP, но не по домену, проблема почти наверняка в vhost или server_name. Если по домену работает HTTP, но ломается HTTPS, внимание переносится на сертификат, цепочку, редирект и конфигурацию 443.

Если сайт по-разному открывается у разных пользователей, возможна смесь DNS-кэша, CDN и разных edge-серверов. Разбор почему сайт открывается по-разному у разных людей помогает не искать одну универсальную причину там, где фактически отвечают разные узлы.

CDN и прокси могут скрывать настоящий сервер

Cloudflare, reverse proxy и другие CDN меняют картину проверки. Пользователь обращается не к вашему origin-серверу напрямую, а к промежуточной сети. DNS может указывать на CDN, CDN может держать кэш, а origin может быть недоступен или неправильно настроен. Владелец при этом видит «сайт открывается», потому что получает закэшированную страницу, а новый пользователь видит ошибку.

Если используется проксирование, нужно разделять два маршрута: клиент → CDN и CDN → origin. Первый отвечает за публичное открытие сайта, второй — за связь CDN с сервером. Ошибка 521, 522, 525 или похожие сообщения часто говорят не о DNS, а о недоступности origin, TLS-проблеме между CDN и сервером или firewall, который блокирует запросы не с тех адресов.

Кэш CDN тоже может мешать диагностике. После исправления приложения старая ошибка может ещё показываться из кэша. Поэтому для проверки используют bypass, purge cache или прямое обращение к origin, если это безопасно и предусмотрено архитектурой. Но DNS-записи при этом трогать не нужно, если они уже ведут на правильный CDN.

Firewall, приложение и база данных

Сайт может не работать даже при правильном DNS, открытом порте и корректном сертификате. Например, backend упал, база недоступна, приложение отдаёт 500, PHP-FPM не отвечает, Node-процесс не запущен, Django не видит переменные окружения. Пользователь описывает это как «сайт не открывается», но причина уже внутри приложения.

Firewall добавляет ещё один слой. Сервер может отвечать с localhost, но не принимать внешние подключения. Порт 443 может быть закрыт, доступ может разрешаться только с IP CDN, а после смены DNS запросы начинают приходить напрямую и блокируются. Поэтому диагностика должна включать проверку портов и журналов веб-сервера, а не только DNS-панели.

Практический путь: проверить DNS-ответ, затем TCP-доступность, затем HTTP-код, затем HTTPS-сертификат, затем логи Nginx/Apache, затем приложение. Если идти в таком порядке, не возникает желания «ещё раз поменять A-запись», когда ошибка находится в конфигурации сайта. Для проверки типовых ловушек пригодится разбор типичных ошибок DNS и HTTPS, но применять его лучше после разделения DNS и веб-сервера.

Кейс: A-запись была правильной

После переноса сайта владелец настроил A-запись на новый сервер. DNS отвечал корректно, но домен показывал стандартную страницу Nginx. В панели DNS несколько раз меняли запись, пытались очищать кэш и ждать «распространения». Ничего не менялось. Проверка curl показала, что запрос приходит на нужный IP, а заголовки отдаются новым сервером.

Причина оказалась в конфигурации Nginx: для домена не был создан отдельный server block, и запрос попадал в default vhost. После добавления server_name, привязки корня сайта и перезагрузки Nginx домен открыл правильную страницу. DNS не требовал дальнейших правок. Вывод: когда имя уже указывает на нужный сервер, следующая проверка должна идти в веб-конфигурацию.

Что проверять, если DNS уже настроен, а сайт молчит

Имя и запись

Домен VPN проверьте по A и AAAA. Поддомены VPN могут вести на разные серверы. Сайт VPN сервиса и домен для VPN сервера не обязаны иметь один IP. Адрес VPN сервера сверяйте с процессом, который должен отвечать на этом порту.

Сервис и хостинг

Хостинг для VPN может быть доступен, когда веб-процесс остановлен. VPN на VPS проверяют по сервису и правилам firewall. Сертификат для VPN сверяют по имени. Ошибка сертификата VPN после получения ответа означает отдельную проблему TLS, а не ошибку DNS.

Клиент и подписка

VPN подписка может использовать API на другом имени. Профиль VPN может содержать старый адрес. Ссылка VPN обновляется штатным механизмом и не публикуется в диагностике. VPN соединение проверяйте после подтверждения актуальной конфигурации.

Контроль

DNS через VPN оценивают отдельно от публичной страницы. Проверить VPN соединение нужно новой попыткой. Надежный VPN имеет контрольные запросы для сайта, кабинета и узла. Ответ одной страницы не доказывает доступность всех компонентов.

В этой схеме отдельно проверяют vpn сервер, потому что от него зависит следующий шаг настройки.

FAQ: DNS есть, сайта нет

Если DNS отвечает правильно, почему сайт не открывается?

DNS только приводит пользователя к IP-адресу. Дальше должны ответить порт, веб-сервер, virtual host, HTTPS и само приложение.

Как отличить ошибку DNS от ошибки nginx?

Сначала проверьте A/AAAA через авторитетный NS, затем `curl -I` к домену. Если DNS верный, но сервер возвращает 403, 404, 502 или connection refused, искать нужно уже в веб-слое.

Может ли HTTPS выглядеть как проблема DNS?

Да. Пользователь видит “сайт не открывается”, хотя DNS указывает правильно, а ломается сертификат, SNI, редирект на HTTPS или неполная цепочка.

Что проверить после смены A-записи?

Порт 80/443, vhost, редиректы, сертификат, firewall и приложение. A-запись не гарантирует, что веб-сервер готов принять запрос на этот домен.

Что проверить, если домен VPN разрешается, но сервер недоступен?

Ответ DNS не подтверждает работу порта и выбранного протокола. Сравните IP с ожидаемым, затем проверьте доступность нужной службы, имя TLS и сообщение авторизации. Не меняйте всю DNS-зону, если ошибка появляется уже после успешного соединения с сервером.

DNS для VPN настроен, но сервер не отвечает — что проверять дальше?

После подтверждения адреса проверьте порт, состояние процесса и требуемое имя подключения. Начните с разбора DNS для ВПН, чтобы исключить ошибку зоны. Если VPN сайт доступен только части пользователей, сравните IPv4, IPv6 и маршруты. Удаление профиля не исправит неработающий серверный процесс.

Первоисточники

---