Когда вам нужно использовать прокси для обеспечения безопасности вашей среды с нулевым доверием, это часто сопряжено с затратами: низкой производительностью для ваших пользователей. Вскоре после развертывания клиентского прокси команды безопасности, как правило, оказываются завалены обращениями в службу поддержки от пользователей, разочарованных медленной скоростью работы браузера, медленной передачей файлов и сбоями видеозвонков в самый неподходящий момент. Спустя некоторое время вы начинаете списывать это на особенности прокси — потенциально закрывая глаза на другие проблемы, влияющие на производительность.
Мы знали, что так быть не должно. Мы знали, что пользователи могут работать быстрее, не жертвуя безопасностью, если мы полностью пересмотрим наш подход к прокси-режиму. Так мы и поступили.
На ранних этапах разработки клиентского приложения для устройств нашей платформы SASE, Cloudflare One, мы уделили приоритетное внимание универсальной совместимости. Когда администратор включал прокси-режим, Клиент действовал как локальный прокси SOCKS5 или HTTP. Однако, поскольку наша базовая архитектура туннеля была построена на WireGuard, протоколе 3-го уровня (L3), мы столкнулись с техническим препятствием: как передать трафик транспортного уровня (L4, TCP) в туннель L3. Переход с L4 на L3 был особенно сложным, потому что наш клиент для настольных систем работает на нескольких платформах (Windows, macOS, Linux), поэтому мы не могли использовать ядро системы для этого.
Чтобы преодолеть это препятствие, мы использовали smoltcp — реализацию TCP в пользовательском пространстве, написанную на Rust. Когда пакет попадал на локальный прокси, Клиенту приходилось выполнять преобразование, используя smoltcp для конвертации потока L4 в пакеты L3 для туннеля WireGuard.
Хотя это работало, это было неэффективно. Smoltcp оптимизирован для встроенных систем и не поддерживает современные функции TCP. Кроме того, на краевых серверах Cloudflare нам приходилось преобразовывать пакеты L3 обратно в поток L4. Для пользователей это проявлялось как потолок производительности. На сайтах с большим объемом медиа, где браузер может открывать десятки одновременных соединений для изображений и видео, отсутствие высокопроизводительного стека TCP приводило к высокой задержке и медленному времени загрузки, так что даже на высокоскоростных оптоволоконных соединениях прокси-режим ощущался значительно медленнее всех других режимов клиента для устройств.
Представляем прямое проксирование L4 с помощью QUIC
Чтобы решить эту проблему, мы с нуля перестроили прокси-режим клиента Cloudflare One и отказались от использования WireGuard для прокси-режима, чтобы воспользоваться преимуществами возможностей QUIC. Мы уже использовали MASQUE (часть QUIC) для проксирования IP-пакетов и добавили использование потоков QUIC для прямого проксирования L4.
Используя HTTP/3 (RFC 9114) с методом CONNECT, мы теперь можем оставлять трафик на транспортном уровне (L4), где ему и место. Когда ваш браузер отправляет запрос SOCKS5 или HTTP Клиенту, он больше не разбивается на пакеты L3.
Вместо этого он инкапсулируется напрямую в поток QUIC.
Это архитектурное изменение дает три непосредственных технических преимущества:
Обход smoltcp: Удаляя слой преобразования L3, мы устраняем обработку IP-пакетов и ограничения реализации TCP в smoltcp.
Преимущества нативного QUIC: Мы получаем выгоду от современного управления перегрузками и контроля потока, которые обрабатываются нативно на транспортном уровне.
Настраиваемость: Клиент и краевая сеть Cloudflare могут настраивать параметры QUIC для оптимизации производительности.
В ходе нашего внутреннего тестирования результаты были очевидны: скорость загрузки и выгрузки удвоилась, а задержка значительно снизилась.
Кто получит максимальную выгоду
Хотя быстрее — всегда лучше, это обновление особенно открывает возможности для трех ключевых распространенных сценариев использования.
Во-первых, при совместном использовании со сторонними VPN, где устаревший VPN все еще требуется для доступа к определенным локальным ресурсам или где требуется двойная настройка SASE для избыточности/соответствия нормам, локальный прокси-режим является предпочтительным решением для добавления безопасности с нулевым доверием к веб-трафику. Это обновление гарантирует, что «наслоение» безопасности не означает ухудшение пользовательского опыта.
Во-вторых, для разделения трафика высокопропускных приложений прокси-режим часто используется для направления определенного трафика браузера через Cloudflare Gateway, оставляя остальную часть ОС в локальной сети. Теперь пользователи могут транслировать контент в высоком разрешении или работать с большими наборами данных без ущерба для производительности.
Наконец, разработчики и продвинутые пользователи, которые полагаются на вторичный слушатель SOCKS5 для CLI-инструментов или скриптов, сразу увидят улучшения. Удаленные вызовы API и передача данных через прокси теперь получают преимущества от такого же низко задержанного соединения, как и остальная часть глобальной сети Cloudflare.
Как начать работу
Улучшения прокси-режима доступны начиная с минимальной версии клиента 2025.8.779.0 для устройств Windows, macOS и Linux. Чтобы воспользоваться этими улучшениями производительности, убедитесь, что у вас установлена последняя версия клиента Cloudflare One.
Войдите в панель управления Cloudflare One.
Перейдите в раздел Команды и ресурсы > Устройства > Профили устройств > Общие профили.
Выберите профиль для редактирования или создайте новый и убедитесь, что для Режима службы установлено значение Локальный прокси-режим, а для Протокола туннеля устройства установлено значение MASQUE.
Вы можете проверить активный протокол на клиентской машине, выполнив следующую команду в терминале:
warp-cli settings | grep protocolПосетите нашу документацию для получения подробных инструкций по включению прокси-режима для ваших устройств.