Błąd http 405 zwykle nie oznacza awarii domeny, tylko konflikt między metodą HTTP a tym, co dany zasób ma prawo przyjąć. W praktyce problem pojawia się najczęściej przy formularzach, panelach administracyjnych, API albo po migracji strony na nowy hosting. Poniżej rozpisuję, jak odczytać ten status, gdzie szukać przyczyny i co naprawić, żeby nie wracał.
Najważniejsze fakty o kodzie 405
- 405 Method Not Allowed oznacza, że serwer zna adres zasobu, ale nie akceptuje użytej metody, na przykład `POST`, `PUT` albo `DELETE`.
- Problem najczęściej leży w trasie aplikacji, formularzu, API, regule serwera lub pośredniku takim jak CDN czy WAF, a nie w samej nazwie domeny.
- W odpowiedzi serwer powinien podać nagłówek `Allow` z listą dozwolonych metod.
- Po zmianie domeny, hostingu lub konfiguracji przekierowań 405 często wychodzi na jaw dopiero wtedy, gdy ruch zaczyna iść nową ścieżką.
- Ten kod łatwo pomylić z 404, 403 i 500, ale każdy z nich oznacza inny typ problemu i wymaga innej naprawy.
Co naprawdę oznacza kod 405
405 Method Not Allowed mówi wprost: serwer rozpoznaje zasób, ale nie zgadza się na metodę używaną w żądaniu. To ważna różnica wobec 404, bo adres może być poprawny, a problem leży wyłącznie w sposobie komunikacji. Jeśli strona działa dla `GET`, ale odrzuca `POST`, `PUT` lub `DELETE`, widzisz właśnie ten scenariusz.
Jak opisuje MDN, odpowiedź 405 powinna zawierać nagłówek `Allow`, który wskazuje dozwolone metody. RFC 9110 traktuje to podobnie i wymaga, by serwer jasno podał, co wolno wykonać na danym zasobie. Jeśli tego nagłówka brakuje, diagnoza zwykle staje się mniej precyzyjna, a ja od razu sprawdzam wtedy warstwę proxy albo reguły aplikacji.
W praktyce najczęściej chodzi o prosty rozjazd: formularz wysyła `POST`, a endpoint przyjmuje tylko `GET`; frontend próbuje wykonać `DELETE`, ale backend nie ma takiej trasy; albo zabezpieczenie blokuje `OPTIONS`, przez co sypie się preflight CORS. To nie są egzotyczne przypadki, tylko codzienność przy dynamicznych serwisach. Kiedy rozumiesz sam mechanizm, łatwiej odróżnić błąd aplikacji od problemu wynikającego z konfiguracji domeny czy serwera.
Dlaczego pojawia się na stronie pod własną domeną
Domena sama w sobie nie generuje 405. DNS wskazuje tylko, gdzie serwer ma odbierać ruch, a błąd powstaje dopiero później, gdy żądanie trafia do konkretnego zasobu. Z mojego doświadczenia najwięcej zamieszania robią migracje: adres się zmienia, routing zostaje stary, a metoda HTTP już nie pasuje do nowej konfiguracji.
Cloudflare zwraca uwagę, że 405 zwykle pochodzi z serwera źródłowego, a nie jest tworzony przez sam CDN. To dobra wskazówka diagnostyczna, bo jeśli błąd widać tylko na publicznej domenie, a znika przy bezpośrednim dostępie do originu, winna bywa warstwa pośrednia albo reguły bezpieczeństwa.
| Sytuacja | Co zwykle widać | Najczęstsza przyczyna |
|---|---|---|
| Formularz kontaktowy | Wysyłka kończy się 405 | Backend nie obsługuje `POST` albo endpoint ma złą trasę |
| Panel lub API | Błąd po `PUT`, `PATCH` lub `DELETE` | Brak reguły dla tej metody |
| Po zmianie domeny | Część linków działa, część nie | Stare przekierowania lub reguły rewrite prowadzą do złej ścieżki |
| Za CDN lub WAF | Na bezpośrednim adresie działa, przez domenę publiczną nie | Pośrednik przepuszcza ruch, ale origin odrzuca metodę albo filtr ją blokuje |
Warto rozdzielać te warstwy, bo naprawa DNS nie pomoże, jeśli problem siedzi w kontrolerze albo w regule bezpieczeństwa. Najpierw ustalam, gdzie request ginie, a dopiero potem zmieniam konfigurację. Gdy to jest jasne, diagnostyka staje się znacznie krótsza.
Jak zdiagnozować problem krok po kroku
Najkrótsza droga do rozwiązania to sprawdzenie, jaka metoda naprawdę wychodzi z przeglądarki i co wraca w odpowiedzi. W praktyce robię to w tej kolejności:
- Otwieram narzędzia deweloperskie i sprawdzam zakładkę Network, żeby zobaczyć, czy idzie `GET`, `POST`, `PUT` albo `DELETE`.
- Patrzę w odpowiedź i szukam nagłówka `Allow`. Jeśli jest pusty lub nie zgadza się z oczekiwaniem, to ważny trop.
- Porównuję adresy `www` i bez `www`, `http` i `https`, a także wersję z ukośnikiem i bez niego. Takie różnice potrafią prowadzić do innej trasy w aplikacji.
- Testuję ten sam zasób z `curl`, bo łatwiej wtedy oddzielić problem przeglądarki od problemu serwera.
curl -i -X POST https://twojadomena.pl/formularz
curl -i https://twojadomena.pl/formularzJeśli pierwsze wywołanie kończy się 405, a drugie działa, źródło problemu jest praktycznie potwierdzone. Jeśli oba warianty failują tylko po przejściu przez CDN albo reverse proxy, sprawdzam pośrednika, nie samą aplikację. Na końcu zaglądam do logów serwera i aplikacji, bo to najszybciej pokazuje, czy blokada pochodzi z routingu, uprawnień, wtyczki bezpieczeństwa czy reguły typu rewrite.
Kiedy problem jest już zlokalizowany, można go poprawić na konkretnej warstwie zamiast zgadywać.
Jak naprawić błąd po stronie domeny, serwera i aplikacji
Naprawa 405 zależy od tego, gdzie dokładnie powstał rozjazd. Domena zwykle nie wymaga żadnej zmiany, ale serwer, aplikacja albo pośrednik już tak. Poniżej zestawiam najczęstsze korekty, które faktycznie mają sens.
| Warstwa | Co zmienić | Kiedy to ma sens |
|---|---|---|
| Formularz lub frontend | Ustawić właściwą metodę żądania i endpoint | Gdy interfejs wysyła `POST`, `PUT` albo `DELETE` do niewłaściwej trasy |
| Backend lub API | Dodać obsługę brakującej metody albo ograniczyć klienta do obsługiwanych metod | Gdy jedna ścieżka odpowiada tylko na część żądań |
| Serwer www | Skorygować reguły `rewrite`, konfigurację hosta i listę dozwolonych metod | Po migracji, zmianie hostingu lub wdrożeniu nowego środowiska |
| CDN, WAF, reverse proxy | Przepuścić wymagane metody i wyczyścić cache | Gdy 405 pojawia się tylko na publicznym adresie domeny |
| CMS lub wtyczki | Wyłączyć problematyczny plugin albo zaktualizować jego reguły | Gdy błąd zaczął się po instalacji dodatku bezpieczeństwa lub formularza |
Jest jeszcze jedna pułapka, o której często się zapomina: przekierowania 301 i 302 nie zawsze zachowują metodę żądania tak, jak oczekuje aplikacja. Przy formularzach i API bezpieczniej działają 307 i 308, bo przenoszą metodę bez jej zmiany. To drobny detal, ale po migracji domeny potrafi uratować wiele godzin debugowania.
Jeśli problem dotyczy frontendu i API, nie ignoruję też `OPTIONS`. Preflight CORS może zostać odrzucony jako 405, zanim do serwera trafi właściwy `POST` albo `DELETE`. Wtedy strona wygląda tak, jakby nagle przestała działać, choć kłopot siedzi tylko w jednym dodatkowym żądaniu kontrolnym.
Żeby nie pomylić kierunku naprawy, dobrze jest jeszcze odróżnić 405 od kodów, które wyglądają podobnie, ale znaczą coś innego.
Czym 405 różni się od 404, 403 i 500
Te błędy są mylone częściej, niż powinny. A to właśnie przez to wiele osób zaczyna naprawę od złej strony i traci czas na obszar, który w ogóle nie jest uszkodzony.
| Kod | Co oznacza | Gdzie zwykle leży problem | Co sprawdzić najpierw |
|---|---|---|---|
| 404 | Zasób nie został znaleziony | URL, trasa, plik albo routing | Czy adres jest poprawny i czy zasób istnieje |
| 403 | Dostęp jest zabroniony | Uprawnienia, autoryzacja, reguły bezpieczeństwa | Czy użytkownik ma prawo wejść na zasób |
| 405 | Metoda nie jest dozwolona | Routing, formularz, API, serwer, proxy | Czy użyto właściwego `GET`, `POST`, `PUT`, `DELETE` lub `OPTIONS` |
| 500 | Wewnętrzny błąd serwera | Kod aplikacji, wyjątek, konfiguracja środowiska | Logi i stack trace |
Jeśli po zmianie metody błąd znika, to był 405, nie 404. Jeśli po zalogowaniu wszystko działa, a bez logowania nie, problem częściej przypomina 403. Ten prosty filtr oszczędza sporo czasu, zwłaszcza przy większych serwisach z wieloma podstronami i różnymi rolami użytkowników.
Na końcu warto jeszcze sprawdzić jeden scenariusz, który potrafi ukryć przyczynę lepiej niż sam serwer.
Co jeszcze sprawdzić po migracji domeny i zmianie infrastruktury
Po zmianie domeny, hostingu lub architektury problem bywa ukryty, a nie rozwiązany. Stare reguły przekierowań, cache na CDN, inny virtual host dla `www` i bez `www` albo zmieniony filtr bezpieczeństwa potrafią wywołać 405 tylko w jednym wariancie adresu. To właśnie wtedy przydaje się sprawdzenie całego łańcucha: od przeglądarki, przez proxy, aż po origin.
- Sprawdź, czy oba warianty domeny trafiają do tego samego backendu.
- Porównaj zachowanie po wyłączeniu cache na CDN i w przeglądarce.
- Zweryfikuj, czy przekierowania nie zmieniają metody żądania.
- Upewnij się, że ścieżki w aplikacji i na serwerze są identyczne po wdrożeniu.
- Jeśli błąd dotyczy tylko jednego subdomenowego adresu, sprawdź osobno jego konfigurację hosta.
W praktyce najskuteczniejsze podejście do 405 pozostaje zaskakująco proste: sprawdzić metodę, nagłówek `Allow`, logi i pośredników. Gdy te elementy są spójne, błąd zwykle znika. Jeśli nie znika, winny jest zazwyczaj konkretny endpoint albo reguła, a nie sama domena.
