Исправление петли перенаправлений для кастомного домена: www, apex, куки и TLS

Что сломается, если добавить домен поздно

Добавить кастомный домен после того, как приложение уже работает на дефолтном URL, кажется простой задачей. На практике приложение часто продолжает «помнить» старый адрес. Ваш провайдер домена, слой хостинга, CDN/прокси и настройки приложения могут все пытаться помочь, перенаправляя трафик. Если два слоя не согласны, пользователи могут застрять, отскакивая между URL.

Первые признаки обычно очевидны:

• Страницы, которые перезагружаются снова и снова
• Ошибки «Слишком много перенаправлений» (Too many redirects)
• Главная страница, которая загружается только иногда

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

Поздние изменения домена ломают чаще, потому что в системе уже заложены рабочие допущения. Правила перенаправлений были написаны для исходного URL (например, превью-платформы). Куки были ограничены старым хостом. TLS и политики безопасности выданы для одного имени хоста, но не для другого.

Одна мелкая рассогласованность может одновременно вызвать несколько симптомов. Например, если CDN форсит HTTPS, а приложение тоже форсит HTTPS (и обе стороны по-разному переписывают www в apex), это может создать петлю. Между тем, если домен куки установлен как www.example.com, а пользователи попадают на example.com, вход может не работать, даже если перенаправления кажутся «правильными».

Типичная ситуация: прототип, сгенерированный ИИ, работал на URL платформы (например, Replit). Вы добавляете www.yourapp.com, настраиваете DNS, и вдруг часть пользователей видит ошибки перенаправлений, а другие не могут оставаться залогиненными.

Цель проста: один канонический URL (либо www, либо apex), который остаётся стабильным, сохраняет сессии и корректно загружается по HTTPS.

Ключевые термины: www, apex, перенаправления, куки и TLS

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

Apex domain vs www subdomain: apex — это корневой домен, например example.com. Версия с www — это поддомен, например www.example.com. Они оба могут указывать на одно приложение, но важно выбрать один в качестве канонического адреса.

Перенаправление: перенаправление говорит браузеру «иди туда». Например, отправлять example.com на www.example.com. Петля перенаправлений — это когда браузер застревает, отскакивая между двумя адресами (или правилами), например www -> apex -> www -> apex, пока не сдастся.

Петли часто возникают, когда приложение перенаправляет в одну сторону, а другой слой (хостинг, CDN, прокси, настройки платформы) перенаправляет обратно.

TLS/SSL: TLS — это то, что рисует замочек в браузере. Он шифрует трафик и подтверждает, что сайт соответствует имени хоста. Если TLS отсутствует, выдан для неправильного хоста (только www, но не apex, или наоборот) или конфликтует со старыми HTTP-правилами, браузеры могут предупреждать пользователя, блокировать запросы или незаметно не загружать важные файлы.

Куки и сессии входа: куки — это маленькие данные, которые браузер хранит для сайта и часто используются для поддержания входа. Куки строго ограничены областью применения. Наиболее распространённые ловушки:

• Domain куки: кука, установленная для www.example.com, не будет надёжно работать на example.com.
• Secure: многие аутентификационные куки должны отправляться только по HTTPS.
• SameSite: влияет на потоки входа, особенно при редиректах или при использовании сторонних провайдеров.

Если приложение «входит», а затем сразу возвращает на страницу логина, проверьте в первую очередь несоответствие домена куки.

Почему петли возникают из-за www и apex

Петля обычно означает, что срабатывают несколько правил перенаправления. Одно правило говорит «перейти на https», другое — «перейти на www», третье — «вернуться к apex». Каждое правило по отдельности может выглядеть обоснованным. Вместе они создают отскок, из которого браузер не может выбраться.

Наиболее частая причина — более одного места, где настроены перенаправления одновременно. Приложение может форсить HTTPS, панель хостинга — www, а CDN или фреймворк — переписывать хост.

Порядок имеет значение. Если сначала происходит HTTP -> HTTPS, а затем www -> apex (или наоборот), вы можете непреднамеренно зациклиться между двумя «каноническими» URL. Это легко возникнуть при позднем добавлении домена, когда настройки копируются из старых окружений, не проверяя, как они сочетаются.

