302가 301보다 좋습니까?

어느 것도 더 좋지 않습니다 — 다른 신호를 보냅니다. 301(영구)은 페이지를 영구적으로 이동했고 검색 엔진이 새 URL로 랭킹 신호를 전달하기를 원할 때 사용합니다. 302(일시)는 이동이 단기적이고 원래 URL이 정규 상태를 유지하기를 원할 때 사용합니다. 잘못 선택하면 SEO 에쿼티가 듭니다.

왜 302 리다이렉트 후 POST 요청이 GET으로 바뀝니까?

브라우저는 역사적으로 302를 따를 때 POST를 GET으로 바꿔 HTTP 사양을 위반했고, 그 동작이 너무 널리 퍼져 WHATWG Fetch Standard에서 표준화되었습니다. 오늘날 모든 주요 브라우저가 그렇게 합니다. 리다이렉트를 가로질러 POST 메서드를 보존하려면 302 대신 307 Temporary Redirect를 반환하세요.

Google은 302 리다이렉트를 통해 PageRank를 전달합니까?

Google Search Central에 따르면 302는 이동이 일시적임을 신호하므로 301처럼 랭킹 신호를 전달하지 않습니다. Google은 원래 URL을 정규로 유지합니다. 영구 이동을 302에 충분히 오래 두면 Google이 결국 301로 처리할 수 있지만 — 그 지연 동안 랭킹 에쿼티를 잃습니다. 영구 이동에는 항상 301을 사용하세요.

302 상태 코드 오류를 어떻게 수정합니까?

302는 엄격히 오류가 아닙니다 — 리다이렉트입니다. 예기치 않게 200 대신 302를 받는다면 서버 구성(.htaccess, nginx.conf), 프레임워크 미들웨어, CDN 규칙에서 의도하지 않은 리다이렉트 규칙을 확인하세요. CDN을 우회하여 origin 서버에 직접 curl -I를 사용하면 리다이렉트가 어디에서 추가되는지 격리할 수 있습니다.

HTTP에서 302 상태 코드를 어떻게 보냅니까?

상태 라인 `HTTP/1.1 302 Found`와 새 URL을 가리키는 `Location` 헤더를 반환합니다. Nginx에서: `return 302 https://example.com/new-page;`. Apache에서: `Redirect 302 /old https://example.com/new`. Express에서: `res.redirect('/new')`(302가 기본). 셋 모두 유효한 302 응답을 생성합니다.

302와 307의 차이는 무엇입니까?

둘 다 임시 리다이렉트입니다. 차이는 메서드 처리입니다: 302는 종종 브라우저가 리다이렉트를 따를 때 POST를 GET으로 바꾸어 본문을 버리게 합니다. 307 Temporary Redirect는 원래 메서드 보존을 보장합니다 — POST가 POST로 유지, PUT이 PUT으로 유지. 메서드 보존이 중요할 때 307을 사용하세요.

302 리다이렉트는 브라우저에 캐시됩니까?

기본적으로 아니요 — 서버가 명시적으로 `Cache-Control: max-age=...` 또는 `Expires` 헤더를 설정하지 않는 한 브라우저는 302 응답을 캐시하지 않습니다. 이는 리다이렉트의 임시 성격과 일치합니다. 안전을 위해 중간 프록시가 캐시하지 않도록 302 응답에 항상 `Cache-Control: no-cache`를 보내세요.

URL이 302 상태 코드를 반환하는지 어떻게 확인합니까?

가장 빠른 방법은 터미널에서 `curl -I https://example.com/your-url`입니다 — 리다이렉트를 따르지 않고 상태 코드와 Location 헤더를 보여줍니다. 터미널 액세스가 없으면 URL을 DNS Robot의 무료 리다이렉트 체커에 붙여넣으세요. 체인의 모든 홉을 추적하고 각 단계의 상태 코드를 표시합니다.

HTTP 302 상태 코드(302 Found): 의미와 사용 시점

Shaik Vahid2026년 4월 26일9 분 소요

HTTP 302 상태 코드 인포그래픽 — Location 헤더로 임시 리다이렉트 흐름과 301/302/307 비교

HTTP 302 상태 코드란?

