Cloudflare One Client для Windows: що змінюється в бета-версії 2026.9.2663.1

У бета-версії Cloudflare One Client для Windows (2026.9.2663.1) команда Cloudflare робить кілька помітних кроків в керуванні трафіком (Global Acceleration), захисті від несанкціонованого видалення, діагностиці продуктивності та стабільності тунелю. Нижче розбір підходу розробників Cloudflare та ключових змін для адміністраторів Zero Trust і звичайних користувачів.

Автовибір endpoint для Global Acceleration

Для організацій з увімкненим Global Acceleration клієнт тепер сам обирає, куди підключатися:

якщо пристрій знаходиться в регіоні акселерації — використовується спеціальний Global Acceleration endpoint;
якщо ні — клієнт переключається на стандартні anycast endpoint;
при зміні мережі (наприклад, перехід між Wi-Fi та мобільною мережею) клієнт автоматично перепідключається без дій з боку користувача.

На вкладці Connectivity тепер видно, до яких tunnel та API endpoint підключений клієнт. Якщо політика дозволяє, користувач може вручну змінити endpoint в Settings.

Практична користь для адміністраторів:

менше ручних перемикань між профілями для віддалених офісів;
простіше відлагоджувати проблеми продуктивності — endpoint видно прямо в UI;
менше збоїв при перемиканні мереж, оскільки перепідключення відбувається автоматично.

Захист від несанкціонованого видалення та зупинки сервісу

У клієнт додано захист від неавторизованих змін або деінсталяції:

для видалення Cloudflare One Client потрібен код, який генерує адміністратор;
без коду деінсталяція блокується;
користувачі, включаючи адміністраторів на самому пристрої, більше не можуть зупиняти сервіс клієнта;
усі спроби авторизувати видалення за допомогою коду чи токена, незалежно від того, прийнято чи відхилено, репортуються в Cloudflare.

Такий підхід корисний для керованих пристроїв: користувач не може «тимчасово вимкнути захист», щоб обійти політику, а служба безпеки отримує журнал спроб видалення.

Нова сторінка Diagnostics та спрощений збір warp-diag

У клієнті з'явилась окрема сторінка Diagnostics з усіма ключовими показниками в одному місці:

статус та «здоров'я» підключення;
метрики тунелю та пристрою в реальному часі;
деталі мережі;
результати DEX-тестів (Digital Experience Monitoring).

Користувач може запустити спідтест, який порівнює продуктивність всередині тунелю та поза ним, поки клієнт підключений. Це зручно, коли потрібно відокремити проблеми мережі компанії від проблем оператора або локальної Wi-Fi.

Кнопка Troubleshooting tools тепер:

або збирає повний warp-diag bundle;
або запускає captive portal test, що коротко перепідключає Wi-Fi та зберігає результат на Desktop.

Раніше для цього потрібно було запускати warp-diag з терміналу; тепер достатньо дій у графічному інтерфейсі, що помітно спрощує підтримку користувачів без доступу до консолі.

Робота з MTU та Path MTU Discovery

Окремий блок змін стосується MTU, що важливо для стабільності тунелю, особливо в мобільних мережах та з хот-спотами.

Корекція MTU в проблемних мережах

Клієнт тепер застосовує MTU тунелю в діапазоні 1147 — 1199 байт, якщо Path MTU Discovery виміряв такі значення. Раніше клієнт ігнорував цей діапазон і залишав більший MTU, що могло призводити до дропу великих пакетів при видимому «connected» стані.
Коли Path MTU Discovery увімкнено, клієнт приймає більші пакети від Cloudflare, а не обмежує їх до власного розміру вихідних пакетів. Це дозволяє ефективніше використовувати пропускну здатність там, де шлях у зворотному напрямку допускає більший MTU.

Перемикання з IPv6 на IPv4 при занадто малому MTU

Якщо Path MTU Discovery визначає, що MTU по IPv6 опускається нижче 1280 байт, клієнт тепер автоматично перепідключається через IPv4 та зберігає пріоритет IPv4 до зміни мережі. Раніше клієнт міг залишатися на «урізаному» IPv6 тунелі, хоча IPv4 дозволяв більші пакети. Для адміністраторів це означає менше «дивних» проблем, коли через IPv6 все повільне або нестабільне при нормальному IPv4.

Попередження про деградований MTU

Коли мережа зменшує MTU тунелю до деградованого чи критично низького рівня, клієнт показує банер з попередженням. Банер зникає, якщо MTU відновлюється або клієнт відключається. Це дає явний сигнал, що причина повільної роботи може бути у властивостях конкретної мережі, а не в політиках Zero Trust.

MDM-параметри, multicast та поведінка в Zero Trust

