Когда сайт доступен по адресу `www.site.ru`, но не открывается по `site.ru`, проблема обычно выглядит странно: домен один и тот же, контент один и тот же, а результат разный. Для владельца сайта это не мелочь. Часть клиентов вводит адрес с `www`, часть без `www`, часть переходит из поиска, рекламы, письма или старой закладки. Если один вариант не работает, пользователь видит ошибку и может решить, что сайт полностью недоступен.
Ниже разберем, почему так происходит, как быстро отделить DNS-проблему от ошибки SSL или настройки хостинга, и что лучше проверять после исправления.
Почему адрес с www и без www может работать по-разному
`site.ru` и `www.site.ru` технически являются разными именами. Они могут вести на один сервер, но для этого их нужно отдельно настроить в DNS, на хостинге, в SSL-сертификате и в правилах редиректа. Браузер не обязан автоматически понимать, что эти адреса должны быть одинаковыми.
Обычно владелец выбирает основной вариант: например, сайт должен открываться без `www`, а адрес с `www` должен делать постоянный редирект на него. Можно выбрать и обратную схему. Важно не то, какой вариант выбран, а то, чтобы оба адреса предсказуемо открывались и не показывали ошибку.
Что чаще всего ломается
Нет DNS-записи для одного из вариантов
Самая понятная причина: в DNS настроили запись для `www.site.ru`, но забыли запись для `site.ru`, или наоборот. Тогда один адрес может возвращать IP-адрес сервера, а второй не находится вообще.
Пример: после переноса на новый хостинг вебмастер обновил CNAME для `www`, потому что так было в инструкции конструктора сайта. Корневой домен `site.ru` остался на старом IP или без A-записи. В результате `www.site.ru` открывается, а `site.ru` показывает ошибку DNS.
SSL-сертификат выпущен только на один адрес
Даже если DNS настроен верно, браузер проверяет сертификат. Сертификат должен покрывать тот адрес, который открыл пользователь. Если сертификат выпущен только для `www.site.ru`, а посетитель зашел на `site.ru`, браузер может показать предупреждение о небезопасном соединении.
Это часто проявляется после ручной установки сертификата, смены панели хостинга или подключения CDN. Для надежной схемы сертификат должен включать оба имени: основной домен и вариант с `www`.
Редирект настроен неправильно
Редирект нужен, чтобы привести пользователей к одному каноническому адресу. Но ошибка в правилах может привести к циклу, двойному переходу на `http`, возврату на старый домен или неожиданной странице хостинга.
Пример: пользователь открывает `http://www.site.ru`, сервер отправляет его на `https://site.ru`, а другое правило снова возвращает на `https://www.site.ru`. Браузер останавливает цепочку и показывает ошибку слишком большого количества перенаправлений.
Хостинг или веб-сервер не знает второй домен
DNS может вести оба адреса на правильный IP, но веб-сервер должен принять запрос для каждого имени. Если в панели хостинга добавлен только `site.ru`, а `www.site.ru` не указан как алиас, сервер может отдать стандартную страницу, 403, 404 или чужой виртуальный хост.
Такое бывает после переноса сайта, смены тарифа, ручной настройки Nginx/Apache или подключения нового домена в панели управления.
CDN или прокси подключены только к одному варианту
Если сайт работает через CDN, оба варианта адреса должны быть согласованы с настройками CDN, DNS и сертификатов. Иногда `www` уже идет через CDN, а корневой домен остается на старом сервере. Внешне это выглядит как частичная недоступность: один адрес быстрый и рабочий, второй отвечает ошибкой или старой версией сайта.
Как проверить проблему вручную
Начните с простой проверки в браузере. Откройте четыре варианта адреса:
- `http://site.ru`;
- `https://site.ru`;
- `http://www.site.ru`;
- `https://www.site.ru`.
Запишите, что происходит в каждом случае: открывается ли сайт, есть ли предупреждение SSL, появляется ли ошибка DNS, идет ли редирект и на какой конечный адрес он приводит.
Дальше проверьте DNS. Можно использовать онлайн-инструмент проверки DNS или консольные команды вроде `nslookup site.ru` и `nslookup www.site.ru`. Важно понять, возвращают ли оба имени ожидаемые записи. Если один адрес не имеет записи или ведет на старый IP, сначала исправляют DNS.
После DNS проверьте SSL. Откройте проблемный адрес через `https` и посмотрите, на какое имя выдан сертификат. Для сайта с двумя вариантами адреса сертификат должен покрывать оба имени. Если сертификат корректный только для одного варианта, нужно перевыпустить или расширить его.
Затем проверьте цепочку редиректов. Она должна быть короткой и понятной: например, `http://www.site.ru` -> `https://site.ru`. Если цепочка прыгает между адресами или возвращает пользователя на `http`, проблема в правилах сервера, CMS, CDN или панели хостинга.
Практические сценарии
После переноса на новый хостинг работает только www
В панели нового хостинга добавили `www.site.ru`, потому что именно такой адрес был в старой инструкции. Корневой домен остался на старом DNS или не был добавлен как алиас. Исправление: добавить оба варианта домена в панели хостинга, настроить A/AAAA или CNAME-записи и выпустить SSL на оба имени.
После выпуска SSL без www появился браузерный риск
Сайт открывается по `https://site.ru`, но `https://www.site.ru` показывает предупреждение. Это не ошибка контента, а несовпадение имени в сертификате. Исправление: перевыпустить сертификат так, чтобы он включал `site.ru` и `www.site.ru`, затем проверить редирект.
После настройки редиректа сайт ушел в цикл
Администратор добавил правило в `.htaccess`, а CMS уже делала собственный редирект на другой вариант адреса. В итоге браузер получает несколько противоположных команд. Исправление: выбрать один канонический адрес, оставить одно главное правило редиректа и убрать конфликтующие настройки.
Как правильно настроить основной адрес
Сначала выберите канонический вариант: с `www` или без. Для SEO и удобства важно, чтобы все внутренние ссылки, карта сайта, настройки CMS и редиректы использовали один основной адрес.
Затем настройте DNS для обоих имен. Корневой домен чаще указывает на IP через A/AAAA-запись, а `www` может быть CNAME или отдельной A-записью, в зависимости от хостинга и CDN. Не копируйте настройки вслепую: проверьте требования вашей платформы.
После этого настройте SSL-сертификат. Он должен быть действительным, не просроченным и подходить к обоим вариантам адреса. Если используется автоматическое продление, убедитесь, что проверка домена проходит для каждого имени.
Финальный шаг - редирект. Все второстепенные варианты должны приводить к одному рабочему HTTPS-адресу. Проверять нужно не только главную страницу, но и внутренние URL: старая ссылка из рекламы или письма тоже должна открываться без ошибки.
Почему ручной проверки недостаточно
Проблема с `www` и без `www` часто появляется после работ, которые кажутся рутинными: перенос сайта, обновление DNS, выпуск SSL, изменение CDN, настройка редиректов. В момент проверки все может открываться у администратора, но часть пользователей уже получает ошибку из-за кэша DNS, другого региона, IPv6 или старой закладки.
Поэтому полезно проверять оба варианта адреса автоматически. В Web-Puls можно настроить мониторинг доступности сайта и отдельно контролировать важные URL: основной домен, вариант с `www`, страницу входа, корзину, форму заявки или другой критичный путь. Такой подход помогает быстрее заметить, что один адрес перестал открываться, хотя второй еще отвечает.
Когда стоит обратиться за технической поддержкой
Если проблема сводится к одной DNS-записи, ее можно исправить самостоятельно. Но при связке DNS, SSL, CDN, хостинга и редиректов легко пропустить конфликт. Особенно если сайт уже получает трафик, а ошибка проявляется только у части клиентов.
Если нужно не только увидеть недоступность, но и разобрать причину, можно отправить заявку через форму профессиональной поддержки: https://web-puls.ru/support/. Для сложных случаев также подойдет контактная информация: https://web-puls.ru/contacts/. В заявке лучше указать оба варианта адреса, текст ошибки, время проверки и что менялось перед сбоем.
Короткий чек-лист
- Выберите основной адрес: с `www` или без.
- Проверьте DNS-записи для обоих вариантов.
- Убедитесь, что хостинг принимает оба имени.
- Проверьте SSL-сертификат для `site.ru` и `www.site.ru`.
- Настройте один понятный редирект на HTTPS и канонический адрес.
- Проверьте главную страницу и несколько внутренних URL.
- Добавьте оба варианта в мониторинг, чтобы не искать проблему по жалобам клиентов.
Вывод
Сайт с `www` и сайт без `www` выглядят как один проект, но для DNS, SSL и веб-сервера это разные адреса. Если один из них не настроен, часть пользователей увидит ошибку, даже когда владелец считает, что сайт работает. Надежная схема проста: оба адреса должны резолвиться, иметь корректный сертификат, приниматься хостингом и приводить к одному основному HTTPS-варианту. После настройки стоит включить автоматическую проверку, чтобы следующая ошибка стала видна сразу, а не после обращения клиента.