301 на .htaccess или nginx: где делать редиректы и как не словить цикл

Когда нужно настроить 301-редирект, первый вопрос — куда его вообще писать. Вариантов три: .htaccess (Apache), конфиг nginx или уровень приложения (middleware, плагин). Они не равнозначны: отличаются по скорости, по надёжности и по тому, насколько легко всё сломать.

Разберу, что выбрать, и три классические ошибки, из-за которых редирект зацикливается и страница перестаёт открываться вообще.

Чем отличаются три уровня

.htaccess (Apache). Самый доступный — файл лежит рядом с сайтом, правится без перезапуска сервера. Минус: Apache перечитывает .htaccess на каждый запрос, поэтому на больших правилах это медленнее. Подходит для шаред-хостинга и небольших списков.

Redirect 301 /old-page /new-page
RewriteRule ^catalog/(.*)$ /shop/$1 [R=301,L]

nginx. Быстрее: правила читаются один раз при старте, дальше работают из памяти. Минус — нужен доступ к конфигу и nginx -s reload после правок. Это правильный выбор, когда редиректов сотни.

location = /old-page { return 301 /new-page; }
rewrite ^/catalog/(.*)$ /shop/$1 permanent;

Уровень приложения. Middleware (Next.js, Express), плагин WordPress, правила Webflow/Vercel. Удобно, когда логика редиректа зависит от данных. Минус — медленнее серверного уровня и зависит от того, что приложение вообще поднялось.

Правило большого пальца: статичные редиректы — на сервере (nginx быстрее всего), редиректы с логикой — в приложении. Не дублируй один и тот же редирект на двух уровнях — будешь ловить конфликты.

Три ошибки, из-за которых редирект зацикливается

Бесконечный цикл (ERR_TOO_MANY_REDIRECTS) — самая частая беда. Три причины:

1. Источник и цель пересекаются. Редиректишь /catalog/ → /shop/, но правило написано так, что /shop/ снова попадает под маску и улетает обратно. Всегда исключай цель из условия редиректа.
2. www и https гоняют по кругу. Один редирект тянет на https://, другой — на www, и они перекидывают запрос туда-сюда. Решение: один блок, который за один шаг приводит к канону (https://site.ru), а не цепочка из четырёх.
3. Слэш в конце. /page → /page/, а другое правило /page/ → /page. Определись с одним вариантом канона и держи его везде.

Проверять цепочку удобно через curl -I https://site.ru/old-page — увидишь все промежуточные 301 и финальный 200. Если 301 идёт больше одного-двух раз — у тебя цепочка, её надо схлопнуть в один прыжок.

Когда редиректов много

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

RedirectMap принимает два CSV (старые и новые URL), мэппит их по slug и нормализованным окончаниям и отдаёт готовый файл сразу в нужном формате — .htaccess, nginx, Cloudflare Bulk, Webflow, Vercel или Next.js middleware. То есть один и тот же список ты выгружаешь под любой из трёх уровней выше, не переписывая синтаксис вручную. Подробный разбор миграции без потери трафика — в отдельной статье.

Итог

Статичные редиректы — на nginx (быстро) или .htaccess (просто), редиректы с логикой — в приложении. Главный враг — циклы: исключай цель из источника, схлопывай www/https/слэш в один прыжок и проверяй цепочку через curl -I. А когда правил становится много — генерируй список, а не пиши его руками.