HTTP 302 상태 코드(공식 명칭 302 Found)는 클라이언트(보통 브라우저)에 요청된 리소스가 다른 URL로 일시적으로 이동했음을 알리는 HTTP 응답 코드입니다. 새 URL은 응답의 Location 헤더에 제공되며, 클라이언트는 이번 요청에 한해 그곳에서 리소스를 가져옵니다.

이동이 일시적이므로 클라이언트는 향후 요청에서도 원래 URL을 계속 사용해야 합니다. 검색 엔진, 브라우저, 북마크는 원래 URL을 리다이렉트 대상으로 대체해서는 안 됩니다. 이것이 HTTP 302와 301 Moved Permanently의 핵심적인 동작 차이입니다.

302 코드는 RFC 9110에 정의된 HTTP 상태 코드의 3xx 리다이렉션 클래스에 속합니다. 역사적 이름인 'Found'에도 불구하고 응답 본문은 거의 사용되지 않습니다 — 현대 브라우저는 Location 헤더를 렌더링하지 않고 즉시 따릅니다.

302 응답의 구조

HTTP 302 상태 코드 응답은 항상 두 가지 필수 요소를 포함합니다: 상태 라인 자체와 새 URL을 가리키는 Location 헤더입니다. 유효한 Location 헤더가 없으면 클라이언트는 리다이렉트를 따를 수 없습니다.

상태 라인 — HTTP/1.1 302 Found(HTTP/2에서는 HTTP/2 302)
Location 헤더 — 클라이언트가 따라야 할 대상 URL(필수)
Cache-Control — 보통 no-cache, 브라우저가 리다이렉트 대상을 영구적으로 캐시하지 않도록
Body — 일반적으로 비어 있음. 레거시 클라이언트를 위해 작은 HTML 페이지를 포함할 수 있습니다(<html><body><a href="...">여기를 클릭</a></body></html>)

http

HTTP/1.1 302 Found
Location: https://www.example.com/new-page
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Cache-Control: no-cache, no-store
Date: Mon, 27 Apr 2026 14:00:00 GMT

