← Cloudflare Tunnel / tunnel

Устранение неполадок

Используйте эту страницу, чтобы диагностировать и устранить распространённые проблемы с Cloudflare Tunnel. Многие из них решаются обновлением до последней версии cloudflared : см. Обновите cloudflared прежде чем продолжать расследование.

Сведения о мониторинге состояния туннеля, журналах и метриках см. в Мониторинг.

Когда cloudflared не может обратиться к сети Cloudflare, журналы конкретные сообщения об ошибках, указывающие, связана ли проблема с разрешением DNS, QUIC (UDP) или TCP-соединением.

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 172.19.64.1:53: no such host"

Эта ошибка означает, что DNS-резолвер, настроенный на вашем компьютере, не может преобразовать SRV-записи, которые cloudflared которую cloudflared использует для обнаружения Целевые IP-адреса Cloudflare Tunnel. Наиболее частые причины: корпоративные DNS-резолверы, удаляющие или блокирующие SRV-записи, а также DNS-резолверы, возвращающие сжатые SRV-записи.

Чтобы провести диагностику:

На cloudflared хост-машине выполните:

dig SRV _v2-origintunneld._tcp.argotunnel.com

Если вы получаете SERVFAIL, NXDOMAIN, или пустой ответ, проверьте через публичный DNS-резолвер Cloudflare:

dig SRV _v2-origintunneld._tcp.argotunnel.com @1.1.1.1

Чтобы решить проблему:

• Если 1.1.1.1 возвращает результаты, а локальный резолвер нет, настройте на хосте использование Cloudflare DNS (1.1.1.1) или другой публичный DNS-резолвер.
• Если ни один из резолверов не возвращает результатов, скорее всего, ваш брандмауэр блокирует исходящие DNS-запросы (UDP-порт 53). Обратитесь к администратору сети, чтобы разрешить трафик DNS.

ERR edge discovery: error looking up Cloudflare edge IPs: the DNS query failed
    error="lookup _v2-origintunneld._tcp.argotunnel.com on 127.0.0.11:53:
    read udp 127.0.0.1:53467->127.0.0.11:53: i/o timeout"

Этот вариант означает, что DNS-запросы от cloudflared полностью блокируются или отбрасываются, и резолвер так и не отвечает. Это часто встречается в контейнерных средах (Docker, Kubernetes), где внутренний DNS-резолвер (127.0.0.11) недоступен или настроен неправильно.

Чтобы решить проблему:

• В Docker проверьте конфигурацию DNS своего контейнера (/etc/resolv.conf). Резолвер можно переопределить с помощью --dns 1.1.1.1 при запуске контейнера.
• В Kubernetes проверьте kube-dns или CoreDNS сервис запущен и доступен из пода.
• На cloudflared хосте убедитесь, что резолвер, указанный в /etc/resolv.conf доступен и отвечает на запросы.

ERR Failed to dial a quic connection error="failed to dial to edge with quic:
    timeout: handshake did not complete in time" connIndex=0 ip=198.41.192.227
INF Retrying connection in up to 2s connIndex=0 ip=198.41.192.227

Эта ошибка означает cloudflared разрешил Целевые IP-адреса Cloudflare Tunnel но не удалось выполнить QUIC-рукопожатие через порт UDP 7844. Ваша сеть или брандмауэр блокирует исходящий UDP-трафик к Cloudflare.

cloudflared повторяет попытки с экспоненциальной задержкой (2, 4, 8, 16, 32, до 64 секунд). После исчерпания попыток происходит переход на HTTP/2 через TCP:

INF Switching to fallback protocol http2 connIndex=0

Если резервный вариант тоже не сработает, вы увидите Таймаут TCP-соединения ошибка.

Чтобы провести диагностику:

На cloudflared хост-машине проверьте подключение к порту 7844:

nc -uvz -w 3 198.41.192.227 7844

