← Cloudflare One / cloudflare-one / team-and-resources / devices / cloudflare-one-client / troubleshooting

Известные ограничения

Ниже приведена информация об устройствах, ПО и конфигурациях, несовместимых с Cloudflare One Client (ранее WARP).

Cloudflare One Client не работает на Windows Server. См. страница скачивания для списка поддерживаемых операционных систем.

На устройствах Windows с процессорами на базе ARM клиент Cloudflare One иногда может зависание в отключённом состоянии при подключении (например, при первой установке Cloudflare One Client).

Чтобы обойти эту проблему, можно временно удалить сетевой адаптер WARP:

1. Откройте графический интерфейс Cloudflare One Client и отключитесь.
2. В Windows откройте Диспетчер устройств.
3. Выберите Просмотр > Показать скрытые устройства.
4. В разделе Сетевые адаптеры, найдите Туннель интерфейса Cloudflare WARP и выберите Удалить устройство.
5. Выберите Попытаться извлечь диск для этого устройства, затем выберите Удалить.
6. Переподключите Cloudflare One Client.

Теперь Cloudflare One Client переустановит свой сетевой адаптер, и в графическом интерфейсе Cloudflare One Client теперь должно отображаться Подключено.

Обнаружение управляемой сети не будет работать, если TLS-сертификат предоставляется с IIS 8.5 на Windows Server 2012 R2. Чтобы обойти это ограничение, перенесите сертификат на другой хост.

На устройствах Windows в Режим только DNS, nslookup по умолчанию отправляет DNS-запросы на Локальный DNS-прокси WARP через IPv6. Однако, поскольку Cloudflare One Client использует IPv4-адрес, отображённый в IPv6 (вместо настоящего IPv6-адреса), nslookup не распознает этот тип адреса, и запрос завершится ошибкой:

C:\Users\JohnDoe>nslookup google.com
Server:  UnKnown
Address:  ::ffff:127.0.2.2

*** UnKnown can't find google.com: No response from server

Чтобы обойти эту проблему, укажите IPv4-адрес Локальный DNS-прокси WARP в своём запросе:

C:\Users\JohnDoe>nslookup google.com 127.0.2.2

Как вариант, используйте PowerShell:

Resolve-DnsName -Name google.com

DNS-трафик Comcast (на указанные ниже IP-адреса) нельзя проксировать через Cloudflare One Client, поскольку Comcast отклоняет DNS-трафик, отправленный не напрямую с устройства пользователя.

• IPv4-адреса: 75.75.75.75 и 75.75.76.76
• Адреса IPv6: 2001:558:feed::1 и 2001:558:feed::2

Чтобы обойти эту проблему, можно либо:

• Создайте Правило Split Tunnel который исключает указанные выше IP-адреса из Cloudflare One Client.
• Настройте своё устройство или маршрутизатор для использования общедоступного сервера DNS, например 1.1.1.1 ↗.

Аналогично DNS-серверы Comcast ограничения, указанного выше, серверы Cox DNS не будут отвечать на трафик с исходящих IP-адресов WARP (или с любого IP-адреса, не принадлежащего Cox). Обходной путь почти такой же, за исключением того, что серверы Cox DNS могут быть индивидуальными для каждого конечного пользователя. Вы можете выбрать один из следующих вариантов:

• Создайте Правило Split Tunnel который исключает все DNS-серверы Cox. Для корпоративных клиентов см. Документация COX ↗ для IP-адресов DNS-сервера. Для домашних пользователей проверьте свои локальные DNS-серверы. Домашние DNS-серверы обычно относятся к 68.105.28.0/24 и 68.105.29.0/24.
• Настройте своё устройство или маршрутизатор для использования общедоступного сервера DNS, например 1.1.1.1 ↗.

В драйвере HP Velocity есть ошибка, которая вызывает синий экран смерти на устройствах с запущенным Cloudflare One Client. HP рекомендует удаление этого драйвера ↗.

Для устройств Dell с версией прошивки 1.35.0 (выпущенной 2025-07-07), независимо от операционной системы, Cloudflare подтвердила ошибку, которая не позволяет запуститься службе WARP. Пользователям, столкнувшимся с этой проблемой, Cloudflare рекомендует обновить прошивку устройства Dell до версии 1.36.0 или более поздней версии.