Ещё одна частая причина — путаница с прокси. Приложение может получать трафик по HTTP от платформы (соединение с origin), хотя пользователи заходят по HTTPS. Если proxy-заголовки вроде X-Forwarded-Proto отсутствуют или игнорируются, приложение думает, что нужно перейти на HTTPS, а платформа затем применяет свои правила.

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

Несколько быстрых способов сузить круг поиска:

• Тестируйте в приватном окне, чтобы уменьшить влияние кеша браузера.
• Посмотрите один запрос в DevTools > Network и прочитайте заголовки Location.
• Временно отключите перенаправления в приложении или у хоста, чтобы найти «лишнее» правило.
• Убедитесь, что proxy/forwarded-заголовки установлены так, как этого ожидает приложение.

Пошагово: выберите один канонический домен и исправьте перенаправления

Петля обычно означает, что два (или более) слоя спорят о том, где «должен» находиться сайт. Самый быстрый фикс — выбрать один канонический URL и сделать так, чтобы все остальные варианты указывали на него.

Сначала решите, хотите ли вы apex или www в качестве «единственного» адреса. Любой вариант приемлем. Важна согласованность в DNS, TLS, настройках приложения и правилах перенаправления.

Простое 5-шаговое исправление

1. Выберите канонический хост: определитесь с https://example.com или https://www.example.com. Запишите это.
2. Выберите одно место для перенаправления: по возможности делайте перенаправления в одном слое (edge/CDN, балансировщик нагрузки или приложение). Несколько слоёв — обычная причина петель.
3. Создайте одно правило: перенаправляйте неканонический хост на канонический, сохраняя путь и query string. Избегайте дополнительных «чистящих» правил, пока базовая схема не заработает.
4. Сделайте так, чтобы приложение генерировало канонический хост: проверьте настройки вроде base URL, public URL, site URL и auth callback URL. Если приложение строит абсолютные ссылки с неправильным хостом, пользователи будут прыгать между доменами.
5. Тестируйте из чистого состояния браузера: используйте приватное окно или новый профиль, чтобы старые куки и кешированные перенаправления не скрывали реальное поведение.

После настройки перенаправления убедитесь, что вы не форсите перенаправления внутри приложения одновременно (например, «принудительный HTTPS» плюс правило на edge, которое тоже переписывает протокол/хост). Одно перенаправление достаточно.

Быстрая проверка здравомыслия: введите оба варианта (www и apex) в адресной строке. Вы должны попадать на один и тот же итоговый URL, максимум с одним редиректом. Если он переключается туда-сюда, где-то ещё есть перенаправление, которое нужно убрать или отключить.

Проблемы с куками, которые ломают вход и сессии

Если вход работает на одном хосте (например, www.example.com), но не работает на другом (example.com), обычно виноваты куки. Признаки: бесконечные экраны логина, сессии исчезают после обновления, или пользователи вылетают при переходе между хостами.

Частая ошибка — установка атрибута Domain куки не там, где нужно. Если вы установите Domain=www.example.com, эта кука не будет отправляться на example.com (и не покроет другие поддомены). Если нужен общий session между поддоменами, обычно используют Domain=example.com (apex). Если совместного доступа не нужно, куки без Domain (host-only) часто безопаснее, потому что они не утекут на другие поддомены.

Переход на HTTPS тоже может сломать сессии. После поздней миграции домена приложения часто начинают форсить HTTPS. Если сессионная кука не помечена Secure, браузеры могут отказаться отправлять её по HTTPS. Если SameSite слишком строгий, шаги типа OAuth или возврата после оплаты могут молча проваливаться, и пользователь будет «залогинен» в одной вкладке и анонимен в другой.

Поддомены добавляют ещё одну ловушку: app.example.com и api.example.com должны договориться о области куки. Если фронтенд ожидает аутентификационную куку, установленную API, оба должны использовать совместимые домены, а ваши CORS и настройки с credentials должны позволять отправку куков.

Чтобы подтвердить ситуацию, откройте DevTools и проверьте:

• Какие куки устанавливаются после входа и их Domain, Path, SameSite и Secure
• Появляется ли кука на www и на apex
• Отправляется ли заголовок Cookie в запросах, или браузер сбрасывает его

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

Настройки TLS, которые вызывают предупреждения, блокировки и ошибки загрузки

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

Начните с простого: ваш сертификат должен покрывать точные имена хостов, которые вы обслуживаете. Частое несоответствие — сертификат для www.example.com только, в то время как DNS или перенаправления всё ещё позволяют пользователям попасть на example.com (и наоборот). Браузеры воспринимают это как разные имена.

Понять, где реально заканчивается HTTPS

HTTPS может завершаться в разных местах: CDN, балансировщик, reverse proxy или сервер приложения. Проблемы начинаются, когда один слой думает, что трафик HTTPS, а следующий — что HTTP. Это может вызвать петли (приложение продолжает «апгрейдить» до HTTPS) и ломать secure-куки.

Если не уверены, проверьте:

• Какому компоненту прикреплён TLS-сертификат (CDN, балансировщик или сервер)
• Получает ли приложение оригинальный протокол в заголовке (часто X-Forwarded-Proto)
• Доверяет ли приложение прокси
• Обрабатываются ли www и apex одинаково

HSTS и смешанный контент: два простых способа застрять

HSTS говорит браузеру «всегда использовать HTTPS для этого домена». Если вы включите HSTS раньше, чем HTTPS корректно настроен везде (включая перенаправления, API и поддомены), вы можете «заблокировать» пользователей в ошибке, которую трудно быстро отменить.

Смешанный контент — другая тихая проблема. Если HTML загружает скрипты, изображения или CSS по http, браузер может блокировать их на странице https. В результате кнопка входа может не работать или страница загрузится без стилей.

Подводные камни в настройках приложения: прокси, базовые URL, callback’ы аутентификации

Многие «проблемы с редиректами» на самом деле не про DNS. Это приложение спорит с платформой хостинга о том, какой реальный публичный URL.

Прокси и заголовки, которым приложение доверяет

Если ваше приложение находится за reverse proxy или CDN (обычно на управляемых хостах), запрос, который доходит до сервера, может выглядеть как plain HTTP, даже если посетитель использовал HTTPS. Приложения решают это через заголовки X-Forwarded-Proto и X-Forwarded-Host.

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

Также следите за настройками вроде «force HTTPS», «trust proxy» и «secure cookies only». Это полезные настройки, но они должны соответствовать тому, как платформа завершает TLS.

Базовые URL, callback’ы, CORS и интеграции

После выбора канонического хоста нужно обновить все места, где хранится полный URL. Если хотя бы одна настройка всё ещё указывает на старый хост, вы получите сломанные входы, неудачные OAuth, или вызовы API, которые падают без явной причины.

Типичные места, требующие внимания:

• Базовый URL приложения (для построения абсолютных ссылок и редиректов)
• Callback/redirect URL в провайдерах аутентификации (OAuth строго проверяет совпадение)
• Разрешённые источники для CORS (хост фронтенда должен точно совпадать)
• Вебхуки (платежи, email, CRM и т. д.)
• Переменные окружения вроде NEXTAUTH_URL, PUBLIC_URL и т.п.

Пример: страница входа на https://www.example.com, а OAuth-провайдер настроен на https://example.com/auth/callback. Провайдер перенаправляет на apex, приложение редиректит на www, а провайдер отклоняет ответ, потому что callback URL больше не совпадает.

Распространённые ошибки, которые усугубляют проблему

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

Паттерн «работало минуту, потом снова сломалось» обычно означает, что задействован кеш. Браузер закешировал одно перенаправление, прокси закешировал другое, и теперь запросы идут по разным путям в зависимости от точки старта.

Ошибки, которые чаще всего создают проблемы:

• Включение перенаправлений в нескольких слоях (панель хостинга, CDN/edge и приложение).
• Добавление множества перенаправлений до тех пор, пока одно не кажется рабочим, при этом ломаются API, callback’ы или ассеты.
• Забывание, что куки и callback’ы всё ещё привязаны к старому домену.
• Слишком раннее включение HSTS.
• Тестирование только в одном профиле браузера и пропуск поведения новых пользователей.

