Nginx Error 400: Bad Request (client sent invalid header line) Linux / DevOps

Nginx 400: client sent invalid header line — Решение проблемы

Обновлено: 18.08.2026 · Официальная база знаний

Клиентский запрос блокируется сервером с возвратом ошибки 400 Bad Request. В логе error.log Nginx фиксируется отказ в парсинге заголовка: client sent invalid header line: "X_Custom_User_Auth: ..." while reading client request headers.

Символ / Заголовок	Поведение Nginx по умолчанию	Причина ошибки
Символ подчеркивания `_`	Заголовок молча отбрасывается	Защита от спуфинга заголовков в CGI/FastCGI
Пробелы перед двоеточием	Возврат ошибки 400 Bad Request	Нарушение стандарта RFC 7230 (HTTP/1.1 Specification)
Спецсимволы / Не-ASCII	Возврат ошибки 400 Bad Request	Недопустимые управляющие байты в именах заголовков

Кастомные мобильные приложения или устаревшие клиенты API получают ошибку 400 при отправке специфических метаданных.
Интеграции со сторонними сервисами сбоят из-за передачи нестандартных заголовков.

Если ваши клиенты передают кастомные заголовки с символами подчеркивания (например, Auth_Token или X_Api_Key), включите их поддержку в блоке http или server:
```
# Разрешить знаки подчеркивания в именах клиентских заголовков:
underscores_in_headers on;
```
Если клиент отправляет некорректные/поврежденные заголовки, которые вы хотите проигнорировать без сброса соединения по 400:
```
# Игнорировать невалидные строки заголовков вместо отдачи ошибки 400:
ignore_invalid_headers on;
```
Если в заголовках передаются объемные токены авторизации или сертификаты, увеличьте размеры буферов заголовков:
```
client_header_buffer_size 4k;
large_client_header_buffers 4 16k;
```
Проверьте корректность синтаксиса и выполните перезагрузку:
```
sudo nginx -t
sudo systemctl reload nginx
```

Стандарт безопасности: Символы подчеркивания (_) запрещены по умолчанию, так как в интерфейсе CGI/WSGI все дефисы в заголовках автоматически трансформируются в подчеркивания (X-Forwarded-For превращается в HTTP_X_FORWARDED_FOR). Наличие заголовков с оригинальными подчеркиваниями создает уязвимость подмены переменных окружения (CGI Header Spoofing).

Практический опыт инженера: Рекомендуйте разработчикам API переходить на стандартные дефисы в заголовках (`X-Custom-Auth` вместо `X_Custom_Auth`). Это снимет зависимость от нестандартных настроек прокси-серверов.

Частые вопросы (FAQ)

Почему Nginx строго относится к символам в именах HTTP-заголовков?

Строгий парсинг защищает инфраструктуру от атак класса HTTP Request Smuggling, при которых злоумышленники маскируют вредоносные запросы внутри поврежденных заголовков.

Разрешены ли пробелы внутри значений заголовков?

Внутри значений пробелы допустимы, но пробел перед двоеточием (например, 'User-Agent : Mozilla') строго запрещен стандартом RFC 7230 и вызывает ошибку 400.

Где лучше включать underscores_in_headers?

Рекомендуется включать эту опцию только в блоке server конкретного API-сервиса, где это действительно требуется, оставляя глобальную защиту включенной в http.

Как увидеть полный проблемный заголовок в логе Nginx?

Повысьте уровень логирования error_log /var/log/nginx/error.log info; — Nginx запишет проблемную строку заголовка целиком.