Маршрутизация QUIC-прокси для HTTPS и HTTP/3

BotBrowser 154.0.8037.44 или новее с соответствующим пакетом профиля позволяет оставить HTTPS и совместимые HTTP/3-запросы в одном утверждённом маршруте браузера, но провайдер должен реализовать нужные операции. Здесь описано, какую операцию выбрать, как зафиксировать решение и какие ограничения остаются на стороне провайдера.

Кратко

• Для обычного HTTPS-туннеля через QUIC-прокси используйте CONNECT.
• Для HTTP/3 через QUIC используйте MASQUE CONNECT-UDP, если это требуется провайдеру и сценарию.
• Адрес quic:// не гарантирует HTTP/3: участвуют сайт, политика браузера и провайдер.
• При недоступности прокси BotBrowser не переходит незаметно на прямое соединение: можно повторить, выбрать утверждённый маршрут или остановить сценарий.

Содержание

• Выбрать транспорт
• Настроить контролируемый маршрут
• Проверить ограничения и сбои
• Выпустить с записью
• Частые вопросы
• Итоги и операционные границы
• Итоги: заключение

Выбрать транспорт

CONNECT создаёт туннель к адресу HTTPS. Это обычный выбор, если провайдер заявляет поддержку CONNECT в своём QUIC-прокси. MASQUE CONNECT-UDP передаёт UDP-потоки и нужен для совместимого HTTP/3. Операции связаны, но не заменяют друг друга. О том, что означает CONNECT-UDP и как вписываются HTTP Datagrams, читайте в статье MASQUE и CONNECT-UDP для веб-операторов, где также перечислено, что операторам стоит уточнить у провайдера прокси.

Сценарий	Операция	Основание выбора
Страницы и API HTTPS	CONNECT	В договоре провайдера указан CONNECT
HTTP/3 при разрешённом QUIC	CONNECT-UDP	Провайдер поддерживает MASQUE и UDP
Смешанный трафик	Обе операции или утверждённый резерв	Зафиксировать протокол и резерв

Настроить контролируемый маршрут

Используйте BotBrowser 154.0.8037.44 или новее с соответствующим пакетом профиля и свяжите бинарный файл, профиль, политику хоста и endpoint в записи выпуска. Это пример маршрута на уровне процесса:

chromium-browser \
  --bot-profile="/path/to/profile.enc" \
  --proxy-server="quic://user:[email protected]:443"

Кодируйте зарезервированные символы URL в учётных данных, а реальные секреты храните в контролируемом хранилище. В контексте применяйте утверждённые флаги до создания первой страницы. См. документацию QUIC Proxy Routing и руководство по настройке прокси.

Маршрутизация по контексту доступна через BotBrowser ENT Tier3 и BotBrowser.setBrowserContextFlags; применяйте утверждённые флаги до создания страницы. Эта граница API и уровня отделена от приведённого выше CLI-примера для процесса.

Проверить ограничения и сбои

HTTP/3 согласуется для каждого запроса. Сайт может выбрать HTTP/2, политика браузера может отключить QUIC, а провайдер может поддерживать CONNECT без CONNECT-UDP. Проверьте реальный сценарий и запишите наблюдавшийся протокол. О том, как браузеры согласуют HTTP/3 и переходят на другие протоколы, читайте в статье Основы совместимости HTTP/3 и QUIC в браузере, где объясняется, почему один сетевой путь не универсален.

Когда QUIC-прокси недоступен, BotBrowser не переходит незаметно на прямое соединение. Контролируемый повтор, заранее утверждённый резерв или явная остановка позволяют проверить границы приватности, согласованности и защиты. BotBrowser предоставляет настроенную возможность и изоляцию контекста, но не гарантирует доступность провайдера, согласование HTTP/3 или прямой резерв. О планировании упорядоченных утверждённых маршрутов с ограниченным бюджетом повторов читайте в статье Переключение прокси и непрерывность для пользователя, где показано, как отделять сбои участка прокси от сбоев назначения.

QUIC-прокси отличается от UDP через SOCKS5. SOCKS5 использует UDP ASSOCIATE, а QUIC-прокси имеет собственный контракт CONNECT и MASQUE. Одна замена префикса URL не добавляет отсутствующую возможность.

Выпустить с записью

До выпуска запишите версию BotBrowser, идентификатор профиля, поддержку CONNECT и CONNECT-UDP у провайдера, владельца учётных данных, ожидаемый результат HTTP/3 и утверждённое действие при сбое. Это сохраняет возможность проверки без раскрытия секретов и без скриптов страницы.

