405 Method Not Allowed 진단

Problem

요청에 대한 최종 응답 코드가 405 Method Not Allowed로 반환됩니다.

Symptoms

• HTTP Check에서 최종 코드가 405입니다.
• 같은 URL에 GET은 되는데 POST·PUT·DELETE·PATCH는 실패합니다.
• 일반 브라우징은 멀쩡한데 API 클라이언트나 CORS preflight에서만 나타납니다.

405가 실제로 뜻하는 것

RFC 9110(§15.5.6)은 405를 “오리진 서버가 메서드를 알지만 대상 리소스가 지원하지 않는” 경우로 정의합니다. 서버는 당신의 동사를 완벽히 이해합니다 — 다만 여기서는 받지 않을 뿐입니다. 그리고 스펙은 강한 요구를 덧붙입니다: 오리진 서버는 그 리소스가 받아들이는 메서드를 나열한 Allow 헤더를 반드시(MUST) 생성해야 합니다. 그래서 제대로 된 405는 항상 대안을 알려줍니다. Allow 값이 비어 있는 것도 적법하며, 현재 어떤 메서드도 받지 않는다는 뜻입니다.

이 점이 405를 이웃들과 구분합니다. 501 Not Implemented는 서버가 메서드 자체를 인식하지 못하는 것(서버 전반의 공백, 5xx)이고, 403 Forbidden은 메서드는 괜찮지만 권한이 없는 것입니다. 405는 이렇게 말합니다 — 동사는 맞고, 문이 틀렸으며, 열리는 문 목록은 여기 있다.

Top 3 Causes

1. 라우트가 일부 메서드만 제공 - 해당 경로가 정적 파일, CDN, 또는 읽기 전용 핸들러(GET/HEAD)에 연결돼 있습니다. 쓰기 메서드가 연결돼 있지 않은 것이죠. Allow 헤더를 읽으면 무엇이 되는지 보입니다.
2. 프록시·WAF가 엣지에서 메서드 차단 - 리버스 프록시와 보안 규칙이 GET·POST만 전달하고 PUT·DELETE·PATCH를 오리진 도달 전에 거부하기도 합니다. 애플리케이션은 그 호출을 보지도 못합니다.
3. OPTIONS 핸들러 부재로 CORS preflight 깨짐 - 브라우저의 preflight OPTIONS 요청이 OPTIONS를 처리하지 않는 라우트에 닿아, 서버가 CORS 헤더 대신 405로 답합니다.

Diagnose with DechoNet

• HTTP Check로 최종 코드가 405인지 확인하고, 리소스가 실제로 받는 메서드를 나열한 Allow 헤더를 읽습니다.
• DNS Lookup으로 요청이 의도한 오리진에 닿고 있는지, 더 좁은 메서드만 제공하는 다른 호스트·환경이 아닌지 확인합니다.

Resolution Checklist

• 405 응답의 Allow 헤더를 읽습니다 — 작동하는 메서드가 나열돼 있습니다.
• 올바른 URL을 호출하는지 확인합니다. 정적·읽기 전용 경로에 쓰기 메서드를 보내는 것이 흔한 원인입니다.
• 그 메서드가 지원돼야 한다면, 애플리케이션 코드만이 아니라 라우트(서버·프레임워크 설정)에서 활성화합니다.
• 리버스 프록시, CDN, WAF가 오리진 도달 전에 메서드를 떼거나 막는지 점검합니다.
• CORS 실패라면 라우트에 OPTIONS 핸들러를 추가하거나 엣지에서 preflight를 종료합니다.
• HTTP Check를 다시 실행해 405가 사라졌는지 확인합니다.

When to Escalate

• 메서드가 엣지에서 막히고 규칙을 직접 못 바꾸면, 리버스 프록시·CDN·WAF 소유자에게 넘깁니다.
• 라우트가 분명히 그 메서드를 받아야 하는데 프레임워크가 계속 405를 반환하면, 라우트 설정과 Allow 헤더를 애플리케이션 담당자에게 전달합니다.