В устройствах Cisco Meraki есть ошибка, из-за которой клиентский трафик иногда может определяться как Statistical-P2P ↗ и понижается в приоритете либо отбрасывается полностью. Чтобы устранить эту проблему, отключите Statistical-P2P на устройстве Cisco Meraki.

Windows Teredo ↗ интерфейс конфликтует с Cloudflare One Client. Поскольку Teredo и Cloudflare One Client будут бороться за контроль над маршрутизацией трафика IPv6, вам нужно отключить Teredo на устройстве с Windows. Это позволит Cloudflare One Client обеспечивать подключение по IPv6 на устройстве.

Docker ↗ в Linux не выполняет изменения MTU базового сетевого туннеля, которые требуются Cloudflare One Client. Это может вызвать проблемы с подключением внутри контейнера Docker, если Cloudflare One Client включён на хост-машине. Например, curl -v https://cloudflare.com > /dev/null завершится ошибкой при запуске из контейнера Docker, использующего сетевой драйвер bridge по умолчанию.

Чтобы обойти эту проблему, пользователи Cloudflare One Client с Docker в Linux могут вручную перенастроить MTU на сетевом интерфейсе Docker. Можно либо изменить /etc/docker/daemon.json чтобы включить:

{
	"mtu": 1420
}

или создайте сеть Docker с рабочим значением MTU:

docker network create -o "com.docker.network.driver.mtu=1420" my-docker-network

Значение MTU следует устанавливать равным MTU интерфейса вашего хоста по умолчанию за вычетом 80 байт на накладные расходы протокола WARP. У большинства MTU равен 1500, поэтому значение 1420 подходит большинству пользователей.

Cloudflare One Client запускает локальный DNS-прокси на 127.0.2.2 и 127.0.2.3. Вам может понадобиться доступ к этим адресам из контейнеров Docker для разрешения доменов, доступных только внутри сети, или резервных доменов. Docker по умолчанию сеть bridge ↗ копирует настройки DNS с хоста, но исключает loopback-адреса DNS, такие как 127.0.2.2 и 127.0.2.3, поэтому контейнеры не могут их использовать.

Чтобы включить DNS-разрешение Cloudflare One Client в контейнерах:

• Используйте пользовательская сеть Docker ↗ (рекомендуется): позволяет контейнеру Docker по-прежнему использовать сетевой драйвер bridge, который сохраняет сетевую изоляцию от хоста. Если вы создаете собственную сеть bridge, вам также следует настройте MTU соответствующим образом.
• Используйте сетевое взаимодействие хоста ↗ (не рекомендуется): устраняет преимущества сетевой изоляции с точки зрения безопасности и может привести к конфликтам портов.

В следующем примере используется специальный хост (connectivity-check.warp-svc) которое может быть разрешено только локальным DNS-прокси, чтобы показать поддерживаемые режимы работы сети Docker.

# This host is not resolvable by default
❯ docker run --rm alpine nslookup connectivity-check.warp-svc.
Server:         8.8.8.8
Address:        8.8.8.8:53

** server can't find connectivity-check.warp-svc.: NXDOMAIN
** server can't find connectivity-check.warp-svc.: NXDOMAIN

# Create a bridge network called demo
❯ docker network create demo
e1e1943a6995a7e8c115a1c60357fe64f87a3ae90074ce6e4c3f0d2bba3fa892

# The host is resolvable by running a container under this custom network
❯ docker run --rm --net demo alpine nslookup connectivity-check.warp-svc.
Server:         127.0.0.11
Address:        127.0.0.11:53Non-authoritative answer:
Name:   connectivity-check.warp-svc
Address: ::ffff:127.0.2.2
Name:   connectivity-check.warp-svc
Address: ::ffff:127.0.2.3Non-authoritative answer:
Name:   connectivity-check.warp-svc
Address: 127.0.2.2
Name:   connectivity-check.warp-svc
Address: 127.0.2.3