Замените 198.41.192.227 с IP-адресом, указанным в вашем сообщение об ошибке. Если порт закрыт или заблокирован брандмауэром, команда вернёт Connection refused или превысит время ожидания.

Чтобы решить проблему:

• Разрешить исходящий UDP-трафик через порт 7844 в брандмауэре или группе безопасности. См. раздел полный список IP-адресов и портов.
• Если вы не можете открыть UDP, cloudflared автоматически переключится на HTTP/2 через TCP. Также можно принудительно включить HTTP/2, указав флаг --protocol http2 параметр запуска, но для более высокой производительности рекомендуется QUIC.

ERR Unable to establish connection with Cloudflare edge
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0
ERR Serve tunnel error
    error="DialContext error: dial tcp 198.41.200.43:7844: i/o timeout" connIndex=0

Эта ошибка означает cloudflared не может обратиться к Cloudflare через порт TCP 7844. Если вы также видите Тайм-аут рукопожатия QUIC и выше, блокируются и UDP, и TCP, поэтому туннель вообще не может установить соединение.

Чтобы провести диагностику:

Для быстрой проверки выполните:

curl -v https://region1.v2.argotunnel.com:7844

Если соединение зависает, трафик отбрасывается между вашим хостом и Cloudflare.

Чтобы проверить, cloudflared может подключиться через порт 7844, выполните:

nc -vz -w 3 198.41.200.43 7844

Замените 198.41.200.43 с IP-адресом, указанным в вашем сообщение об ошибке. Если порт закрыт или заблокирован брандмауэром, команда вернёт Connection refused или превысит время ожидания.

Чтобы решить проблему:

• Разрешить исходящий TCP-трафик через порт 7844 к Диапазоны IP-адресов Cloudflare Tunnel.
• Если ваша среда блокирует порт 7844 полностью (как UDP, так и TCP), туннель не сможет работать. Обратитесь к администратору сети, чтобы разрешить исходящий трафик на этом порту.

Если эта ошибка появляется при установке удаленно управляемого туннеля, убедитесь, что никакой другой cloudflared экземпляры работают как служба на этой машине. На этой машине может работать только один экземпляр cloudflared может работать как служба только на одной машине. Вместо этого добавьте дополнительные маршруты к существующему туннелю. Либо вы можете запустить sudo cloudflared service uninstall чтобы удалить cloudflared.

Если не удается сохранить публичное имя хоста туннеля, выберите другое имя хоста или удалите существующую запись DNS. Проверьте DNS-записи для вашего домена из Панель управления Cloudflare ↗.

Если при запуске туннеля вы получаете следующую ошибку, ещё раз проверьте config.yml файл и убедитесь, что credentials-file указывает на правильное расположение. Возможно, потребуется изменить /root/ в вашу домашнюю директорию.

cloudflared tunnel run

2021-06-04T06:21:16Z INF Starting tunnel tunnelID=928655cc-7f95-43f2-8539-2aba6cf3592d
Tunnel credentials file '/root/.cloudflared/928655cc-7f95-43f2-8539-2aba6cf3592d.json' doesn't exist or is not a file

Чтобы начать использовать Cloudflare Tunnel, пользователь с ролью Super Administrator в аккаунте Cloudflare должен сначала войти через cloudflared login. Клиент откроет окно браузера и предложит пользователю выбрать имя хоста в своем аккаунте Cloudflare. После выбора Cloudflare сгенерирует сертификат, состоящий из трех компонентов:

• Публичный ключ исходного сертификата для этого имени хоста
• Приватный ключ исходного сертификата для этого домена
• Токен, уникальный для Cloudflare Tunnel

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

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

Это означает, что источник использует сертификат, который cloudflared не доверяет. Например, эта ошибка может появиться, если вы используете проверку SSL/TLS в прокси между вашим сервером и Cloudflare. Чтобы устранить проблему:

• Добавьте сертификат в системное хранилище сертификатов.
• Используйте --origin-ca-pool флаг и укажите путь к сертификату.
• Используйте --no-tls-verify флаг, чтобы остановить cloudflared проверки сертификата на наличие цепочки доверия.

