Домен открывается с www, но не открывается без www: DNS или конфигурация сервера

Почему сайт может работать с www, но не работать без www

Если www.example.com работает, а example.com нет, два hostname где-то обрабатываются по-разному. Разница может появиться уже в DNS, позже на IPv6, в Nginx или Apache, при выборе TLS-сертификата либо внутри цепочки редиректов.

Сам симптом уже многое говорит. NXDOMAIN означает, что запрос до веб-сервера не дошёл. Страница другого сайта или 404 от Nginx, наоборот, подтверждает: DNS привёл клиента к какому-то серверу, и теперь нужно выяснять, почему этот сервер выбрал неправильный virtual host. Ошибка сертификата означает ещё больше: TCP-соединение с 443 состоялось, TLS начался, но имя не совпало с тем сертификатом, который отдал сервер.

Проверять стоит все четыре входа отдельно:

http://example.com
https://example.com
http://www.example.com
https://www.example.com

Если HTTP без www работает, а HTTPS без www нет, DNS уже сделал свою работу. Переставлять A-запись в такой ситуации бессмысленно: следующий подозреваемый — порт 443, HTTPS virtual host и сертификат.

Если же dig example.com A возвращает пустой ответ или NXDOMAIN, WordPress, PHP-FPM и Nginx пока можно вычеркнуть из диагностики. До них запрос ещё не дошёл.

Есть ли DNS-запись у корневого домена

Если www.example.com успешно резолвится, а example.com нет, сначала проверяется сама DNS-зона. Запись для www не распространяется автоматически на корень домена.

В большинстве DNS-панелей корень зоны обозначается @. Типичная неисправная конфигурация после переноса сайта выглядит очень просто: www уже отправили на новый VPS, а запись @ осталась на старом IP или вообще была удалена.

example.com       A       отсутствует
www.example.com   A       203.0.113.10

В таком состоянии браузер сможет открыть адрес с www, а у корневого hostname не будет маршрута к сайту.

Сравните A и AAAA отдельно:

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

Для Windows можно начать с:

nslookup example.com
nslookup www.example.com

Обычная конфигурация сайта без CDN может выглядеть так:

example.com       A       203.0.113.10
www.example.com   CNAME   example.com

Это не единственно возможная схема. На корне DNS-зоны стандартный CNAME обычно использовать нельзя из-за обязательных записей SOA и NS, поэтому некоторые DNS-провайдеры предлагают виртуальные типы ALIAS, ANAME или CNAME flattening. В таком случае отсутствие привычной A-записи само по себе ещё не доказывает ошибку: нужно смотреть конечный ответ DNS.

Как сравнить конечные IP у www и корневого домена

dig +short example.com
dig +short www.example.com

Одинаковые IP — хороший признак, но не доказательство исправной конфигурации. Один IP может обслуживать десятки сайтов, а Nginx позже выберет virtual host по имени запроса.

Разные IP тоже не всегда означают ошибку. При CDN оба hostname могут попадать на разные edge-адреса, а origin вообще не будет виден в публичном DNS. Проверять нужно не только адрес, но и то, какой HTTP-ответ получается в конце.

Как проверить authoritative DNS, а не кеш провайдера

Обычный dig example.com обращается к настроенному у системы recursive resolver. Если он держит старый ответ в кеше, можно сделать неправильный вывод о текущем состоянии зоны.

Сначала найдите authoritative NS:

dig NS example.com

Затем опросите каждый из них напрямую:

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

Если один authoritative NS возвращает:

example.com.  300  IN  A  203.0.113.10

а второй:

example.com.  300  IN  A  198.51.100.20

проблема уже найдена: сами авторитетные серверы зоны не согласованы. Один пользователь может попасть на новый сервер, другой — на старый. Снаружи это часто выглядит как «то работает, то нет» или «на мобильном интернете открылось, дома не открывается».

Для более сложного случая можно посмотреть всю цепочку делегирования:

dig +trace example.com

Эта команда особенно полезна, если непонятно, какие NS реально делегированы у регистратора и где цепочка начинает отдавать неожиданный ответ.

Почему DNS уже исправлен, а старый IP всё ещё виден

