Błąd 405 Method Not Allowed: co oznacza i jak naprawić

Czym jest błąd 405 Method Not Allowed?

405 Method Not Allowed to kod statusu HTTP oznaczający, że serwer zna adres, o który prosisz, ale nie dopuszcza metody użytej w żądaniu. RFC 9110 (sekcja 15.5.6) definiuje go jako metodę znaną serwerowi źródłowemu, ale nieobsługiwaną przez docelowy zasób („known by the origin server but not supported by the target resource”).

Każde żądanie HTTP ma metodę: GET, by odczytać stronę, POST, by wysłać formularz lub coś utworzyć, PUT i PATCH, by zaktualizować, DELETE, by usunąć, oraz OPTIONS, by zapytać, co jest dozwolone. Błąd 405 oznacza, że adres URL istnieje, ale nie dla tej metody. Gdyby adres w ogóle nie istniał, dostałbyś błąd 404.

Ponieważ chodzi o to, jak wysłano żądanie, a nie o brakującą stronę, błąd 405 prawie zawsze musi naprawić programista strony. Odwiedzający trafiają na niego zwykle po wysłaniu formularza albo po kliknięciu nieaktualnego linku.

Jak wygląda błąd 405

Krok 1: Odczytaj nagłówek Allow

Zapytaj serwer, jakie metody akceptuje dla danego adresu URL. Wyślij żądanie OPTIONS albo powtórz nieudane żądanie z widocznymi nagłówkami:

# Jakie metody akceptuje ten adres URL?
curl -i -X OPTIONS https://example.com/api/contact

# Powtórz nieudane żądanie i sprawdź status oraz nagłówek Allow
curl -i -X POST https://example.com/api/contact -d 'name=test'
# HTTP/2 405
# allow: GET, HEAD

Narzędzie HTTP Headers od DNS Robot pokazuje kod statusu i nagłówki, które adres URL zwraca na zwykłe żądanie GET. Przydaje się, gdy sprawdzasz stronę w przeglądarce, a nie API.

Nie każdy serwer przestrzega tej zasady. Na przykład wbudowana strona 405 w nginx jest wysyłana bez nagłówka Allow, więc w nginx trzeba zamiast tego sprawdzić, który blok location obsługuje dany adres URL (rozwiązanie 2).

Jeśli jesteś odwiedzającym

• Wróć i odśwież stronę, a potem wyślij formularz ponownie. Formularz wczytany ze starej kopii w pamięci podręcznej może wysyłać dane pod adres, który się od tego czasu zmienił.

• Nie odświeżaj strony po wysłaniu formularza. Odświeżenie strony będącej wynikiem formularza może ponownie wysłać POST pod adres, który akceptuje tylko GET.

• Sprawdź adres pod kątem literówki albo otwórz stronę główną witryny i przejdź do celu jeszcze raz.

• Zgłoś problem. Jeśli formularz na stronie zawsze zawodzi, naprawić go musi właściciel strony, więc wyślij mu adres tej podstrony.

Rozwiązanie 1: Wyślij właściwą metodę pod właściwy adres URL

Najczęstszą przyczyną w kodzie jest zwykłe niedopasowanie: formularz lub wywołanie fetch() używa POST, a endpoint akceptuje tylko GET, albo żądanie trafia na adres strony zamiast na adres API. Porównaj metodę w kodzie z nagłówkiem Allow i dokumentacją API.

// Endpoint dopuszcza tylko POST, więc GET (domyślna metoda fetch) zwraca 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"))

Rozwiązanie 2: nginx zwraca 405 dla POST do plików statycznych

Moduł plików statycznych w nginx obsługuje tylko GET i HEAD. POST do pliku .html albo do bloku location, który serwuje pliki zamiast przekazywać żądanie do aplikacji, dostaje 405 Not Allowed. Często dzieje się tak, gdy atrybut action formularza wskazuje stronę statyczną albo gdy blok location przeznaczony dla aplikacji nie pasuje do adresu.

Właściwym rozwiązaniem jest skierowanie POST do aplikacji (PHP, Node, Python) przez proxy_pass lub fastcgi_pass we właściwym bloku location. Sprawdź, który blok obsługuje dany adres URL:

# Dane z formularzy muszą trafić do aplikacji, a nie do obsługi plików statycznych
location /api/ {
    proxy_pass http://127.0.0.1:3000;
}

# Po zmianach przetestuj konfigurację i przeładuj nginx
# sudo nginx -t && sudo systemctl reload nginx

Rozwiązanie 3: IIS blokuje PUT i DELETE (WebDAV)

Na serwerach Windows z IIS moduł WebDAV przejmuje metody PUT i DELETE, więc API typu REST (ASP.NET Web API i inne) odpowiadają na nie błędem HTTP Error 405.0. Jeśli nie korzystasz z WebDAV, usuń go dla swojej witryny w web.config:

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

Sprawdź też ustawienia Filtrowanie żądań (Request Filtering) witryny w Menedżerze IIS (karta HTTP Verbs), które mogą wprost blokować określone metody (IIS zgłasza je jako 404.6, a nie 405).

Rozwiązanie 4: Dodaj metodę do handlera trasy

Frameworki zwracają 405, gdy trasa istnieje, ale nie ma handlera dla użytej metody:

• Next.js (App Router): plik route.ts odpowiada tylko na metody, które eksportuje. Jeśli eksportuje GET, ale nie POST, żądanie POST zwraca 405. Dodaj export async function POST(request: Request) { … }.

• Flask: trasy domyślnie akceptują tylko GET. Użyj @app.route("/contact", methods=["GET", "POST"]).

• Django: widoki oparte na klasach zwracają 405 dla metod bez pasującego handlera (dodaj metodę post()), a dekorator require_http_methods działa tak samo.

• Express: domyślnie niedopasowana metoda kończy się błędem 404, a nie 405. Jeśli Twoje API ma zwracać 405, dodaj handler typu catch-all, który ustawia nagłówek Allow.

Rozwiązanie 5: Obsłuż żądania preflight CORS (OPTIONS)

Gdy strona internetowa wywołuje API w innej domenie z danymi JSON lub własnymi nagłówkami, przeglądarka najpierw wysyła żądanie OPTIONS preflight. Jeśli API odpowie na to żądanie OPTIONS kodem 405, przeglądarka zgłosi błąd CORS i nigdy nie wyśle właściwego żądania, mimo że właściwy endpoint by zadziałał.

Skonfiguruj API tak, by odpowiadało na OPTIONS dla tych tras kodem 204 lub 200 z właściwymi nagłówkami Access-Control-Allow-Methods i Access-Control-Allow-Headers. Większość frameworków ma middleware CORS, które robi to za Ciebie. Na przykład własne DNS Lookup API od DNS Robot odpowiada na preflight kodem 204 z nagłówkami CORS, więc przeglądarki mogą je wywoływać z dowolnej strony.

405 a 400, 403, 404 i 501

Powiązane poradniki: 400 Bad Request, 403 Forbidden i 401 Unauthorized.