www или apex: какой домен выбрать и как настроить редирект

Выберите один из двух вариантов, example.com или www.example.com, обслуживайте сайт на нём и на каждый запрос ко второму отвечайте постоянным редиректом на выбранный. Какой из двух вы выберете, значит гораздо меньше, чем сам факт выбора. Сайт, отвечающий на обоих без редиректа, для кэшей, cookie, аналитики и поисковых систем - два разных сайта, и день, когда это становится очевидным, обычно наступает, когда кто-нибудь входит на одном хосте и оказывается разлогинен на другом.

Между ними есть одно настоящее техническое различие, и это не вопрос вкуса: www.example.com - обычный поддомен и может быть CNAME, а example.com - apex зоны и не может. Всё остальное в споре - какой красивее, какой короче, какой «современнее» - предпочтения. Здесь разобраны это ограничение, выбор, записи, редирект, сертификат и четыре способа, которыми редирект ломается.

Что на самом деле означают apex и www#

Apex, он же корень, «голый» домен или apex зоны, - это имя, которое вы зарегистрировали, без чего-либо перед ним: example.com. Он особенный, потому что именно там живут собственные административные записи зоны: запись SOA, говорящая, какой неймсервер авторитетен и как стареет зона, и записи NS, перечисляющие неймсерверы. Они есть всегда, и от них происходит приведённое ниже ограничение.

www - обычный поддомен, как любой другой. У него нет особого статуса ни в DNS, ни в HTTP, ни в каком-либо браузере. Это условность, оставшаяся с эпохи, когда машины одной организации назывались www, ftp, mail и news, и она уцелела, потому что оказалась полезной: имя с меткой впереди можно направить на что угодно, в том числе на имя, принадлежащее кому-то другому.

Браузеры скрывают разницу. Chrome, Safari и Edge отрезают www. и https:// при показе адресной строки, поэтому большинство посетителей никогда не видят, на каком из двух они находятся. Это довод не мучиться над эстетикой и довод убедиться, что работают оба: люди всё равно набирают тот, который запомнили.

Почему нельзя поставить CNAME на apex#

Запись CNAME говорит: «это имя - псевдоним для того имени, идите смотреть туда». Спецификация DNS здесь строга: если у имени есть CNAME, других записей любого типа у него быть не может. Это правило существует потому, что резолвер, найдя CNAME, вообще перестаёт смотреть на это имя и начинает заново с цели.

На apex всегда есть записи SOA и NS. Значит, на apex никогда не может быть CNAME. Авторитетные серверы, всё же принимающие такую запись, порождают зону, которая ломается трудно диагностируемым образом: почта перестаёт доставляться, потому что запись MX не видна за псевдонимом, либо пропадает само делегирование.

Это важно, потому что многие сервисы дают вам только имя хоста, а не адрес. Балансировщик нагрузки, конечная точка сайта в объектном хранилище, платформа как услуга и большинство CDN выдают что-то вроде d1a2b3c4.cloudfront.net и оставляют за собой право менять адреса за ним, когда захотят. Поддомен может быть CNAME на него. Apex не может, и поэтому вендоры придумали три обходных пути:

• CNAME flattening - DNS-провайдер хранит на apex нечто, выглядящее как CNAME, сам разрешает его и отвечает на запросы получившимися записями A и AAAA. Так делает Cloudflare.
• Записи ALIAS или ANAME - та же идея под другим именем, её предлагают несколько управляемых DNS-провайдеров. То же поведение: на входе псевдоним, на выходе адреса.
• Собственные alias-записи провайдера - тип alias-записи в Route 53, указывающий на собственные ресурсы провайдера и разрешаемый внутри него.

Все три - возможность вашего DNS-хостинга, а не самого DNS. Если вы переносите зону к провайдеру, у которого такой возможности нет, apex, полагавшийся на неё, ломается. Это самый сильный практический довод в пользу того, чтобы сделать основным хостом www: тогда apex остаётся простым редиректом, который можно отдавать откуда угодно, а настоящее имя остаётся свободным для CNAME.

Если ваш сайт работает на фиксированном адресе - сервер, VDS, контейнер в панели, - всё это к вам не относится. Вы пишете на apex запись A с адресом, и готово. Сами типы записей разобраны в статье DNS-записи простыми словами, а о том, кто вообще держит вашу зону, рассказано в статье неймсерверы или DNS-записи.

Выбор основного хоста#

Ни один из выборов не повлияет на ваши позиции в поиске. Google говорил об этом столько раз, сколько вообще говорит что-либо: оба эквивалентны, пока один из них последовательно является каноническим. Настоящие различия таковы.

Пункт про cookie - тот, который кусает позже. Cookie, установленная на example.com с атрибутом Domain, отправляется на api.example.com, blog.example.com и каждый другой поддомен, включая те, что вы отдали третьей стороне. Если вы когда-нибудь разместите на поддомене что-то, что не полностью контролируете, сессионная cookie с apex поедет туда же. Если сайт работает на www, а apex остаётся редиректом, радиус поражения остаётся небольшим.

