Ошибка 405 значит, что адрес существует, но обратились к нему не тем способом. Самый частый случай — форма заявки отправляет данные на страницу, которая принимать их не умеет. Посетитель видит ошибку, если повезёт. Если не повезёт — видит «Спасибо», а заявка пропадает.
Что говорит стандарт
В RFC 9110 код описан так:
The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource.
Метод — это глагол запроса. GET — «дай страницу», POST — «прими
данные». Сервер знает оба, но конкретный адрес поддерживает не все.
Там же обязательное условие: сервер «MUST generate an Allow header
field» — должен перечислить в заголовке Allow, какие методы адрес
принимает.
Чем 405 отличается от соседних кодов
| Код | Что значит | Пример |
|---|---|---|
| 404 | адреса нет | опечатка в ссылке |
| 405 | адрес есть, метод не тот | POST на обычную страницу |
| 403 | адрес есть, но вам нельзя | закрытая папка |
| 400 | запрос испорчен | слишком большие куки |
Про 400 и испорченные запросы — в статье ошибка 400.
Наш замер: заявка на главную страницу
Самая частая ошибка формы — адрес отправки указывает на главную или на саму страницу с формой. Мы повторили её: 25 сентября 2026 года отправили одну пробную заявку методом POST на главные страницы 300 случайных сайтов организаций Екатеринбурга из OpenStreetMap. Все они на обычный запрос отвечают кодом 200.
| Ответ на заявку | Сайтов |
|---|---|
| 200 — страница, будто всё в порядке | 198 |
| 404 — «страницы нет» | 61 |
| 405 — метод не разрешён | 17 |
| 400 — запрос испорчен | 13 |
| прочее и нет ответа | 11 |
Честный 405 вернули только 17 сайтов. Девять из них — стандартная
страница nginx «405 Not Allowed». И из этих 17 обязательный заголовок
Allow отправили только четыре.
Главное в таблице — первая строка. Две трети сайтов на заявку «не туда» ответили кодом 200. Это худший вариант: ошибки нет, страница открылась, а приняли ли данные — снаружи не видно.
Проверка на стенде: как 405 теряет заявки молча
Мы собрали страницу с тремя вариантами отправки. Все шлют телефон на адрес, который отвечает 405 — как статический сервер без обработчика. Различаются только скрипты:
| Форма | Как устроена | Что увидел посетитель |
|---|---|---|
| А | скрипт отправляет и сразу пишет «спасибо» | «Спасибо, заявка принята» |
| Б | скрипт проверяет ответ сервера | «Не отправилось: 405» |
| В | обычная отправка без скрипта | страница «405 Not Allowed» |
В журнале сервера все три заявки легли одинаково: POST / 405. Сервер
отказал трижды. Но посетитель формы А уверен, что его заявку приняли, и
ждёт звонка.
Скрипт вида «отправил — показал спасибо» встречается часто: fetch
считает ответ 405 успешным завершением запроса, ошибкой для него будет
только обрыв сети. Проверять код ответа — забота того, кто писал скрипт.
Откуда берётся 405 на форме
- Переезд сайта. Сайт перенесли со старой системы на статический хостинг или новый конструктор, а формы оставили с прежним адресом отправки. Обработчика там больше нет.
- Адрес отправки не заполнен. Форма без
actionотправляет данные на ту же страницу. Если страница — просто файл, сервер ответит 405, а у многих сайтов из замера — 200 или 404. - Смена домена или https. Форма шлёт на
http://, сервер переадресует наhttps://, и данные теряются по пути. Браузер при переадресации 301 и 302 заменяет POST на GET и отбрасывает содержимое — заявка превращается в обычный переход на страницу. - Защита режет POST. Правило защиты от атак закрывает приём данных на адрес, где он нужен.
Похожая история бывает без всякого 405. Мы разбирали сайт, где формы заявок стояли на нескольких страницах, а обработчика не было ни одного: форма отправлялась сама на себя, страница перезагружалась с кодом 200, данные исчезали. Снаружи всё выглядело рабочим.
Как проверить свою форму
- Отправьте заявку сами и найдите её там, куда она должна прийти: в почте, в CRM, в базе. Осмотр вёрстки ничего не доказывает.
- Откройте инструменты разработчика, вкладка «Сеть», и отправьте форму. Посмотрите код ответа на запрос отправки: нужен 200 или 201 от обработчика, а не 405, 404 и не 301.
- Проверьте адрес отправки из командной строки:
curl -s -o /dev/null -w '%{http_code}\n' -X POST --data 'test=1' https://сайт.ru/адрес-обработчика
- Проверьте скрипт отправки. Он должен показывать «спасибо» только после успешного ответа, а при ошибке — говорить, что заявка не ушла, и давать другой способ связи.
Что делать владельцу
- Заявка сначала сохраняется, потом отправляется письмо. Тогда сбой почты не съест заявку.
- Показывайте ошибку честно. «Не удалось отправить, позвоните по номеру…» лучше ложного «спасибо».
- Проверяйте формы после каждого переезда и обновления. Именно там обработчик теряется чаще всего.
- Отдавайте Allow с кодом 405. Этого требует стандарт, и так проще найти причину.
Если форма требует галочку согласия, проверьте и её: как она устроена по закону, мы разобрали в статье галочка согласия на формах.
Границы замера
- 300 случайных сайтов организаций Екатеринбурга из OpenStreetMap, по одной пробной заявке на главную страницу. Настоящие формы сайтов мы не отправляли.
- Что сайт сделал с данными, снаружи не видно: 200 значит только, что сервер ответил страницей.
- Стенд — наш тестовый сервер и Chrome под управлением программы.
- Данные сняты 25.09.2026.
Коротко
- 405 — адрес есть, но метод запроса он не принимает; обычно это POST формы на страницу без обработчика.
- Стандарт требует заголовок
Allowс кодом 405; из 17 серверов с 405 его отправили четыре. - На заявку «не туда» две трети сайтов ответили 200 — ошибка не видна вовсе.
- Форма, которая не проверяет ответ, пишет «спасибо» и при 405.
- Проверка формы — только отправкой и поиском заявки на той стороне.