Нові MDM-параметри для файлів та керованих мереж

Для централізованого керування через MDM додано кілька нових параметрів.

mdm_file_debounce_secs (1 — 60 секунд) — як довго клієнт чекає перед застосуванням зміненого MDM-файлу.
mdm_file_unavailable_debounce_secs (0 — 300 секунд) — затримка перед реакцією на відсутній або непридатний до читання MDM-файл.

Це допомагає уникати «дребезгу» конфігурацій при тимчасових збоях у доступі до файлів.

Для логіки керованих мереж додано:

managed_network_probe_interval_secs (30 — 300, за замовчуванням 30) — інтервал між перевірками;
managed_network_probe_count — скільки разів перевіряти: 0 (повністю вимкнути додаткові перевірки, зберігаючи стару поведінку), 1 — 10 або -1 (перевіряти доти, доки не буде знайдено керовану мережу; за замовчуванням 1).

Після реєстрації або зміни мережі, якщо керована мережа не знайдена, клієнт тепер переперевіряє, щоб пристрій не застряг на default-профілі через тимчасовий збій з'єднання.

Політика multicast

З'явилась нова політика мережі та MDM-налаштування multicast з параметрами allow або drop (за замовчуванням drop). Якщо встановити allow, клієнт надсилатиме трафік на multicast-адреси через тунель замість того, щоб його відкидати. Це актуально для середовищ, де діапазони multicast використовують не тільки для класичного multicast, а й для іншого службового трафіку.

Zero Trust: трасування поза тунелем та DNS

Для Zero Trust деплойментів клієнт тепер зберігає traceroute мережевого шляху поза тунелем, коли тунель деградує або не може підключитися. Той самий трейс потрапляє в warp-diag, що спрощує аналіз, чи проблема всередині тунелю, чи у маршрутизації «в чистому інтернеті».
У proxy-режимі для Zero Trust клієнт пересилає хостнейми з HTTP/HTTPS та SOCKS5-запитів до Cloudflare для резолву, а не резолвить їх локально на пристрої. Це забезпечує єдину точку контролю DNS та повніший аудит у Zero Trust.

Оновлення warp-diag і діагностичних інструментів

Утиліта warp-diag отримала кілька важливих змін:

додає редаговані копії MDM-файлів, які застосовані на пристрої;
включає імена (але не значення) збережених registration secrets;
рапортує QUIC path MTU тільки тоді, коли він дійсно виміряний;
включає трасування мережі поза тунелем при деградації чи відмові з'єднання.

Це дає адміністраторам повніший контекст без витоку чутливих значень секретів, але з корисними метаданими для підтримки.

Покращення UI та досвіду користувача

Connectivity, повідомлення про помилки та PQ-захист

На сторінці Connectivity тепер показуються IPv4 та IPv6 адреси, призначені тунелю, поки клієнт підключений.
Якщо застосунок не може зв'язатися з сервісом клієнта, головний екран більше не показує абстрактний «IPC error», а пояснює причину: сервіс не запущений, не приймає з'єднання, не відповідає або з'єднання скинуте й триває повторне підключення. Додається код помилки та посилання Learn more.
З'являються нотифікації, коли адміністратор видаляє віртуальну мережу, обрану користувачем, а також окреме повідомлення, якщо користувач намагається вибрати віртуальну мережу, якої вже немає.
У consumer-клієнті домашній екран тепер показує, коли з'єднання зашифроване з використанням постквантової криптографії.

Оптимізація продуктивності та споживання ресурсів

зменшене використання CPU службою Windows Capability Access Manager (camsvc), яке було пов'язане із запитами клієнта до Wi-Fi;
знижене споживання пам'яті інтерфейсом клієнта;
UI клієнта більше не запускає процеси WMIC або PowerShell для збору інформації про пам'ять у звітах про краш.

Зміни в Access, DNS та CLI

Запити повторної автентифікації Access тепер довіряють сертифікатам з системного сховища сертифікатів ОС, щоб реавтентифікація працювала в мережах з TLS inspection.
Команда warp-cli target list отримала опцію --hostname для фільтрації таргетів за одним чи кількома хостнеймами (через кому).
DEX HTTP-тести тепер надсилають User-Agent за замовчуванням, який ідентифікує Cloudflare One Client, якщо тест не вказує свій User-Agent.
DNS-проксі виправлено так, щоб він не кешував відповіді довше, ніж TTL CNAME-запису в ланцюжку.
Виправлено декілька сценаріїв з warp-cli, де неправильні параметри або повільна мережа призводили до неспівпадіння між фактичним станом (ліцензія застосована, fallback-домени налаштовані) та тим, що показує CLI.

Виправлення інсталятора та надійності сервісу

