← Cloudflare One / cloudflare-one / troubleshooting

Gateway

Это руководство поможет вам устранить распространённые проблемы с политиками Cloudflare Gateway.

Заблокированные веб-сайты и подключение

Веб-сайт заблокирован ошибочно

Если вы считаете, что домен был заблокирован по ошибке категориями безопасности Gateway или данными Threat Intelligence, вы можете использовать Форма обратной связи по категоризации Cloudflare Radar ↗ и запросите проверку.

Error 526: Invalid SSL certificate

Gateway представляет 526 страница ошибки, если не удаётся установить защищённое соединение с источником. Обычно это происходит в двух случаях:

Недоверенный сертификат исходного сервера: Сертификат, предоставленный сервером origin, просрочен, отозван или выдан неизвестным центром сертификации.
Небезопасное подключение origin: Сервер origin не поддерживает современные наборы шифров или перенаправляет все запросы HTTPS на HTTP.

Подробнее см. в Ошибка 526.

Error 502: Bad Gateway

Эта проблема может возникать при обращении к источнику, который поддерживает HTTP/2 лишь частично. Если источник запрашивает понижение версии до HTTP/1.1 (например, через RST_STREAM кадр с HTTP_1_1_REQUIRED), Gateway не будет автоматически повторно отправлять запрос по HTTP/1.1, а вместо этого вернёт 502 Bad Gateway. Чтобы решить эту проблему, отключите HTTP/2 на сервере-источнике.

Предупреждения о недоверенных сертификатах

Если пользователи видят предупреждения о сертификате на каждой странице, убедитесь, что корневой сертификат Cloudflare установлен и является доверенным на их устройствах. Это необходимо, чтобы Gateway мог проверять HTTPS-трафик.

Панель управления и аналитика

Аналитика Gateway не отображается

Если на странице Gateway Overview не отображается аналитика:

Проверить DNS-трафик: Убедитесь, что ваши устройства действительно отправляют запросы в Gateway. Проверьте Локации DNS и проверьте исходный адрес IPv4.
Проверить другие резолверы: Убедитесь, что на устройстве не настроены другие DNS-резолверы, поскольку они могут работать в обход Gateway.
Ожидание обработки: Появление аналитики в панели управления может занять до 5 минут.

Политики Egress

К симптомам проблем с политиками Egress относятся: трафик не использует выделенный исходящий IP-адрес, некорректное поведение отказоустойчивости или высокая задержка из-за того, что Gateway направляет трафик через удаленный дата-центр.

Симптом: трафик не использует ваш выделенный исходящий IP-адрес

Даже при активной политике исходящего трафика вы можете обнаружить, что трафик выходит с IP-адреса Cloudflare по умолчанию, а не с вашего выделенного исходящего IP-адреса.

Распространённая причина	Решение
Разрешение DNS в начальный разрешённый IP-адрес	Если политика Egress использует Домен или Host селектор, Gateway сначала должен разрешить этот домен в исходный разрешённый IP-адрес. Если ваш аккаунт всё ещё использует устаревший диапазон в адресном пространстве CGNAT (carrier-grade NAT), этот IP-адрес может считаться внутренним для сети Cloudflare и не подпадать под действие политик Egress, которые применяются к трафику, покидающему сеть. Измените селектор в своей политике Egress с Домен или Host к IP-адрес назначения (используя публичные IP-адреса службы, к которой вы пытаетесь подключиться), или перенести исходный диапазон разрешённых IP-адресов за пределы CGNAT.
Приоритет политики	Другая политика egress с более высоким приоритетом (меньшим числом) обрабатывает трафик первой. Помните, что политики egress следуют той же логике: побеждает первое совпадение.
Конфигурация Split Tunnel	IP-адрес или домен назначения исключён из туннеля WARP с помощью конфигурации Split Tunnel. Трафик, исключённый из туннеля, не подпадает ни под какие политики Gateway, включая Egress.
Без исходящих журналов	Логирование исходящего трафика доступно через Logpush с набором данных Gateway Egress. Это необходимо для устранения неполадок. Вы также можете использовать стороннюю службу проверки IP-адресов, чтобы проверить исходящий IP-адрес с тестового устройства.

Симптом: переключение при сбое не работает или использует неверный IP-адрес

