301 리디렉션 설정 후 웹사이트가 열리지 않을 때 어떻게 점검하나요?

301 리디렉션을 설정한 후 웹사이트가 열리지 않는다면, 먼저 요청이 어디에서 멈추는지 확인해야 합니다. 기존 URL에 응답이 없는지, 여러 주소 사이에서 반복적으로 리디렉션되는지, 아니면 새 URL로 이동한 뒤 새 사이트에서 오류가 발생하는지 확인하세요. 검색 시 흔히 보이는 “301 오류”가 301 자체의 장애를 의미하는 것은 아닙니다. 301은 영구 리디렉션을 뜻하며, 실제로 점검해야 할 것은 리디렉션 규칙, 대상 주소, 접속 경로입니다.

먼저 전체 리디렉션 경로를 기록한 다음 해당 설정을 수정하세요. 도메인 DNS, 인증서, 재작성 규칙을 동시에 변경하면 장애 원인을 파악하기가 더 어려워집니다.

요청이 어디에서 멈추는지 먼저 확인하세요

브라우저 개발자 도구를 열고 ‘네트워크’ 패널에서 ‘로그 보존’을 선택한 다음, 문제가 발생한 전체 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가 포함된 도메인과 포함되지 않은 도메인이 서로 리디렉션되는 경우가 있습니다. 예를 들어 서버에서 example.com을 www.example.com으로 보내고, 사이트 관리 도구에서는 후자를 다시 전자로 보내도록 설정하면 브라우저가 페이지에 도달하지 못합니다.

먼저 기준이 되는 공식 접속 주소를 하나로 정한 다음 CDN, 로드 밸런서, 서버, 사이트 관리 도구가 모두 같은 대상을 사용하고 있는지 확인하세요. 여러 계층의 규칙이 함께 작동할 수는 있지만, 각 규칙이 서로 다른 도메인이나 프로토콜을 가리켜서는 안 됩니다.

사이트가 리버스 프록시를 사용하는 경우에는 원본 서버가 방문자의 접속 프로토콜을 어떻게 판단하는지도 확인해야 합니다. 방문자는 HTTPS로 CDN에 접속하지만 CDN은 HTTP로 원본 서버에 연결할 수 있습니다. 원본 서버가 자체 연결만 기준으로 판단하면 계속 HTTPS로 이동하라고 요청하여 루프가 발생할 수 있습니다.

이 경우 원본 서버 연결 프로토콜과 애플리케이션이 신뢰할 수 있는 프록시에서 전달한 프로토콜 정보를 올바르게 인식하는지 확인하세요. 예를 들어 X-Forwarded-Proto를 점검할 수 있습니다. 해당 요청 헤더를 임의의 출처에서 전달된 경우에도 무조건 신뢰해서는 안 되며, 신뢰할 수 있는 프록시의 범위를 제한해야 합니다.

규칙끼리 서로 이동하지 않더라도 일치 범위와 실행 순서를 확인하세요

수정하기 전에 기존 설정을 백업한 다음 서버 재작성 규칙, 제어판 리디렉션, 프로그램 플러그인, CDN 규칙을 하나씩 확인하세요. 특히 다음 세 가지 문제를 살펴보세요.

• 대상이 여전히 원래 규칙에 적용되는 경우: 규칙이 모든 요청을 특정 주소로 보내면서 대상 주소 자체는 제외하지 않았을 수 있습니다.
• 와일드카드 또는 정규식의 범위가 지나치게 넓은 경우: 홈페이지 리디렉션 규칙이 제품 페이지, 관리자 페이지, API 또는 정적 리소스까지 잘못 적용될 수 있습니다.
• 경로 조합에 오류가 있는 경우: 디렉터리가 중복되거나 슬래시 처리가 일관되지 않거나 캡처 그룹 참조가 잘못되어 존재하지 않는 페이지로 이동할 수 있습니다.

규칙을 일시적으로 비활성화한 뒤 접속이 복구되더라도, 이는 해당 규칙 또는 다른 규칙과의 조합에 문제가 있다는 점만을 의미합니다. 필요한 도메인 표준화 설정을 바로 삭제하지 말고, 어떤 조건에서 규칙이 적용되는지 계속 확인하세요. Apache에서는 규칙의 순서와 상속 관계를 살펴보고, Nginx에서는 server, location, rewrite 간의 일치 관계도 확인해야 합니다. 수정 후에는 설정 문법을 검사한 뒤 다시 로드하세요.

대상 URL이 열리지 않으면 DNS, 인증서, 페이지 매핑을 확인하세요