У цій версії багато уваги приділено «шорохам» при інсталяції та оновленнях.

Інсталяція та оновлення

Виправлено помилки інсталяції з кодом 1603 на системах із політиками Windows App Control (WDAC): деякі файли всередині custom actions інсталятора були не підписані, тепер підписані всі компоненти.
Інсталятор більше не просить закривати запущені застосунки під час оновлення, даунгрейду чи видалення через те, що інші програми завантажили Visual C++ runtime клієнта через системний PATH. Лібрарії тепер завантажуються з приватної папки.
Виправлено сценарій, коли перевстановлення тієї ж версії з MSI прибирало сервіс оновлення, після чого клієнт переставав отримувати апдейти.

Стабільність сервісу та адаптерів

Усунено креш сервісу, який локальний користувач міг спричинити, надсилаючи спеціально сформований запит до локального DNS-резолвера.
Виправлено перезапуск сервісу, коли оновлення firewall для captive portal detection зависало під час сну пристрою.
Закрито витік handles до завершених процесів, через який ті могли довго залишатися у списку «running».
На Windows on Arm виправлено «залипання» в стані disconnected через те, що залишкові tunnel-адаптери не видалялись.
Виправлено сценарій, коли правила firewall в режимі Exclude split tunnel блокували перевірки мережі самою Windows, що змушувало ОС скидати Wi-Fi-адаптер після sign-in або перезапуску Wi-Fi. Клієнт тепер пропускає мережеві перевірки Windows.

Обробка змін конфігурації та split tunnel

Клієнт коректно відслідковує кілька послідовних змін мережевої конфігурації, а не тільки першу.
Виправлено проблему, коли клієнт не міг підключитися після послідовної зміни версій (upgrade, downgrade, upgrade) зі зміною між consumer та Zero Trust реєстрацією: тепер при конфлікті реєстрацію очищують і користувач може зареєструватися заново.
При невдалій ротації ключів для зміни протоколу тунелю клієнт більше не продовжує використовувати старий протокол без спроб виправитись: тепер повторює ротацію при наступному з'єднанні.
Виправлено нескінченні перепідключення, коли був увімкнений автоматичний вибір endpoint для Global Acceleration в регіоні акселерації, а також випадок, коли клієнт «тримався» за старий датацентр після зміни endpoint.
Hostname-based split tunnel правило тепер спрацьовує відразу, навіть якщо раніше застосування firewall-правила для нього провалилося (раніше ефект був лише після перепідключення).
При split tunnel-адресі в mdm.xml без префікса тепер bare IP інтерпретується як один вузол, і сервіс успішно стартує.
Один некоректний елемент у mdm.xml більше не змушує клієнт ігнорувати весь файл. У warp-diag файл включається «як є».
warp-cli dns fallback add більше не приймає порожній домен (що раніше спрямовувало всі DNS-запити на локальний резолвер замість Gateway). Fallback-домени та split tunnel-entries нормалізуються (без урахування регістру та з/без фінальної крапки), тому видалення працює незалежно від формату.

Корекції DEX, часу та CLI

Результати Digital Experience Monitoring (DEX) більше не мають зміщених timestamp після корекції системного годинника: тепер час звіту відповідає реальному моменту вимірювання.
warp-cli debug network більше не показує GUID інтерфейсу з усіма нулями — виправлено відображення ідентифікатора.
warp-cli registration license не сигналізує помилку на повільних мережах, якщо насправді ліцензію успішно застосовано; раніше це залишало клієнт прив'язаним до WARP+ акаунта, який він «не впізнавав».

Відомі проблеми та обмеження

Регресія в Windows DNS client може спричиняти збої connectivity check на системах з великими файлами hosts. Хоча клієнт Cloudflare має пом'якшення, користувачі все ще можуть бачити знижену продуктивність DNS та збої connectivity check.
Після того, як адміністратор видаляє віртуальну мережу з профілю пристрою або змінює default network, список віртуальних мереж у клієнті може продовжувати показувати попередні мережі до перезапуску клієнта. Це лише візуальна проблема: пристрій реально підключається до мереж, дозволених профілем, а спроба вибрати видалену мережу відхиляється без зміни з'єднання. Актуальний список показує команда warp-cli vnet. За заявою розробників, це буде виправлено до наступного GA-релізу.

Бета-версія фокусується на керованості (MDM, Global Acceleration, Zero Trust), спрощенні діагностики (Diagnostics, warp-diag) та усуненні проблем з MTU, інсталятором і стабільністю сервісу. Для продакшн-середовищ такі зміни варто тестувати на обмеженій групі пристроїв, враховуючи згадані відомі проблеми.

Джерело: Cloudflare Changelog