После изменения A-записи старый ответ может некоторое время оставаться в кешах recursive DNS. Это нормальная часть работы DNS, если прежняя запись имела ненулевой TTL.

Есть и менее очевидный вариант: до создания правильной записи resolver уже получил NXDOMAIN и закешировал отрицательный ответ. Negative caching тоже существует, поэтому ситуация «запись уже добавили, а у части сетей домен ещё не находится» вполне реальна.

Сравните ответ локального resolver с authoritative NS:

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

Если authoritative DNS уже отдаёт новый IP, а обычный запрос показывает старый, проблема не в панели DNS. Вы смотрите на кеш.

Можно дополнительно сравнить публичные resolvers:

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

Разные ответы на коротком промежутке после изменения зоны ещё не означают массовый сбой. Сначала сравните TTL и authoritative DNS.

Что означает SERVFAIL и при чём здесь DNSSEC

SERVFAIL отличается от NXDOMAIN. При NXDOMAIN DNS сообщает, что имени нет. При SERVFAIL resolver не смог корректно обработать запрос.

Одна из причин — ошибка DNSSEC после смены DNS-провайдера: у регистратора осталась старая DS-запись, а новая зона уже подписана другим ключом либо не подписана вовсе. Валидирующий resolver видит нарушение цепочки доверия и отказывается возвращать A-запись.

Для первичной проверки:

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

Если разные валидирующие resolvers стабильно возвращают SERVFAIL, а authoritative сервер при прямом запросе отвечает, DNSSEC стоит проверить отдельно. Просто добавлять ещё одну A-запись в такой ситуации бесполезно.

Не подменяет ли адрес локальный hosts-файл

Иногда DNS полностью исправен, но конкретный компьютер продолжает открывать старый сервер. Такое бывает после тестирования сайта через файл hosts.

В Linux стоит проверить:

grep -n "example.com" /etc/hosts

В Windows файл находится здесь:

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

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

Не ломает ли корневой домен старая AAAA-запись или IPv6

Правильная A-запись ещё не гарантирует одинаковую работу сайта у всех пользователей. Если для example.com опубликована AAAA-запись, клиенты с доступным IPv6 могут выбрать именно её.

После миграции часто остаётся неприятная асимметрия: IPv4 уже ведёт на новый VPS, а AAAA всё ещё указывает на старый сервер. Владелец сайта открывает страницу со своей сети и видит нормальный результат, а другой пользователь получает timeout, чужой сертификат или старую копию сайта.

Разделите проверки:

dig example.com A
dig example.com AAAA

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

curl -4 работает, а curl -6 висит — подозреваемый уже конкретный. Теперь не нужно трогать WordPress или A-запись.

На сервере посмотрите, какие адреса и порты действительно слушаются:

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

Если в Nginx присутствуют только:

listen 80;
listen 443 ssl;

а IPv6 должен обслуживаться напрямую, проверьте наличие соответствующих IPv6 listeners, например:

listen [::]:80;
listen [::]:443 ssl;

Одного listener тоже недостаточно. IPv6-адрес должен быть назначен интерфейсу, маршрут должен работать, firewall — разрешать соединения, а HTTPS virtual host — обслуживать нужный hostname.

Есть важное исключение для CDN. Cloudflare может публиковать IPv6 на своей edge-сети даже тогда, когда origin доступен только по IPv4. Это нормальная схема: клиент подключается к Cloudflare по IPv6, а Cloudflare — к origin по IPv4. Поэтому наличие AAAA у проксируемого hostname не доказывает, что у самого VPS обязан быть IPv6.

Доходит ли запрос example.com до правильного веб-сервера

Если DNS возвращает ожидаемый IP, но без www открывается 404, чужой сайт или стандартная страница Nginx, DNS свою часть работы уже выполнил. Теперь нужно понять, какой virtual host поймал запрос.

Один IP способен обслуживать много доменов. Для HTTP клиент передаёт имя в заголовке Host, а Nginx или Apache выбирает подходящую конфигурацию. Поэтому одинаковый IP у www.example.com и example.com ничего не гарантирует.

