Ошибка 414 URI Too Long: что значит и как исправить

Что означает код 414

По стандарту HTTP код 414 значит: адрес, который запросил клиент, длиннее, чем сервер готов разобрать. Стандарт называет это редким случаем и перечисляет три причины: клиент превратил запрос POST с длинными данными в GET, клиент попал в бесконечную цепочку перенаправлений или кто-то атакует сервер, пытаясь найти уязвимость.

Стандарт HTTP/1.1 рекомендует серверам и клиентам поддерживать строку запроса длиной не меньше 8000 байт. В старом стандарте, RFC 2616, код назывался Request-URI Too Long, а nginx пишет на странице ошибки «414 Request-URI Too Large».

Если вы посетитель

1. Если адрес очень длинный, удалите всё после знака «?» и откройте страницу снова.
2. В каталоге с фильтрами сбросьте часть фильтров и выберите их заново.
3. Если адрес растёт при каждом переходе и в нём повторяется одно и то же, сайт попал в цикл перенаправлений — сообщите владельцу.

Откуда берутся слишком длинные адреса

• Форма отправляет данные методом GET. Все поля попадают в адрес после знака «?». Большой текст или много полей — и адрес выходит за лимит.
• Цикл перенаправлений. Правило перенаправления каждый раз дописывает к адресу часть пути или параметр, и адрес растёт, пока сервер не ответит 414.
• Фильтры в каталоге. Каждый выбранный фильтр добавляет в адрес параметр, и при длинных значениях вместе они могут превысить лимит.
• Сканеры и атаки. Запросы с огромными адресами шлют программы, которые ищут уязвимости. Такие 414 в журнале — норма.

Где задан лимит в nginx

В nginx длину адреса ограничивает директива large_client_header_buffers: по умолчанию это 4 буфера по 8 КБ. Строка запроса — метод, адрес и версия протокола — должна поместиться в один такой буфер. Если она длиннее, nginx отвечает 414 и пишет в журнал ошибок строку «client sent too long URI» на уровне info. Как включить уровень info в журнале, рассказано в разборе ошибки 400.

Поднять лимит можно в блоке http или server:

large_client_header_buffers 4 16k;

Та же директива ограничивает и длину одного заголовка запроса: если в буфер не помещается заголовок, nginx отвечает уже не 414, а 400.

После любых правок: sudo nginx -t, затем sudo systemctl reload nginx.

Как исправить

Форма. Если форма отправляет много данных, переведите её на метод POST: данные поедут в теле запроса, а не в адресе.

Цикл перенаправлений. Посмотрите, как меняется адрес на каждом шаге:

curl -IL "https://example.com/strannyj-adres/"

Ключ -L велит curl идти по перенаправлениям, -I — показывать только заголовки. Если адрес в заголовке Location с каждым шагом удлиняется, ищите правило, которое его дописывает.

Фильтры. Передавайте в адресе короткие коды значений, а не полные названия.

Лимит. Поднимайте его, только если длинные адреса действительно нужны сайту. Больший лимит не исправит ни форму, ни цикл перенаправлений.

На обычном хостинге

Лимит веб-сервера там задаёт хостер. Проверьте формы и правила перенаправлений — в .htaccess и в настройках плагинов. Если адреса нормальные, а 414 остаётся, напишите в поддержку адрес страницы и время.

414 и поиск Яндекса

По справке Яндекса, при ответе 414 адрес, который запросил робот, длиннее, чем сервер может обработать. Яндекс советует увеличить допустимую длину адреса на сервере или упростить структуру адресов сайта.

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

Источники

• RFC 9110, раздел 15.5.15 — определение кода 414.
• RFC 9112, раздел 3 — рекомендуемая длина строки запроса.
• RFC 2616, раздел 10.4.15 — старое название Request-URI Too Long.
• Документация nginx: large_client_header_buffers.
• Исходный код nginx — сообщение «client sent too long URI».
• Яндекс Вебмастер: коды ответа HTTP.

Сверено 6 октября 2026 года.

Что почитать дальше

• Ошибка 413 Request Entity Too Large — когда слишком большой файл.
• Ошибка 400 Bad Request — в том числе когда слишком длинный заголовок.
• Коды ответа HTTP — полный список с расшифровкой.
• Как разместить сайт на VPS — настройка nginx с нуля.