Ошибка 405 Method Not Allowed: причины и диагностика

HTTP 405 Method Not Allowed означает, что сервер распознал HTTP-метод, но не разрешает использовать его для конкретного ресурса. Например, endpoint существует и принимает GET, но запрос POST к тому же URL запрещён.

Это отличается от 404 Not Found и 501 Not Implemented. При 405 сервер понимает метод как таковой и знает целевой ресурс, однако сочетание «метод + ресурс» не поддерживается. RFC 9110 требует, чтобы origin server включал в 405 заголовок Allow со списком поддерживаемых методов.

Что означает HTTP 405

POST /reports/42
       ↓
маршрут существует
       ↓
POST для него не разрешён
       ↓
405 Method Not Allowed
Allow: GET, HEAD

Главный вопрос диагностики: какой метод фактически отправляет клиент и какие методы разрешает именно этот URL.

Чем 405 отличается от соседних кодов

Основные причины 405

Клиент отправляет неправильный метод

Например:

контракт: PUT /v1/users/42
клиент:   POST /v1/users/42

URL правильный, но router не имеет POST-handler.

Frontend и backend разошлись после релиза

Frontend уже вызывает новый метод, а backend ещё не обновлён или rollout прошёл не на всех инстансах. При балансировке возможно чередование успеха и 405.

Reverse proxy ограничивает методы

Запрос может быть отклонён до приложения. Если application log не видит запрос, а proxy log фиксирует 405, искать нужно раньше приложения.

URL попал не в тот route/location

Trailing slash, rewrite или порядок location способны отправить API-запрос в статический обработчик, где GET работает, а POST получает 405.

CORS preflight получает 405

Браузер перед основным запросом может отправить OPTIONS. Если 405 получает именно preflight, нужно исправлять обработку OPTIONS/CORS, а не бизнес-метод вслепую.

Шаг 1. Зафиксируйте точный URL и метод

curl -i https://example.com/api/items

Проблемный метод:

curl -i -X POST https://example.com/api/items

Смотрите на status, Allow, response body, proxy/CDN headers и request ID.

Важно: -X меняет слово метода, но не формирует автоматически правильное тело и поведение запроса. Для POST с данными используйте подходящие options --data/--data-binary.

Шаг 2. Проверьте Allow

Корректный ответ может выглядеть так:

HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD, OPTIONS

Если Allow отсутствует в ответе origin server, проверьте реализацию: RFC 9110 требует этот заголовок для 405.

Шаг 3. Постройте матрицу «URL × метод»

Для безопасного тестового endpoint:

for method in GET POST PUT PATCH DELETE OPTIONS; do
  code=$(curl -sS -o /dev/null -w '%{http_code}' -X "$method" https://example.com/api/items)
  printf '%-7s %s\n' "$method" "$code"
done

Не запускайте DELETE, POST, PUT или PATCH против production-ресурса, если они способны изменить реальные данные.

Шаг 4. Сверьте route table приложения

Проверьте фактический контракт:

GET    /v1/items
POST   /v1/items
GET    /v1/items/{id}
PATCH  /v1/items/{id}
DELETE /v1/items/{id}

Частая ошибка — отправить POST /v1/items/42, когда нужен PATCH /v1/items/42.

Шаг 5. Сравните public proxy и upstream

Если это безопасно и инфраструктура позволяет:

public URL → 405
upstream   → 200/204

указывает на proxy/rewrite/method policy. Если оба дают 405, проверьте приложение или контракт.

Шаг 6. Проверьте логи

Для расследования нужны method, URL, timestamp, response status, upstream status и request ID. Строка «405» без метода почти бесполезна.

405 и REST API

Пример:

curl -i \
  -X PATCH \
  -H 'Content-Type: application/json' \
  --data '{"name":"Новое имя"}' \
  https://api.example.com/v1/users/42

Если endpoint поддерживает только PUT, он может вернуть 405 с Allow.

Связанный материал: как мониторить API endpoint.

Когда 405 появился после deployment

Проверьте:

1. версии frontend/backend;
2. route registration;
3. proxy/ingress config;
4. mixed-version replicas;
5. redirect/rewrite;
6. OPTIONS preflight.

Если ошибка плавающая, проверяйте backend-инстансы по отдельности.

Как проверить восстановление

Нужно подтвердить и позитивный, и негативный сценарий:

GET  → 200
POST → 405 + Allow: GET, HEAD

Если после «исправления» все методы возвращают 200, ограничение могло быть снято слишком широко.

Автоматический контроль

Монитор должен использовать реальный безопасный метод критичного endpoint. Проверка только GET / не обнаружит поломку POST /checkout.

UpWatch можно использовать для регулярного контроля HTTP/API endpoint, если запрос безопасен и ожидаемый результат определён заранее.

Типичные ошибки

• считать 405 отсутствием URL;
• игнорировать Allow;
• менять backend, не проверив фактический method клиента;
• тестировать destructive методы на production;
• разрешать все методы глобально;
• путать 405 основного запроса и 405 CORS preflight.

Практический чек-лист

1. Зафиксировать URL и method.
2. Подтвердить 405 через curl.
3. Проверить Allow.
4. Сверить API contract.
5. Определить слой, вернувший ответ.
6. Проверить route table.
7. Проверить proxy/rewrite.
8. Для браузера проверить OPTIONS.
9. Не выполнять опасные методы на реальных данных.
10. Проверить разрешённый и запрещённый сценарии после исправления.

Источники и спецификации

• RFC 9110: 405 Method Not Allowed
• RFC 9110: HTTP Methods
• curl: официальная документация