Сравните ответы:

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

Смотрите на HTTP status, Location, Server и, если есть CDN, на его заголовки.

Например:

www.example.com     200 OK
example.com         404 Not Found

DNS здесь уже ни при чём. Сервер видит оба запроса, но обрабатывает hostname по-разному.

Как отличить нужный virtual host от default server

Для HTTP удобно обратиться прямо к IP и менять только Host:

curl -I -H "Host: example.com" http://203.0.113.10/
curl -I -H "Host: www.example.com" http://203.0.113.10/
curl -I -H "Host: random-invalid-host.example" http://203.0.113.10/

Если example.com и случайный несуществующий hostname возвращают один и тот же ответ, велика вероятность, что корневой домен попадает в default virtual host.

Например:

Host: example.com
HTTP/1.1 404 Not Found
Server: nginx

Host: random-invalid-host.example
HTTP/1.1 404 Not Found
Server: nginx

Host: www.example.com
HTTP/1.1 200 OK

Картина довольно ясная: сервер знает www, а корневое имя не сопоставилось с нужным vhost.

Как использовать access log для подтверждения

Когда по HTTP-коду непонятно, кто именно вернул 404 — Nginx, WordPress или upstream-приложение, полезно смотреть access log во время запроса.

Путь зависит от конфигурации и панели, поэтому сначала лучше найти его через активный конфиг:

nginx -T 2>&1 | grep -n "access_log"

После этого можно наблюдать конкретный файл:

tail -f /var/log/nginx/access.log

И в другом терминале выполнить:

curl -I http://example.com

Если запрос появляется в access log нужного сайта, Nginx выбрал ожидаемый vhost, и 404 уже может приходить от приложения или upstream. Если запись появляется в логе default host, причина находится раньше WordPress.

Это хороший способ перестать гадать по внешнему виду страницы и увидеть, какой конфигурационный блок реально обслужил запрос.

Почему для HTTPS одного Host недостаточно

Команда:

curl -I -H "Host: example.com" https://203.0.113.10/

не полностью воспроизводит обычное обращение по имени, потому что TLS-сервер выбирает сертификат ещё до HTTP-заголовков. Здесь участвует SNI.

Для HTTPS правильнее использовать:

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

Так curl подключится к заданному IP, но сохранит hostname и для SNI, и для HTTP. Это уже полноценная проверка конкретного HTTPS vhost без изменения публичного DNS.

Добавлен ли домен без www в конфигурацию Nginx или Apache

Nginx или Apache должен явно знать, что делать с example.com: обслуживать его тем же сайтом либо сразу перенаправлять на основной hostname. DNS за веб-сервер эту часть не выполняет.

Проблемная конфигурация Nginx может выглядеть так:

server_name www.example.com;

Корневого домена здесь нет. Если другого подходящего server block тоже нет, запрос уйдёт в default server.

Как проверить активную конфигурацию Nginx

Не стоит предполагать, что нужный файл обязательно находится в /etc/nginx/sites-enabled/. Панели и дистрибутивы строят include-цепочки по-разному.

Посмотрите то, что Nginx реально загрузил:

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

Если домен встречается несколько раз, это тоже повод внимательно посмотреть конфигурацию. После миграций или ручных правок иногда остаются два server block, которые претендуют на одно имя.

Полный вывод можно сохранить и изучить:

nginx -T > /tmp/nginx-full.conf 2>&1
grep -n "server_name.*example.com" /tmp/nginx-full.conf

Перед применением изменений всегда проверяйте синтаксис:

nginx -t

И только после успешной проверки:

systemctl reload nginx

Один server block или отдельный redirect-host

Есть два нормальных подхода. Первый — оба hostname обслуживаются одним virtual host:

server {
    listen 80;
    server_name example.com www.example.com;

    # конфигурация сайта
}

Второй — основной hostname обслуживается отдельно, а вторичный существует только ради редиректа:

server {
    listen 80;
    server_name www.example.com;

    return 301 https://example.com$request_uri;
}

А основной сайт находится в другом block:

server {
    listen 80;
    server_name example.com;

    # конфигурация сайта
}

