HTTP 405 Method Not Allowed — 메서드 허용 안 됨 원인·해결·예방

HTTP 405 Method Not Allowed — 메서드 허용 안 됨 원인·해결·예방

API를 호출했는데 405 Method Not Allowed가 돌아온다. 주소는 분명 맞다. 같은 URL을 브라우저로 열면 잘 뜨는데, 폼을 제출하거나 PUT으로 수정하려 하면 405가 난다. 405는 "그 주소는 있는데, 네가 쓴 메서드(GET·POST·PUT·DELETE)는 거기서 허용하지 않는다"는 뜻이다. 자원이 없어서 막힌 404와는 다르고, 서버가 그 메서드 자체를 모르는 501과도 다르다. 이 글은 405가 정확히 무엇인지, 왜 나는지, Allow 헤더로 어떻게 진단하고 푸는지를 정리한다.

HTTP 405 Method Not Allowed

이 글의 구성

 

🔎405 Method Not Allowed의 의미

🧩자주 나오는 발생 원인 5가지

💻재현과 Allow 헤더 확인

🛠해결 방법과 단계별 진단

⚖️404·501·400과의 차이

💬자주 묻는 질문 5가지

---

🔎 405 Method Not Allowed의 의미

405는 4xx, 즉 클라이언트 측 요청에 문제가 있다는 묶음에 속한다. 정확히는 "서버가 그 메서드를 인식은 하지만, 요청한 자원(URL)에 대해서는 허용하지 않는다"는 뜻이다. 메서드 자체를 모르는 게 아니라, 이 주소에는 그 메서드를 쓸 수 없다는 것이다.

 

예를 들어 게시글을 보여주는 /posts/1 주소는 GET은 받지만, 그 주소로 DELETE를 보내면 "여기서 삭제는 안 된다"며 405를 줄 수 있다. 중요한 규칙이 하나 있다. 405를 보낼 때 원본 서버(origin server)는 응답에 Allow 헤더를 담아 "그럼 어떤 메서드는 되는지"를 알려야 한다. 명세상 의무 사항이라, 잘 만든 서버라면 Allow: GET, POST처럼 허용 목록을 돌려준다. 이 헤더가 진단의 출발점이다. 다만 현실에서는 일부 서버(예: 정적 파일에 대한 Nginx)가 405를 주면서 Allow를 빠뜨리기도 하므로, Allow가 없다고 405가 아닌 건 아니다. 그땐 내가 보낸 메서드를 단서로 함께 본다.

핵심 — 자원은 있고, 메서드가 안 맞는다

405는 "주소가 틀렸다"가 아니라 "주소는 맞는데 동작이 안 맞는다"는 신호다. 자원이 없으면 404, 메서드 자체를 서버가 구현 안 했으면 501이다. 405는 그 중간, 자원은 존재하고 메서드도 알지만 이 조합만 거부된 경우다. 그래서 응답의 Allow 헤더부터 보면 허용 메서드를 바로 알 수 있다.

---

🧩 자주 나오는 발생 원인 5가지

원인 1 — 잘못된 메서드로 호출

가장 흔하다. GET 전용 엔드포인트에 POST를 보내거나, 수정 API에 PUT 대신 POST를 쓰는 식이다. API 문서가 정한 메서드와 실제 호출이 어긋난 경우다.

원인 2 — 서버에 해당 메서드 라우트가 없음

백엔드에서 GET 핸들러만 만들고 POST 라우트를 안 만든 경우다. 프레임워크가 "이 경로에 그 메서드 핸들러가 없다"며 405를 돌려준다. 라우팅 설정 누락이 원인이다.

원인 3 — 정적 파일·웹서버에 쓰기 메서드

Nginx·Apache 같은 웹서버는 정적 파일(.html·이미지)에 대해 GET·HEAD만 허용하고, POST·PUT을 보내면 기본적으로 405로 거부한다. 정적 자원에 쓰기 메서드를 보낸 설계 실수다.

