Код статуса 302 (HTTP 302 Found): что значит, 302 vs 301

Что такое код статуса 302?

HTTP 302 Found — это временное перенаправление. Сервер отвечает: «то, что вы запросили, пока находится в другом месте» — и указывает другой URL в заголовке Location. Браузер сразу загружает этот URL, но закладки, ссылки и поисковые системы должны и дальше использовать исходный (RFC 9110 §15.4.3).

Это «пока» и есть вся разница с 301 Moved Permanently, который означает, что старый URL ушёл навсегда. В HTTP/1.0 код 302 назывался «Moved Temporarily» (RFC 1945); в 1999 году RFC 2616 переименовал его в «Found», но смысл не изменился.

Посетитель редко видит 302, потому что браузер переходит по нему раньше, чем что-либо появится на экране. Его можно увидеть в DevTools, в curl, в API-клиентах и в SEO-аудитах.

Из чего состоит ответ 302

Ответ 302 невелик. Его части:

• Строка статуса — HTTP/1.1 302 Found или просто HTTP/2 302 (в HTTP/2 нет текстовой причины)
• Location — URL, на который нужно перейти. RFC 9110 говорит, что сервер SHOULD (следует) его отправить; без него браузеру некуда идти, и он показывает тело самого ответа 302, обычно пустое
• Тело — RFC 9110 говорит, что оно «обычно содержит короткую гипертекстовую заметку» со ссылкой. Браузеры его игнорируют; nginx, Apache и Express по умолчанию отправляют однострочную заметку, а многие крупные сайты отправляют пустое тело
• Заголовки кэширования — не нужны. Браузеры не кэшируют 302, пока вы не добавите Cache-Control: max-age или Expires; 301 и 308, наоборот, кэшируются по умолчанию. CDN всё же может его закэшировать (см. «302, который залип» ниже)

HTTP/1.1 302 Found
Location: https://www.example.com/login?next=%2Fdashboard
Content-Length: 0
Date: Mon, 26 Oct 2026 14:00:00 GMT

Location может быть полным URL или относительным путём вроде /login: RFC 9110 допускает любую URI-ссылку, а браузеры разрешают её относительно запрошенного URL. В коде приложения (например, Express) относительный путь не раскрывает внутреннее имя хоста и не подставляет http:// за прокси; nginx и Apache всё равно превращают его в абсолютный URL, если не задать absolute_redirect off или RedirectRelative On.

Почему приходит 302 вместо 200?

Потому что странице нужно то, чего в вашем запросе не было, или URL, который вы использовали, — не тот, что отдаёт сайт. Обычные причины:

• Вы не вошли в аккаунт — страницы за авторизацией отвечают 302 на страницу входа, передавая нужную страницу в параметре возврата. Без входа github.com/settings перенаправляет на /login?return_to=…. В curl или API-клиенте передайте cookie сессии или токен.
• Ваш клиент не следует за редиректами — браузеры, fetch() и Python requests делают это автоматически. curl — нет, пока вы не добавите -L: он останавливается на 302 и печатает только его тело, часто пустое (добавьте -i, чтобы увидеть статус и Location).
• URL — не тот, что отдаёт сайт — лишний или отсутствующий слэш в конце, языковой путь или трекинговая ссылка, которая пересылает дальше. res.redirect() в Express, return с одним URL в nginx и Redirect в Apache отправляют 302, если не указать иное.
• Редирект добавляет что-то перед сервером — если исходный сервер при прямой проверке отвечает 200, а публичный URL даёт 302, значит, редирект выполняет правило CDN, балансировщика нагрузки или прокси.

API на отсутствие авторизации обычно отвечают 401 Unauthorized, а не редиректом. Чтобы увидеть каждый переход и его код статуса, прогоните URL через Проверку редиректов.

302, 301, 307 и 308: какой редирект выбрать?

Почти все случаи покрывают пять кодов перенаправления. Они различаются двумя признаками: постоянное ли перемещение и остаётся ли POST методом POST:

303 и 307 появились из-за 302. HTTP/1.1 добавил 303 в 1997 году, а в 1999 году RFC 2616 признал, что «большинство существующих реализаций user agent обрабатывают 302 так, как если бы это был ответ 303», добавил 307 и переименовал 302 в «Found» (RFC 2616 §10.3.3). Если временный редирект может получить POST, используйте 307, чтобы сохранить его, или 303, чтобы следующую страницу загрузить через GET.

