# Только разрешённые HTTP‑методы проходят: блокируем шумные запросы Nginx 405/444

Во время работы с веб‑приложением, наблюдая за логами, иногда встречаются такие моменты.

* Я думал, что использую только `GET / POST / PUT / DELETE`
* В логах появляется неизвестный метод

Например, в логах может появиться `PROPFIND` – метод WebDAV. Приложение, конечно, отреагирует как «неподдерживаемый метод», но важно то, что происходит.

**Нужно ли заставлять серьёзное приложение обрабатывать лишний шум?**
Ответ обычно «нет». Поэтому удобно **позволять только нужные методы, а остальные блокировать на уровне Nginx**.

---

## Почему стоит блокировать на Nginx {#sec-b5d4f5f6dfc2}

Блокировать можно и на уровне приложения, но к тому моменту запрос уже пришёл, и уже возникли расходы.

* Вход в WSGI/ASGI
* Запуск некоторых middleware/логирования/аутентификации
* Загрязнение логов приложения «настоящими» проблемами
* При росте трафика накапливается лишняя нагрузка

Если блокировать на Nginx:

* **Сразу завершаем на первом уровне** → минимальные расходы
* **Логи приложения остаются чистыми** → упрощается эксплуатация
* **Уменьшается поверхность атаки** → лишние методы просто не видны

В одном предложении:

> **Приложение создаёт продукт, а Nginx играет роль стража.**

---

## Необычные методы в логах обычно не «нормальный» трафик {#sec-7f5126fc3fdf}

Методы вроде `PROPFIND` – типичный пример.

* Сканирование, чтобы проверить, включён ли WebDAV
* Если по ошибке открыты `PUT/MKCOL`, пытаются перейти к следующему шагу
* Иногда видны паттерны с пустым User‑Agent или «плохим» HTTP/1.0

Главный вывод:

**Если наш сервис не использует этот метод, то вероятность того, что это нормальный трафик, почти нулевая.** Поэтому нет смысла отправлять запрос в приложение и отвечать дружелюбно.

---

## Стратегия проста: работа по списку разрешённых {#sec-84ef31ae1a20}

![nginx как охранник, управляющий входом](/media/editor_temp/6/e09dd4fc-f987-43bf-b38f-9ac6c4c594f6.png)

Принцип – «открыть только то, что нужно, и закрыть всё остальное».

* Статические страницы/ресурсы: обычно достаточно `GET`, `HEAD`
* API: ограничиваем `POST/PUT/PATCH/DELETE` только нужными эндпоинтами

И все остальные методы (например, `PROPFIND`, `MKCOL`, `LOCK` и т.д.)
**если мы их не используем, блокируем полностью** – это самый удобный способ управления.

---

## 405 против 444: какой ответ использовать {#sec-967ed2222242}

Есть два основных способа блокировки.

### 1) 405 Method Not Allowed {#sec-c79f33550d87}

* Стандартный и понятный
* Сообщает клиенту, что метод недоступен

### 2) 444 (Nginx‑специфичный: закрыть соединение без ответа) {#sec-fe4e18cb7c1d}

* Полностью разрывает соединение
* Не даёт подсказок сканерам/ботам
* В эксплуатации тихий и чистый подход («убираем шум»)

На практике часто применяют так:

* Для «неполезных» методов в открытом вебе – 444
* Для клиентских ошибок, где пользователь может ошибиться – 405

---

## Пример конфигурации Nginx: «разрешить только нужные методы» – два шаблона {#sec-3c7629273a8a}

Ниже приведены готовые примеры, которые можно сразу копировать.

### Шаблон A) Базовый: только GET/HEAD, API – дополнительные методы {#sec-42bc13636133}

```nginx
server {
    # ... listen/server_name и т.д. ...

    # 1) Базовый: веб/статические – только GET/HEAD
    location / {
        if ($request_method !~ ^(GET|HEAD)$) { return 444; }  # или 405
        proxy_pass http://app;
    }

    # 2) API: разрешаем нужные методы
    location /api/ {
        if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE|OPTIONS)$) { return 444; }
        proxy_pass http://app;
    }
}
```

* `/` обычно обслуживает только страницы, поэтому `GET/HEAD` достаточно.
* `/api/` может потребовать `OPTIONS` из‑за CORS.

### Шаблон B) «Блокируем только подозрительные методы» (легкое начало) {#sec-fa0b2940f799}

```nginx
location / {
    if ($request_method ~ ^(PROPFIND|PROPPATCH|MKCOL|COPY|MOVE|LOCK|UNLOCK)$) { return 444; }
    proxy_pass http://app;
}
```

* Убирает шумные методы, которые обычно видны в логах.
* В долгосрочной перспективе лучше использовать **Allowlist** (шаблон A).

> Примечание: хотя в Nginx часто предупреждают о злоупотреблении `if`, простые условия с `return` широко применяются в практике. Если нужна более строгая реализация, можно использовать `limit_except`.

---

## Вывод: «Разрешить только нужные» упрощает эксплуатацию {#sec-35fe67d750b5}

Ключевые моменты:

* Необычные методы почти всегда не «нормальный» трафик
* Отправка в приложение создаёт лишние расходы и загрязняет логи
* **Блокируем всё, кроме разрешённых методов, на уровне Nginx** (405/444)

Применив один из этих шаблонов, вы получите:

* Меньше нагрузки на приложение
* Чистые логи
* Упрощённую эксплуатацию