원인 4 — 리다이렉트로 메서드가 바뀜

301·302 리다이렉트를 거치며 POST가 GET으로 바뀌어, 도착지가 그 메서드를 안 받아 405가 나기도 한다. http→https 이동 중 흔히 생긴다. 메서드 보존이 필요하면 307·308을 쓴다.

원인 5 — 프록시·OPTIONS 처리 누락

리버스 프록시나 API 게이트웨이가 특정 메서드를 막거나, CORS 프리플라이트(OPTIONS)를 처리하지 않아 405가 나는 경우다. 미들웨어·프록시 단의 메서드 정책을 확인해야 한다.

---

💻 재현과 Allow 헤더 확인

405 진단의 핵심은 응답의 Allow 헤더다. curl로 의도적으로 막힌 메서드를 보내, 서버가 어떤 메서드를 허용하는지 받아 본다.

# GET 전용 자원에 POST → 405 재현
curl -i -X POST https://example.com/posts/1

# 응답 — Allow 헤더가 허용 메서드를 알려준다
HTTP/2 405
allow: GET, HEAD

자원이 어떤 메서드를 받는지 미리 보려면 OPTIONS로 물어보는 방법도 있다. 서버가 지원하면 Allow에 목록을 준다.

# 이 자원이 허용하는 메서드 묻기
curl -i -X OPTIONS https://example.com/posts/1

# ✓ 응답 예시
HTTP/2 204
allow: GET, HEAD, PUT, DELETE

개발자도구 네트워크 탭에서도 실패한 요청의 Status가 405인지, 응답 헤더에 Allow가 있는지 확인할 수 있다. Allow 목록과 내가 보낸 메서드를 비교하면 원인이 거의 드러난다.

---

🛠 해결 방법과 단계별 진단

405는 "맞는 메서드를 쓰거나, 서버가 그 메서드를 받도록 하거나" 둘 중 하나다. 클라이언트 잘못인지 서버 설정인지부터 가른다.

입장	해결 방법
호출하는 쪽	Allow 헤더·API 문서 확인 후 올바른 메서드로 호출
백엔드	필요한 메서드 라우트·핸들러 추가, REST 설계 점검
웹서버	정적 자원에 쓰기 보내지 말고, 동적 처리는 앱 서버로 라우팅
리다이렉트	POST 보존이 필요하면 301·302 대신 307·308 사용
프록시·CORS	게이트웨이 메서드 정책·OPTIONS 프리플라이트 처리 확인

단계별 진단 절차

 

01응답의 Allow 헤더를 확인해 허용 메서드 목록을 본다.

02내가 보낸 메서드가 목록에 있는지 비교한다. 없으면 호출 메서드를 고친다.

03메서드가 맞는데도 405면, 서버 라우트·핸들러가 그 메서드를 처리하는지 본다.

04리다이렉트를 거치는지(curl -IL) 확인해 메서드 변질 여부를 점검한다.

05프록시·웹서버·CORS 프리플라이트 단에서 막는지 마지막으로 확인한다.

---

⚖️ 404·501·400과의 차이

405는 비슷한 4xx·5xx 코드와 헷갈리기 쉽다. 무엇이 문제인지에 따라 코드가 갈린다.

코드	무엇이 문제
405	자원은 있고 메서드도 알지만, 이 자원엔 그 메서드 허용 안 됨
404	자원(URL) 자체가 없음
501	서버가 그 메서드를 어떤 자원에도 구현하지 않음(Not Implemented)
400	요청 구문·형식이 잘못됨(Bad Request)

한 줄로 정리하면, 404는 "그 주소 없음", 501은 "그 메서드 아예 모름", 400은 "요청이 깨짐", 405는 "주소·메서드 다 알지만 이 조합은 안 됨"이다. 405가 떴다는 건 적어도 자원은 존재한다는 뜻이라, 디버깅 방향이 "메서드와 라우팅"으로 좁혀진다.

“

