Максимальная длина URL: реальный лимит символов

There is no maximum URL length. RFC 3986 - стандарт, который определяет синтаксис URI, - никогда её не задаёт: он описывает, какие символы допустимы и как собирается URL, и на этом останавливается. На практике вы сталкиваетесь с цепочкой отдельных, никак не связанных друг с другом лимитов: адресная строка браузера, веб-сервер на другом конце, прокси между ними, почтовый клиент, в котором кто-то открывает вашу ссылку, или QR-код, который вы собираетесь напечатать. Каждый из них применяет свой собственный потолок, и реальная максимальная длина URL - это самый низкий из этих потолков. Отправьте URL длиной 3000 символов, и он может прекрасно отрендериться в Chrome, быть отклонён сервером с настройками по умолчанию и прийти в Outlook перенесённым на четыре строки. Ничего из этого не баг. Это практическое следствие спецификации, которая сознательно молчит по этому вопросу.

Отсюда следуют четыре темы: что стандарт говорит и о чём молчит, откуда взялось знаменитое число 2083 символа и почему оно до сих пор всплывает в чек-листах спустя годы после того, как перестало иметь значение, какие лимиты реально кусаются, как только ссылка покидает браузер, и что делать с URL, который разросся слишком сильно. О том, что делает сокращатель со всем этим на проводе, читайте в статье как работают сокращатели URL.

Что на самом деле говорит RFC 3986 о длине URL

RFC 3986 определяет общий синтаксис URI - схема, полномочия, путь, запрос, фрагмент - и молчит о том, насколько длинным может быть любой из этих элементов. Молчит не по недосмотру - молчит осознанно. Грамматика в разделе 3 собирает URI из небольшого набора порождающих правил, и ничто в этих правилах не ограничивает, сколько раз правило может повториться. С точки зрения синтаксиса сегмент пути может состоять из одного символа или из ста тысяч. Длинные URL - это совершенно легальные URL.

Единственное ограничение, которое всё же накладывает RFC, - косвенное: компонент полномочий в URL включает имя хоста, а DNS ограничивает полностью определённое имя хоста намного жёстче, чем допускает грамматика URI, - инженерная документация Chromium устанавливает этот потолок в 253 символа всего и 63 на метку. Путь, строка запроса и фрагмент нигде в стандарте такому ограничению не подвергаются.

Это вся история со стороны спецификации. Лимит символов URL, в который вы реально упираетесь на практике, идёт от программного обеспечения, которое читает URL, а вовсе не от формата URL самого по себе.

Откуда взялось число 2083 и что делают браузеры сейчас

Если вам где-то встречалась рекомендация по длине URL, в ней наверняка фигурировало число 2083 символа. Это число реальное, но оно принадлежит одному браузеру, одной эпохе и одному участку кода. Сетевая библиотека WinINET браузера Internet Explorer определяла INTERNET_MAX_URL_LENGTH как 2083 символа, а собственный технический разбор Microsoft по этому лимиту отмечает, что сама адресная строка была ограничена на один символ меньше - 2047. Этот потолок определял судьбу огромной доли веб-трафика больше десятилетия, поэтому под него все и проектировали, и привычка пережила браузер, который она описывает.

Современные браузеры работают иначе. Документация Chrome указывает внутренний лимит в 2 мегабайта, введённый, чтобы избежать проблем межпроцессного взаимодействия, а не чтобы защитить поле интерфейса, а гораздо меньшая константа - около 32 килобайта на десктопе - ограничивает то, что реально отобразит омнибокс. Firefox и Safari столь же щедры - ни один из них не подавится URL сколько-нибудь близким по длине к тому, что вы, скорее всего, соберёте вручную. Я ни разу не отлаживал реальную проблему в продакшене, вызванную тем, что современный браузер отказался принять длинный URL. Каждый баг с длинным URL, который я отслеживал, начинался уже после браузера.

Реальные лимиты, которые действительно кусаются

Выстройте по порядку места, куда реально попадает URL, и закономерность проявится быстро: самый жёсткий лимит редко оказывается тем, что в браузере.

• Строка запроса сервера читает URL как часть первой строки HTTP-запроса, и у этой строки есть собственный буфер. Превысьте его - и сервер вообще не разберёт ваш маршрут: он откажет в соединении ещё до того, как запустится код вашего приложения.
• Почтовые клиенты обрабатывают переполнение по-разному. Outlook переносит длинный текстовый URL на несколько строк, а не обрезает его, - это некрасиво, но ссылка всё ещё кликабельна; некоторые веб-почтовые клиенты и шлюзы пересылки менее снисходительны и просто обрезают ссылку.
• Ссылка внутри текстового сообщения конкурирует с телом сообщения за один и тот же бюджет символов, а ссылки для SMS-маркетинга живут внутри сегмента в 160 символов - один длинный URL сам по себе может превратить одно-сегментный текст в два, а операторы тарифицируют и фильтруют их по-разному.
• QR-код не обрезает длинный URL - он просто становится плотнее. Каким должен быть размер QR-кода напрямую зависит от того, сколько вы просите его закодировать, а URL, перегруженный трекинговыми параметрами, может поднять код на версию-другую, сократив дистанцию, с которой он ещё будет сканироваться.
• Функции гиперссылок в таблицах применяют собственный жёсткий лимит символов к аргументу ссылки, значительно меньший, чем у типичного размеченного URL, и ссылка, превышающая этот лимит, отказывает молча - ячейка отображается нормально, а сама ссылка не работает.
• Рекламные платформы ограничивают поле URL назначения фиксированной длиной по собственному усмотрению - это правило платформы, а не техническое ограничение, - и менеджер кампании узнаёт об этом только тогда, когда кнопка сохранения отклоняет то, что браузер открыл бы без единой жалобы.