Location 헤더는 절대 URL(https://example.com/path)이거나 경로 상대 URL(/path)일 수 있습니다. 현대 HTTP 클라이언트는 둘 다 받아들이지만, 명확성을 위해 절대 URL이 권장됩니다.

302 vs 301 vs 307 vs 308: 어떤 리다이렉트를 사용해야 할까?

HTTP는 다섯 가지 일반적인 리다이렉트 상태 코드를 정의하며, 올바른 코드 선택은 캐싱, SEO, 요청 메서드 보존에 영향을 줍니다. 다음 표를 결정 매트릭스로 사용하세요:

코드	영속성	메서드 보존?	브라우저 캐시?	최적 용도
301 Moved Permanently	영구	POST→GET으로 변할 수 있음	예(적극적으로)	영구 URL 변경, 도메인 마이그레이션
302 Found	일시적	자주 POST→GET으로 변경	아니오	로그인 흐름, A/B 테스트, 점검
303 See Other	일시적	항상 GET으로 변경	아니오	폼 제출 후 POST/Redirect/GET 패턴
307 Temporary Redirect	일시적	예 — 보존됨	아니오	POST/PUT 보존이 필요한 임시 리다이렉트
308 Permanent Redirect	영구	예 — 보존됨	예	POST/PUT 보존이 필요한 영구 리다이렉트

현대 권장사항: 임시 리다이렉트가 필요하고 메서드 처리에 모호함이 없게 하려면 302 대신 307을 사용하세요. 307 코드는 HTTP/1.1에 추가되었는데, 이는 정확히 브라우저들이 역사적으로 302에서 POST를 GET으로 바꾸어 사양을 위반했고 — 그 잘못된 동작이 너무 널리 퍼져 사실상의 표준이 되었기 때문입니다.

302 리다이렉트를 사용해야 할 때

리다이렉트가 정말로 임시일 때 — 즉, 미래에 리다이렉트 대상을 제거하거나 변경할 예정인 경우 — HTTP 302 상태 코드를 사용하세요. 일반적인 정당한 사용 사례:

로그인 리다이렉트 — 인증되지 않은 사용자를 /dashboard에서 /login으로 보내고, 로그인 후 다시 돌아오게 함
A/B 테스트 — 정규 URL을 변경하지 않고 사용자의 50%를 변형으로 라우팅
점검 페이지 — 서버를 패치하는 동안 모든 트래픽을 일시적으로 /maintenance로 리다이렉트
지역 라우팅 — 방문자를 국가에 따라 /에서 /kr 또는 /us로 보내고, /를 정규 진입점으로 유지
모바일 리다이렉트 — 스마트폰 사용자를 example.com에서 m.example.com으로 리다이렉트(오늘날에는 반응형 디자인이 선호됨)
재고 없는 상품 페이지 — 상품이 다시 입고될 때까지 구매자를 카테고리 페이지로 보냄
단기 프로모션 URL — 세일 기간에만 /black-friday가 캠페인 랜딩으로 리다이렉트

이 중 어느 것이든 영구화되면 301로 전환하세요. 검색 엔진은 장기간의 302를 301로 처리하기 전 몇 달을 기다리므로, 영구 이동을 302에 두면 그 기간 동안 랭킹 신호를 잃습니다.

302 상태 코드 보내는 방법

대부분의 웹 서버와 프레임워크에는 302 리다이렉트를 보내기 위한 내장 헬퍼가 있습니다. 아래는 가장 일반적인 패턴입니다. 각각은 HTTP 302 Found와 Location 헤더를 발행합니다 — 302 응답에 엄격히 필요한 두 가지뿐입니다.

Nginx

Nginx에서는 return 지시어를 코드 302와 함께 사용합니다(코드를 생략한 경우의 기본값도 302):

nginx

server {
    listen 80;
    server_name example.com;

    # 임시 리다이렉트 (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

Apache에서는 Redirect를 302 코드와 함께, 또는 RewriteRule을 [R=302,L] 플래그와 함께 사용합니다:

apache

# 단순 임시 리다이렉트
Redirect 302 /old-page https://example.com/new-page

# 또는 패턴 매칭을 위해 mod_rewrite 사용
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

Express의 res.redirect() 메서드는 코드를 제공하지 않으면 기본적으로 302를 사용합니다:

javascript

// 임시 리다이렉트(기본값 302 Found)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // 302 전송
  }
  // ...dashboard 렌더링
})

// 또는 명시적으로:
res.redirect(302, '/login')

302 상태 코드 테스트 방법

302 리다이렉트를 구현한 후 올바르게 작동하는지 확인하세요. 가장 빠른 방법은 터미널에서 curl을 사용하는 것입니다 — 브라우저 캐시 간섭 없이 정확한 상태 코드와 Location 헤더를 보여줍니다.

bash

# 리다이렉트를 따르지 않고 응답 헤더만 표시(-I)
curl -I https://example.com/old-page

# 예상 출력:
# HTTP/2 302
# location: https://example.com/new-page
# cache-control: no-cache
# date: Mon, 27 Apr 2026 14:00:00 GMT

# 전체 체인 따르기(-L) 및 각 홉 표시
curl -ILs https://example.com/old-page | grep -i 'HTTP/\|location:'

터미널 액세스가 없으면 DNS Robot의 리다이렉트 체커 무료 도구로 중립 위치에서 전체 체인을 추적하거나 HTTP 헤더 체커로 원시 응답 헤더를 검사하세요 — 둘 다 브라우저 캐시를 우회합니다.

302 리다이렉트와 SEO

HTTP 302 상태 코드는 검색 엔진에 '이 이동은 일시적이므로 원래 URL을 인덱스에 유지하라'고 알립니다. 이것은 랭킹 신호에 직접적인 결과를 갖습니다.

Google Search Central에 따르면 302는 301처럼 원래 URL의 랭킹 신호를 리다이렉트 대상으로 전달하지 않습니다. 원래 URL이 정규로 유지됩니다. 다른 정규화 신호(내부 링크, 사이트맵, hreflang)가 대상 페이지를 가리키면 Google은 여전히 인덱스할 수 있지만 — 302 자체는 정규 신호가 아닙니다.