Для HTTPS редиректный hostname тоже должен корректно принимать TLS. Если https://www.example.com должен перенаправляться на https://example.com, сертификат на этапе первого соединения всё равно должен быть валиден для www.example.com. Браузер проверяет сертификат до получения HTTP 301.

Как проверить Apache

У Apache основное имя задаётся через:

ServerName www.example.com

Дополнительное:

ServerAlias example.com

Посмотреть активные virtual host:

apachectl -S

А перед reload проверить синтаксис:

apachectl configtest

Название systemd-сервиса зависит от дистрибутива: это может быть apache2 или httpd. Команду перезагрузки лучше не копировать механически.

В панелях управления аналогичная функция может называться Domain Alias, Aliases, Additional domains или WWW alias. Название несущественно. Важно другое: сервер должен либо принимать оба hostname в нужном vhost, либо иметь отдельное понятное правило для вторичного имени.

Покрывает ли SSL-сертификат и www, и домен без www

Если http://example.com работает, а https://example.com выдаёт ошибку, DNS уже не главный подозреваемый. Нужно проверить прослушивание 443, HTTPS virtual host и сертификат, который сервер отдаёт именно для example.com.

Сертификат на www.example.com не обязан быть валидным для example.com. Для TLS это разные DNS-имена.

Посмотрите реальный сертификат:

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

Более компактный вариант:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName

В нормальном случае SAN может содержать:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

Если присутствует только:

DNS:www.example.com

сертификат для корневого hostname не подходит.

Сертификат неправильный или запрос попал в другой HTTPS vhost

Есть более интересная ситуация: нужный сертификат на сервере установлен, SAN содержит оба имени, но клиент всё равно получает сертификат соседнего сайта.

Это уже не обязательно проблема выпуска сертификата. Запрос мог попасть в неправильный HTTPS virtual host.

Сравните:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -ext subjectAltName

openssl s_client -connect www.example.com:443 -servername www.example.com </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -ext subjectAltName

Например, для www приходит:

subject=CN=example.com
X509v3 Subject Alternative Name:
    DNS:example.com, DNS:www.example.com

а для корневого hostname:

subject=CN=other-site.example
X509v3 Subject Alternative Name:
    DNS:other-site.example

Запрос дошёл до 443, но TLS vhost выбран неправильно. Перевыпускать сертификат в такой ситуации можно сколько угодно — причина останется.

Проверяйте не только имя сертификата

Даже если SAN правильный, TLS может ломаться по другим причинам. Посмотрите даты:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
| openssl x509 -noout -dates

Также возможны:

• просроченный сертификат;
• неполная certificate chain;
• не тот default certificate на 443;
• 443 не слушается вообще;
• сертификат установлен в одном server block, а hostname обслуживает другой;
• после миграции осталась старая конфигурация HTTPS.

Через curl можно увидеть больше деталей соединения:

curl -Iv https://example.com

Особенно полезны строки о подключённом IP, сертификате, проверке имени и итоговом HTTP status.

Почему Let's Encrypt не выпускается для домена без www

После переноса сайта иногда пытаются решить ошибку HTTPS повторным выпуском Let's Encrypt, но challenge для example.com не проходит. Если корневой DNS всё ещё ведёт на старый сервер или вообще не имеет записи, центр сертификации проверяет не тот хост.

Перед выпуском сертификата стоит проверить:

dig +short example.com A
dig +short example.com AAAA
curl -I http://example.com/.well-known/acme-challenge/test

Последняя команда сама по себе не создаёт challenge-файл, но помогает увидеть, куда приходит HTTP-запрос и нет ли неожиданного редиректа или чужого virtual host.

Сначала DNS и vhost. Потом выпуск сертификата.

Что меняется при Cloudflare

При Cloudflare существуют два отдельных TLS-участка:

• браузер → Cloudflare edge;
• Cloudflare → origin.

Сертификат, который видит браузер, и сертификат на origin могут быть разными. Cloudflare Origin Certificate предназначен для соединения Cloudflare с origin и не является обычным публично доверенным сертификатом для прямого доступа пользователя к IP сервера.