Когда стоит использовать редирект 302?

Используйте 302, когда редирект должен со временем исчезнуть. Типичные случаи:

• Перенаправление на вход — отправить неавторизованного пользователя с /dashboard на /login, а после входа вернуть обратно
• A/B-тесты — отправить часть посетителей на вариант страницы; в собственных рекомендациях по тестированию Google советует использовать здесь 302, а не 301 (Google Search Central)
• Страницы на ремонте — на несколько дней отправить посетителей на страницу с уведомлением, пока страницу переделывают
• Краткосрочные URL кампаний — /black-friday указывает на страницу распродажи этого года только на время распродажи
• Техническое обслуживание — только для посетителей; для поисковых систем при плановом простое лучший ответ — 503 с Retry-After

Если любое из этих перенаправлений станет постоянным, замените его на 301.

Как отправить код статуса 302

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

Nginx

В nginx используйте return с кодом. return с одним URL тоже отправляет 302 (документация nginx):

server {
    listen 80;
    server_name example.com;

    # Temporary redirect (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

В Apache используйте Redirect (302 — его значение по умолчанию, если статус не указан) или RewriteRule с [R=302,L]:

# Simple temporary redirect
Redirect 302 /old-page https://example.com/new-page

# Or with mod_rewrite for pattern matching
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

res.redirect() в Express по умолчанию использует 302, если код статуса не указан:

// Temporary redirect (302 Found by default)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // sends 302
  }
  // ...render dashboard
})

// Or be explicit:
res.redirect(302, '/login')

Как проверить код статуса 302

Самая быстрая проверка — curl в терминале: он показывает код статуса и заголовок Location, и кэш браузера не мешает.

# Status and headers, without following the redirect
curl -sI https://example.com/old-page

# -I sends HEAD, which some servers answer differently; this sends a real GET
curl -s -o /dev/null -D - https://example.com/old-page

# Expected:
# HTTP/2 302
# location: https://example.com/new-page

# Follow the whole chain and print each hop's status and Location
curl -sL -o /dev/null -D - https://example.com/old-page | grep -iE '^(HTTP/|location:)'

Нет терминала? Проверка редиректов DNS Robot проходит по каждому переходу (301, 302, 303, 307, 308 и meta refresh) с нашего сервера и показывает каждый код статуса и конечный URL, а Проверка HTTP-заголовков в разделе Redirects показывает необработанные заголовки каждого перехода.

Редиректы 302 и SEO

Google воспринимает два вида перенаправлений как разные инструкции. Временное перенаправление (302, 303, 307) Googlebot выполняет, но Google не считает его признаком того, что целевой URL должен стать каноническим, поэтому исходная страница обычно остаётся в результатах поиска. Целевая страница всё же может быть проиндексирована, если на неё указывают другие сигналы (Google Search Central).

Постоянное перенаправление (301, 308) говорит обратное: показывать новый URL. Поэтому настоящий вопрос не «передаёт ли 302 PageRank?», а «какой URL я хочу видеть в результатах поиска?». Тег rel=canonical — один из других сигналов; Проверка мета-тегов показывает, какой URL объявляет страница.

• Для постоянных переездов используйте 301 или 308 — новый домен, новая структура URL, объединённые страницы
• Для временных используйте 302 — вход, A/B-тесты, кампании
• Не оставляйте постоянный переезд на 302 — Google может продолжать показывать старый URL
• Делайте цепочки короткими — каждый переход стоит одного обращения к серверу, а Googlebot по умолчанию проходит до 10 переходов (Google)

Почему 302 превращает POST-запрос в GET

Это самая неожиданная особенность 302. Ранние спецификации не позволяли клиентам менять метод, но браузеры всё равно превращали POST в GET при 302. Сегодня стандарт Fetch, который реализуют браузеры, закрепляет эту привычку: при 301 или 302 POST становится GET, а его тело отбрасывается (Fetch Standard).

