405 Method Not Allowed 오류 원인과 해결 방법

405 Method Not Allowed 오류란?

405 Method Not Allowed는 서버가 요청한 주소는 알고 있지만, 요청에 사용된 메서드를 허용하지 않는다는 뜻의 HTTP 상태 코드입니다. RFC 9110(15.5.6절)은 이를 해당 메서드가 "known by the origin server but not supported by the target resource", 즉 원본 서버는 알고 있지만 대상 리소스가 지원하지 않는 경우로 정의합니다.

모든 HTTP 요청에는 메서드가 있습니다. 페이지를 읽는 GET, 폼을 제출하거나 무언가를 생성하는 POST, 수정하는 PUT과 PATCH, 삭제하는 DELETE, 허용되는 것을 묻는 OPTIONS입니다. 405는 URL은 존재하지만 그 동작(메서드)으로는 쓸 수 없다는 뜻입니다. URL 자체가 없다면 대신 404가 반환됩니다.

없는 페이지가 아니라 요청 방식의 문제이므로, 405는 거의 항상 사이트 개발자가 해결해야 합니다. 방문자는 보통 폼을 제출한 뒤나 오래된 링크를 따라갔을 때 이 오류를 만납니다.

405 오류가 표시되는 방식

1단계: Allow 헤더 확인하기

해당 URL에서 어떤 메서드를 허용하는지 서버에 물어보세요. OPTIONS 요청을 보내거나, 실패한 요청을 헤더가 보이도록 다시 보내면 됩니다:

# 이 URL이 허용하는 메서드는?
curl -i -X OPTIONS https://example.com/api/contact

# 실패한 요청을 다시 보내 상태 코드와 Allow 헤더 확인
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

DNS Robot의 HTTP 헤더 확인 도구는 일반 GET 요청에 대해 URL이 반환하는 상태 코드와 헤더를 보여 주므로, API가 아니라 브라우저로 여는 페이지를 점검할 때 유용합니다.

모든 서버가 이 규칙을 지키는 것은 아닙니다. 예를 들어 nginx의 기본 405 페이지는 Allow 헤더 없이 전송되므로, nginx에서는 대신 어떤 location 블록이 해당 URL을 처리하는지 확인해야 합니다(해결 방법 2).

방문자라면 이렇게 해 보세요

• 뒤로 가서 페이지를 새로고침한 다음 폼을 다시 제출하세요. 오래된 캐시에서 불러온 폼은 그사이 바뀐 주소로 POST를 보낼 수 있습니다.

• 제출 후에 새로고침하지 마세요. 폼 제출 결과 페이지를 새로고침하면 GET만 허용하는 URL로 POST가 다시 전송될 수 있습니다.

• 주소에 오타가 없는지 확인하거나, 사이트 홈페이지를 열고 다시 찾아 들어가세요.

• 문제를 알리세요. 사이트의 폼이 항상 실패한다면 사이트 운영자가 고쳐야 하므로, 해당 페이지 주소를 운영자에게 보내 주세요.

해결 방법 1: 올바른 URL에 올바른 메서드 보내기

코드에서 가장 흔한 원인은 단순한 불일치입니다. 엔드포인트는 GET만 허용하는데 폼이나 fetch() 호출이 POST를 쓰거나, 요청이 API URL이 아니라 페이지 URL로 가는 경우입니다. 코드의 메서드를 Allow 헤더 및 API 문서와 비교해 보세요.

// 이 엔드포인트는 POST만 허용하므로 GET(fetch의 기본값)을 보내면 405가 반환됩니다
const res = await fetch("/api/contact", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({ name: "Ana" }),
})
if (res.status === 405) console.log("Allowed:", res.headers.get("allow"))

해결 방법 2: nginx가 정적 파일로 보낸 POST에 405를 반환하는 경우

