Ошибка 405 Method Not Allowed означает, что сервер распознал HTTP-метод запроса, но не разрешает применять его к выбранному адресу. Например, страница открывается через GET, а отправка формы методом POST заканчивается ошибкой. Поэтому простой совет «перезагрузить сайт» редко помогает: нужно выяснить, какой метод отправляет клиент и на каком уровне его отклоняют.
Ниже — безопасный порядок проверки для владельца сайта, разработчика или администратора. Он помогает отделить ошибку в форме от проблемы маршрута приложения, конфигурации веб-сервера, CDN или защитного фильтра.
Что означает код 405
В HTTP у запроса есть метод: GET получает ресурс, POST обычно передаёт данные, PUT и PATCH изменяют ресурс, DELETE удаляет его, а OPTIONS запрашивает поддерживаемые возможности. Код 405 появляется, когда сервер знает полученный метод, но конкретный URL его не поддерживает.
По RFC 9110 ответ 405 должен содержать заголовок Allow со списком методов, разрешённых для целевого ресурса. Например:
~~~text HTTP/1.1 405 Method Not Allowed Allow: GET, HEAD ~~~
Это полезная подсказка, но не окончательный диагноз. Заголовок может сформировать приложение, веб-сервер или промежуточный прокси, а неверная конфигурация иногда даёт неполный ответ.
Чем 405 отличается от 403, 404 и 501
- 403 Forbidden означает, что сервер понял запрос, но отказывается его выполнять из-за правил доступа или авторизации.
- 404 Not Found сообщает, что целевой ресурс не найден или скрыт от клиента.
- 405 Method Not Allowed указывает на несовпадение метода и конкретного URL.
- 501 Not Implemented означает, что сервер не реализует или не распознаёт сам метод.
Менять 405 на другой код только ради исчезновения сообщения не стоит. Правильное исправление должно восстановить ожидаемый маршрут и одновременно сохранить ограничения безопасности.
Как быстро воспроизвести ошибку
Зафиксируйте точный запрос
Откройте инструменты разработчика браузера, вкладку Network, повторите проблемное действие и выберите запрос со статусом 405. Запишите без персональных данных:
- полный URL и HTTP-метод;
- статус ответа;
- значение заголовка Allow, если оно есть;
- Content-Type запроса;
- время воспроизведения;
- действие, после которого возникла ошибка.
Не ограничивайтесь открытием того же адреса в новой вкладке. Браузер выполнит GET, а исходная форма могла отправлять POST; в результате страница откроется, хотя неисправный сценарий останется.
Сравните методы через curl
Проверять нужно тестовый адрес или безопасный запрос, который не создаёт заказ, платёж, пользователя либо другую запись. Для начала можно получить заголовки обычным GET и запросить поддерживаемые возможности:
~~~bash curl -i https://example.com/api/feedback curl -i -X OPTIONS https://example.com/api/feedback ~~~
Затем воспроизведите только тот метод и формат данных, которые ожидает приложение. Для тестового обработчика POST пример может выглядеть так:
~~~bash curl -i -X POST \ -H "Content-Type: application/json" \ --data '{"test":true}' \ https://example.com/api/feedback ~~~
Сравните статус, Allow и тело ответа. Если GET успешен, а POST стабильно возвращает 405, проблема относится к обработке метода, а не к общей доступности домена.
Определите, кто сформировал ответ
Проверьте журналы CDN или WAF, веб-сервера и приложения за один и тот же момент времени. Если запрос отсутствует в журнале приложения, его, вероятно, остановил внешний слой или reverse proxy. Если приложение видит запрос и пишет, что маршрут не найден для метода POST, проверять следует роутер и код обработчика.
Заголовок Server или оформление HTML-страницы могут подсказать источник, но полагаться только на них нельзя: прокси способен заменить заголовки и страницу ошибки.
Частые причины 405 Method Not Allowed
Форма отправляет данные не на тот маршрут
У формы мог измениться атрибут action, а метод остался POST. Например, страница формы находится по адресу /feedback, но обработчик принимает данные только по /api/feedback. Похожая ситуация возникает после изменения завершающего слеша, базового URL или правил перенаправления.
Проверьте итоговый URL в Network, а не только HTML-шаблон. Важно увидеть адрес после всех редиректов. Некоторые клиенты при перенаправлении меняют способ повторного запроса, поэтому обработчик может получить не тот метод, который ожидался изначально.
В приложении нет маршрута для нужного метода
Роутер может иметь GET-маршрут для показа страницы, но не иметь POST-маршрута для сохранения данных. После релиза это бывает, когда конфигурация маршрутов обновилась не полностью, кэш маршрутов остался старым или запрос ушёл в другую версию API.
Сверьте таблицу маршрутов приложения с фактическим URL. Затем проверьте, что обработчик развёрнут на каждом экземпляре приложения и что прокси отправляет запрос в нужный upstream.
Метод ограничен в Nginx или Apache
На уровне Nginx методы могут ограничиваться внутри location, в том числе директивой limit_except. В Apache ограничения задают конфигурация виртуального хоста, .htaccess и модули контроля методов. Проверяйте не только общий конфигурационный файл, но и правила для конкретного каталога или location: более узкий блок может изменить поведение.
Не разрешайте все методы «для проверки» на рабочем сайте. Откройте только тот метод, который нужен конкретному маршруту, и сохраните требования к авторизации, CSRF-защите и ролям пользователя.
Запрос блокирует CDN, WAF или защитный модуль
Защитный слой может разрешать GET и HEAD, но блокировать POST, PUT, PATCH, DELETE или OPTIONS. Сопоставьте время запроса с журналом правил, идентификатором события и маршрутом. Если правило сработало ошибочно, сузьте исключение до нужного адреса и условия, а не отключайте фильтр целиком.
OPTIONS не проходит при запросе из другого домена
Перед некоторыми междоменными запросами браузер выполняет предварительный запрос OPTIONS. Если он получает 405, основной POST или PATCH может вообще не отправиться. В Network это выглядит как ошибка OPTIONS рядом с сообщением CORS в консоли.
Исправление должно быть согласовано с политикой доступа приложения: разрешите OPTIONS на нужном маршруте и возвращайте только необходимые CORS-заголовки для доверенных источников. Значение «разрешить всё» без проверки происхождения может создать новую уязвимость.
POST отправляется на статический файл или каталог
Статический обработчик обычно предназначен для получения файлов. Если из-за неверного rewrite запрос POST попал на HTML-файл, изображение или каталог, сервер может ответить 405. Проверьте порядок location и rewrite, итоговый путь, а также fallback на front controller приложения.
Практический пример: форма работает как страница, но не отправляется
Представим форму обратной связи. Адрес /feedback открывается, поля заполняются, но после нажатия кнопки появляется 405.
Порядок диагностики:
- В Network видно, что браузер отправляет POST на /feedback.
- GET /feedback возвращает страницу, а в Allow указаны GET и HEAD.
- В маршрутах приложения POST-обработчик зарегистрирован по /api/feedback.
- В action формы по ошибке указан адрес страницы вместо адреса обработчика.
- После исправления action тестовая отправка возвращает ожидаемый ответ, а приложение записывает запрос в журнал.
В другом проекте HTML может быть правильным, но reverse proxy направляет /api/feedback в location со статическими файлами. Симптом похож, а исправление находится уже в конфигурации сервера. Именно поэтому важно идти по цепочке запроса, а не сразу переписывать форму.
Как исправлять 405 безопасно
Используйте короткий план:
- Подтвердите URL, метод и формат тела запроса.
- Проверьте Allow и определите слой, который вернул ответ.
- Сверьте маршрут приложения и правила proxy/rewrite.
- Проверьте ограничения Nginx, Apache, CDN и WAF.
- Внесите минимальное изменение для одного маршрута.
- Повторите позитивный и негативный тест.
- Проверьте журналы и соседние сценарии после релиза.
Позитивный тест подтверждает, что разрешённый метод работает. Негативный тест нужен, чтобы убедиться: ненужные методы всё ещё запрещены, запрос без авторизации не выполняется, а защита от подделки запросов не исчезла.
Если ошибка появилась после релиза, сравните конфигурацию и таблицу маршрутов до и после изменения. При нескольких серверах проверьте каждый экземпляр: часть трафика может попадать на узел со старой версией.
Как заметить повторение проблемы
Обычная проверка главной страницы методом GET может оставаться успешной, даже когда POST-форма или API возвращают 405. Поэтому контроль должен соответствовать критичному пользовательскому сценарию: кроме доступности сайта проверяйте безопасный endpoint приложения и отслеживайте всплески 405 в серверных журналах.
Web-Puls можно использовать для регулярной проверки общей доступности сайта и уведомлений о недоступности. Такой мониторинг не заменяет функциональный тест формы, но помогает отделить общий сбой сайта от ошибки отдельного маршрута. После релиза полезно сочетать внешний контроль доступности с проверкой формы, API и журналов приложения.
Когда нужна профессиональная диагностика
Передавайте задачу специалисту, если непонятно, какой слой возвращает 405, конфигурация распределена между CDN, reverse proxy и приложением или изменение метода затрагивает авторизацию и безопасность. Для разбора подготовьте URL, метод, время запроса, обезличенные заголовки ответа и фрагменты журналов без токенов и персональных данных.
Отправить описание можно через форму профессиональной поддержки или воспользоваться контактной информацией. Полезный результат диагностики — не просто исчезновение кода 405, а понятная причина, минимальное исправление и проверка, что лишние методы по-прежнему закрыты.
Вывод
Ошибка 405 говорит не о полном падении сайта, а о том, что конкретный URL не принимает использованный HTTP-метод. Начните с точного запроса в Network, проверьте Allow, затем последовательно пройдите приложение, веб-сервер, прокси и защитные правила. Исправляйте только нужный маршрут и обязательно повторяйте негативные проверки. Так можно восстановить форму или API, не ослабив защиту сайта.