A 1033 ошибка означает, что ваш туннель не подключён к сети Cloudflare, так как сеть Cloudflare не может найти работоспособный cloudflared экземпляр для приёма трафика.

Сначала проверьте, отображается ли ваш туннель как Active в Панель управления Cloudflare ↗ перейдя в Сеть > Tunnels или выполните cloudflared tunnel list. Если туннель не Active, просмотрите следующее и предпримите действия, необходимые для статуса вашего туннеля:

Дополнительные сведения см. в полный список ошибок Cloudflare 1xxx.

A 502 Bad Gateway ошибка с Unable to reach the origin service. The service may be down or it may not be responding to traffic from cloudflared на маршруте туннеля означает, что сам туннель подключён к сети Cloudflare, но cloudflared не может подключиться к исходной службе, указанной в правиле ingress. В отличие от ошибка 1033, что означает отсутствие подключения туннеля к Cloudflare, ошибка 502 означает, что проблема находится между cloudflared и вашей локальной службой.

Чтобы определить точную причину, проверьте свои Журналы туннеля для error-уровня. Наиболее частые причины:

Если исходная служба остановлена или никогда не запускалась, cloudflared логи будут показывать ошибку, похожую на следующую:

error="dial tcp [::1]:8080: connect: connection refused"

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

curl -v http://localhost:8080

Если служба не запущена, запустите или перезапустите её. Убедиться, что служба прослушивает порт, можно с помощью команды ss -tlnp | grep <PORT> (Linux) или lsof -iTCP -sTCP:LISTEN -nP | grep <PORT> (macOS).

Если источник ожидает HTTPS, а в маршруте туннеля указан http://, или наоборот, cloudflared логи будут показывать ошибку, похожую на следующую:

error="net/http: HTTP/1.x transport connection broken: malformed HTTP response \"\x15\x03\x01\x00\x02\x02\""

Чтобы устранить это, измените URL-адрес службы в маршруте туннеля в соответствии с протокол который ожидает ваш источник. Например, измените http://localhost:8080 к https://localhost:8080. Если вы используете туннель с локальным управлением, обновите правило входящего трафика в файл конфигурации.

Если порт в маршруте туннеля не совпадает с портом, который прослушивает ваша служба, cloudflared запишет в журнал connection refused ошибка для этого порта. Проверьте URL службы в правиле ingress и сравните его с портом, к которому привязано ваше приложение.

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

error="x509: certificate is valid for example.com, not localhost"

Обычно это происходит, когда исходный сервер использует самоподписанный сертификат, или когда прокси-сервер проверки SSL/TLS находится между cloudflared и источником.

Чтобы устранить это, используйте один из следующих подходов:

• Задайте originServerName к имени хоста в сертификате источника в маршруте туннеля. Если вы используете туннель с локальным управлением, вот пример файл конфигурации:

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        originServerName: app.example.com

• Укажите сертификат CA с помощью caPool:

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        caPool: /path/to/ca-cert.pem

• В крайнем случае отключите проверку TLS с помощью noTLSVerify. Это не рекомендуется для производственных сред.

  ingress:
    - hostname: app.example.com
      service: https://localhost:443
      originRequest:
        noTLSVerify: true

Эта ошибка возникает, когда cloudflared не распознаёт SSL/TLS-сертификат, предоставленный вашим источником. Чтобы устранить проблему, задайте имя исходного сервера параметр в имя хоста, указанное в сертификате источника. Ниже приведён пример конфигурации туннеля с локальным управлением:

ingress:
  - hostname: test.example.com
    service: https://localhost:443
    originRequest:
      originServerName: test.example.com

