HTTP 405 Method Not Allowed: 의미와 해결 방법

이 오류의 의미와 확인 방법

• 브라우저, API 클라이언트, 모니터링 도구 또는 검사기가 405 Method Not Allowed를 수신합니다.
• 한 HTTP 메서드는 실패하지만 동일한 라우트에 대한 다른 메서드는 작동할 수 있습니다.
• 문제가 전체 사이트가 아니라 특정 URL, 라우트 패턴, 클라이언트 또는 배포에만 영향을 줄 수 있습니다.
• 응답에 허용된 메서드를 나열한 Allow 헤더가 포함될 수 있습니다.
• 다른 헤더를 통해 리디렉션, 캐시, 인증, 프록시, CDN 또는 서버 관련 정보를 확인할 수 있습니다.
• HTTP 응답을 수신했다는 것은 DNS 확인과 TLS 협상이 이미 성공했을 가능성을 의미하지만, 애플리케이션이나 라우트가 올바르게 구성되었다는 뜻은 아닙니다.

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

일반적인 원인

1. 라우트가 해당 메서드를 지원하지 않습니다. 엔드포인트가 GET은 허용하지만 POST는 거부하거나, POST는 허용하지만 PUT 또는 PATCH와 같은 업데이트 메서드는 거부할 수 있습니다.
2. 라우팅 또는 웹 서버 규칙이 메서드를 거부합니다. 라우트, 가상 호스트 또는 서버 정책이 요청을 의도한 핸들러로 전달하지 않을 수 있습니다.
3. 리버스 프록시, CDN 또는 WAF가 먼저 응답을 반환합니다. 중간 계층이 메서드 제한을 적용하거나 오리진과 다른 방식으로 요청을 라우팅할 수 있습니다.
4. 요청이 애플리케이션 계약과 일치하지 않습니다. 경로, 후행 슬래시, 콘텐츠 유형, 호스트, 인증 상태 또는 기타 요청 세부 정보에 따라 다른 라우트나 검증 규칙이 선택될 수 있습니다.
5. 최근 배포 또는 구성 변경으로 불일치가 발생했습니다. 애플리케이션 라우트, 프록시 규칙, 허용 메서드 및 캐싱 동작이 더 이상 서로 일치하지 않을 수 있습니다.
6. 의도된 정책 또는 엔드포인트 설계입니다. 일부 리소스는 안전하지 않거나 지원되지 않거나 문서화된 인터페이스 범위를 벗어난 메서드를 의도적으로 거부합니다.

상태 코드만으로는 어떤 계층 또는 규칙이 응답을 발생시켰는지 확인할 수 없습니다. 시스템을 변경하기 전에 메서드, 헤더, 로그 및 최근 변경 사항을 확인하세요.

해결 방법

방문자 또는 API 사용자라면

1. 정확한 URL과 클라이언트가 의도한 메서드를 전송하는지 확인하세요. 브라우저 주소 표시줄을 통한 요청은 일반적으로 GET을 사용하지만, API 클라이언트는 POST, PUT, PATCH, DELETE 또는 다른 메서드를 사용할 수 있습니다.
2. 응답 헤더에서 Allow 헤더와 리디렉션, 인증, 캐시 또는 프록시 관련 정보를 확인하세요. 사이트 또는 API 문서에서 지원한다고 명시하지 않았다면 다른 메서드를 유효한 우회 방법으로 간주하지 마세요.
3. 엔드포인트에 계정이 필요한 경우 일반적인 절차로 로그인한 후 다시 시도하세요. 지원 요청에 자격 증명을 노출하지 마세요.
4. 서비스에서 속도 제한, 시간 초과 또는 과부하 증상도 보고하는 경우 반복해서 재시도하지 마세요.
5. 문제가 계속되면 URL, 메서드, 타임스탬프, 상태 코드 및 관련 헤더를 민감 정보가 제거된 상태로 사이트 운영자에게 전달하세요. 비밀번호, 쿠키, 인증 토큰 또는 API 시크릿은 공유하지 마세요.

사이트를 소유하거나 관리한다면

1. 최소 재현을 확보하세요. 정확한 메서드, URL, 호스트, 요청 경로, 상태 및 관련 응답 헤더를 기록하세요. 요청 본문에 시크릿이나 개인 데이터가 포함되지 않은 경우에만 보존하세요.
2. 응답이 의도된 것인지 확인하세요. 요청을 라우트 또는 API 계약과 비교하세요. 리소스가 해당 메서드를 지원하도록 설계되었는지, Allow 헤더에 허용된 메서드가 표시되는지 확인하세요.
3. 응답 계층을 식별하세요. 응답 헤더, 요청 ID 및 타임스탬프를 사용해 응답이 애플리케이션, 웹 서버, 리버스 프록시, CDN 또는 WAF에서 반환되었는지 확인하세요. 프록시가 생성한 응답은 오리진에 도달하지 않았을 수 있습니다.
4. 일치하는 로그를 확인하세요. 식별한 계층과 가능한 경우 업스트림 계층에서 동일한 타임스탬프, 경로, 메서드 및 요청 ID를 검색하세요. 라우트 불일치, 메서드 필터, 거부된 업스트림 요청 및 최근 정책 변경을 살펴보세요.
5. 최근 변경 사항을 비교하세요. 배포, 라우트 정의, 웹 서버 규칙, 프록시 또는 CDN 동작, 인증 구성 및 WAF 정책을 검토하세요. 동일한 라우트에서 오류가 발생하는 메서드를 정상적으로 지원되는 메서드와 비교하세요.
6. 권한이 승인된 가장 좁은 범위의 수정만 적용하세요. 해당 메서드를 지원해야 하는 라우트 또는 규칙만 업데이트하세요. 오류를 없애기 위해 인증, WAF 보호 또는 메서드 제한을 광범위하게 비활성화하지 마세요.
7. 안전하게 다시 테스트하세요. 가능하면 먼저 비프로덕션 환경에서 동일한 요청을 반복한 다음, 승인된 변경 절차에 따라 영향을 받은 프로덕션 라우트를 테스트하세요. 지원되지 않는 메서드는 계속 거부되는지, 관련 라우트가 의도한 상태 코드를 계속 반환하는지 확인하세요.
8. 캐시와 중간 계층을 확인하세요. 클라이언트나 위치에 따라 동작이 다르면 프록시 또는 CDN이 응답을 캐시했거나 별도의 규칙을 적용하고 있는지 확인하세요. 캐시된 동작을 제거하거나 변경할 때는 서비스의 일반적인 운영 절차를 따르세요.

예방 및 해결 확인 방법

• 중요한 웹 라우트와 API 엔드포인트에서 지원하는 메서드를 정의하고 문서화하세요.
• 애플리케이션, 서버, 프록시, CDN 및 WAF를 변경한 후 중요한 라우트의 대표적인 메서드를 테스트하세요.
• 모든 4xx 응답을 하나의 그룹으로 취급하지 말고 라우트와 메서드별 상태 코드 비율을 모니터링하세요.
• 라우팅, 메서드 제한, 인증 및 프록시 구성을 버전 관리하세요.
• 중간 계층과 오리진 계층의 장애를 상호 연관시킬 수 있도록 요청 ID와 로그를 충분히 오래 보존하세요.
• 의도된 405 응답을 문서화하여 지원 및 모니터링 팀이 예상된 동작과 회귀를 구분할 수 있도록 하세요.
• 광범위한 메서드 허용을 피하고, 각 리소스와 애플리케이션 계약에 필요한 메서드만 허용하세요.

자주 묻는 질문