Простая привычка тестирования экономит часы догадок: проверьте в чистом профиле (или инкогнито), затем в другом браузере и на мобильном. Если поведение различается, скорее всего вы боретесь с кешем, куками или HSTS, а не с последним правилом перенаправления.

Быстрая проверка перед завершением работ

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

Проверки перенаправлений (правило «ровно один раз»)

Введите каждый вариант в адресную строку и проследите итоговый URL. Вам нужен один чистый прыжок, а не отскок между хостами или протоколами.

• http://yourdomain.com должен перейти на https:// ровно один раз.
• http://www.yourdomain.com должен перейти на https:// ровно один раз.
• Неканонический хост (www или apex) должен перенаправлять на канонический ровно один раз.
• Повторная вставка финального канонического URL не должна вызывать перенаправлений.

Даже если один хост всегда перенаправляет, оба хоста должны предоставлять валидный сертификат во время TLS-рукопожатия.

Проверки сессии и замка

Войдите на каноническом хосте, затем обновите, закройте вкладку и снова откройте сайт. Если вы разлогиниваетесь, подозревайте несоответствие домена куки, SameSite или callback URL, указывающий не на тот хост.

Также проверьте индикаторы безопасности браузера. Вы должны видеть валидный замок и на apex, и на www (даже если один сразу перенаправляет). Затем откройте несколько ключевых страниц и убедитесь, что нет предупреждений о смешанном контенте (например, старый http:// для скрипта или изображения).

Реалистичный пример: добавление домена после ИИ-прототипа

Основатель выпускает ИИ-сгенерированный SaaS-прототип на превью-домене платформы. Регистрация работает, дашборд загружается, платежи проходят простую проверку. Потом они добавляют кастомный домен накануне демо, и всё разваливается: сайт прыгает между www и apex, вход выкидывает обратно на страницу логина, а браузер показывает предупреждения безопасности.

Изменилось не что-то одно. Браузер теперь видит другой хост, поэтому куки могут не совпадать. OAuth-провайдеры (Google, GitHub и т.д.) могут отвергнуть редирект, потому что callback URL изменился. И слой хостинга может начать форсить HTTPS, в то время как приложение генерирует внутренние HTTP-адреса.

План восстановления:

• Выберите один канонический хост (www или apex) и сделайте так, чтобы всё указывало на него.
• Сделайте перенаправления в одном месте и стремитесь к одному прыжку: неканонический -> канонический.
• Исправьте область куки в соответствии с каноническим планом и пометьте auth-куки как Secure при использовании HTTPS.
• Обновите настройки аутентификации: callback URL, разрешённые origin’ы и любые хардкодные базовые URL.
• Повторно протестируйте в чистой сессии браузера, чтобы старые куки не скрывали реальную проблему.

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

Следующие шаги: закрепите стабильную настройку домена

Сначала запишите ваш единственный источник истины — полный URL с схемой и хостом, например https://www.example.com (или apex). Затем чётко пропишите единственное правило перенаправления: все прочие хосты должны попадать на этот точный URL с одним 301.

Далее перечислите все места, которые могут перенаправлять запросы или влиять на сессии: настройки домена/DNS, правила CDN/edge, балансировщики/прокси, базовый URL приложения и callback’ы аутентификации, а также настройки куки/сессий. Цель — простая ответственность: одно место делает перенаправления, одно место завершает TLS, и одно место определяет публичный базовый URL.

Если приложение было сгенерировано инструментами вроде Lovable, Bolt, v0, Cursor или Replit, предполагайте, что есть скрытые дефолты и дрейф конфигураций. Прототип мог работать на одном хосте, потому что фреймворк автоматически определял URL, а затем ломаться после позднего добавления прокси, CDN или более строгой политики HTTPS.

Если вы застряли в петле и кодовая база запутана, FixMyMess (fixmymess.ai) специализируется на диагностике и починке ИИ-сгенерированных приложений: правила перенаправлений, область куки/сессий и настройки TLS/proxy. Бесплатный аудит кода быстро выявит несколько рассогласований, которые запускают всю цепную реакцию.