Это означает, что ваш cloudflared access клиент не может подключиться к вашему cloudflared tunnel источник. Чтобы это диагностировать, посмотрите cloudflared tunnel логи. Распространённая основная причина заключается в том, что cloudflared tunnel не может проксировать запросы к вашему источнику (например, из-за неправильной настройки ingress, недоступности источника или невозможности проверить HTTPS-сертификат источника с помощью cloudflared tunnel). Если cloudflared tunnel не имеет журналов, это значит, что сеть Cloudflare не может направить к нему websocket-трафик.

У этой ошибки может быть несколько возможных первопричин:

• Ваш cloudflared tunnel либо не запущен, либо не подключён к сети Cloudflare.
• WebSocket-соединения не включено.
• В вашем аккаунте Cloudflare включен Universal SSL, но режим шифрования SSL/TLS установлен на Отключено (небезопасно). Чтобы решить эту проблему, перейдите в SSL/TLS > Обзор в панели управления Cloudflare и установите для режима шифрования SSL/TLS значение Flexible, Full, или Full (strict).
• Ваши запросы блокируются Super Bot Fight Mode. Чтобы решить эту проблему, убедитесь, что вы задали Definitely automated к Allow в настройках Bot Fight Mode.
• У вашего приложения Access для SSH или RDP есть Привязка cookie включено. Чтобы отключить файл cookie, перейдите в Контроль доступа > Приложения и измените настройки приложения.
• Один или несколько Workers routes пересекаются с именем хоста туннеля, и Workers не обрабатывают трафик корректно. Чтобы устранить это, либо исключите свой туннель из маршрута Worker, не определяя маршрут, который включает имя хоста туннеля, либо настройте Worker так, чтобы он обрабатывал только определённые пути, а все остальные запросы перенаправлял на origin (например, используя return fetch(req)).

Если cloudflared возвращает ошибку error="remote error: tls: handshake failure", убедитесь, что данное имя хоста охвачено SSL-сертификатом. При использовании многоуровневого субдомена расширенный сертификат может потребоваться, так как Universal SSL не покрывает более одного уровня поддомена. В браузере это может отображаться как ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

Если ваш Журналы Cloudflare Tunnel возвращает socket: too many open files ошибка, это означает, что cloudflared исчерпал лимит открытых файлов на вашем компьютере. Максимальное количество открытых файлов, или дескрипторов файлов, это настройка операционной системы, которая определяет, сколько файлов может открыть процесс. Чтобы увеличить лимит открытых файлов, вам нужно настроить параметры ulimit на машине, где выполняется cloudflared.

Об этом увеличении размера буфера сообщает библиотека quic-go ↗ используемый cloudflared ↗. Подробнее об этом сообщении журнала можно узнать в репозиторий quic-go ↗. Это сообщение в журнале обычно не имеет значения, и при устранении неполадок его можно спокойно игнорировать. Однако если вы развернули cloudflared в уникальной среде с высокой пропускной способностью, то размер буфера можно вручную переопределить для целей тестирования.

Чтобы задать максимальный размер буфера приёма в Linux:

1. Создайте новый файл в /etc/sysctl.d/:

   sudo vi 98-core-rmem-max.conf

2. В файле укажите нужный размер буфера:

   net.core.rmem_max=2500000

3. Перезагрузите хост-машину, на которой выполняется cloudflared.

4. Чтобы убедиться, что изменения вступили в силу, используйте grep команда:

   sudo sysctl -a | grep net.core.rmem_max

   net.core.rmem_max = 2500000

Проксируемый трафик через Cloudflare Tunnel по умолчанию буферизуется, если только исходный сервер не включает Content-Type: text/event-stream заголовок ответа. Этот заголовок сообщает cloudflared чтобы передавать данные потоком по мере их поступления, а не буферизировать весь ответ.

Компании Cloudflare стало известно об изменении в базе данных App-ID версии 9128 для Palo Alto Networks Next Generation Firewall (NGFW), которое повлияло на требования к разрешению трафика Cloudflare Tunnel и Cloudflare One Client.

Palo Alto Networks Next Generation Firewall (NGFW) обнаруживает как Cloudflare Tunnel (cloudflared) и Cloudflare One Client (WARP с Zero Trust) как cloudflare-warp, независимо от версии базы данных App-ID. В настоящее время отдельного App-ID для cloudflared.

