← Cloudflare One / cloudflare-one / networks / connectors / cloudflare-tunnel / troubleshoot-tunnels

Распространённые ошибки

В этом разделе перечислены наиболее распространенные ошибки, с которыми вы можете столкнуться при подключении ресурсов через Cloudflare Tunnel. Если нужной проблемы нет в списке ниже, обратитесь к Устранение неполадок Cloudflare One, просмотрите свой Журналы туннеля, или обратитесь в службу поддержки Cloudflare.

Вы можете проверить статус подключения туннеля либо через панель управления Cloudflare (перейдя в Сеть > Tunnels) или выполнив cloudflared tunnel list команду. Для каждого туннеля отображается статус, который отражает его текущее состояние подключения:

Если эта ошибка появляется при установке удаленно управляемого туннеля, убедитесь, что никакой другой 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 One, например SSH-сессии, могут длиться до восьми часов. Однако сбои на пути прохождения трафика могут приводить к более частым разрывам соединения. Часто такие разрывы вызваны плановыми работами по обслуживанию, например обновлениями и перезапусками дата-центров, серверов или служб. Если вы считаете, что причина не в этих событиях, соберите соответствующие журналы клиента и Журналы туннеля и обратитесь в Support.

Если отключения в основном затрагивают неактивные сессии SSH, соединения WebSocket или другие долгоживущие соединения, причина может быть в транспортном протоколе.

Когда cloudflared использует QUIC, неактивные сеансы могут быть более чувствительны к сетевым устройствам, которые агрессивно завершают неактивный трафик UDP по тайм-ауту. Если неактивные соединения обрываются постоянно, попробуйте один или несколько из следующих способов:

• Настройте keepalive-сигналы на уровне приложения, такие как ServerAliveInterval для SSH.
• Протестировать с помощью cloudflared имеет значение protocol: http2.
• Проверьте локальные брандмауэры, устройства NAT и вышестоящее сетевое оборудование на наличие коротких таймеров простоя UDP.

Об ошибках установления соединения из-за блокировки трафика QUIC см. в разделах устранения неполадок QUIC выше.

Чтобы отправить эхо-запрос (ping) на IP-адрес за Cloudflare Tunnel, система должна разрешать трафик ICMP через cloudflared. Инструкции по настройке см. в документация по ICMP-прокси.

Эта ошибка возникает, когда вы пытаетесь добавить маршрут CIDR, который попадает в диапазон Cloudflare One Client Диапазон IP-адресов CGNAT. 100.96.0.0/12 диапазон, который охватывает адреса от 100.96.0.1 к 100.111.255.254, зарезервирован для внутренней маршрутизации WARP и не может быть добавлен как маршрут Cloudflare Tunnel. Чтобы подключить вашу приватную сеть, нужно изменить её IP/CIDR так, чтобы он не пересекался с 100.96.0.0/12.

Если вы видите ошибку с заголовком This site can't provide a secure connection и подзаголовок <hostname> uses an unsupported protocol, вам необходимо заказать Advanced Certificate.

Если вы добавили многоуровневый субдомен (более одного уровня поддомена), необходимо заказать Advanced Certificate для имени хоста так как универсальный сертификат Cloudflare по умолчанию не покрывает публичное имя хоста.

Дополнительные сведения об ошибках Tunnel см. в ваших Журналы туннеля или обратитесь в службу поддержки Cloudflare.