Частые вопросы

quic:// заставляет все сайты использовать HTTP/3?

Нет. Результат зависит от назначения, политики браузера и провайдера; HTTPS может использовать HTTP/2 через CONNECT.

Нужен ли CONNECT-UDP для обычного HTTPS?

Нет. Обычный HTTPS использует CONNECT. CONNECT-UDP нужен для UDP, включая совместимый HTTP/3.

Что произойдёт при сбое QUIC?

BotBrowser позволяет применять настроенный QUIC-прокси в утверждённом контексте, но не гарантирует доступность провайдера, согласование HTTP/3 или прямой резервный маршрут. Настроенная граница защиты сохраняется, а оператор может повторить, выбрать утверждённый маршрут или остановить сценарий.

Сравните варианты в руководстве по настройке прокси. Считайте UDP через SOCKS5 отдельной возможностью провайдера.

Итоги и операционные границы

Рабочие границы.

HTTP/3 переносит HTTP-запросы и ответы в потоках QUIC. Это отличается от прокси-операции, которая используется для достижения назначения. CONNECT создаёт туннель, внутри которого браузер и сайт обмениваются данными. CONNECT-UDP позволяет передавать UDP-датаграммы через прокси; браузер и сайт согласуют собственный протокол по этому маршруту. Поэтому «QUIC-прокси» не означает, что прокси завершает или понимает обмен HTTP/3 с сайтом.

При согласовании HTTP/3 используются идентификаторы протокола, определённые для HTTP/3 поверх QUIC, включая h3 при выборе протокола приложения. Сайт с поддержкой HTTP/3 может выбрать другой протокол для конкретного соединения. Влияют предложения браузера, сеть, прокси и ответ сайта. Отличайте заявленную поддержку от наблюдаемого результата. RFC 9114 описывает HTTP/3, но не гарантирует выбор этого протокола для каждого запроса.

Потоки QUIC являются отдельными упорядоченными потоками байтов внутри соединения. HTTP/3 использует такую модель для потоков запросов. Это не значит, что все запросы завершаются независимо от перегрузки, ресурсов хоста или зависимостей приложения. Страница может ждать критический ответ. Эти свойства объясняют возможные отличия от HTTP/2, но не гарантируют скорость прокси-маршрута.

CONNECT-UDP относится к другому уровню. Операция указывает назначение и позволяет передавать UDP-датаграммы через HTTP-прокси. RFC 9298 определяет обмен HTTP Datagrams или Capsule Protocol между клиентом и прокси. Это не превращает прокси в универсальный туннель и не отменяет его политику. Назначения, порты, тариф и ограничения датаграмм задаёт провайдер.

При HTTPS через CONNECT туннель не делает прокси TLS-узлом сайта: браузер обычно устанавливает защищённый обмен с сайтом через туннель. Для HTTP/3 по UDP-маршруту согласование QUIC и TLS с сайтом отличается от QUIC-соединения до прокси. «Зашифрованный туннель» не означает отсутствия метаданных: провайдер может видеть назначение и время соединений, а BotBrowser не управляет его журналами.

Каждая проверка отвечает на отдельный вопрос. Соединение с прокси подтверждает доступность сервиса. Принятие CONNECT или CONNECT-UDP подтверждает разрешение операции. Завершённый HTTPS-запрос показывает обмен с приложением, а наблюдаемый HTTP/3 показывает согласование с сайтом. Успех одного этапа не доказывает автоматически остальные.

HTTP/2 может быть нормальным результатом совместимости, если сценарию нужен только HTTPS. Он также может означать, что требование HTTP/3 не выполнено. Протокол сам не определяет оценку: важен заранее заявленный сценарий. Укажите, допустим ли HTTP/2. Если HTTP/3 обязателен, отдельно запишите поддержку операции прокси и согласованный протокол.

Стандарты описывают протокол, а не коммерческие условия конкретного прокси. RFC 9114 описывает HTTP/3 поверх QUIC, а RFC 9298 задаёт CONNECT-UDP для HTTP-прокси. Провайдер определяет endpoint, аутентификацию, назначения, доступность и тарифные ограничения. BotBrowser применяет документированный маршрут, но не включает возможности провайдера и не гарантирует выбор HTTP/3 сайтом.

