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

During clone, fetch and push git wraps it as "error: RPC failed; curl 56 GnuTLS recv error (-110): …"; during ls-remote or the first request it appears after "fatal: unable to access '<url>': ". OpenSSL builds of git report the same event as "OpenSSL SSL_read: … unexpected eof while reading".

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

What it means

While git was receiving data over HTTPS, the TCP connection closed without the TLS close_notify message that marks a proper end. GnuTLS (error -110, GNUTLS_E_PREMATURE_TERMINATION) treats that as a failed read, so the clone, fetch or push aborts. Certificates were fine; something cut the connection in the middle of the transfer.

Why it happens

• A proxy, firewall or NAT gateway drops the connection

  common

  Corporate proxies and firewalls with connection or idle time limits, VPN clients and some home routers cut long-running HTTPS transfers without a TLS shutdown.

• The Git server or its reverse proxy times out

  common

  Large repositories take a while to pack on the server side. If nginx, HAProxy or a load balancer in front of GitLab, Gitea or Bitbucket has a short timeout, the connection is closed while git is still waiting.

• Very large clones or pushes

  occasional

  Repositories with big binary history push transfers into the range where every time or size limit on the path matters. Raising http.postBuffer is commonly suggested but only changes how git sends request bodies; it does not stop a connection from being cut.

• Unstable network links

  occasional

  Wi-Fi roaming, mobile tethering and congested VPN links can reset connections mid-transfer; the same command then succeeds on a retry or a wired connection.

How to fix it

1. 1.

   Trace the transfer

   GIT_TRACE_CURL shows the HTTP exchange with time stamps. A failure after a round number of seconds points to a timeout; a failure at random points to the network.

   # 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.

   Transfer less in one request

   A partial clone (--filter=blob:none) or a shallow clone followed by git fetch --unshallow splits the work into smaller requests that are less likely to hit a limit.

   # 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.

   Server owners: raise proxy timeouts and body limits

   Give the reverse proxy in front of the Git server timeouts that cover your largest repositories, and do not limit request body size for Git endpoints.

   # 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.

   Use SSH instead of HTTPS

   If the HTTPS path goes through a proxy that cuts transfers and SSH is permitted, an SSH remote avoids that hop.

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

← Browse the full signature error database