영구 이동에는 301 사용 — 도메인 변경, URL 구조 변경, 페이지 통합
일시 이동에는 302 사용 — 로그인 흐름, A/B 테스트, 점검, 지역 라우팅
영구 이동을 302에 두지 말 것 — Google은 장기 302를 301로 처리하기까지 몇 달을 기다리므로 랭킹 에쿼티를 잃습니다
체인 피하기 — A → 302 → B → 302 → C는 신호를 희석하고 페이지 로드를 늦춥니다. 각 홉이 지연을 추가합니다

왜 302는 POST 요청을 GET으로 바꾸는가

이것이 HTTP 302의 가장 놀라운 동작입니다. 원래 RFC는 클라이언트가 리다이렉트를 따를 때 요청 메서드를 보존해야 한다고 했습니다. 그러나 초기 브라우저들 — Mosaic, Netscape, IE — 모두 302에서 POST를 GET으로 바꾸었고, 그 잘못된 동작이 너무 널리 퍼져 WHATWG Fetch Standard에서 표준화되었습니다.

오늘날 브라우저가 POST /login을 보내고 서버가 302 Found로 응답하면, 브라우저는 자동으로 리다이렉트 대상으로 GET /next-page를 발행합니다. 폼 데이터는 버려집니다. 이것은 서버 개발자가 거의 의도하지 않는 일입니다.

http

# 보내는 것:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# 서버가 302로 응답:
HTTP/1.1 302 Found
Location: /thank-you

# 브라우저는 GET으로 따름(폼 데이터 버려짐!):
GET /thank-you HTTP/1.1
Host: example.com

리다이렉트가 원래 메서드를 보존해야 한다면(POST가 POST로 유지, PUT이 PUT으로 유지) 302 대신 307 Temporary Redirect를 사용하세요. 의도적으로 본문을 버리고 GET으로 전환하려면 — 고전적인 POST/Redirect/GET 패턴 — 303 See Other를 사용하세요. 둘 다 모호하지 않습니다; 302는 그렇지 않습니다.

일반적인 302 문제와 해결

HTTP 302가 잘못되면 보통 다음 증상 중 하나로 나타납니다. 대부분 간단한 해결책이 있습니다:

`200 대신 302 받음` — 서버가 리다이렉트해서는 안 될 때 리다이렉트하고 있음. .htaccess, Nginx 구성 또는 프레임워크 미들웨어에서 의도하지 않은 리다이렉트 규칙 확인
`Location 헤더 없는 302` — 잘못된 응답. 브라우저는 빈 페이지를 표시. 코드가 상태 전송 전에 Location 헤더를 설정하는지 확인
`자기 자신으로 리다이렉트하는 302` — 리다이렉트 루프. Location URL이 요청 URL과 일치. 누락된 조건에 대해 규칙 확인
`폼 데이터를 버리는 302` — POST → 302 → GET이 본문을 버림. POST를 보존하려면 307 Temporary Redirect로 전환
`브라우저가 캐시한 302` — 버그가 있는 서버가 리다이렉트에 Cache-Control: max-age=...를 설정. Cache-Control: no-cache 추가하고 브라우저 캐시 비우기
`프로덕션에서는 302지만 로컬에서는 아님` — 보통 CDN이나 로드 밸런서가 리다이렉트를 추가. 격리하려면 origin에 직접 테스트

302 리다이렉트 루프: 진단 방법

리다이렉트 루프는 URL A가 302를 URL B로 반환하고 URL B가 다시 302를 A로 반환할 때 발생합니다. 20홉 후(Chrome과 Firefox에서) 브라우저는 ERR_TOO_MANY_REDIRECTS를 표시하고 포기합니다.

가장 흔한 단일 원인은 CDN(예: Cloudflare)과 origin 서버 간의 SSL/HTTPS 충돌입니다: CDN이 origin에 HTTP로 연결하고, origin이 HTTP→HTTPS로 리다이렉트하고, CDN이 HTTPS를 제거하고 다시 HTTP로 연결 — 무한 루프입니다.

bash

# 전체 체인 따르기(무한 루프 방지를 위해 10홉으로 제한)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# 루프 예시:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- 루프 확인됨