# The host is also resolvable by running a container using a host network
❯ docker run --rm --net host alpine nslookup connectivity-check.warp-svc.
Server:         127.0.0.11
Address:        127.0.0.11:53Non-authoritative answer:
Name:   connectivity-check.warp-svc
Address: ::ffff:127.0.2.2
Name:   connectivity-check.warp-svc
Address: ::ffff:127.0.2.3Non-authoritative answer:
Name:   connectivity-check.warp-svc
Address: 127.0.2.2
Name:   connectivity-check.warp-svc
Address: 127.0.2.3

В некоторых системах Linux с systemd-resolved более ранние версии, чем 252.3, DNS-домены, настроенные на интерфейсах, не относящихся к WARP, могут разрешаться не так, как ожидается, пока подключен Cloudflare One Client. Это может затронуть имена хостов, которые зависят от доменов поиска, предоставленных DHCP, или доменов маршрутизации DNS, привязанных к конкретному интерфейсу.

Например, выполнение команд, определяющих имя хоста устройства, может занимать несколько секунд или завершаться ошибкой, похожей на:

sudo: unable to resolve host <HOSTNAME>: Temporary failure in name resolution

Это происходит потому, что systemd-resolved более ранние версии, чем 252.3 не поддерживают привязанную к интерфейсу DNS-конфигурацию, которую Cloudflare One Client использует в новых дистрибутивах Linux. В таких системах Cloudflare One Client переходит на глобальную DNS-конфигурацию. В результате DNS-домены, настроенные на других интерфейсах, например поисковые домены облачного провайдера или корпоративной сети, могут маршрутизироваться или разрешаться непоследовательно, пока подключён WARP.

Чтобы обойти эту проблему, обновитесь до дистрибутива Linux с systemd-resolved версия 252.3 или более позднюю версию, когда это возможно. Если проблема затрагивает разрешение локальных имён хостов, добавьте локальное имя хоста в /etc/hosts чтобы Linux разрешал это имя раньше, чем через DNS:

echo "127.0.1.1 $(hostname)" | sudo tee -a /etc/hosts

Прежде чем добавлять запись, проверьте, /etc/hosts уже содержит сопоставление для этого имени хоста. Если ваша организация управляет /etc/hosts, свяжитесь со своим администратором, прежде чем изменять это значение.

Если Cloudflare One Client активен на локальном компьютере, пользователи могут быть не в состоянии подключиться к ПК Windows 365 с помощью Windows App ↗. Эта проблема не затрагивает подключения к Windows 365 через браузер.

Чтобы устранить это, исключите указанные ниже сети из любых соответствующих Cloudflare One Client профили устройств. Необходимые сети перечислены в разделе WindowsVirtualDesktop тег службы в Azure IP Ranges and Service Tags - Public Cloud ↗ ресурс (найдите "name": "WindowsVirtualDesktop").

Microsoft ранее предоставляла Скрипт PowerShell ↗ для получения этих сетей, но с тех пор он устарел. Соответствующие сети теперь объединены в следующие подсети, которые следует исключить из всех соответствующих профилей устройств Cloudflare One Client:

40.64.144.0/20
51.5.0.0/16
57.156.5.248/29
57.156.73.192/28
172.183.252.22/32
2603:1061:2010::/48
2603:1061:2011::/48

Использование Cloudflare One Client в Cloud PC Microsoft 365 с Windows 10 не поддерживается. Чтобы обойти это ограничение, используйте Windows 11.

В Traffic only mode, устройства, использующие DNS-серверы IPv6, могут испытывать проблемы с подключением, если эти серверы не исключены вручную из туннеля WARP.

В отличие от типичных конфигураций DHCP для IPv4, где серверы DNS часто попадают в автоматически исключаемые диапазоны приватных адресов, в средах IPv6 для корректной работы обычно требуется вручную исключить адреса DNS-серверов через настройки Split Tunnel.

Если ваш DNS-сервер использует адрес IPv6, его нужно вручную исключить с помощью настройки Split Tunnel для корректной работы режима Traffic only.

VPN-клиент Ivanti Secure Access может конфликтовать с Cloudflare One Client, устанавливая правила Windows Filtering Platform (WFP), которые блокируют исходящий трафик к Локальный DNS-прокси WARP на порту 53. Это приводит к Host not found ошибки или полную потерю подключения к интернету, даже если Ivanti отключён или деактивирован.

