Erro 405 Method Not Allowed: o que é e como resolver

O que é o erro 405 Method Not Allowed?

O 405 Method Not Allowed (método não permitido) é um código de status HTTP que significa que o servidor conhece o endereço que você pediu, mas não permite o método que a sua requisição usou. A RFC 9110 (seção 15.5.6) o define como um método "known by the origin server but not supported by the target resource", ou seja, conhecido pelo servidor de origem, mas não suportado pelo recurso de destino.

Toda requisição HTTP tem um método: GET para ler uma página, POST para enviar um formulário ou criar algo, PUT e PATCH para atualizar, DELETE para remover, OPTIONS para perguntar o que é permitido. Um 405 significa que a URL existe, mas não para aquele verbo. Se a URL nem existisse, você receberia um 404.

Como o problema está na forma como a requisição foi feita, e não em uma página que falta, um 405 quase sempre precisa ser resolvido pelo desenvolvedor do site. Os visitantes normalmente esbarram nele depois de enviar um formulário ou de seguir um link desatualizado.

Como o erro 405 aparece

Passo 1: leia o cabeçalho Allow

Pergunte ao servidor quais métodos ele aceita para aquela URL. Envie uma requisição OPTIONS ou repita a requisição que falha mostrando os cabeçalhos:

# Quais métodos esta URL aceita?
curl -i -X OPTIONS https://example.com/api/contact

# Repita a requisição que falha e veja o status e o cabeçalho Allow
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

O Verificador de Cabeçalhos HTTP do DNS Robot mostra o código de status e os cabeçalhos que uma URL retorna para uma requisição GET normal, o que ajuda quando você está verificando uma página no navegador, e não uma API.

Nem todo servidor segue a regra. A página 405 nativa do nginx, por exemplo, é enviada sem cabeçalho Allow, então no nginx você vai precisar verificar qual bloco location trata a URL (correção 2).

Se você é um visitante

• Volte e recarregue a página e depois envie o formulário de novo. Um formulário carregado de uma cópia antiga em cache pode enviar os dados para um endereço que já mudou.

• Não atualize a página depois de enviar. Atualizar uma página que foi o resultado de um formulário pode reenviar um POST para uma URL que só aceita GET.

• Confira o endereço em busca de erros de digitação, ou abra a página inicial do site e navegue de novo.

• Avise o site. Se um formulário do site sempre falha, quem precisa resolver é o dono do site, então envie o endereço da página para ele.

Correção 1: envie o método certo para a URL certa

A causa mais comum no código é simplesmente uma incompatibilidade: um formulário ou uma chamada fetch() usa POST enquanto o endpoint só aceita GET, ou a requisição vai para a URL da página em vez da URL da API. Compare o método no seu código com o cabeçalho Allow e com a documentação da API.

// O endpoint só permite POST, então um GET (o padrão do fetch) retorna 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"))

Correção 2: o nginx retorna 405 para POST em arquivos estáticos

O handler de arquivos estáticos do nginx só atende GET e HEAD. Um POST para um arquivo .html, ou para um location que serve arquivos em vez de repassar a requisição para a sua aplicação, recebe 405 Not Allowed. Isso costuma acontecer quando o action de um formulário aponta para uma página estática, ou quando um bloco location feito para o seu app não corresponde à URL.

A correção de verdade é enviar o POST para uma aplicação (PHP, Node, Python) com proxy_pass ou fastcgi_pass no bloco location certo. Verifique qual bloco trata a URL:

# Os POSTs de formulários precisam chegar ao app, não ao handler de arquivos estáticos
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Teste e recarregue depois das alterações
# sudo nginx -t && sudo systemctl reload nginx

Correção 3: o IIS bloqueia PUT e DELETE (WebDAV)

Em servidores Windows com IIS, o módulo WebDAV assume os verbos PUT e DELETE, então as APIs REST (ASP.NET Web API e outras) respondem HTTP Error 405.0 para eles. Se você não usa WebDAV, remova-o do seu site no web.config:

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

Verifique também as configurações de Filtragem de Solicitações (Request Filtering) do site no Gerenciador do IIS (aba Verbos HTTP), que podem negar métodos específicos de cara (o IIS informa esses casos como 404.6, não como 405).

Correção 4: adicione o método ao seu route handler

Os frameworks retornam 405 quando uma rota existe, mas não tem handler para o método usado:

• Next.js (App Router): um route.ts só responde aos métodos que exporta. Se ele exporta GET mas não POST, um POST retorna 405. Adicione export async function POST(request: Request) { … }.

• Flask: as rotas aceitam só GET por padrão. Use @app.route("/contact", methods=["GET", "POST"]).

• Django: as class-based views retornam 405 para métodos sem um handler correspondente (adicione um método post()), e o decorator require_http_methods faz o mesmo.

• Express: por padrão, um método sem rota correspondente cai no 404, não no 405. Se a sua API deve retornar 405, adicione um handler genérico que defina o cabeçalho Allow.

Correção 5: trate as requisições de preflight do CORS (OPTIONS)

Quando uma página web chama uma API em outro domínio com JSON ou cabeçalhos personalizados, o navegador primeiro envia uma requisição de preflight OPTIONS. Se a API responde a esse OPTIONS com 405, o navegador mostra um erro de CORS e nunca envia a requisição real, mesmo que o endpoint real fosse funcionar.

Faça a API responder ao OPTIONS dessas rotas com 204 ou 200 e os cabeçalhos Access-Control-Allow-Methods e Access-Control-Allow-Headers corretos. A maioria dos frameworks tem um middleware de CORS que faz isso por você. Por exemplo, a própria API de Consulta DNS do DNS Robot responde ao preflight com 204 e os cabeçalhos de CORS, para que os navegadores possam chamá-la a partir de qualquer site.

405 vs. 400, 403, 404 e 501

Guias relacionados: 400 Bad Request, 403 Forbidden e 401 Unauthorized.