Location 헤더에서 두 URL이 번갈아 나타나면 302 루프가 확인된 것입니다. 완전한 가이드는 ERR_TOO_MANY_REDIRECTS 가이드를 참고하세요. DNS Robot의 리다이렉트 체커는 중립 위치에서 전체 체인을 추적하고 루프 지점에서 멈춥니다.

302 상태 코드 모범 사례

302 Found를 올바르게 보내면 리다이렉트 구현 시 개발자가 부딪히는 대부분의 버그를 피할 수 있습니다:

항상 Location 헤더 포함 — Location이 없는 302는 잘못되었으며 빈 페이지로 렌더링됩니다
항상 Cache-Control: no-cache 설정 — 그렇지 않으면 일부 브라우저가 세션 동안 리다이렉트를 캐시하여 '임시' 계약을 깹니다
Location에 절대 URL 사용 — https://example.com/new는 모호하지 않음; /new는 작동하지만 호스트를 변경하는 프록시 뒤에서 깨질 수 있음
리다이렉트는 한 홉으로 유지 — A → 302 → B는 괜찮음; A → 302 → B → 302 → C는 페이지 로드를 늦추고 신호를 희석
POST에서 다른 페이지로 302로 리다이렉트하지 말 것 — 303(의도적 GET) 또는 307(POST 보존) 사용
매월 리다이렉트 감사 — 오래된 임시 리다이렉트는 종종 그 이유보다 오래 살아남음. Redirect Checker로 확인
이동이 영구화되면 301로 전환 — 영구 이동을 302에 몇 주 이상 두지 말 것

브라우저 및 캐시 동작

다양한 브라우저와 중개자가 HTTP 302를 약간씩 다르게 처리합니다. 특이점을 알면 디버깅 시간이 절약됩니다:

클라이언트	302의 기본 동작	기본 캐시
Chrome / Edge	자동 따름, POST→GET 변경	헤더가 지시하지 않으면 캐시되지 않음
Firefox	자동 따름, POST→GET 변경	헤더가 지시하지 않으면 캐시되지 않음
Safari	자동 따름, POST→GET 변경	리다이렉트 캐싱이 약간 더 적극적
curl(기본)	따르지 않음 — 302 + Location 표시	캐시 없음
curl -L	--max-redirs(기본 50)까지 따름	캐시 없음
wget(기본)	--max-redirect=20까지 자동 따름	캐시 없음
Googlebot	따름, 임시 신호로 처리	원래 URL 재크롤

엣지 케이스(POST 메서드, 무한 루프, 헤더 존재)에서 리다이렉트 동작을 확인하려면 DNS Robot의 HTTP 헤더 체커가 브라우저 측 메서드 재작성 없이 원시 응답을 보여줍니다. 임시 리다이렉트에 대해서는 MDN 문서와 RFC 9110 사양에서 더 알아보세요.

리다이렉트 체인을 몇 초 만에 추적

DNS Robot의 무료 리다이렉트 체커로 리다이렉트 체인의 모든 홉을 검사하세요 — 상태 코드, Location 헤더, 최종 목적지를 중립 서버에서 확인(브라우저 캐시 없음).

사용해보기 리다이렉트 체커

자주 묻는 질문

302 상태 코드(HTTP 302 Found)는 요청된 리소스가 응답의 Location 헤더에 지정된 다른 URL에 일시적으로 있음을 의미합니다. 클라이언트는 이번 요청에 대해 리다이렉트를 따르지만 향후 요청에서는 원래 URL을 계속 사용해야 합니다. 301 Moved Permanently의 임시 대응물입니다.

HTTP 302 상태 코드(302 Found): 의미와 사용 시점

Shaik Vahid2026년 4월 26일9 분 소요

HTTP 302 상태 코드란?

302 응답의 구조

상태 라인 — HTTP/1.1 302 Found(HTTP/2에서는 HTTP/2 302)
Location 헤더 — 클라이언트가 따라야 할 대상 URL(필수)
Cache-Control — 보통 no-cache, 브라우저가 리다이렉트 대상을 영구적으로 캐시하지 않도록
Body — 일반적으로 비어 있음. 레거시 클라이언트를 위해 작은 HTML 페이지를 포함할 수 있습니다(<html><body><a href="...">여기를 클릭</a></body></html>)