Чтобы устранить это, обратитесь в службу поддержки Ivanti или к своему администратору, чтобы изменить или удалить конкретные правила брандмауэра, блокирующие трафик к 127.0.2.2.

Если вы используете Microsoft Intune для развертывания Cloudflare One Client на Android с Always-On VPN и режим Lockdown включены ↗, агент Cloudflare One может не зарегистрироваться. Это происходит потому, что Lockdown mode запрещает агенту Cloudflare One доступ к базовой сети, необходимый для завершения процесса регистрации.

Это известное ограничение ОС Android, о котором уже сообщено в Google. Отслеживать статус запроса на добавление функции можно на Google Issue Tracker ↗.

Чтобы обойти эту проблему, можно отключить Lockdown mode, оставив Always-On VPN включённым:

1. В профиле Intune отключите Lockdown mode сохраняя при этом Always-On VPN включено.
2. Используйте auto_connect и switch_locked параметры в управляемой конфигурации для бесперебойного подключения.
3. Попросите пользователей запустить приложение-агент Cloudflare One и вручную завершить одноразовую регистрацию.

Когда вы развертываете Cloudflare One Client .pkg на macOS с помощью Microsoft Intune, Intune может неоднократно переустанавливать пакет. При каждой переустановке клиент перезапускается, и соединение WARP кратковременно прерывается, поэтому в течение одного цикла оценки Intune клиент может быть переустановлен несколько раз.

Это затрагивает версии Cloudflare One Client начиная с 2026.3.566.1: первого релиза с обновлённым интерфейсом клиента (новым интерфейсом клиента). Обновлённый клиент включает несколько встроенных фреймворков внутри приложения, из-за чего и возникает цикл переустановки. Это проблема конфигурации обнаружения на стороне Intune, а не дефект клиента, поэтому применяйте указанное ниже решение для любой затронутой версии.

Это происходит из-за того, как Intune определяет, является ли macOS .pkg приложение уже установлено. При загрузке пакета Intune автоматически заполняет Включённые приложения список обнаружения со всеми bundle, найденными внутри пакета, включая около двух десятков встроенных framework-бандлов, которые поставляются внутри клиента (например, io.flutter.flutter-macos, org.sparkle-project.Sparkle, и несколько org.cocoapods.* пакетов). Intune считает приложение установленным только тогда, когда каждый запись в Включённые приложения список обнаружен на устройстве.

Эти встроенные фреймворки не являются самостоятельно устанавливаемыми приложениями. Они находятся внутри пакета приложения клиента и не имеют ни квитанции установщика, ни отдельного присутствия в системе, поэтому Intune не может обнаружить их как установленные приложения самостоятельно. В результате Intune никогда их не обнаруживает, всегда считает, что приложение установлено не полностью, и переустанавливает пакет, циклически перебирая каждый необнаруживаемый фреймворк. Intune обнаруживает собственный идентификатор пакета клиента (com.cloudflare.1dot1dot1dot1.macos) корректно на протяжении всего времени. Именно из-за лишних записей framework не проходит проверка, что и вызывает цикл переустановки. Cloudflare сообщила об этом поведении в Microsoft.

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

1. В Microsoft Intune admin center ↗, перейдите в Приложения > macOS и выберите приложение Cloudflare One Client.
2. Перейдите в Свойства и рядом с Правила обнаружения, выберите Изменить.
3. В Включённые приложения список, удалите все записи, кроме com.cloudflare.1dot1dot1dot1.macos.
4. Задайте Игнорировать версию приложения к Да чтобы обнаружение срабатывало независимо от версии развёрнутого клиента.
5. Выберите Review + save чтобы применить изменение.

Для пользователей Windows 11 24H2 Microsoft подтвердила регрессию, которая может вызывать проблемы с производительностью: задержку указателя мыши, треск звука и другие замедления. Пользователям, столкнувшимся с этими проблемами, Cloudflare рекомендует обновиться минимум до Версия Windows 11 24H2 KB5062553 ↗ или выше для разрешения.

Устройства Windows с установленным обновлением KB5055523 могут получать предупреждение о Win32/ClickFix.ABA присутствия в установщике. Чтобы устранить это ложное срабатывание, обновите Microsoft Security Intelligence до версии 1.429.19.0 ↗ или более поздней версии.