Как устранить неполадки, если сайт не открывается после настройки перенаправления 301?

Если после настройки перенаправления 301 сайт не открывается, сначала выясните, на каком этапе останавливается запрос: старый URL не отвечает, несколько адресов перенаправляют друг на друга или запрос уже перешёл на новый URL, но новый сайт выдаёт ошибку. Встречающееся в поиске выражение «ошибка 301» не означает, что сама переадресация 301 неисправна: код 301 обозначает постоянное перенаправление, а проверять нужно правила переадресации, целевой адрес и цепочку доступа.

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

Сначала выясните, на каком этапе останавливается запрос

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

• Появляется сообщение о слишком большом количестве перенаправлений: проверьте, не перенаправляют ли два адреса друг на друга и не перенаправляет ли адрес постоянно сам на себя.
• После перенаправления появляется ошибка 404 или 5xx: запрос достиг целевого адреса; проверьте путь к странице, службу приложения или шлюз.
• Появляется сообщение об ошибке сертификата, невозможности разрешить доменное имя или превышении времени ожидания подключения: сначала устраните проблемы с сертификатом, DNS или сетью. Возможно, запрос ещё не дошёл до правила 301.

Если доступна командная строка, выполните curl -I https://old.example.com/path, чтобы просмотреть заголовки ответа, а затем curl -IL --max-redirs 10 https://old.example.com/path, чтобы проверить последовательность перенаправлений. Некоторые сайты по-разному обрабатывают запросы HEAD. Если результат вызывает сомнения, ориентируйтесь на фактический GET-запрос в браузере или выполните проверку с помощью curl -sS -D - -o /dev/null URL.

При циклическом перенаправлении сначала проверьте протокол, домен и настройки прокси

К распространённым циклам относятся перенаправление с HTTP на HTTPS с последующим возвратом на HTTP, а также взаимные перенаправления между доменом с www и без www. Например, сервер перенаправляет example.com на www.example.com, а панель управления сайтом настроена перенаправлять второй адрес обратно на первый. В результате браузер не может открыть страницу.

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

Если сайт работает через обратный прокси, проверьте также, как исходный сервер определяет протокол, используемый посетителем. Посетитель подключается к CDN по HTTPS, а CDN — к исходному серверу по HTTP. Если исходный сервер ориентируется только на собственное подключение, он может снова и снова требовать перехода на HTTPS, создавая цикл.

В этом случае проверьте протокол соединения с исходным сервером и убедитесь, что приложение правильно распознаёт информацию о протоколе, передаваемую доверенным прокси, например X-Forwarded-Proto. Не следует безоговорочно доверять этому заголовку запроса, поступающему из любого источника: ограничьте круг доверенных прокси.

Если правила не перенаправляют друг на друга, проверьте область их применения и порядок выполнения

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

• Целевой адрес снова попадает под исходное правило: правило перенаправляет все запросы на определённый адрес, но сам целевой адрес не исключён.
• Слишком широкая область действия шаблона или регулярного выражения: правило перенаправления главной страницы ошибочно распространяется на страницы товаров, административную панель, API или статические ресурсы.
• Ошибки формирования пути: дублирование каталогов, несогласованная обработка косой черты или неверная ссылка на захватывающую группу приводят к перенаправлению на несуществующую страницу.

Если после временного отключения правила доступ восстанавливается, это означает лишь, что проблема связана с этим правилом или его сочетанием с другими. Уточните условия его срабатывания, чтобы случайно не удалить необходимые настройки нормализации домена. В Apache проверьте порядок правил и наследование; в Nginx — взаимодействие условий сопоставления server, location и rewrite. После внесения изменений сначала проверьте синтаксис конфигурации и только затем перезагрузите её.

Если целевой URL не открывается, проверьте DNS, сертификат и соответствие страниц

Откройте полный адрес из заголовка Location. Если целевой адрес тоже не открывается, продолжайте проверку на целевом сайте, а не меняйте снова перенаправление 301 на старом сайте.

При переносе домена проверьте, что записи A, AAAA или CNAME нового домена указывают на нужную службу. Если настроены и IPv4, и IPv6, но один из протоколов недоступен, в одних сетях сайт может открываться, а в других — нет.

Для HTTPS важно помнить: старый домен должен сначала успешно выполнить TLS-рукопожатие, чтобы браузер получил возвращаемый им ответ 301. Поэтому даже если старый домен используется только для перенаправления, ему необходим действующий сертификат, соответствующий доменному имени. Проверьте адреса как с www, так и без www: исправный сертификат целевого сайта не заменяет сертификат старого домена.

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

Что делать, если сервер уже исправлен, но браузер всё ещё выдаёт ошибку?

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

CDN также может продолжать возвращать закэшированный ответ перенаправления. В этом случае очистите кэш затронутых URL. Автоматический переход браузера с HTTP на HTTPS может быть связан и с HSTS. Проверяйте фактические сетевые запросы, а не считайте это во всех случаях кэшированием 301.

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

После восстановления доступа проверьте работу основных сценариев сайта

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

Если используются формы запросов, корзина или обратные вызовы платёжной системы, отдельно проверьте процесс отправки данных. В некоторых клиентах при перенаправлении 301 метод POST может измениться на GET. Для таких интерфейсов не следует без проверки применять обычные правила перенаправления страниц; если метод запроса необходимо сохранить, оцените возможность использования 307 или 308 с учётом логики приложения.

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