http

HTTP/1.1 302 Found
Location: https://www.example.com/new-page
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Cache-Control: no-cache, no-store
Date: Mon, 27 Apr 2026 14:00:00 GMT

302 vs 301 vs 307 vs 308: 어떤 리다이렉트를 사용해야 할까?

코드	영속성	메서드 보존?	브라우저 캐시?	최적 용도
301 Moved Permanently	영구	POST→GET으로 변할 수 있음	예(적극적으로)	영구 URL 변경, 도메인 마이그레이션
302 Found	일시적	자주 POST→GET으로 변경	아니오	로그인 흐름, A/B 테스트, 점검
303 See Other	일시적	항상 GET으로 변경	아니오	폼 제출 후 POST/Redirect/GET 패턴
307 Temporary Redirect	일시적	예 — 보존됨	아니오	POST/PUT 보존이 필요한 임시 리다이렉트
308 Permanent Redirect	영구	예 — 보존됨	예	POST/PUT 보존이 필요한 영구 리다이렉트

302 리다이렉트를 사용해야 할 때

로그인 리다이렉트 — 인증되지 않은 사용자를 /dashboard에서 /login으로 보내고, 로그인 후 다시 돌아오게 함
A/B 테스트 — 정규 URL을 변경하지 않고 사용자의 50%를 변형으로 라우팅
점검 페이지 — 서버를 패치하는 동안 모든 트래픽을 일시적으로 /maintenance로 리다이렉트
지역 라우팅 — 방문자를 국가에 따라 /에서 /kr 또는 /us로 보내고, /를 정규 진입점으로 유지
모바일 리다이렉트 — 스마트폰 사용자를 example.com에서 m.example.com으로 리다이렉트(오늘날에는 반응형 디자인이 선호됨)
재고 없는 상품 페이지 — 상품이 다시 입고될 때까지 구매자를 카테고리 페이지로 보냄
단기 프로모션 URL — 세일 기간에만 /black-friday가 캠페인 랜딩으로 리다이렉트

302 상태 코드 보내는 방법

Nginx

Nginx에서는 return 지시어를 코드 302와 함께 사용합니다(코드를 생략한 경우의 기본값도 302):

nginx

server {
    listen 80;
    server_name example.com;

    # 임시 리다이렉트 (302 Found)
    location /old-page {
        return 302 https://example.com/new-page;
    }
}

Apache (.htaccess)

Apache에서는 Redirect를 302 코드와 함께, 또는 RewriteRule을 [R=302,L] 플래그와 함께 사용합니다:

apache

# 단순 임시 리다이렉트
Redirect 302 /old-page https://example.com/new-page

# 또는 패턴 매칭을 위해 mod_rewrite 사용
RewriteEngine On
RewriteRule ^maintenance$ /maintenance.html [R=302,L]

Node.js (Express)

Express의 res.redirect() 메서드는 코드를 제공하지 않으면 기본적으로 302를 사용합니다:

javascript

// 임시 리다이렉트(기본값 302 Found)
app.get('/dashboard', (req, res) => {
  if (!req.user) {
    return res.redirect('/login') // 302 전송
  }
  // ...dashboard 렌더링
})

// 또는 명시적으로:
res.redirect(302, '/login')

302 상태 코드 테스트 방법

bash

# 리다이렉트를 따르지 않고 응답 헤더만 표시(-I)
curl -I https://example.com/old-page

# 예상 출력:
# HTTP/2 302
# location: https://example.com/new-page
# cache-control: no-cache
# date: Mon, 27 Apr 2026 14:00:00 GMT

# 전체 체인 따르기(-L) 및 각 홉 표시
curl -ILs https://example.com/old-page | grep -i 'HTTP/\|location:'

302 리다이렉트와 SEO

영구 이동에는 301 사용 — 도메인 변경, URL 구조 변경, 페이지 통합
일시 이동에는 302 사용 — 로그인 흐름, A/B 테스트, 점검, 지역 라우팅
영구 이동을 302에 두지 말 것 — Google은 장기 302를 301로 처리하기까지 몇 달을 기다리므로 랭킹 에쿼티를 잃습니다
체인 피하기 — A → 302 → B → 302 → C는 신호를 희석하고 페이지 로드를 늦춥니다. 각 홉이 지연을 추가합니다