Поэтому при Cloudflare нужно всегда понимать, какой именно TLS-участок сейчас диагностируется.

Не создают ли редиректы www и non-www цикл или неправильный адрес

Если браузер сообщает ERR_TOO_MANY_REDIRECTS, hostname уже обслуживается. Проблема в том, что разные уровни инфраструктуры отправляют пользователя по несовместимым маршрутам.

Типичная схема: Nginx перенаправляет www.example.com на example.com, а WordPress настроен на https://www.example.com и отправляет запрос обратно.

Посмотрите цепочку:

curl -IL https://example.com

Например:

HTTP/2 301
location: https://www.example.com/

HTTP/2 301
location: https://example.com/

HTTP/2 301
location: https://www.example.com/

Редиректный пинг-понг виден сразу.

Проверять нужно все места, где может существовать перенаправление:

• Nginx;
• Apache и .htaccess;
• WordPress home и siteurl;
• плагины редиректов;
• Cloudflare Redirect Rules;
• reverse proxy;
• HTTP-to-HTTPS функция панели управления.

Почему браузер может мешать проверке из-за HSTS

Если для домена раньше был включён HSTS, браузер может автоматически заменить http://example.com на HTTPS ещё до отправки обычного HTTP-запроса. Пользователь думает, что проверяет порт 80, а фактически сразу попадает на 443.

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

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

Если первая команда показывает обычный HTTP 301, вы действительно видите серверный редирект. Поведение браузера в этот момент уже не является единственным источником информации.

Как X-Forwarded-Proto создаёт бесконечный HTTPS-редирект

За CDN или reverse proxy приложение может получать внешний HTTPS-запрос как внутренний HTTP-запрос. Если proxy не передаёт корректный протокол через X-Forwarded-Proto, приложение решает, что пользователь всё ещё пришёл по HTTP, и снова отправляет его на HTTPS.

Снаружи получается цикл, хотя браузер каждый раз открывает https://example.com.

Схема выглядит так:

Browser: HTTPS
    |
Reverse proxy
    |
Origin sees: HTTP
    |
Application: redirect to HTTPS
    |
Browser: HTTPS again

В Nginx перед upstream обычно проверяют передачу нужного заголовка:

proxy_set_header X-Forwarded-Proto $scheme;

Но исправление зависит от архитектуры: некоторые приложения используют другие доверенные proxy headers и требуют отдельно указать список доверенных прокси.

Что выбрать: www или домен без www

С технической точки зрения оба варианта нормальны. Нужен один основной hostname и последовательная канонизация.

Если основным выбран https://example.com, вторичный https://www.example.com должен корректно принять HTTPS и вернуть постоянный redirect на основной адрес.

Если основным остаётся www, направление меняется:

https://example.com/
301 → https://www.example.com/

Менять уже работающий основной hostname только потому, что версия без www кажется короче, не требуется. Это затронет внутренние ссылки, canonical, sitemap, настройки CMS и внешние URL, хотя исходная задача состоит лишь в том, чтобы оба входа работали предсказуемо.

Может ли Cloudflare или другой CDN создавать разницу между www и корнем домена

Cloudflare способен обрабатывать www.example.com и example.com по-разному. Один hostname может быть Proxied, второй DNS only; могут отличаться origin, Redirect Rules, Origin Rules и SSL/TLS-настройки.

Поэтому сравните не только сами DNS-записи:

• A и AAAA для обоих hostname;
• proxy status;
• целевой origin;
• Redirect Rules;
• Origin Rules;
• SSL/TLS mode;
• HTTP-ответы публичного адреса.

Как проверить origin напрямую, не выключая Cloudflare

Не нужно сразу переводить запись в DNS only. Сначала можно обратиться к origin напрямую, сохранив hostname и SNI:

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

--resolve заставляет curl подключиться к указанному IP, но запрос всё равно идёт к example.com. Nginx получает правильный Host, а TLS — правильный SNI.

Сравните два результата:

curl -I https://example.com

curl --resolve example.com:443:203.0.113.10 \
https://example.com/ -I

Если публичный адрес ломается, а origin возвращает 200, сервер уже не главный подозреваемый. Смотрите Cloudflare edge, правила, режим SSL и доступ Cloudflare к origin.

