HTTP 410 Gone: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 크롤러, 모니터링 도구 또는 uptime checker가 410 Gone을 보고합니다.
• 응답은 웹사이트 전체가 아니라 특정 URL, 경로 패턴, HTTP 메서드 또는 API 버전에만 영향을 줄 수 있습니다.
• 요청이 HTTP 엔드포인트에 도달했기 때문에 DNS는 여전히 해석되고 TLS도 성공할 수 있습니다.
• 응답 헤더에서 캐싱 동작, 리디렉션 대상, 인증 컨텍스트, 프록시 또는 CDN 정보, 요청을 처리한 서버를 확인할 수 있습니다.
• 리소스가 의도적으로 삭제된 경우 같은 요청을 반복해도 일반적으로 동일한 결과가 반환됩니다.

가능성이 높은 순서의 주요 원인

가장 가능성 높은 원인

1. 의도적인 리소스 삭제 또는 지원 중단 — 소유자가 페이지, 파일, API 엔드포인트 또는 버전을 영구적으로 삭제하고 이전 주소가 410을 반환하도록 설정했습니다.
2. 애플리케이션 또는 라우팅 규칙 — 애플리케이션이 폐기된 라우트, 삭제된 레코드 또는 지원되지 않는 API 버전을 410으로 매핑합니다.
3. 웹 서버 rewrite 또는 virtual host 설정 — 라우트 규칙, 배포 변경 또는 잘못된 사이트 설정으로 인해 정상적으로 작동해야 하는 URL이 410을 반환합니다.
4. Reverse proxy 또는 CDN 동작 — 중간 계층이 라우팅, 캐시 또는 edge 설정에 따라 응답을 캐시하거나 생성할 수 있습니다.
5. 요청 불일치 — URL이 특정 메서드나 경로 형식에서는 유효하지만, 현재 사용한 메서드에서는 삭제되었거나 지원되지 않을 수 있습니다.
6. 사용자 지정 보안 또는 요청 처리 로직 — WAF, gateway 또는 애플리케이션 정책이 의도적으로 410을 사용할 수 있습니다. 다만 인증, 권한 부여 및 rate limit 문제에는 대개 다른 상태 코드가 사용됩니다.

상태 코드만으로는 어떤 컴포넌트가 응답을 생성했는지 확인할 수 없습니다. 의도된 삭제인지, 잘못된 규칙 또는 오래된 중간 계층 응답인지 구분하려면 응답 헤더, 타임스탬프 및 로그가 필요합니다.

해결 방법

사이트를 방문하는 경우

1. 호스트 이름, 경로, 철자, 대소문자 및 버전 세그먼트를 포함하여 주소를 주의 깊게 확인하세요.
2. 계속 새로 고침하지 말고 정확한 URL을 한 번 다시 요청하세요. 계정이 필요한 페이지라면 사이트의 일반적인 절차로 로그인한 후 다시 시도하세요.
3. 오래된 북마크, 검색 결과 또는 외부 링크에서 URL에 접속했다면 사이트의 현재 내비게이션이나 공지된 대체 페이지를 확인하세요. 410에 동등한 대상이 있다고 가정하지 마세요.
4. 응답이 계속되고 리소스가 여전히 존재해야 한다면 사이트 소유자에게 URL, 요청 시간, HTTP 메서드 및 표시된 410 결과를 전달하세요. 비밀번호, 쿠키 또는 access token은 보내지 마세요.

사이트를 소유하거나 개발하는 경우

1. 정확한 요청을 재현하세요. URL, HTTP 메서드, 호스트, query parameter, 상태, 응답 헤더 및 요청의 인증 여부를 기록하세요. 문제가 발생한 요청을 정상적으로 작동하는 관련 라우트 또는 메서드와 비교하세요.
2. 410이 의도된 것인지 결정하세요. 페이지, 파일, 레코드 또는 API 버전이 의도적으로 삭제되었는지 확인하세요. 의도적인 삭제라면 삭제 내용을 문서화하고, 적절한 대체 리소스가 필요한 경우가 아니라면 응답을 유지하세요.
3. 응답을 생성한 계층을 식별하세요. 헤더와 요청 경로를 통해 애플리케이션, 웹 서버, reverse proxy, CDN 또는 WAF가 응답을 생성했는지 확인하세요. 모든 계층을 한 번에 변경하지 말고 요청 경로의 각 계층을 검토하세요.
4. 관련 로그를 점검하세요. 타임스탬프, 라우트 및 request identifier를 사용하여 관련 access, 애플리케이션, 프록시, CDN 또는 보안 로그를 검색하세요. 삭제 규칙, 삭제된 레코드, rewrite, 배포 변경 또는 캐시된 응답을 확인하세요.
5. 최근 변경 사항과 캐시 상태를 확인하세요. 라우팅, API 버전 관리, 인증, rewrite 및 edge-cache 설정을 마지막으로 정상 작동한 배포와 비교하세요. 중간 계층이 잘못된 응답을 캐시했다면 캐싱을 광범위하게 비활성화하지 말고 해당 시스템의 문서화된 승인된 cache-invalidation 절차를 따르세요.
6. 승인된 범위에서 가장 좁은 수정만 적용하세요. 리소스를 제공해야 하는 경우에만 라우트를 복원하거나 잘못된 규칙을 제거하세요. 동등한 대체 리소스가 있다면 의도적인 리디렉션을 구성하고 테스트하세요. 410을 숨기기 위해 관련 없는 URL이나 존재하지 않는 URL을 리디렉션하지 마세요.
7. 같은 요청을 다시 테스트하세요. 관련 클라이언트에서, 그리고 해당되는 경우 영향을 받은 네트워크 또는 edge 위치에서 상태, 헤더 및 응답 본문을 확인하세요. 의도적으로 삭제된 라우트가 문서화된 대로 계속 동작하는지, 관련 라우트가 의도한 상태를 유지하는지 확인하세요.
8. 모니터링과 문서를 검토하세요. 향후 릴리스에서 활성 리소스가 실수로 삭제되지 않도록 라우트 목록, API 지원 중단 공지, 리디렉션 및 테스트를 업데이트하세요.

예방 및 해결 확인 방법

• 중요한 웹 라우트, 파일 및 API 버전의 목록을 관리하고 각각의 의도된 삭제 동작을 기록하세요.
• 의도적인 삭제를 릴리스 변경 사항으로 취급하세요. 삭제 내용을 문서화하고 테스트하며 승인된 대체 URL이 있는지 확인하세요.
• 애플리케이션, 웹 서버, 프록시, CDN 및 WAF 설정을 version control로 관리하고 배포 전에 라우트 변경 사항을 검토하세요.
• 릴리스, 마이그레이션 및 지원 중단 이후 중요한 URL과 API 메서드를 테스트하세요.
• 라우트, 메서드 및 배포별 HTTP 상태 비율을 모니터링하여 예기치 않은 410 응답과 계획된 삭제를 구분할 수 있게 하세요.
• 응답과 해당 계층을 연관 지을 수 있을 만큼 충분한 기간 동안 access 로그와 애플리케이션 로그를 보관하세요.
• 잘못된 edge 또는 프록시 응답에 대비한 캐시 무효화 및 rollback 절차를 정의하세요.

자주 묻는 질문