GnuTLS recv error (-110): The TLS connection was non-properly terminated.

При clone, fetch и push git выводит эту ошибку внутри сообщения «error: RPC failed; curl 56 GnuTLS recv error (-110): …»; при ls-remote или первом запросе она идёт после «fatal: unable to access '<url>': ». Сборки git с OpenSSL сообщают о том же событии так: «OpenSSL SSL_read: … unexpected eof while reading».

git over HTTPS with libcurl-gnutls (Debian, Ubuntu) — GNUTLS_E_PREMATURE_TERMINATION

Что это означает

Пока git получал данные по HTTPS, TCP-соединение закрылось без сообщения TLS close_notify, которое обозначает штатное завершение. GnuTLS (ошибка -110, GNUTLS_E_PREMATURE_TERMINATION) считает это неудачным чтением, поэтому clone, fetch или push прерывается. С сертификатами всё в порядке: что-то оборвало соединение посреди передачи данных.

Почему это происходит

• Прокси, межсетевой экран или NAT-шлюз обрывает соединение

  часто

  Корпоративные прокси и межсетевые экраны с ограничениями на длительность соединения или время простоя, VPN-клиенты и некоторые домашние маршрутизаторы обрывают долгие HTTPS-передачи без штатного завершения TLS.

• Git-сервер или его обратный прокси прерывает соединение по тайм-ауту

  часто

  Большие репозитории упаковываются на стороне сервера не сразу. Если у nginx, HAProxy или балансировщика нагрузки перед GitLab, Gitea или Bitbucket короткий тайм-аут, соединение закрывается, пока git ещё ждёт ответа.

• Очень большие клоны или push-операции

  иногда

  В репозиториях с большой историей двоичных файлов передачи становятся настолько объёмными, что начинает играть роль любое ограничение по времени или размеру на пути трафика. Часто советуют увеличить http.postBuffer, но это меняет лишь то, как git отправляет тела запросов, и не мешает оборвать соединение.

• Нестабильные сетевые каналы

  иногда

  Роуминг между точками доступа Wi-Fi, раздача интернета с телефона и перегруженные VPN-каналы могут сбрасывать соединения посреди передачи; та же команда затем проходит при повторной попытке или по проводному подключению.

Как исправить

1. 1.

   Включите трассировку передачи

   GIT_TRACE_CURL показывает HTTP-обмен с метками времени. Сбой через круглое число секунд указывает на тайм-аут, а сбой в случайный момент — на сеть.

   # Where does the transfer stop? Time stamps show cut-offs at fixed timeouts.
   GIT_TRACE_CURL=1 GIT_TRACE_CURL_NO_DATA=1 git clone https://git.example.com/team/app.git 2>&1 | tail -40

2. 2.

   Передавайте меньше данных за один запрос

   Частичное клонирование (--filter=blob:none) или поверхностное клонирование с последующим git fetch --unshallow разбивает работу на запросы поменьше, которые реже упираются в ограничения.

   # Transfer less per request: shallow or partial clone, then fetch the rest
   git clone --filter=blob:none https://git.example.com/team/app.git
   git clone --depth 1 https://git.example.com/team/app.git && cd app && git fetch --unshallow

3. 3.

   Владельцам серверов: увеличьте на прокси тайм-ауты и лимиты на размер тела запроса

   Задайте обратному прокси перед Git-сервером такие тайм-ауты, которых хватает на самые большие репозитории, и не ограничивайте размер тела запроса для эндпоинтов Git.

   # Reverse proxy in front of the Git server (nginx), for long clones and pushes
   proxy_read_timeout 600s;
   proxy_send_timeout 600s;
   client_max_body_size 0;

4. 4.

   Используйте SSH вместо HTTPS

   Если HTTPS-трафик идёт через прокси, который обрывает передачи, а SSH разрешён, удалённый репозиторий по SSH позволяет обойти этот промежуточный узел.

   # Bypass the HTTPS path (and the proxy that cuts it) entirely
   git remote set-url origin git@git.example.com:team/app.git

← Открыть всю базу ошибок подписей