nginx의 정적 파일 핸들러는 GET과 HEAD만 처리합니다. .html 파일로 보낸 POST나, 요청을 애플리케이션에 넘기지 않고 파일을 제공하는 location으로 보낸 POST는 405 Not Allowed를 받습니다. 폼의 action이 정적 페이지를 가리키거나, 앱용 location 블록이 일치하지 않을 때 자주 발생합니다.

근본적인 해결책은 올바른 location 블록에서 proxy_pass나 fastcgi_pass로 POST를 애플리케이션(PHP, Node, Python)에 보내는 것입니다. 어떤 블록이 해당 URL을 처리하는지 확인하세요:

# 폼 POST는 정적 파일 핸들러가 아니라 앱으로 전달되어야 합니다
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# 변경 후 설정을 테스트하고 다시 로드하세요
# sudo nginx -t && sudo systemctl reload nginx

해결 방법 3: IIS가 PUT과 DELETE를 차단하는 경우(WebDAV)

IIS를 실행하는 Windows 서버에서는 WebDAV 모듈이 PUT과 DELETE 동사를 가로채므로, REST API(ASP.NET Web API 등)가 이 메서드에 HTTP Error 405.0으로 응답합니다. WebDAV를 쓰지 않는다면 web.config에서 사이트의 WebDAV를 제거하세요:

<system.webServer>
  <modules>
    <remove name="WebDAVModule" />
  </modules>
  <handlers>
    <remove name="WebDAV" />
  </handlers>
</system.webServer>

IIS 관리자에서 사이트의 요청 필터링(Request Filtering) 설정, 그중 HTTP 동사(HTTP Verbs) 탭도 확인하세요. 여기서 특정 메서드를 아예 거부할 수 있습니다(이 경우 IIS는 405가 아니라 404.6을 반환합니다).

해결 방법 4: 라우트 핸들러에 메서드 추가하기

프레임워크는 라우트는 있지만 사용된 메서드에 대한 핸들러가 없을 때 405를 반환합니다:

• Next.js(App Router): route.ts는 내보낸(export) 메서드에만 응답합니다. GET은 내보내고 POST는 내보내지 않았다면 POST 요청은 405를 받습니다. export async function POST(request: Request) { … }를 추가하세요.

• Flask: 라우트는 기본적으로 GET만 허용합니다. @app.route("/contact", methods=["GET", "POST"])를 사용하세요.

• Django: 클래스 기반 뷰는 일치하는 핸들러가 없는 메서드에 405를 반환하며(post() 메서드를 추가하세요), require_http_methods 데코레이터도 같은 방식으로 작동합니다.

• Express: 기본적으로 일치하지 않는 메서드는 405가 아니라 404로 넘어갑니다. API가 405를 반환해야 한다면 Allow 헤더를 설정하는 catch-all 핸들러를 추가하세요.

해결 방법 5: CORS 프리플라이트(OPTIONS) 요청 처리하기

웹 페이지가 JSON이나 사용자 지정 헤더로 다른 도메인의 API를 호출하면, 브라우저는 먼저 OPTIONS 프리플라이트 요청을 보냅니다. API가 이 OPTIONS 요청에 405로 응답하면 브라우저는 CORS 오류를 표시하고 실제 요청은 보내지 않습니다. 실제 엔드포인트는 정상적으로 작동했을 텐데도 말입니다.

해당 라우트에서 API가 OPTIONS에 204나 200으로 응답하고, 올바른 Access-Control-Allow-Methods와 Access-Control-Allow-Headers 헤더를 보내도록 하세요. 대부분의 프레임워크에는 이를 대신 처리하는 CORS 미들웨어가 있습니다. 예를 들어 DNS Robot의 DNS 조회 API는 프리플라이트에 204와 CORS 헤더로 응답하므로 어느 사이트에서든 브라우저로 호출할 수 있습니다.

405와 400, 403, 404, 501 비교

관련 가이드: 400 Bad Request, 403 Forbidden, 401 Unauthorized.