Эта проблема, скорее всего, затрагивает Cloudflare One Client и WARP client, так как Palo Alto Networks NGFW определяет их трафик как cloudflare-warp.

В этом разделе рассматривается Cloudflare Tunnel (cloudflared) подключается к Cloudflare по QUIC (UDP-порт 7844).

Начиная с версии базы данных App-ID 9128 (выпущена 27 июля 2026 года) требования NGFW к разрешению этого трафика изменились. Начиная с версии 9128 базы данных App-ID необходимо явно разрешить quic-base приложение в дополнение к ранее необходимым App-ID и их зависимостям.

Чтобы восстановить подключение, откатите базу данных App-ID либо явно разрешите нужные приложения и порт UDP.

Откатитесь до версии базы данных App-ID 9127 и отключите автоматические обновления App-ID до тех пор, пока Palo Alto Networks не предложит постоянное решение.

Если вы откатываете базу данных App-ID, считайте это временной мерой и согласуйте действия с командой безопасности. Включите автоматические обновления снова, как только Palo Alto Networks предоставит постоянное решение.

1. В PAN-OS перейдите в Объекты > Службы.

2. Создайте службу со следующими параметрами:

   Параметр	Значение
   Название	cloudflared_7844_udp
   Описание	Необязательно
   Протокол	UDP
   Порт назначения	7844
   Порт источника	Оставьте пустым
   Session Timeout	Inherit from application

3. Выберите OK.

1. Перейдите в Политики.
2. Создайте или измените универсальный или межзональный правило брандмауэра.
3. Настройте Источник и Назначение критерии, соответствующие нужным потокам трафика в вашей среде:
   • Источник: выберите подходящую Source Zone и/или Source Address.
   • Назначение: выберите подходящую Destination Zone и/или Destination Address.
4. В разделе Приложение, добавьте все указанные ниже приложения:
   • cloudflare-warp
   • quic-base
5. В разделе Service/URL Category, добавьте пользовательскую службу cloudflared_7844_udp.
6. Настройте правило Действие к Allow.
7. Включите журналирование в соответствии с политикой безопасности вашей организации.
8. Примените изменение политики, а затем убедитесь, что Cloudflare Tunnel может устанавливать и поддерживать соединения через брандмауэр.

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

Чтобы обеспечить эффективное разрешение запросов, когда обращение в поддержку, укажите в тикете как можно больше релевантных деталей:

• Контекст: кратко опишите сценарий или ситуацию использования (например, где находился пользователь, что он пытался сделать).

• Шаги воспроизведения: опишите действия, которые вы выполнили, чтобы воспроизвести проблему при устранении неполадок.

• Временные метки: указывайте точное время и часовой пояс возникновения проблемы.

• Попытки устранения неполадок: опишите действия или изменения, которые уже предпринимались для решения проблемы.

• ID туннеля и имя туннеля.

• cloudflared версии (выполните cloudflared --version).

• Способ настройки туннеля (локальное управление или удалённое через панель управления).

• Журналы туннеля: укажите журналы с локального компьютера.

• Диагностические журналы туннеля: укажите диагностические журналы туннеля.

Чтобы получить подробный вывод для диагностики:

• Туннели с локальным управлением: Выполните cloudflared на --loglevel debug флаг:

  cloudflared tunnel --loglevel debug run

  Чтобы сохранять журналы в файл, добавьте --logfile флаг:

  cloudflared tunnel --loglevel debug --logfile /var/log/cloudflared/cloudflared.log run

• Туннели с удалённым управлением (создан через панель управления): настройте журналирование туннеля в параметры запуска. Вы также можете просматривать журналы в режиме реального времени с помощью удалённая потоковая передача журналов функция.

При обращении в поддержку прикладывайте журналы отладки. Полный перечень сведений для включения приведен в контрольном списке выше.