405는 주소가 아니라 동작이 틀렸다는 신호다. 응답의 Allow 헤더가 정답지를 들고 있다.

 

— 허용 메서드부터 확인하라

---

💬 자주 묻는 질문 5가지

Q1주소는 맞는데 왜 405가 나죠?

자원은 존재하지만 그 자원이 당신이 쓴 메서드를 허용하지 않기 때문입니다. 예를 들어 GET만 받는 주소에 POST를 보낸 경우죠. 응답의 Allow 헤더를 보면 어떤 메서드가 허용되는지 바로 확인할 수 있습니다.

Q2405랑 404는 뭐가 다른가요?

404는 주소(자원) 자체가 없는 것이고, 405는 주소는 있는데 그 메서드만 거부된 것입니다. 405가 떴다면 적어도 자원은 존재한다는 뜻이라, 문제 범위가 메서드와 라우팅으로 좁혀집니다.

Q3메서드는 맞게 보냈는데도 405예요.

서버에 그 메서드 라우트·핸들러가 없을 가능성이 큽니다. 백엔드에서 GET만 만들고 POST 라우트를 빠뜨린 경우가 흔하죠. 또 리다이렉트를 거치며 POST가 GET으로 바뀌었거나, 프록시·웹서버가 막는 경우도 확인하세요.

Q4정적 사이트에 POST했더니 405가 나요.

Nginx·Apache 같은 웹서버는 정적 파일에 GET·HEAD만 허용하고 POST·PUT은 기본 거부합니다. 폼 처리·쓰기 동작은 정적 파일이 아니라 앱 서버나 API 엔드포인트로 보내야 합니다. 라우팅 설계를 점검하세요.

Q5405와 501은 어떻게 구분하나요?

405는 서버가 그 메서드를 알지만 이 자원에는 허용하지 않는 것이고, 501은 서버가 그 메서드 자체를 구현하지 않은 것입니다. 405는 Allow 헤더로 대안 메서드를 제시하지만, 501은 그 기능이 서버에 아예 없다는 뜻이라 성격이 다릅니다.

---

📌 결론

405 Method Not Allowed는 "주소는 맞는데 그 메서드는 이 자원에서 허용하지 않는다"는 신호다. 자원이 없는 404, 메서드를 모르는 501과 달리, 405는 자원도 메서드도 알지만 이 조합만 거부된 상태다. 그래서 디버깅은 메서드와 라우팅에 집중하면 된다.

실무 원칙은 다음과 같다.

 

🚦 Allow 헤더부터 본다. 405 응답에는 허용 메서드 목록이 담기므로, 내가 보낸 메서드와 비교하면 원인이 드러난다.

🔀 라우팅을 점검한다. 메서드가 맞는데도 405면 서버에 그 메서드 핸들러가 있는지, 정적 자원에 쓰기를 보냈는지 확인한다.

📋 경로 전체를 의심한다. 리다이렉트로 메서드가 바뀌었는지, 프록시·CORS 프리플라이트가 막는지까지 점검한다.

405 트러블슈팅 체크리스트

 

01응답 Allow 헤더로 허용 메서드 확인.

02보낸 메서드 vs 허용 목록 비교, 틀리면 호출 수정.

03맞는데도 405면 서버 라우트·핸들러 존재 확인.

04정적 자원에 쓰기 메서드 보냈는지 점검(웹서버 기본 거부).

05리다이렉트 메서드 변질·307·308 필요 여부 확인.

06프록시·게이트웨이·CORS 프리플라이트 메서드 정책 점검.

---

본 글은 HTTP 405 응답의 일반적 원인과 해결 방법을 정리한 자료다. 서버·라우팅 설정 변경은 영향 범위를 확인한 뒤 신중히 적용한다.

 

#HTTP405 #MethodNotAllowed #405에러 #Allow헤더 #HTTP메서드 #REST #API에러 #라우팅 #Nginx #Apache #POST #PUT #DELETE #웹개발 #백엔드