Ваш основной выделенный исходящий IP-адрес становится недоступен, но вместо использования настроенного вторичного выделенного IP-адреса трафик переключается на общий IP-адрес Cloudflare по умолчанию.

Распространённая причина	Решение
Проблема маршрутизации или конфигурации на стороне Cloudflare	Зафиксируйте время инцидента и соберите идентификаторы запросов (Request ID) из журналов HTTP или DNS Gateway для затронутых пользователей. Откройте обращение в службу поддержки и предоставьте эту информацию. Временно вы можете изменить политику egress, указав вторичный IP-адрес в качестве основного, чтобы восстановить работу службы.

Распространённая причина

Решение

Проблема маршрутизации или конфигурации на стороне Cloudflare

Зафиксируйте время инцидента и соберите идентификаторы запросов (Request ID) из журналов HTTP или DNS Gateway для затронутых пользователей. Откройте обращение в службу поддержки и предоставьте эту информацию. Временно вы можете изменить политику egress, указав вторичный IP-адрес в качестве основного, чтобы восстановить работу службы.

Симптом: пользователи выходят в интернет из географически удалённого местоположения

Gateway направляет трафик пользователей из одной страны (например, Австралии) через выделенный исходящий IP-адрес, расположенный в другом регионе (например, в Германии), что приводит к высокой задержке и нарушает доступ к контенту с географическими ограничениями.

Распространённая причина Решение

Одна политика Egress У вас может быть одна общая политика Egress, которая применяется ко всем пользователям независимо от их местоположения. Создайте политики Egress с учётом местоположения. Используйте User Location селектор в политике, чтобы привязать конкретные местоположения пользователей к ближайшему выделенному исходящему IP-адресу. Например, создайте одну политику для случая, когда User Location это United Kingdom, исходящий трафик через IP-адрес Лондона. Создайте вторую политику для случаев, когда User Location это Australia, исходящий трафик через IP-адрес Сиднея.

Неверные данные геолокации IP-адрес интернет-провайдера пользователя может быть определён геолокацией неверно. Проверьте местоположение пользователя, которое видит Cloudflare, в журналах Gateway. Если оно выглядит неверным, вы можете сообщить об этом в Cloudflare Support.

Распространённая причина	Решение
Одна политика Egress	У вас может быть одна общая политика Egress, которая применяется ко всем пользователям независимо от их местоположения. Создайте политики Egress с учётом местоположения. Используйте User Location селектор в политике, чтобы привязать конкретные местоположения пользователей к ближайшему выделенному исходящему IP-адресу. Например, создайте одну политику для случая, когда User Location это `United Kingdom`, исходящий трафик через IP-адрес Лондона. Создайте вторую политику для случаев, когда User Location это `Australia`, исходящий трафик через IP-адрес Сиднея.
Неверные данные геолокации	IP-адрес интернет-провайдера пользователя может быть определён геолокацией неверно. Проверьте местоположение пользователя, которое видит Cloudflare, в журналах Gateway. Если оно выглядит неверным, вы можете сообщить об этом в Cloudflare Support.

Приоритет политики

Один из частых источников путаницы связан с тем, как Gateway оценивает разные типы политик и правила внутри них.

Симптом: политика Block переопределяет более точную политику Allow или Do Not Scan

У вас настроена политика Allow или Do Not Scan с высоким приоритетом для конкретного приложения (например, Allow finance.example.com), но Gateway всё равно блокирует трафик по политике Block с более низким приоритетом (например, Block All High-Risk Sites).

Самым важным понятием является Приоритет политик Gateway, которую Gateway применяет на основе порядкового номера политики в списке. Чем меньше порядковый номер, тем выше приоритет. Gateway прекращает обработку последующих политик, как только находит первое совпадающее правило.

Чтобы устранить проблемы с приоритетом политик Gateway:

В Панель управления Cloudflare ↗, перейдите в Zero Trust > Политики трафика > Политики Firewall.
Проверьте порядок ваших политик DNS, Network и HTTP.
Убедитесь, что ваши наиболее конкретные политики Allow, Do Not Scan или Do Not Inspect имеют более низкий порядковый номер, чем общие политики Block.
Перетащите политики, чтобы изменить их порядок по необходимости. Политика Allow для teams.microsoft.com следует разместить перед общей политикой блокировки для всех приложений обмена файлами.