С другой стороны: apex короче, его пишут на визитках, и если ваш сайт всегда будет жить на фиксированном адресе, ограничение CNAME никогда не всплывёт. Для небольшого магазина, блога или приложения на одном сервере apex - вполне хороший выбор.

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

Записи, в обе стороны#

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

example.com.        300   IN   A       203.0.113.10www.example.com.    300   IN   CNAME   example.com.

example.com.        300   IN   A       203.0.113.10www.example.com.    300   IN   A       203.0.113.10

Оба варианта допустимы. Во втором можно ещё сделать www записью CNAME на имя платформы, а apex оставить указывать на небольшой сервер, единственная работа которого - редирект; к такой схеме приходят крупные сайты.

О TTL стоит подумать до переезда, а не после. TTL 300 означает, что резолвер забудет ответ в течение пяти минут; 86400 - через сутки. Снижайте его за день-два до любых изменений и поднимайте обратно, когда новый адрес проверен. Та же дисциплина описана в статье перенос WordPress на новый хостинг, и именно она отличает переключение в считаные минуты от переключения, после которого «кто-то всё ещё видит старый сайт».

Редирект за один переход и с правильным кодом статуса#

Редирект принадлежит веб-серверу или обратному прокси, перед приложением. Используйте 301 Moved Permanently. Браузеры и поисковики его кэшируют, а это ровно то, что нужно для хоста, который никогда не вернётся.