Ни один из этих лимитов не связан с другими. URL может спокойно пройти через строку запроса вашего сервера и всё равно умереть в таблице три отдела спустя.

Лимиты строки запроса на сервере и прокси

Случай с сервером заслуживает отдельного рассмотрения, потому что именно он порождает настоящий код ошибки, а не косметический глюк. 414 Request-URI Too Long - это ответ, который сервер отправляет, когда отказывается обрабатывать запрос, потому что URI длиннее, чем он готов интерпретировать, - лимит размера URL, применяемый на каждом хопе отдельно тем программным обеспечением, которое в данную секунду читает строку запроса.

Каждый сервер и прокси в цепочке применяет свою версию этого ограничения. Директива Apache LimitRequestLine по умолчанию равна 8190 байт для всей строки запроса целиком, включая метод и версию протокола, а не только сам URL. nginx читает заголовки запроса в фиксированный буфер, которым управляет large_client_header_buffers, по умолчанию 8 килобайт, и строка запроса, которая туда не влезает, получает 414 ещё до того, как совпадёт ваш маршрут. Балансировщики нагрузки и CDN перед любым из них часто применяют третий, отдельный лимит, так что URL может пройти настройку вашего исходного сервера и всё равно быть отклонённым на хоп раньше.

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

Скучное, но рабочее решение здесь - построить слой редиректа самостоятельно, а не писать разбор запросов вручную. API Elido принимает адрес назначения любой разумной длины и возвращает короткую ссылку, размер которой никогда не меняется, так что потолок строки запроса сервера превращается в то, что вы настраиваете один раз на edge, а не в то, что каждой интеграции приходится решать самостоятельно.

Как измерить реальную длину URL, прежде чем её отправить

Подсчёт символов - это вся суть измерения, и его стоит проверять до того, как URL попадёт в кампанию, а не после того, как придёт отчёт об отказах.

printf '%s' "https://example.com/path?utm_source=newsletter&utm_campaign=spring-sale-2026" | wc -c

Это даёт длину URL в байтах ровно в том виде, в каком он написан. Два момента усложняют картину. Во-первых, символы после процентного кодирования стоят дороже, чем кажутся: буква с диакритикой или эмодзи внутри значения запроса могут после кодирования разрастись до шести и более символов, поэтому измерять URL нужно после кодирования, а не до. Во-вторых, UTM-параметры обычно оказываются самой быстрорастущей частью URL - горстка тегов кампании, источника, канала и содержания может добавить несколько сотен символов к тому, что начиналось как короткий путь, и именно туда стоит смотреть в первую очередь, когда URL незаметно разросся слишком сильно.

Если ссылка, которая раньше работала, вдруг перестала, проведите ту же диагностику, что и для любой неработающей ссылки: статья короткая ссылка не работает разбирает, как проверить адрес назначения напрямую, - именно так вы поймаете URL, который перерос лимит сервера, накапливая трекинговые параметры один за другим.

Что делать, если URL слишком длинный

Реально работают только два способа исправления, и они одни и те же независимо от того, в какой лимит вы упёрлись.

Первый - сократить URL. Короткая ссылка - это указатель фиксированной длины: слаг остаётся той же длины независимо от того, насколько разрастётся адрес назначения или его трекинговые параметры, потому что всё это живёт на стороне сервера и подтягивается при каждом клике, а не переносится внутри самой ссылки. Это одним движением решает проблему плотности QR-кода, проблему сегментов SMS и проблему таблиц, потому что все три завязаны на количество символов в ссылке, а не на длину того, куда она в итоге ведёт.

Второй - вообще убрать состояние из строки запроса. Если ваш URL становится длинным из-за данных сессии, содержимого корзины или длинного списка фильтров, а не из-за настоящих трекинговых параметров, эти данные обычно должны жить на стороне сервера за непрозрачным идентификатором, а не быть выписанными в адресной строке. URL вида /checkout?session=a1b2c3d4 стареет лучше, чем /checkout?items=... с полностью выписанными артикулами и количествами каждого товара, и он разом обходит все лимиты из этой статьи, потому что измерять там больше нечего длинного.

Оба решения указывают в одну сторону: относитесь к длине URL как к осознанному дизайнерскому решению, а не как к случайности от того, сколько параметров на нём накопилось.

Читайте цикл опорных статей

Эта статья входит в инженерный кластер. О том, что происходит на другом конце короткой ссылки, статья как работают сокращатели URL рассказывает про сам поиск, а типы редиректов URL разбирает коды статуса, которые задействуются, когда адрес назначения найден.

Связанные статьи в блоге

• URL-кодирование объяснено: какие символы нужно экранировать
• UTM-параметры объяснены, со схемой именования, которая выживает
• Каким должен быть размер QR-кода? Правила размера и дистанции
• Сокращатель URL для SMS-маркетинга, которому доверяют операторы
• Короткая ссылка не работает? Диагностика одной командой