Рассматривайте наблюдаемый протокол как свидетельство для отдельного соединения, а не как метку всей страницы. Страница может обращаться к нескольким сайтам, и соединения могут использовать разные протоколы. HTTP/2 у основного документа не доказывает, что API или медиа используют его же; ответ HTTP/3 от одного сайта тоже не означает, что все ресурсы передавались по HTTP/3. Укажите сайт и запрос, входящие в критерий приёмки, и фиксируйте результат именно для них.

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

Повторное использование соединения меняет смысл проверки. Несколько запросов могут идти по уже открытому соединению, поэтому более поздний ответ HTTP/3 не обязательно означает новое согласование прокси. Новое соединение, наоборот, может иметь затраты на установку, отсутствующие при повторном запросе. Разделяйте холодный запуск и повторные запросы, если это важно сценарию. Используйте контролируемый тестовый контекст и не меняйте данные или настройки приватности ради желаемого протокола.

Возможности QUIC-прокси определяет договор провайдера, а не запись URL. Проверьте CONNECT для HTTPS-туннеля и CONNECT-UDP для UDP-датаграмм совместимого HTTP/3, а также аутентификацию, ограничения назначения, UDP, доступность и тариф. QUIC в описании услуги не означает наличие CONNECT-UDP.

Зафиксируйте владельцев endpoint, аккаунта провайдера, учётных данных и пакета профиля. Идентификатор endpoint храните вместе с версией BotBrowser и ревизией профиля, чтобы отличать миграцию провайдера от изменения браузера. Общий hostname не доказывает владельца.

Учётные данные относятся к данным выпуска. Кодируйте зарезервированные символы, подставляйте секреты из утверждённого хранилища и не помещайте их в код, историю shell, тикеты или диагностику. После ротации повторите ту же операцию и endpoint. Ошибка аутентификации должна оставаться видимой как ошибка аутентификации.

CLI задаёт маршрут процессу. Маршрутизация по контексту требует BotBrowser ENT Tier3 и BotBrowser.setBrowserContextFlags до создания страницы. В записи контекста укажите владельца, маршрут и ожидаемые назначения. Смена маршрута после навигации затрудняет интерпретацию сценария.

Недоступный прокси означает событие политики. BotBrowser не переходит незаметно на прямое соединение. Утверждённый ответ: ограниченный повтор, проверенный резерв или остановка. Для резерва заранее проверьте провайдера, географию, журналы, учётные данные и политику назначения.

Разделяйте слои сбоя: разрешение endpoint, транспорт QUIC, аутентификация, отказ CONNECT или CONNECT-UDP и согласование назначения. Выбор HTTP/2 сайтом не равен отказу аутентификации. За каждый результат отвечает разный владелец.

Проводите ограниченную проверку с утверждённым endpoint и несколькими назначениями в непроизводственном контексте. Запишите требуемую операцию, ожидаемый и наблюдаемый протоколы, идентификатор маршрута, категорию состояния и действие при сбое. Для обычного HTTPS HTTP/2 может быть допустим; HTTP/3 требует отдельной проверки CONNECT-UDP и согласования.

Храните только нужное свидетельство: время, маршрут, операцию и результат. Не сохраняйте учётные данные, cookies, чувствительные URL или содержимое страниц. Провайдер может хранить метаданные по своим условиям, а BotBrowser не управляет этим сроком. Владелец выпуска отдельно проверяет доступ и хранение.

Соединение QUIC с прокси подтверждает только первый переход. Оно не доказывает выбор HTTP/3 на стороне назначения. Политика браузера может отключить QUIC, а провайдер ограничить UDP для аккаунта или назначения. В записи укажите, допустим ли HTTP/2, и при обязательном HTTP/3 зафиксируйте оба результата.

После смены провайдера, учётных данных, профиля или браузера повторите запись с BotBrowser 154.0.8037.44 или новее, соответствующим пакетом профиля, областью процесса или ENT Tier3, endpoint и операцией. Так решения остаются связанными с проверенной конфигурацией.

Итоги: заключение

Для HTTPS выбирайте CONNECT, добавляйте CONNECT-UDP только при необходимости провайдеру и сценарию, затем проверяйте реальный маршрут браузера. Короткая запись выпуска сохраняет приватность и согласованность и показывает ограничения BotBrowser.

Источники

• MDN: HTTP/3
• RFC 9114: HTTP/3
• RFC 9298: HTTP Datagrams and CONNECT-UDP