Ошибка GnuTLS error in the pull function появляется в момент, когда программа — чаще всего curl, git, yt-dlp или FTP-клиент вроде FileZilla — читает данные из уже установленного TLS-соединения, и это соединение внезапно разрывается. Функция «pull» в библиотеке GnuTLS отвечает именно за приём байтов из сокета, поэтому сбой в ней означает: канал связи оборвался на этапе передачи, а не на этапе рукопожатия.
Типичный сценарий: загрузка файла идёт нормально несколько секунд, затем обрывается с сообщением GnuTLS recv error (-54): Error in the pull function или похожей формулировкой. Код -54 указывает на то, что удалённая сторона закрыла соединение без корректного завершения TLS-сессии. Ниже разберём, почему это происходит и как устранить проблему в зависимости от источника.
Что означает эта ошибка технически
GnuTLS — это библиотека реализации протоколов TLS/SSL, которую используют многие программы в Linux вместо OpenSSL. Когда приложение вызывает функцию чтения данных, GnuTLS обращается к так называемой pull-функции — callback-обёртке над системным вызовом recv(). Если сокет вернул ошибку или неожиданный конец потока, библиотека пробрасывает её наверх в виде «Error in the pull function».
Важно понимать: сама библиотека здесь обычно не виновата. Она лишь сообщает, что транспортный уровень подвёл. Реальная причина почти всегда находится в одном из трёх мест — на стороне сервера, в промежуточном сетевом оборудовании или в локальной конфигурации клиента.
Отличить эту ошибку от проблем с сертификатами просто: ошибки проверки сертификата возникают сразу, до начала передачи данных, а сбой pull-функции случается уже в процессе обмена — иногда на середине скачивания большого файла.
Основные причины сбоя
Практика показывает, что чаще всего обрыв TLS-соединения провоцируют следующие факторы:
- 🔌 Сервер принудительно закрывает соединение — из-за таймаута, ограничения на длительность сессии или защиты от медленных клиентов;
- 🛡️ Файрвол или DPI-система провайдера разрывает «подозрительные» длинные TLS-сессии;
- 🌐 Нестабильный канал связи — потери пакетов, перегруженный VPN или прокси;
- 📦 Несовместимость версий TLS — сервер требует TLS 1.3, а старая сборка клиента с GnuTLS его не поддерживает корректно;
- ⏱️ Слишком агрессивные таймауты на стороне клиента при медленной отдаче данных сервером.
Отдельно стоит упомянуть FTP через TLS (FTPS): там контрольное соединение и соединение передачи данных живут независимо, и разрыв одного из них файрволом — классическая причина именно этой ошибки в lftp и FileZilla.
Диагностика: как найти источник проблемы
Прежде чем менять настройки, полезно локализовать сбой. Проверьте, воспроизводится ли ошибка при обращении к другому серверу: если да — проблема почти наверняка на вашей стороне (сеть, прокси, файрвол). Если сбой происходит только с одним конкретным хостом, вероятнее всего виноват сервер или путь до него.
Запустите команду с подробным выводом, чтобы увидеть, на каком этапе рвётся соединение:
curl -v https://example.com/file.zip -o file.zipВ выводе с флагом -v видно, прошло ли TLS-рукопожатие успешно и на каком объёме данных произошёл обрыв. Если рукопожатие завершается, а разрыв случается при чтении тела ответа — это подтверждает диагноз «обрыв на этапе передачи».
Решения для curl и загрузчиков
Для начала попробуйте самые безопасные варианты, не меняя системные настройки. Часто помогает банальный повтор с докачкой: флаг -C - у curl позволяет продолжить прерванную загрузку с места обрыва, если сервер поддерживает диапазоны.
Если обрывы регулярные, увеличьте таймауты и ограничьте скорость — некоторые серверы и промежуточные устройства рвут соединения при слишком быстром или, наоборот, слишком медленном приёме:
curl --retry 5 --retry-all-errors --connect-timeout 30 -C - -O https://example.com/file.zipЕщё один рабочий приём — принудительно выбрать версию TLS. Если сервер некорректно работает с TLS 1.3, попробуйте ограничить соединение версией 1.2:
curl --tlsv1.2 --tls-max 1.2 https://example.com/☑️ Что проверить при ошибке pull function в curl
⚠️ Внимание: не используйте флаг-k(--insecure) как «решение» этой ошибки. Он отключает проверку сертификата, но не устраняет обрыв соединения, зато делает трафик уязвимым для перехвата.
Ошибка в git: clone, pull и push
В git ошибка GnuTLS recv error (-54) особенно часто возникает при клонировании крупных репозиториев: соединение живёт долго, передаётся много данных, и любое сетевое устройство на пути может его оборвать. Симптом — обрыв на стадии Receiving objects с последующим сообщением про pull function.
Что можно сделать в этом случае:
- 📡 Увеличить буфер HTTP:
git config --global http.postBuffer 524288000— помогает при push больших изменений; - 🔄 Использовать неглубокое клонирование:
git clone --depth 1сокращает объём передаваемых данных и время жизни соединения; - 🔑 Перейти с HTTPS на SSH — SSH-транспорт не использует GnuTLS и устойчивее к таким обрывам;
- 🧩 Отключить HTTP/2 для git:
git config --global http.version HTTP/1.1— в некоторых окружениях это снимает проблему.
Если ошибка появляется только через корпоративную сеть или VPN, проверьте работу через другое подключение — например, мобильный интернет. Успешный клон через альтернативный канал однозначно укажет на виновника.
FTPS и FileZilla: специфика ошибки
В FTP-клиентах с TLS-шифрованием эта ошибка нередко связана с разрывом канала данных, в то время как управляющее соединение остаётся живым. Причина обычно в файрволе или NAT, который не умеет корректно отслеживать динамические порты FTPS и рвёт передачу.
Проверьте в настройках клиента режим соединения: пассивный режим (PASV) обычно надёжнее проходит через NAT, чем активный. В FileZilla это настраивается в разделе настроек соединения — переключите режим передачи и проверьте, исчезнет ли сбой. Если управляете сервером сами, убедитесь, что диапазон пассивных портов открыт и проброшен.
⚠️ Внимание: понижение уровня шифрования или переход на незашифрованный FTP ради устранения ошибки — плохая идея: логин, пароль и данные пойдут по сети в открытом виде. Сначала исчерпайте варианты с настройкой пассивного режима и файрвола.
Почему ошибка часто возникает именно через VPN и прокси
VPN и прокси добавляют промежуточный узел, который инкапсулирует ваш TLS-трафик внутрь своего туннеля. При перегрузке узла, смене маршрута или срабатывании внутреннего таймаута простоя туннель может разорвать соединение, хотя ваш клиент и сервер исправны. GnuTLS при этом честно сообщает об обрыве в pull-функции. Проверка проста: временно отключите VPN и повторите операцию. Если ошибка исчезла — меняйте сервер VPN, протокол туннеля или обратитесь к провайдеру услуги.
Системные причины и обновление библиотек
Иногда виновата устаревшая версия самой библиотеки GnuTLS или программы, собранной с ней. Старые выпуски могли содержать ошибки в обработке TLS 1.3 и session resumption, что приводило к обрывам с отдельными серверами. Узнать версию можно командой:
gnutls-cli --versionОбновите систему штатным пакетным менеджером — в актуальных выпусках дистрибутивов библиотека получает исправления регулярно. Если программа установлена из стороннего источника (snap, flatpak, статическая сборка), проверьте наличие обновлений именно для неё: она может тащить собственную копию GnuTLS.
Также убедитесь, что системное время выставлено верно. Расхождение часов само по себе реже вызывает именно pull-ошибку (обычно оно даёт ошибки валидации сертификата), но в сочетании с session tickets может приводить к странным разрывам.
Сравнение типичных сценариев и решений
| Сценарий | Вероятная причина | Первичное действие |
|---|---|---|
| curl, обрыв на большом файле | Таймаут на сервере или в сети | Докачка с -C - и --retry |
| git clone крупного репозитория | Долгая сессия, разрыв посредником | --depth 1 или переход на SSH |
| FileZilla, FTPS | Файрвол рвёт канал данных | Пассивный режим, проверка портов |
| Любая программа через VPN | Обрыв туннеля | Проверка без VPN |
| Только один конкретный сервер | Настройки или сбой на стороне сервера | Связаться с администратором ресурса |
Частые вопросы
Опасна ли ошибка GnuTLS pull function для системы?
Нет, это не сбой системы и не признак вредоносного ПО. Ошибка лишь фиксирует разрыв TLS-соединения во время передачи данных. Недокачанный файл может оказаться повреждённым, поэтому важные загрузки лучше повторить или проверить контрольные суммы, если они опубликованы.
Почему ошибка возникает только с одним сайтом?
Значит, причина на стороне этого сервера или на маршруте до него: ограничения по длительности сессии, балансировщик нагрузки, защита от DDoS. С вашей стороны можно попробовать сменить версию TLS, отключить HTTP/2 или повторять запросы с автоматическими retry.
Помогает ли переустановка программы?
Редко. Переустановка имеет смысл только если программа использует устаревшую встроенную копию GnuTLS — тогда лучше сразу установить актуальную версию. В большинстве случаев проблема сетевая, и переустановка ничего не меняет.
Что означает код (-54) в сообщении об ошибке?
Это внутренний код GnuTLS GNUTLS_E_PULL_ERROR, сигнализирующий, что низкоуровневая функция чтения из сокета завершилась неудачно. Он не уточняет причину разрыва — её нужно искать диагностикой сети и сервера.
Можно ли исправить ошибку настройкой MTU?
Иногда да: при прохождении трафика через туннели (VPN, PPPoE) слишком большой MTU приводит к фрагментации и потерям, что может обрывать TLS-сессии. Понижение MTU на интерфейсе — допустимый эксперимент, но делайте это осознанно и запомните исходное значение, чтобы откатить изменение.