301/302/307/308 리다이렉트를 홉별로 검사하여 루프, 교차 출처 리다이렉트, HTTPS 다운그레이드 문제를 식별합니다.
<p>브라우저에 주소를 입력할 때 보이지 않는 곳에서 수많은 전환이 일어날 수 있습니다: HTTP→HTTPS, 비www→www, 구 도메인→신 도메인, 단축 링크→원본 링크…… 매 홉 리다이렉트는 시간을 소모하고 SEO 순위에 영향을 미치며 심지어 조용히 HTTPS를 HTTP로 다운그레이드할 수도 있습니다. 리다이렉트 체인 검사기는 서버 관점에서 URL의 완전한 전환 경로를 홉별로 추적하며 각 홉의 상태 코드(301/302/303/307/308), Location 헤더, 대상 주소를 표시하고 루프 전환, 크로스 도메인 전환, HTTPS 다운그레이드, 체인 절단 등 문제를 자동으로 검출하여 도메인 이전, HTTPS 배포, SEO 최적화에서 숨겨진 리다이렉트 위험을 발견하는 데 도움을 줍니다.</p>
Google 공식에서는 리다이렉트 체인을 단일 홉으로 제어하고 최대 3홉을 넘지 않도록 권장합니다. Google Search Center 문서에 따르면 Googlebot은 보통 최대 5개 리다이렉트 홉까지 따라간 후 추적을 중지하지만, 그렇다고 5홉이 안전하다는 의미는 아닙니다. 매 홉 리다이렉트는 페이지 로딩 지연(100-300ms/홉)을 증가시키고 크롤링 예산을 낭비하며 PageRank 전달 감쇠를 초래할 수 있습니다. 1홉은 거의 SEO 영향이 없습니다; 2홉은 수용 가능하지만 최적화할 것을 권장합니다; 3홉 이상은 LCP와 크롤링 효율에 영향을 미치기 시작합니다; 5홉 이상은 페이지가 인덱스되지 않을 위험이 있습니다. 본 도구로 핵심 페이지 전환 체인을 검사하여 핵심 URL(홈페이지, 핵심 제품 페이지, 고트래픽 내부 페이지)이 모두 단일 홉으로 직접 도착하는지 확보하십시오.
올바르게 사용된 301 영구 리다이렉트는 SEO에 해롭지 않습니다. Google의 Gary Illyes와 John Mueller는 여러 차례 확인했습니다. HTTP 도메인에서 HTTPS 도메인으로 이전하는 것과 동일 도메인 내 페이지 영구 이전의 경우 PageRank 전달은 100%이며 손실이 없습니다. 하지만 주의해야 합니다: 1) 302 임시 리다이렉트는 PageRank를 전달하지 않습니다(또는 전달 효율이 극히 낮습니다); 2) 리다이렉트 체인에 noindex, robots.txt 차단, 4xx/5xx 오류가 있으면 가중치 전달이 중단됩니다; 3) 크로스 도메인 301 이전 후 Google Search Console에 도메인 변경 통지를 제출하여 인덱스 이전을 가속화해야 합니다; 4) 301은 브라우저에 장기 캐시되므로 테스트 단계에서는 302로 검증한 후 301로 변경할 것을 권장합니다.
HTTPS→HTTP 다운그레이드 전환은 보통 다음 원인으로 발생합니다: 1) 리버스 프록시/CDN이 HTTP로 회신 소스하여 원본 사이트 Nginx/Apache가 $scheme 변수로 프로토콜을 가져올 때 https가 아니라 http를 얻음; 2) 애플리케이션 층 코드에 http:// 접두사 URL을 하드코딩; 3) WordPress 등 CMS의 Home URL 또는 Site URL이 http로 설정; 4) .htaccess에 구 HTTP 규칙이 잔여; 5) 제3자 서비스(CDN/WAF)의 SSL/TLS 설정이 「유연」 모드이고 「엄격」 모드가 아님. 수정 단계: 먼저 본 도구로 다운그레이드가 어느 홉에서 발생하는지 파악; CDN SSL을 「Full (strict)」 모드로 설정; Nginx에서 X-Forwarded-Proto 헤더를 정확히 처리; WordPress wp-config.php에 $_SERVER['HTTPS']='on'; 추가; HSTS 응답 헤더를 배포하여 브라우저 층 다운그레이드 방지; 모든 리다이렉트 규칙을 검사하여 대상이 https://인지 확인.
Nginx 리다이렉트 루프의 90% 이상은 리버스 프록시/CDN 시나리오에서 X-Forwarded-Proto 헤더가 정확히 처리되지 않아 발생합니다. 수정 방법: 1) CDN/로드밸런서가 백엔드에 X-Forwarded-Proto 헤더를 보내는지 확보: proxy_set_header X-Forwarded-Proto $scheme; 2) Nginx 판단 시 $scheme 대신 X-Forwarded-Proto를 사용하여 HTTPS 전환 여부를 결정. map 블록 사용 권장: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) server 블록에 무한히 자기 자신과 매칭되는 rewrite 규칙을 쓰지 마십시오; 4) www와 비www 리다이렉트는 한 server 블록에서만 단방향 전환을 설정하고 양방향으로 설정하지 마십시오.
Apache .htaccess 루프는 보통 RewriteRule 규칙 충돌로 발생합니다. 수정 단계: 1) RewriteEngine On이 한 번만 나타나는지 확인; 2) HTTP→HTTPS 전환 규칙을 모든 규칙 맨 앞에 두고 다음을 사용: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) www/비www 규칙은 HTTPS 전환 뒤에 두고 단방향 전환만 수행(비www→www 또는 그 반대); 4) [L] 플래그의 의미는 「last」이지만 규칙이 URL을 수정하면 첫 번째부터 다시 매칭되므로 루프가 발생할 수 있습니다. 복잡한 규칙은 [END] 플래그 사용을 고려(Apache 2.3.9+); 5) 여러 .htaccess 파일이 있는지 확인(하위 디렉터리의 .htaccess도적용); 6) 임시로 R=301을 R=302로 변경하여 테스트하여 브라우저 캐시 간섭을 피하십시오.
Cloudflare 루프의 가장 흔한 원인은 SSL/TLS 암호화 모드 설정 오류 또는 페이지 규칙 충돌입니다: 1) Cloudflare SSL/TLS 모드를 「Flexible」에서 「Full」 또는 「Full (strict)」로 변경——Flexible 모드에서는 Cloudflare에서 원본 사이트로 HTTP를 사용하는데 원본 사이트에 HTTPS 강제 전환이 설정되어 있으면 루프가 발생합니다; 2) Cloudflare의 「Edge Certificates」에 있는 「Always Use HTTPS」가 켜져 있는지 확인하고 원본 사이트와 Cloudflare에서 동시에 HTTPS 전환을 중복 설정하지 마십시오; 3) Page Rules에 상호 충돌하는 포워딩 규칙이 있는지 검사; 4) Cloudflare WordPress 플러그인을 사용하는 경우 플러그인과 Cloudflare에서 동시에 HTTPS 리다이렉트를 설정하지 마십시오; 5) Forwarding URL 규칙이 다시 Cloudflare에 의해 리다이렉트되는 주소를 가리키고 있는지 확인.
핵심 차이는 「영구 여부」와 「요청 메서드 보존 여부」 두 가지 차원에 있습니다. 빠른 선택 가이드: 일반 웹페이지 GET 요청(사용자 페이지 접근)의 경우——영구 이전은 301(도메인 이전, HTTPS 전환, URL 영구 변경), 임시 전환은 302(A/B 테스트, 임시 유지보수, 로그인 전환); POST/PUT/DELETE 요청(API 호출, 양식 제출)의 경우——영구 이전은 308, 임시 전환은 307로 하여 요청 메서드와 요청 본문이 손실되지 않도록 확보; 303은 전적으로 POST 양식 제출 후 결과 페이지로 전환하는 데 사용(강제 GET, 중복 제출 방지). 간단한 기억: 301=영구 GET 세이프, 302=임시 GET 세이프, 307=임시 전체 메서드, 308=영구 전체 메서드, 303=POST 후 결과 페이지 전환.
301 영구 리다이렉트는 기본적으로 브라우저에 캐시되지만 캐시 시간은 응답 헤더의 Cache-Control과 Expires 설정에 따라 다릅니다. 캐시 헤더를 명시적으로 지정하지 않은 경우 브라우저마다 기본 캐시 동작이 다릅니다: Chrome은 보통 301 리다이렉트를 수주에서 수개월 캐시합니다(브라우저 재시작 후에도 캐시될 수 있음); Firefox는 기본적으로 301을 캐시하지만 브라우저 재시작 후 재검증할 수 있습니다; Safari의 캐시 정책은 비교적 보수적입니다. 301 캐시를 지우는 방법: 1) Chrome: 설정→개인정보 및 보안→인터넷 사용 기록 삭제→시간 범위 「모든 시간」 선택→「캐시된 이미지와 파일」 체크→데이터 삭제; 2) 개발자 도구(F12)를 열었을 때 Network 패널의 「Disable cache」 체크; 3) URL 뒤에 의미 없는 쿼리 매개변수(?nocache=1)를 붙여 캐시 우회; 4) Chrome 개발자는 chrome://net-internals/#sockets에서 Flush sockets하거나 chrome://net-internals/#dns에서 host cache 지우기; 5) 테스트 단계에서는 301 대신 302 임시 리다이렉트를 사용하여 확인 후 301로 변경.
Meta Refresh는 HTML 문서의 <meta> 태그로실현하는 리다이렉트(예: <meta http-equiv="refresh" content="0;url=https://example.com/new">)로, 브라우저 측에서 HTML을 파싱한 후 전환을 실행합니다. 반면 HTTP 리다이렉트는 3xx 상태 코드를 통해 HTTP 프로토콜 층에서 서버가 직접 전환을 지시합니다. 차이점 비교: 1) 속도: HTTP 리다이렉트는 응답 헤더를 받을 때 전환을 시작하지만 Meta Refresh는 HTML 다운로드와 파싱을 기다려야 하므로 속도가 더 느립니다; 2) SEO: Google은 보통 Meta Refresh를 인식하고 가중치를 전달할 수 있지만(delay=0인 경우) 공식적으로는 HTTP 301/302 리다이렉트 사용을 권장합니다. Meta Refresh는 클라이언트 전환이므로 신호가 서버 리다이렉트만큼 명확하지 않습니다; 3) 지연: Meta Refresh는 지연 시간을 설정할 수 있지만(content="5;url=..."은 5초 후 전환을 의미) HTTP 리다이렉트에는 이 기능이 없습니다; 4) 접근성: W3C는 Meta Refresh 사용을 권장하지 않습니다. 스크린 리더 등 보조 기술이 잘 처리하지 못하고 사용자를 혼란스럽게 할 수 있기 때문입니다; 5) 뒤로 가기 버튼: Meta Refresh는 일부 브라우저에서 뒤로 가기 버튼 동작을 훼손할 수 있습니다. 결론: 항상 HTTP 301/302/307/308 리다이렉트를 우선 사용하고 Meta Refresh는 피하십시오. 단, 서버 설정을 제어할 수 없는 경우(정적 페이지 플랫폼에 호스팅되어 서버 측 규칙을 설정할 수 없는 경우 등)는 예외입니다.
네, 영향이 매우 큽니다. 리다이렉트는 브라우저가 HTML 문서를 획득하기 전에 발생하므로 매 홉 리다이렉트는 HTML 문서 다운로드 시작 시간을 늦춥니다. LCP(Largest Contentful Paint, 최대 콘텐츠 페인트)의 계산 시작점은 네비게이션 시작 시간인데, 브라우저는 최종 HTML을 받아야 DOM 파싱, CSS 로딩, LCP 요소 렌더링을 시작할 수 있습니다. 매 홉 리다이렉트가 150ms 네트워크 지연(DNS+TCP+TLS+요청응답)을 추가한다고 가정하면 3홉 리다이렉트는 LCP를 최소 450ms 증가시키며, 이는 LCP를 「양호」(≤2.5s)에서 「개선 필요」(2.5-4s) 구간으로 밀어넣기에 충분합니다. Google의 Core Web Vitals 문서에서는 「다중 리다이렉트 피하기」를 LCP 최적화의 핵심 제안 중 하나로 명시하고 있습니다. 베스트 프랙티스: 핵심 페이지가 제로 리다이렉트(직접 링크가 최종 URL을 가리킴)인지 확보하고, HTTP→HTTPS와 www 정규화 같은 필요한 리다이렉트는 단일 홉으로 제어하십시오.
단축 링크(t.cn, bit.ly, dwz.cn, url.cn 등)는 보통 1-3홉 리다이렉트를 거쳐 최종 URL에 도달하며 중간에 UTM 추적 매개변수, 기기 감지 전환, 지역 전환 등이 포함될 수 있습니다. 본 도구를 사용하여: 1) 단축 링크 URL을 입력(http:// 또는 https:// 포함); 2) 추적을 클릭하여 각 홉의 완전한 경로 확인; 3) 최종 랜딩 URL, 전환 횟수, 상태 코드 유형 확인; 4) 중간 전환에 HTTP 다운그레이드나 비정상 크로스 도메인이 있는지 검사. 주의: 일부 단축 링크는 User-Agent나 IP 지역에 따라 다른 최종 대상을 반환할 수 있습니다. 본 도구는 서버 IP로 요청하므로 브라우저로 직접 접근하여 보는 결과와 약간 차이가 있을 수 있습니다(특히 해외 단축 링크 서비스의 경우). 위챗/QQ의 url.cn 단축 링크는 위챗 환경 내에서만 정상적으로 대상 페이지로 전환될 수 있습니다.
HTTPS 강제 전환은 301 영구 리다이렉트를 사용해야 합니다. HTTP에서 HTTPS로의 전환은 영구적인 변경이지 임시 전환이 아니기 때문입니다. 301을 설정한 후에도 HSTS 응답 헤더를 배포해야 합니다. 완전한 HTTPS 강제 방안은 세 단계로 나뉩니다: 1) 첫 단계(테스트 기간): 먼저 HTTP→HTTPS 301 리다이렉트를 설정하고 HSTS는 활성화하지 않은 채 1-2주 관찰하여 모든 리소스와 서브도메인이 정상 작동하는지 확인; 2) 두 번째 단계(안정 기간): Strict-Transport-Security 응답 헤더를 추가하고 초기 max-age는 짧게 설정(예: max-age=300 즉 5분)하여 점차 max-age=31536000(1년)으로 늘림; 3) 세 번째 단계(Preload): 모든 서브도메인이 HTTPS를 지원하는지 확인한 후 includeSubDomains와 preload 지시를 추가한 다음 HSTS Preload List(hstspreload.org)에 제출하여 브라우저에 도메인 HSTS 정책이 내장되도록 하여 최초 접속의 HTTP 창을 제거. 주의: HSTS는 한번 브라우저에 캐시되면 max-age가 만료되기 전에 서버 측에서 철회할 수 없으므로 반드시 충분히 테스트하십시오.
JavaScript 전환(예: window.location.href='https://example.com')과 HTTP 3xx 리다이렉트는 본질적인 차이가 있습니다: 1) 실행 층위: HTTP 리다이렉트는 프로토콜 층에서 서버가 상태 코드를 반환하며 브라우저가 응답 헤더를 받는 즉시 전환; JS 전환은 HTML 다운로드, JS 파싱 실행 후에야 전환되므로 속도가 더 느림; 2) SEO: 검색 엔진 크롤러는 HTTP 301/302 리다이렉트를 정확히 인식하고 따라가며 가중치를 전달할 수 있지만, JS 전환의 SEO 효과는 크롤러가 JS를 실행하는지와 실행 시기에 따라 달라지며 신호가 약하고 불안정함; 3) 중간단계: JS 전환 전에 페이지가 이미 로드되기 시작하여(흰 화면이나 일부 콘텐츠 깜빡임이 나타날 수 있음), HTTP 리다이렉트는 사용자가 직접 대상 페이지에 도달하므로 경험이 더 매끄러움; 4) 신뢰성: JS는 브라우저, 플러그인, Content Security Policy에 의해 차단될 수 있지만, HTTP 리다이렉트는 브라우저 핵심에서 처리되므로 신뢰성이 가장 높습니다. 결론: URL을 영구/임시로 전환해야 할 때는 항상 서버 측 HTTP 301/302 리다이렉트를 사용하고, JS 전환은 인터랙션 로직의 페이지 네비게이션(양식 검증 후 전환, 버튼 클릭 전환 등)에만 사용하십시오.
네, 리다이렉트 체인은 A/B 테스트에 여러 방면으로 영향을 미칩니다: 1) A/B 테스트가 리다이렉트로실현되는 경우(50% 사용자는 302로 버전 A로, 50%는 버전 B로), 리다이렉트 지연으로 두 버전의 페이지 로딩 속도가 달라져 속도 자체가 전환율에 영향을 미칠 수 있습니다(속도가 빠른 버전은 자연스럽게 전환율이 높음). 이는 테스트 편향을 초래합니다; 2) 리다이렉트 과정에서 UTM 매개변수나 출처 표시가 손실되어 귀속 데이터가 부정확해질 수 있습니다; 3) 302 리다이렉트가 지속되면 Google이 스스로 301로 판단하여 가중치를 전달할 수 있어 테스트 페이지의 SEO에 영향을 미칩니다; 4) 다중 홉 리다이렉트중 특정 홉에 Cookie가 설정되면 사용자 그룹핑 로직에 영향을 미칠 수 있습니다. A/B 테스트에는 서버 사이드 렌더링 분배나 클라이언트 JS 분배(Google Optimize, Optimizely 등)를 사용하여 리다이렉트 분배를 피할 것을 권장합니다. 부득이 리다이렉트를 사용해야 하는 경우(완전히 다른 URL 경로를 테스트하는 등) 302를 사용(301 금지)하고 단일 홉으로 직접 도달하게 하며 테스트 종료 후 즉시 리다이렉트를 제거하십시오.
웹사이트 리다이렉트 체인을 일괄 검사하려면 크롤러 도구를 결합해야 합니다: 1) Screaming Frog SEO Spider 등 크롤러 도구로 웹사이트 전체를 크롤링하고 Redirect Chains 보고서에서 모든 리다이렉트 URL과 체인 길이를 확인; 2) Ahrefs, Semrush 또는 Sitebulb 등 SEO 도구의 사이트 감사 기능을 사용. 이들은 리다이렉트 체인과 루프를 자동으로 검출합니다; 3) 핵심 페이지 목록에 대해서는 스크립트를 작성하여 본 도구의 백엔드 API를 호출하여 일괄 검사; 4) Google Search Console의 「페이지 인덱스」 보고서에서 「리다이렉트 오류」와 「리다이렉트 체인 과다」 알림 확인; 5) Chrome DevTools의 Lighthouse 감사를 사용. Performance 부분에 리다이렉트 문제가 표시됩니다. 우선적으로 검사할 것을 권장: 홈페이지, 주요 네비게이션 페이지, 고트래픽 랜딩 페이지, 최근 이전/개편한 페이지, HTTPS 전환 후 모든 HTTP URL, 구 도메인의 모든 URL.
301 | Moved Permanently | 예(영구) | 변경 가능(POST→GET) | 도메인 이전, HTTPS 전환, www/비www 정규화, URL 영구 변경 |
302 | Found | 아니요(임시) | 변경 가능(POST→GET) | 임시 유지보수 페이지, 로그인 전환, A/B 테스트, 단기 활동 페이지 |
303 | See Other | 아니요(임시) | 예(강제 GET) | POST 양식 제출 후 결과 페이지로 전환, 중복 제출 방지 |
307 | Temporary Redirect | 아니요(임시) | 아니요(원본 메서드 엄격 보존) | API 임시 리다이렉트, POST 데이터를 보존해야 하는 임시 전환 |
308 | Permanent Redirect | 예(영구) | 아니요(원본 메서드 엄격 보존) | RESTful API 영구 이전, PUT/DELETE 메서드를 보존해야 하는 영구 리다이렉트 |
| 0홉(직접 도착) | 영향 없음, 최적 상태 | 추가 지연 없음 | 현상 유지, 내부 링크는 최종 URL을 직접 가리킴 |
| 1홉 | PageRank 정상 전달, SEO 영향 무시 가능 | 약 100-300ms 지연 추가(1회 왕복) | 수용 가능, HTTP→HTTPS와 도메인 정규화의 흔한 홉 수 |
| 2홉 | 가중치 전달에 약간의 감쇠가 있을 수 있으나 크롤러는 정상 추적 | 약 200-600ms 지연 추가 | 단일 홉으로 최적화할 것을 권장, 내부 링크가 중간 전환 URL을 가리키는지 검사 |
| 3홉 | 가중치 전달 효율하락, 일부 크롤러는 추적을 포기할 수 있음 | 약 300-900ms 지연 추가, LCP에 영향을 미칠 수 있음 | 반드시 최적화, 리다이렉트 규칙을 병합하여 최종 URL로 직접 전달 |
| 4-5홉 | PageRank가 현저히 감쇠, 인덱스에 영향을 미칠 수 있으며 크롤링 예산 낭비 | 500ms-1.5s 지연 추가, LCP가 기준을 초과할 가능성이 높음 | 긴급 수리, CDN/원본 사이트/애플리케이션 다층 리다이렉트 중첩 검사 |
| 6홉 이상 | 심각한 위험, 검색 엔진이 추적을 중단하여 페이지가 인덱스에서 제거될 수 있음 | 지연이 1초 이상 초과, 사용자 경험 매우 나쁨 | 즉시 루프나 설정 오류 진단, 리다이렉트 규칙 재구성 |
| 루프(ERR_TOO_MANY_REDIRECTS) | 페이지에 완전히 접근할 수 없어 검색 엔진이 인덱스에서 제거 | 페이지가 로드되지 않고 브라우저가 오류 표시 | 최우선 수리, 본 도구를 사용하여 루프 노드 파악 |
| ERR_TOO_MANY_REDIRECTS 루프 오류, HTTP↔HTTPS 반복 전환 | CDN/로드밸런서가 HTTP로 회신 소스하고 원본 사이트가 X-Forwarded-Proto 헤더를 정확히 처리하지 못해 계속 HTTPS로 리다이렉트 | Nginx 설정에 추가: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } 또는 $scheme 변수를 proxy_set_header X-Forwarded-Proto 설정과 함께 사용 |
| www와 비www가 상호 전환하여 루프 형성 | CDN 층에 www→비www 전환을 설정하고 원본 사이트 Nginx에 비www→www 전환을 설정하여 규칙이 충돌 | 정규화 버전을 하나 선택(비www 또는 www 권장, 일관성 유지)하고 한 층(CDN 또는 원본 사이트)에서만 리다이렉트를 설정하며 다른 층의 해당 규칙은 삭제 |
| 리다이렉트 체인이 4-5홉을 거쳐야 최종 페이지에 도착 | HTTP→HTTPS 홉→비www→www 홉→뒤 슬래시 추가 홉→구 경로→새 경로 홉 등 다층 규칙이 중첩 | 리다이렉트 규칙을 병합하여 초기 URL에서 최종 URL로 한 번에 전환. Nginx에서 return 지시문을 사용하여 완전한 최종 주소로 한 번에 전달 |
| HTTPS 사이트 리다이렉트 체인에 HTTP 노드가 나타남(다운그레이드) | 서버 설정에 http:// 접두사의 리다이렉트 대상을 하드코딩했거나 애플리케이션이 리다이렉트 URL 생성 시 현재 HTTPS임을 인식하지 못함 | 애플리케이션에서 리버스 프록시를 신뢰하도록 설정하고 X-Forwarded-Proto를 정확히 읽도록 함; Nginx에서 https:// 절대 URL 또는 $scheme 변수를 사용(단, proxy가 scheme을 정확히 설정한 전제); HSTS 배포 |
| 301 리다이렉트를 수정했는데 브라우저가 여전히 구 주소로 전환 | 브라우저가 301 영구 리다이렉트 규칙을 장기 캐시하여 F5 새로고침이 효과 없음 | 테스트 단계에서는 302 임시 리다이렉트를 사용하여 확인 후 301로 변경; 브라우저 캐시 지우기(Chrome: 설정→개인정보→인터넷 사용 기록 삭제→캐시된 이미지와 파일); DevTools의 Disable cache 옵션 사용 |
| POST 요청 리다이렉트 후 양식 데이터 손실 | 301 또는 302 리다이렉트를 사용하여 브라우저가 자동으로 POST를 GET 요청으로 변환하고 요청 본문이 폐기됨 | POST/PUT/DELETE 등 비GET 요청의 경우 307(임시) 또는 308(영구) 리다이렉트로 변경하여 요청 메서드와 요청 본문을 엄격히 보존 |
| 리다이렉트 후 URL에 %2520 등 이중 인코딩 문자가 나타남 | URL 매개변수가 이미 한 번 URL 인코딩되었는데 서버 리다이렉트 시 두 번째 인코딩을 또 수행함 | 리다이렉트 로직을 검사하여 URL이 한 번만 인코딩되도록 함; Nginx에서 $uri(디코딩된 것) 대신 $request_uri(원본 URI, 디코딩되지 않음)를 사용 |
| AJAX/fetch 요청 크로스 도메인 리다이렉트 후 CORS 오류 발생 | 크로스 도메인 리다이렉트 대상 서버에 CORS 응답 헤더(Access-Control-Allow-Origin 등)가 설정되지 않음 | 리다이렉트 체인의 매 홉 서버에 CORS 헤더가 올바르게 설정되도록 확보; 또는 AJAX 요청에서 크로스 도메인 리다이렉트 사용을 피하고 프론트엔드에서 대상 URL을 가져온 후 직접 요청 |