Поэтому, когда браузер отправляет POST /submit-form, а сервер отвечает 302 Found, браузер переходит GET /thank-you, и данные формы теряются. PUT и DELETE браузеры оставляют как есть; другие клиенты ведут себя иначе: Python requests превращает любой метод, кроме HEAD, в GET при 302, а curl -L превращает POST в GET при 301, 302 и 303 (--post302 сохраняет POST при 302).

# What you send:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# Server responds with 302:
HTTP/1.1 302 Found
Location: /thank-you

# Browser follows with GET (form data dropped!):
GET /thank-you HTTP/1.1
Host: example.com

Если редирект должен сохранить исходный метод (POST остаётся POST, PUT остаётся PUT), используйте 307 Temporary Redirect. Если вы намеренно хотите отбросить тело и перейти на GET — классический паттерн POST/Redirect/GET — используйте 303 See Other. Оба кода однозначны; 302 — нет.

Типичные ошибки 302 и как их исправить

Когда 302 работает неправильно, причина обычно одна из этих:

• 302 вместо 200 — стена входа, клиент, который не следует за редиректами, или вариант URL (см. «Почему приходит 302» выше)
• 302 без заголовка Location — за ним нечему следовать, и браузер показывает тело самого 302, обычно пустое. Задайте Location до отправки статуса
• 302, который указывает на самого себя — цикл редиректов: правило срабатывает на собственной цели. Добавьте недостающее условие
• Форма теряет данные — POST → 302 → GET отбрасывает тело. Используйте 303, чтобы намеренно показать страницу результата, или 307, чтобы сохранить POST
• 302, который залип — сервер отправил вместе с ним Cache-Control: max-age или Expires, и браузеры его закэшировали, либо его закэшировал CDN (на контенте, который кэширует Cloudflare, он хранит 302 20 минут, если заголовки не говорят иного, документация Cloudflare). Уберите эти заголовки, очистите кэш CDN и кэш браузера
• 302 в продакшене, но не локально — часто это правило CDN, балансировщика нагрузки или прокси, которое добавляет редиректы. Проверьте исходный сервер напрямую, чтобы выяснить

Циклы редиректов 302: как диагностировать

Цикл редиректов — это когда URL A отправляет вас на B, а B возвращает на A. После 20 перенаправлений — это лимит стандарта Fetch — Chrome сдаётся с ошибкой ERR_TOO_MANY_REDIRECTS, а Firefox пишет «Циклическое перенаправление на странице».

Классическая причина — режим шифрования Flexible в Cloudflare: Cloudflare обращается к вашему серверу по обычному HTTP, сервер перенаправляет HTTP на HTTPS, и Cloudflare снова обращается по HTTP (документация Cloudflare).

# Trace the full redirect chain (limit to 10 hops to avoid infinite loops)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# Example of a loop:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- loop confirmed

Если один и тот же URL постоянно возвращается в Location — указывая на себя или два URL, которые передают друг другу ход, — перед вами цикл (в режиме Flexible у Cloudflare https://example.com/ перенаправляет сам на себя). Полное решение смотрите в нашем руководстве по ERR_TOO_MANY_REDIRECTS. Проверка редиректов DNS Robot проходит цепочку с нашего сервера и останавливается там, где она зацикливается.

Лучшие практики для кода статуса 302

Несколько привычек позволяют избежать большинства проблем с 302:

• Всегда отправляйте заголовок Location — без него редирект некому выполнять
• Не добавляйте заголовки кэширования — 302 без max-age или Expires не кэшируется, а это именно то, что нужно
• Следите за абсолютными URL за прокси — в коде приложения относительный /login не раскрывает во Location внутреннее имя хоста и не подставляет http://; nginx и Apache строят абсолютные URL из собственных настроек
• Ограничивайтесь одним переходом — A → B нормально; A → B → C добавляет лишнее обращение к серверу для каждого посетителя
• Никогда не отправляйте POST на другую страницу через 302 — используйте 303, чтобы показать страницу результата, или 307, чтобы сохранить POST
• Пересматривайте старые временные редиректы — они часто переживают свою причину. Проверяйте их в Проверке редиректов
• Переходите на 301, как только переезд стал постоянным

Как браузеры и инструменты обрабатывают 302

Клиенты одинаково следуют за 302, но различаются в лимитах и в том, что происходит с методом:

Точные формулировки смотрите в определении 302 в RFC 9110 и на странице MDN о 302.