Расшифровка TLS нарушает работу приложений

Turning on Расшифровка TLS необходимо для функций Gateway, таких как Data Loss Prevention (DLP), Browser Isolation и HTTP-политики с учётом приложений. Однако это может вызывать проблемы с некоторыми типами программного обеспечения.

Симптом: инструменты командной строки (CLI-инструменты) или собственные приложения завершаются с ошибками сертификата

Если после включения расшифровки TLS инструменты командной строки (например, git, aws, kubectl, а также terraform) или настольные приложения (например, ChatGPT или Docker) перестают работать, причиной могут быть ошибки сертификата. Приложения могут выдавать такие ошибки, как SSL: CERTIFICATE_VERIFY_FAILED, self-signed certificate in certificate chain, или похожих ошибок TLS.

Эти приложения не используют хранилище доверенных сертификатов операционной системы и поэтому не доверяют установленному вами корневому сертификату Cloudflare. У них часто есть собственное хранилище доверенных сертификатов, либо они используют certificate pinning, при котором ожидается оригинальный сертификат сервера, а не переподписанный Cloudflare.

Чтобы устранить эту проблему:

Создайте целенаправленную политику HTTP, которая обходит расшифровку для конкретных доменов, к которым нужен доступ этим инструментам. Разместите эту политику с более высоким приоритетом (более низким порядковым номером), чем ваша основная политика расшифровки TLS.

Создайте список который включает такие хосты, как github.com, *.amazonaws.com, а также *.docker.io.

Селектор	Оператор	Значение	Действие
Домен	in list	Домены CLI-инструмента	Do Not Inspect

Вы можете настроить некоторые инструменты так, чтобы они доверяли пользовательскому CA, или отключить проверку SSL. Это менее безопасно и сложнее в управлении в больших масштабах. Дополнительные сведения см. в Установите сертификат вручную.

Симптом: пользовательская страница блокировки не отображается

Если HTTP-политика блокирует запрос пользователя, его браузер вернёт общую ошибку (ERR_SSL_PROTOCOL_ERROR) вместо настроенной страницы блокировки Gateway.

Это происходит из-за того, что браузер не доверяет сертификату, который предъявляет страница блокировки и который подписан корневым сертификатом Cloudflare. Это означает, что сертификат не установлен или не является доверенным на устройстве пользователя.

Чтобы устранить эту проблему:

Убедитесь, что корневой сертификат Cloudflare установлено на устройстве.
Убедитесь, что сертификат размещен в правильном системном хранилище доверенных сертификатов (например, в хранилище System приложения Keychain на macOS или в хранилище Trusted Root Certification Authorities для локального компьютера в Windows).
Если вы используете MDM, убедитесь, что сценарий развертывания корректно устанавливает сертификат и добавляет его в доверенные.

Частный DNS и внутренние ресурсы не работают

Вы настроили в Gateway разрешение внутренних имён хостов, но пользователи не могут получить к ним доступ. Например, пользователь, подключённый через Cloudflare One Client, пытается обратиться к внутреннему сервису вида jira.mycompany.local, но DNS-запрос завершается ошибкой.

Распространённые причины	Решение
Отсутствующая или неверная политика резолвера	Перейдите в Политики трафика > Резолвера политики. Создайте политику, которая соответствует суффиксу вашего внутреннего домена и перенаправляет запросы на IP-адреса ваших внутренних DNS-серверов.
Split Tunnel исключает приватный диапазон IP-адресов	Если ваши внутренние ресурсы находятся в диапазоне частных IP-адресов (например, `10.0.0.0/8`), этот диапазон должен быть включен в туннель. Если он находится в списке Exclude list вашей конфигурации Split Tunnel, Cloudflare One Client не будет проксировать этот трафик.
Неправильная настройка Local Domain Fallback	Используйте политики Resolver для корпоративного DNS. Используйте Local Domain Fallback только для доменов, характерных для непосредственной физической сети пользователя.

Дополнительные ресурсы по Gateway

Дополнительные сведения см. в полном руководстве по устранению неполадок Gateway.

Полное руководство по устранению неполадок Gateway ❯