Cloudflare ускоряет TLS к origin: Automatic Key Exchange без лишнего round trip

8 сентября 2026 года Cloudflare подробно рассказал о Automatic Key Exchange — механизме, который помогает быстрее устанавливать новые TLS 1.3 соединения между сетью Cloudflare и origin-сервером. Проблема возникает ещё в первом ClientHello: клиент должен заранее выбрать key share, не зная наверняка, какой алгоритм предпочитает конкретный origin.

Если выбор совпал, TLS-handshake укладывается в один round trip. Если нет, сервер отвечает HelloRetryRequest и просит другой key share, что добавляет ещё один сетевой round trip. По данным Cloudflare, прежняя единая ставка на X25519 была неоптимальной примерно для 30% измеренных origin-соединений.

Что делает Automatic Key Exchange

Cloudflare сканирует активные origin-серверы вне пользовательского запроса и определяет поддерживаемые и предпочитаемые key agreements. После этого для новых TLS 1.3 соединений Cloudflare отправляет прогнозируемый key share в первом ClientHello.

Это не новый режим шифрования сайта и не замена сертификату. Настройка отвечает именно за выбор key agreement при HTTPS-соединении Cloudflare → origin. Режимы Full, Full (strict) и другие настройки SSL/TLS продолжают решать свои отдельные задачи.

Почему HelloRetryRequest добавляет задержку

В TLS 1.3 сервер может принять предложенный key share или попросить другой. Во втором случае он отправляет HelloRetryRequest, после чего клиент повторяет часть обмена. Соединение при этом не ломается, но появляется дополнительный round trip.

На близком origin эта разница может быть небольшой, а на географически удалённом сервере дополнительный сетевой обмен становится заметнее. При этом Automatic Key Exchange влияет только на новые TLS-соединения: уже переиспользуемое соединение не выполняет новый key exchange для каждого HTTP-запроса.

Как Cloudflare выбирает алгоритм

Согласно документации Cloudflare, активные origins сканируются примерно раз в 24 часа. Новое предпочтение раскатывается постепенно: сначала на небольшой доле трафика, затем расширяется при нормальных показателях соединений и частоте HelloRetryRequest. Если изменение выглядит нездоровым, Cloudflare откатывает предпочтение.

При наличии нескольких origins в одной зоне Cloudflare формирует одно предпочтение для зоны на основе результатов с учётом трафика. Origin при необходимости всё равно может запросить другой advertised key share через HelloRetryRequest.

Где здесь post-quantum

Если origin поддерживает и классические, и post-quantum варианты, Cloudflare предпочитает стандартизованный гибридный key agreement X25519MLKEM768, если это разрешено заданными требованиями совместимости. Гибрид объединяет классический X25519 и post-quantum ML-KEM.

Cloudflare отдельно предоставляет compliance-настройки. Можно разрешить обычный набор поддерживаемых алгоритмов, потребовать post-quantum hybrid, FIPS-совместимые варианты или пересечение этих требований. Эти ограничения относятся к TLS 1.3 и не должны включаться без проверки поддержки на origin.

Кому ничего не нужно включать вручную

Automatic Key Exchange включён для существующих зон и включается по умолчанию для новых. Для большинства конфигураций ручное действие не требуется. В панели настройка находится в разделе SSL/TLS → Overview → Origin connection & post-quantum encryption.

Функция доступна на всех планах, но работает только при подходящей схеме подключения: Cloudflare указывает Full, Full (strict) или Strict (SSL-Only Origin Pull), TLS 1.3 до origin и отсутствие Cloudflare Tunnel на этом соединении. Tunnel использует отдельный механизм соединения.

Что проверить владельцу сайта

• Убедиться, что между Cloudflare и origin используется HTTPS и корректный SSL/TLS режим.
• Проверить поддержку TLS 1.3 на origin, если хочется получить пользу именно от Automatic Key Exchange.
• Не включать жёсткое требование post-quantum hybrid, пока origin точно не поддерживает X25519MLKEM768.
• Не путать эту настройку с оптимизацией HTML, кэшем или Core Web Vitals: она относится к установлению новых защищённых соединений до origin.
• При сложной схеме с несколькими origins учитывать, что Cloudflare применяет одно выбранное предпочтение на зону.

Почему это интересно для WordPress и API-инфраструктуры

Для обычного WordPress-проекта эта функция не требует отдельного плагина. Она работает на сетевом слое между Cloudflare и сервером. Практический смысл выше там, где Cloudflare регулярно открывает новые соединения к origin: при распределённой инфраструктуре, большом числе edge-запросов, внешних API или Workers, выполняющих fetch() к origin.

Если WordPress используется вместе с внешним edge-слоем, webhook и serverless-компонентами, полезно рассматривать TLS, кэш, API и origin не по отдельности, а как одну цепочку. Похожую архитектуру я разбирал в материале Cloudflare Workers + D1 для API-интеграций.

Automatic Key Exchange не обещает одинаковый эффект всем

Сам факт включённой функции не означает фиксированное ускорение страницы на определённое число миллисекунд. Результат зависит от того, как часто создаются новые TLS-соединения, где находится origin, какой алгоритм он предпочитает и переиспользуются ли соединения.

Поэтому правильнее считать Automatic Key Exchange инфраструктурной оптимизацией: Cloudflare убирает ненужный retry там, где способен заранее определить подходящий key share, а не «ускорителем сайта» с гарантированным процентом.

Официальные источники

• Cloudflare Blog — Automatic Key Exchange, 8 сентября 2026
• Cloudflare Docs — Automatic key exchange to origins
• Cloudflare Docs — Post-quantum between Cloudflare and origin servers

Если нужно настроить Cloudflare как часть более широкой схемы с WordPress, API, Workers и внешними сервисами, можно посмотреть услугу автоматизации бизнес-процессов или описать текущую архитектуру проекта.