Location에 표시된 전체 주소에 직접 접속하세요. 대상도 열리지 않는다면 기존 사이트의 301을 반복해서 수정할 것이 아니라 대상 사이트를 계속 점검해야 합니다.

도메인을 이전하는 경우 새 도메인의 A, AAAA 또는 CNAME 레코드가 예상한 서비스로 연결되는지 확인하세요. IPv4와 IPv6를 모두 설정했지만 둘 중 하나가 작동하지 않으면 일부 네트워크에서는 정상적으로 접속되고 다른 네트워크에서는 실패할 수 있습니다.

HTTPS에서는 다음 사항에도 유의해야 합니다. 브라우저가 기존 도메인에서 반환된 301을 받으려면 먼저 해당 도메인과 TLS 핸드셰이크를 완료해야 합니다. 따라서 기존 도메인을 리디렉션 용도로만 사용하더라도 유효하고 해당 도메인에 맞는 인증서가 필요합니다. www가 포함된 주소와 포함되지 않은 주소를 모두 점검해야 하며, 대상 사이트의 인증서가 정상이라고 해서 기존 도메인의 인증서를 대신할 수는 없습니다.

홈페이지는 정상적으로 열리지만 제품 페이지나 다국어 페이지에서 404가 발생한다면 새 경로와 기존 경로의 매핑을 확인하세요. 301은 브라우저가 새 주소를 요청하도록 할 뿐, 페이지를 자동으로 생성하지 않습니다. 해외 판매 사이트를 이전할 때는 기존 제품 페이지, 카테고리 페이지, 언어 페이지를 해당 콘텐츠에 우선 매핑하여 모든 페이지가 홈페이지로 연결되지 않도록 하세요.

서버를 수정했는데도 브라우저에서 계속 실패한다면 어떻게 해야 하나요?

301은 브라우저나 CDN에 캐시될 수 있습니다. 명령줄에서는 올바른 결과가 반환되는데 일반 브라우저가 여전히 이전 대상으로 이동한다면, 새 브라우저 프로필이나 다른 기기에서 다시 테스트한 다음 해당 도메인의 캐시를 삭제하세요. 개발자 도구에서 캐시 사용 안 함을 선택할 때는 도구를 계속 열어 두어야 합니다.

CDN이 이전 리디렉션 응답을 계속 반환할 수도 있으므로 영향을 받은 URL의 캐시를 삭제해야 합니다. 브라우저가 HTTP를 자동으로 HTTPS로 업그레이드하는 현상은 HSTS와 관련이 있을 수도 있습니다. 실제 네트워크 요청을 기준으로 판단해야 하며, 이를 모두 301 캐시 문제로 간주해서는 안 됩니다.

조정 중에는 적절한 상황에서 임시 리디렉션을 먼저 사용해 대상과 경로를 검증한 다음, 안정적으로 작동하는 것을 확인한 후 301로 변경할 수 있습니다. 이미 적용된 영구 리디렉션의 캐시는 별도로 처리해야 합니다.

접속이 복구된 후에는 주요 비즈니스 경로를 사용할 수 있는지 확인하세요

HTTP와 HTTPS, www가 포함된 주소와 포함되지 않은 주소, 홈페이지, 제품 상세 페이지, 언어별 디렉터리를 최소한으로 다시 테스트하고, 광고 랜딩 페이지나 검색 결과에 있는 기존 링크를 통해서도 접속해 보세요. 최종 페이지가 정상적으로 로드되어야 하며, 불필요한 중간 이동 없이 리디렉션 경로를 최대한 직접적으로 구성해야 합니다.

문의 양식, 장바구니 또는 결제 콜백이 관련된 경우 제출 과정을 별도로 검증하세요. 일부 클라이언트에서는 301로 인해 POST가 GET으로 바뀔 수 있으므로, 이러한 인터페이스에 일반 페이지 리디렉션 규칙을 그대로 적용해서는 안 됩니다. 요청 메서드를 유지해야 한다면 애플리케이션 로직을 고려해 307 또는 308의 사용을 검토하세요.

광고 매개변수가 유지되는지, 사이트 내부 링크와 사이트맵이 업데이트되었는지도 확인하세요. 웹사이트 구축 플랫폼을 사용하는 경우 서비스 제공업체에 오류 URL, 리디렉션 체인, 발생 시간, 최근 설정 변경 사항을 전달하면 플랫폼, CDN 또는 서버 중 어느 계층을 수정해야 하는지 더 빠르게 파악할 수 있습니다.