server {    listen 443 ssl;    server_name www.example.com;    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;    return 301 https://example.com$request_uri;}

$request_uri переносит путь и строку запроса, поэтому https://www.example.com/shop?page=2 попадает на https://example.com/shop?page=2, а не на главную. Редирект, теряющий путь, хуже, чем его отсутствие: каждая глубокая ссылка с каждого другого сайта в интернете приходит к вашему парадному входу, а не на страницу, которую ей обещали.

В Apache то же самое делается в .htaccess, который вы получаете на большинстве виртуального PHP-хостинга:

RewriteEngine OnRewriteCond %{HTTP_HOST} ^www\.example\.com$ [NC]RewriteRule ^(.*)$ https://example.com/$1 [R=301,L]

Две детали отличают правильный редирект от медленного:

1. Один переход, а не три. http://www должен вести сразу на https://example.com/path, а не на https://www, а оттуда на https://example.com. Каждый лишний переход - полный круг обмена, включая TLS-рукопожатие на тех, что уже зашифрованы. Пишите правила так, чтобы первый же ответ содержал окончательный URL.
2. Редиректить до запуска приложения. Приложение на PHP или Node, решающее сделать редирект, уже заплатило за подключение к базе данных и поиск сессии. Прокси или веб-сервер отвечает за микросекунды.

Если это может сделать только приложение - например, WordPress перенаправляет на то, что записано в его опциях siteurl и home, - то задайте в них основной хост и пусть делает. Только не заставляйте и сервер, и приложение делать редирект одновременно: так начинаются циклы.

308 Permanent Redirect существует и технически строже: он запрещает менять метод, тогда как 301 исторически позволял превратить POST в GET. Для редиректа на основной хост обычного сайта 301 - безопасный и ожидаемый выбор. 302 используйте только при тестировании, потому что неверный 301 кэшируется в браузерах, до которых вы не достанете.

Сертификат должен покрывать оба имени#

Редирект с https://www.example.com возможен только после того, как браузер завершил TLS-рукопожатие с тем, у кого есть сертификат, действительный для www.example.com. Если сертификат покрывает только apex, посетитель получает полностраничное предупреждение о безопасности и до вашего редиректа не доходит. Это самая частая полузавершённая настройка в интернете: apex работает, www выдаёт ошибку сертификата, а владелец не подозревает об этом, потому что сам его никогда не набирает.

Значит, порядок такой: оба имени разрешаются на ваш сервер, затем сертификат выпускается для обоих имён, затем вводится редирект.

Let's Encrypt следует за редиректами при проверке вызова http-01, поэтому редирект с www на apex обычно не мешает выпуску. Мешает имя, которое разрешается куда-то ещё: остаточная запись на старом хостинге или www, который так и не создали. Саму проверку разбирает статья HTTPS и Let's Encrypt простыми словами.

На RE:NODE тарифы для сайтов и приложений включают слот обратного прокси: вы направляете запись A на адрес, показанный в нём, а сертификат выпускается и продлевается автоматически в окне в 21 день. Добавьте там оба имени, а не только то, которым пользуетесь. Мы не регистрируем домены и не хостим зоны DNS, поэтому сами записи создаются там, где живёт ваша зона, - у вашего регистратора или у того DNS-провайдера, на которого указывают неймсерверы. Пошаговый разбор есть в статье как направить домен на ваш сервер.

Как сообщить всему остальному, какой хост настоящий#

Редирект обслуживает посетителей. Кое-что ещё нужно сообщить отдельно, и пропуск этого - способ получить две версии каждой страницы в поисковом индексе.

• Канонические ссылки. Каждая страница должна объявлять свой канонический URL на выбранном хосте. Большинство систем управления содержимым генерируют его из одной настройки URL сайта, поэтому исправление этой настройки исправляет все страницы.
• Карта сайта. Абсолютные URL в sitemap.xml должны использовать основной хост. Карта сайта, перечисляющая другой, - прямое указание обходить редирект.
• Внутренние ссылки. Предпочитайте ссылки от корня (/about), чтобы они не могли указывать на неверный хост. Абсолютные ссылки, зашитые как http://www., - обычный источник редиректа при каждом клике.
• Search Console и аналитика. Зарегистрируйте оба хоста или используйте ресурс уровня домена, покрывающий всю зону, чтобы видеть трафик, всё ещё приходящий на старый.
• Open Graph и структурированные данные. URL изображений и страниц в метаданных абсолютны по необходимости. Если они указывают на неосновной хост, каждый репост загружает через редирект.

Циклы редиректов и другие способы, которыми это ломается#

Цикл через прокси. Ваш обратный прокси завершает TLS и передаёт приложению обычный HTTP. Приложение видит http://, решает, что посетителя нужно перевести, и выдаёт редирект на https://. Прокси завершает и его, снова передаёт обычный HTTP, и браузер сдаётся после двадцати переходов с ERR_TOO_MANY_REDIRECTS. Исправление - заставить приложение доверять заголовку прокси X-Forwarded-Proto, а не смотреть на собственный сокет: в WordPress это значит выставлять $_SERVER['HTTPS'] по заголовку в wp-config.php, в Express - app.set('trust proxy', 1), в Laravel - middleware доверенных прокси. Про этот заголовок рассказано в статье что делает обратный прокси.

Цикл двух наборов правил. Веб-сервер перенаправляет www на apex, а приложение, всё ещё настроенное на старый URL сайта, перенаправляет apex обратно на www. Каждое правило в отдельности верно. Решите, какой слой отвечает за редирект, и отключите его в другом.

HSTS, включённый слишком рано. Strict-Transport-Security: max-age=31536000; includeSubDomains говорит браузеру отказываться от обычного HTTP для этого хоста и всего под ним на год, и взять это назад вы не можете. Добавляйте includeSubDomains только когда у каждого вашего поддомена есть рабочий сертификат, и подавайте заявку в список предзагрузки, только когда абсолютно уверены, потому что удаление из него занимает месяцы.

Смешанное содержимое после переезда. Страницы, загружающие скрипты или изображения с http://www.example.com, зашитого в базе данных. Стандартное лекарство - поиск и замена по всему содержимому; делайте это сначала на копии и сделайте резервную копию, которую вы действительно восстанавливали, прежде чем начинать.

Cookie, которые не переезжают. Если сессии устанавливались на www, а вы переносите основной хост на apex, все один раз выйдут из системы. Безвредно, но предупредите людей до того, как они напишут в поддержку.

Кэши и CDN с ключом по хосту. Кэш перед вашим сайтом считает два хоста разными ключами. После изменения ключ неосновного хоста хранит копии настоящих страниц, пока они не истекут. Очистите его. Что именно и на какой срок используется как ключ, описано в статье заголовки HTTP-кэширования простыми словами.

FAQ#

Влияет ли www или apex на SEO?

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

Можно ли просто поставить CNAME на apex, если провайдер позволяет?

Если провайдер предлагает CNAME flattening, ALIAS или ANAME - да: они отвечают адресами, поэтому зона остаётся корректной. Провайдер, который хранит на apex буквальный CNAME и отдаёт его как есть, производит сломанную зону, и первой жертвой обычно становится доставка почты. Проверьте, что провайдер действительно возвращает, командой dig example.com ANY, прежде чем ему доверять.

Какой редирект нужен: 301 или 302?

301 для основного хоста, потому что он постоянный и вы хотите, чтобы его кэшировали. 302 пока вы тестируете, чтобы ошибка не застряла в браузерах на месяцы. Когда убедитесь, переключитесь на 301 и не возвращайтесь обратно.

Нужен ли сертификат для хоста, с которого я перенаправляю?

Да, если кто-нибудь когда-либо доберётся до него по HTTPS - а доберётся, потому что браузеры сначала пробуют HTTPS и другие сайты ссылаются с префиксом https://. Редирект нельзя доставить, пока рукопожатие не завершилось успешно, поэтому сертификат должен покрывать оба имени.

А если у домена вообще нет www?

Совершенно допустимо. Создайте запись для apex, не заводите www в зоне, и посетители, которые его наберут, получат ошибку разрешения имени, а не страницу с ошибкой. Большинство предпочитает создать www и перенаправить его, потому что набирать его - старая привычка, а сбой выглядит так, будто ваш сайт лежит.

Где всё это делать, если у моего хостера нет редактора DNS?

У того, кто отвечает за вашу зону, а по умолчанию это обычно ваш регистратор. Зоны DNS мы здесь не хостим, поэтому на RE:NODE записи создаются в панели вашего регистратора или DNS-провайдера, а от нас берётся только адрес, на который вы их направляете.