Если --resolve тоже отдаёт неправильный сайт или ошибку сертификата, выключение Cloudflare первопричину не исправит. Сначала чинится origin.

Что означают ошибки Cloudflare 522, 525 и 526

522 не стоит лечить перевыпуском сертификата, а 526 — изменением A-записи без причины. Код ошибки уже показывает, на каком участке стоит копать.

Full и Full (strict) — не одно и то же

В режиме Full Cloudflare устанавливает HTTPS-соединение с origin, но требования к валидности origin certificate мягче. В Full (strict) сертификат origin должен проходить проверку.

Поэтому ситуация «в Full работает, а в Full (strict) выдаёт 526» указывает не на публичный edge-сертификат браузера, а на сертификат origin.

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

Как за 10 минут определить, DNS это или сервер

Диагностику удобнее вести сверху вниз по цепочке. Каждый тест должен отсекать один слой, а не менять сразу несколько настроек.

dig +short example.com A
dig +short www.example.com A
dig +short example.com AAAA
dig +short www.example.com AAAA

dig NS example.com
dig +trace example.com

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

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

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

curl -IL https://example.com

curl --resolve example.com:443:203.0.113.10 \
https://example.com/ -I

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

apachectl -S

curl -svI https://example.com/

Смысл такой последовательности не в количестве команд, а в точке остановки. Как только один слой подтверждён, нет необходимости продолжать менять его настройки.

Как должна выглядеть исправная конфигурация www и non-www

Исправная конфигурация принимает оба hostname и приводит пользователя к одной выбранной HTTPS-версии. Проверять нужно не только главную страницу в браузере, а всю цепочку DNS, TLS и редиректов.

Предположим, основной адрес сайта:

https://example.com/

Тогда ожидаемая схема может быть такой:

Если основным hostname выбран www, схема зеркальная: https://www.example.com/ возвращает 200, остальные варианты приводят к нему.

Приёмочная проверка после исправления

Проверьте четыре URL командой, а не только браузером:

curl -IL http://example.com/
curl -IL https://example.com/
curl -IL http://www.example.com/
curl -IL https://www.example.com/

Хороший результат предсказуем: один основной HTTPS hostname возвращает 200, остальные входы приходят к нему без циклов.

Финальный чек-лист

• example.com имеет корректный DNS-маршрут.
• www.example.com тоже успешно резолвится.
• Все authoritative NS отдают согласованные данные.
• Старый IP не остался в одной из DNS-зон после миграции.
• AAAA отсутствует, если IPv6 не используется, либо IPv6 действительно работает.
• curl -4 возвращает ожидаемый ответ.
• curl -6 работает, если hostname доступен по IPv6.
• Nginx server_name или Apache ServerAlias учитывает оба hostname либо существует отдельный redirect-host.
• Запрос не попадает в default virtual host.
• SSL-сертификат действителен для каждого hostname, который принимает HTTPS.
• На 443 отдаётся именно нужный сертификат, а не certificate соседнего vhost.
• Нет цикла между www и non-www.
• HSTS не маскирует результаты ручной HTTP-проверки.
• Reverse proxy передаёт приложению корректную информацию о протоколе.
• Cloudflare или другой CDN не обрабатывает два hostname противоречиво.
• Origin отдельно проходит проверку через curl --resolve, если используется CDN.
• Выбран один основной HTTPS-адрес.
• Все четыре комбинации HTTP/HTTPS и www/non-www проверены после изменений.

Если dig не возвращает адрес, оставайтесь в DNS. Если curl уже получает 404 от вашего Nginx, DNS можно временно вычеркнуть из списка подозреваемых. Если HTTP работает, а HTTPS нет, проверяйте 443 и TLS. Если -4 работает, а -6 висит, смотрите AAAA и IPv6. А если origin отвечает нормально, но ошибка появляется только через CDN, серверный virtual host уже не первая точка поиска.

Такой маршрут диагностики позволяет не «лечить домен целиком», а точно найти участок, на котором www.example.com и example.com начинают вести себя по-разному.