왜 302는 POST 요청을 GET으로 바꾸는가

http

# 보내는 것:
POST /submit-form HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

name=Alice&email=alice@example.com

# 서버가 302로 응답:
HTTP/1.1 302 Found
Location: /thank-you

# 브라우저는 GET으로 따름(폼 데이터 버려짐!):
GET /thank-you HTTP/1.1
Host: example.com

일반적인 302 문제와 해결

HTTP 302가 잘못되면 보통 다음 증상 중 하나로 나타납니다. 대부분 간단한 해결책이 있습니다:

`200 대신 302 받음` — 서버가 리다이렉트해서는 안 될 때 리다이렉트하고 있음. .htaccess, Nginx 구성 또는 프레임워크 미들웨어에서 의도하지 않은 리다이렉트 규칙 확인
`Location 헤더 없는 302` — 잘못된 응답. 브라우저는 빈 페이지를 표시. 코드가 상태 전송 전에 Location 헤더를 설정하는지 확인
`자기 자신으로 리다이렉트하는 302` — 리다이렉트 루프. Location URL이 요청 URL과 일치. 누락된 조건에 대해 규칙 확인
`폼 데이터를 버리는 302` — POST → 302 → GET이 본문을 버림. POST를 보존하려면 307 Temporary Redirect로 전환
`브라우저가 캐시한 302` — 버그가 있는 서버가 리다이렉트에 Cache-Control: max-age=...를 설정. Cache-Control: no-cache 추가하고 브라우저 캐시 비우기
`프로덕션에서는 302지만 로컬에서는 아님` — 보통 CDN이나 로드 밸런서가 리다이렉트를 추가. 격리하려면 origin에 직접 테스트

302 리다이렉트 루프: 진단 방법

bash

# 전체 체인 따르기(무한 루프 방지를 위해 10홉으로 제한)
curl -ILs --max-redirs 10 https://example.com 2>&1 | grep -i 'HTTP/\|location:'

# 루프 예시:
# HTTP/2 302
# location: http://example.com/
# HTTP/1.1 302 Found
# Location: https://example.com/
# HTTP/2 302
# location: http://example.com/  <-- 루프 확인됨

302 상태 코드 모범 사례

302 Found를 올바르게 보내면 리다이렉트 구현 시 개발자가 부딪히는 대부분의 버그를 피할 수 있습니다:

항상 Location 헤더 포함 — Location이 없는 302는 잘못되었으며 빈 페이지로 렌더링됩니다
항상 Cache-Control: no-cache 설정 — 그렇지 않으면 일부 브라우저가 세션 동안 리다이렉트를 캐시하여 '임시' 계약을 깹니다
Location에 절대 URL 사용 — https://example.com/new는 모호하지 않음; /new는 작동하지만 호스트를 변경하는 프록시 뒤에서 깨질 수 있음
리다이렉트는 한 홉으로 유지 — A → 302 → B는 괜찮음; A → 302 → B → 302 → C는 페이지 로드를 늦추고 신호를 희석
POST에서 다른 페이지로 302로 리다이렉트하지 말 것 — 303(의도적 GET) 또는 307(POST 보존) 사용
매월 리다이렉트 감사 — 오래된 임시 리다이렉트는 종종 그 이유보다 오래 살아남음. Redirect Checker로 확인
이동이 영구화되면 301로 전환 — 영구 이동을 302에 몇 주 이상 두지 말 것

브라우저 및 캐시 동작

다양한 브라우저와 중개자가 HTTP 302를 약간씩 다르게 처리합니다. 특이점을 알면 디버깅 시간이 절약됩니다:

클라이언트	302의 기본 동작	기본 캐시
Chrome / Edge	자동 따름, POST→GET 변경	헤더가 지시하지 않으면 캐시되지 않음
Firefox	자동 따름, POST→GET 변경	헤더가 지시하지 않으면 캐시되지 않음
Safari	자동 따름, POST→GET 변경	리다이렉트 캐싱이 약간 더 적극적
curl(기본)	따르지 않음 — 302 + Location 표시	캐시 없음
curl -L	--max-redirs(기본 50)까지 따름	캐시 없음
wget(기본)	--max-redirect=20까지 자동 따름	캐시 없음
Googlebot	따름, 임시 신호로 처리	원래 URL 재크롤

리다이렉트 체인을 몇 초 만에 추적

사용해보기 리다이렉트 체커

HTTP 302 상태 코드란?

302 응답의 구조

302 vs 301 vs 307 vs 308: 어떤 리다이렉트를 사용해야 할까?

302 리다이렉트를 사용해야 할 때

302 상태 코드 보내는 방법

Nginx

Apache (.htaccess)

Node.js (Express)

302 상태 코드 테스트 방법

302 리다이렉트와 SEO

왜 302는 POST 요청을 GET으로 바꾸는가

일반적인 302 문제와 해결

302 리다이렉트 루프: 진단 방법

302 상태 코드 모범 사례

브라우저 및 캐시 동작

리다이렉트 체인을 몇 초 만에 추적

자주 묻는 질문

302 상태 코드는 무엇을 의미합니까?

302 상태 코드는 무엇을 의미합니까?

302가 301보다 좋습니까?

302가 301보다 좋습니까?

왜 302 리다이렉트 후 POST 요청이 GET으로 바뀝니까?

왜 302 리다이렉트 후 POST 요청이 GET으로 바뀝니까?

Google은 302 리다이렉트를 통해 PageRank를 전달합니까?

Google은 302 리다이렉트를 통해 PageRank를 전달합니까?

302 상태 코드 오류를 어떻게 수정합니까?

302 상태 코드 오류를 어떻게 수정합니까?

HTTP에서 302 상태 코드를 어떻게 보냅니까?

HTTP에서 302 상태 코드를 어떻게 보냅니까?

302와 307의 차이는 무엇입니까?

302와 307의 차이는 무엇입니까?

302 리다이렉트는 브라우저에 캐시됩니까?

302 리다이렉트는 브라우저에 캐시됩니까?

URL이 302 상태 코드를 반환하는지 어떻게 확인합니까?

URL이 302 상태 코드를 반환하는지 어떻게 확인합니까?

관련 도구

관련 기사

HTTP 302 상태 코드란?

302 응답의 구조

302 vs 301 vs 307 vs 308: 어떤 리다이렉트를 사용해야 할까?

302 리다이렉트를 사용해야 할 때

302 상태 코드 보내는 방법

Nginx

Apache (.htaccess)

Node.js (Express)

302 상태 코드 테스트 방법

302 리다이렉트와 SEO

왜 302는 POST 요청을 GET으로 바꾸는가

일반적인 302 문제와 해결

302 리다이렉트 루프: 진단 방법

302 상태 코드 모범 사례

브라우저 및 캐시 동작

리다이렉트 체인을 몇 초 만에 추적

자주 묻는 질문

302 상태 코드는 무엇을 의미합니까?

302 상태 코드는 무엇을 의미합니까?

302가 301보다 좋습니까?

302가 301보다 좋습니까?

왜 302 리다이렉트 후 POST 요청이 GET으로 바뀝니까?

왜 302 리다이렉트 후 POST 요청이 GET으로 바뀝니까?

Google은 302 리다이렉트를 통해 PageRank를 전달합니까?

Google은 302 리다이렉트를 통해 PageRank를 전달합니까?

302 상태 코드 오류를 어떻게 수정합니까?

302 상태 코드 오류를 어떻게 수정합니까?

HTTP에서 302 상태 코드를 어떻게 보냅니까?

HTTP에서 302 상태 코드를 어떻게 보냅니까?

302와 307의 차이는 무엇입니까?

302와 307의 차이는 무엇입니까?

302 리다이렉트는 브라우저에 캐시됩니까?

302 리다이렉트는 브라우저에 캐시됩니까?

URL이 302 상태 코드를 반환하는지 어떻게 확인합니까?

URL이 302 상태 코드를 반환하는지 어떻게 확인합니까?

관련 도구

관련 기사