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

Durante clone, fetch y push, git lo envuelve como «error: RPC failed; curl 56 GnuTLS recv error (-110): …»; durante ls-remote o la primera solicitud aparece después de «fatal: unable to access '<url>': ». Las compilaciones de git con OpenSSL notifican el mismo evento como «OpenSSL SSL_read: … unexpected eof while reading».

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

Qué significa

Mientras git recibía datos por HTTPS, la conexión TCP se cerró sin el mensaje close_notify de TLS que marca un final correcto. GnuTLS (error -110, GNUTLS_E_PREMATURE_TERMINATION) lo trata como una lectura fallida, así que la operación clone, fetch o push se interrumpe. Los certificados estaban bien; algo cortó la conexión a mitad de la transferencia.

Por qué ocurre

• Un proxy, un firewall o una pasarela NAT corta la conexión

  frecuente

  Los proxies y firewalls corporativos con límites de duración de la conexión o de inactividad, los clientes VPN y algunos routers domésticos cortan las transferencias HTTPS largas sin un cierre TLS.

• Se agota el tiempo de espera del servidor Git o de su proxy inverso

  frecuente

  Los repositorios grandes tardan un rato en empaquetarse en el lado del servidor. Si nginx, HAProxy o un balanceador de carga delante de GitLab, Gitea o Bitbucket tiene un tiempo de espera corto, la conexión se cierra mientras git sigue esperando.

• Operaciones clone o push muy grandes

  ocasional

  Los repositorios con un historial binario grande llevan las transferencias a un volumen en el que importa cada límite de tiempo o de tamaño de la ruta. Subir http.postBuffer es una sugerencia habitual, pero solo cambia cómo envía git los cuerpos de las solicitudes; no impide que se corte la conexión.

• Enlaces de red inestables

  ocasional

  El roaming entre puntos de acceso Wi-Fi, la conexión compartida desde un teléfono y los enlaces VPN congestionados pueden restablecer las conexiones a mitad de la transferencia; después, el mismo comando funciona al reintentarlo o con una conexión por cable.

Cómo solucionarlo

1. 1.

   Trazar la transferencia

   GIT_TRACE_CURL muestra el intercambio HTTP con marcas de tiempo. Un fallo tras un número redondo de segundos apunta a un tiempo de espera; un fallo en momentos aleatorios apunta a la red.

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

   Transferir menos en cada solicitud

   Un clon parcial (--filter=blob:none) o un clon superficial seguido de git fetch --unshallow divide el trabajo en solicitudes más pequeñas con menos probabilidades de topar con un límite.

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

   Propietarios del servidor: aumentar los tiempos de espera y los límites de cuerpo del proxy

   Configura en el proxy inverso que está delante del servidor Git tiempos de espera que cubran tus repositorios más grandes, y no limites el tamaño del cuerpo de las solicitudes en los endpoints de 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.

   Usar SSH en lugar de HTTPS

   Si la ruta HTTPS pasa por un proxy que corta las transferencias y SSH está permitido, un remoto SSH evita ese salto.

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

← Explorar toda la base de datos de errores de firma