ERR_CONNECTION_RESET: causas y soluciones

Qué significa ERR_CONNECTION_RESET

A diferencia de ERR_CONNECTION_REFUSED, que salta antes de que se mueva ningún dato, un reset ocurre después de que el handshake TCP tuvo éxito y la conexión ya estaba intercambiando datos. Algo a lo largo de la ruta, o uno de los propios extremos, envía entonces un paquete RST que termina la conexión sin la secuencia de cierre habitual. El navegador no tiene forma de saber si el RST vino del servidor, de un dispositivo intermedio como un firewall o un balanceador de carga, o de la propia pila de red del cliente, así que el mensaje se mantiene genérico sea cual sea la causa.

Un cierre TCP normal implica un intercambio de FIN en ambas direcciones, lo que permite que cada lado termine de enviar lo que ya tenía en cola. Un RST se salta todo eso: lo que estaba en tránsito se descarta, y cualquier dato que el servidor ya hubiera empezado a escribir pero el cliente todavía no hubiera recibido se pierde. Por eso un reset a mitad de una descarga de archivo grande o de una respuesta larga de una API a menudo deja un resultado visiblemente truncado en lugar de un fallo limpio antes de que cargara nada.

Cómo aparece el error

Chrome muestra "This site can't be reached ... ERR_CONNECTION_RESET" a mitad de la carga, a veces después de que ya se haya renderizado parte de la página. curl lo reporta directamente:

curl -v https://example.com/api/report
* TLSv1.2 (IN), TLS alert, close notify
* OpenSSL SSL_read: Connection reset by peer, errno 104
curl: (56) Recv failure: Connection reset by peer

Por el lado del servidor, nginx registra una línea equivalente para el mismo evento: readv() failed (104: Connection reset by peer) while reading upstream. Un reset que ocurre de forma constante en la misma cantidad de bytes o los mismos segundos dentro de una petición apunta a un límite de tamaño o de tiempo de espera en algún punto de la ruta, y no a un fallo de red aleatorio.

Qué causa ERR_CONNECTION_RESET

• Un firewall, un IDS o un WAF corta la conexión a mitad del flujo. Una regla que coincide a mitad de una petición o respuesta, en lugar de en el momento de la conexión, produce un reset en lugar de un rechazo inmediato.
• Problemas de MTU o de fragmentación de paquetes. Una ruta con una MTU menor de la que espera cualquiera de los dos extremos puede corromper paquetes grandes, y algunos routers mal configurados responden reseteando la conexión en lugar de fragmentar correctamente.
• Inspección TLS por parte de un antivirus o un proxy corporativo. Una interceptación que falla a mitad de un handshake o de una respuesta a menudo resetea la conexión en lugar de fallar con elegancia.
• Un proceso worker del servidor se cae a mitad de la petición. Un error de la aplicación, un cierre por falta de memoria, o un reinicio de worker durante un despliegue dejan todos una conexión abierta sin nada que la responda.
• Un desajuste de tiempo de espera de keep-alive entre el cliente y el servidor o proxy. Si el tiempo de espera de inactividad de un balanceador de carga es más corto que el del backend, puede resetear una conexión que el backend todavía considera activa.
• Interferencia o modelado de tráfico del proveedor de internet. Algunos proveedores resetean conexiones de larga duración o de mucho ancho de banda, sobre todo para streaming o descargas grandes, como una forma de gestión del tráfico.

Cómo saber de quién es la culpa

Prueba la misma petición desde una segunda red, como datos móviles en lugar del wifi de la oficina. Si funciona ahí, un firewall local, un antivirus o un proxy está interceptando la conexión. Si el reset ocurre igual en todas partes, la causa está del lado del servidor o en una regla de WAF delante de él. Una comprobación HTTP ejecutada desde varias ubicaciones a la vez muestra si el reset es general o está limitado a una red, sin que necesites un segundo dispositivo desde el que probar.

Cómo corregir ERR_CONNECTION_RESET

Si eres el visitante

1. Reinicia tu router o módem. Una entrada de tabla NAT atascada o un estado de conexión obsoleto en routers de consumo es una causa habitual y fácil de resolver.
2. Desactiva cualquier VPN o proxy y recarga. Si el reset se detiene, la VPN o el proxy están interceptando o gestionando mal la conexión.
3. Desactiva el escaneo HTTPS en tu antivirus, normalmente en un ajuste tipo "protección web" o "escaneo SSL/TLS", y vuelve a intentarlo. Si eso lo arregla, añade el sitio a una lista de exclusiones en lugar de dejar el escaneo desactivado.
4. Revisa si tienes una MTU inusualmente baja si estás en una VPN o en un punto de acceso móvil; bajarla ligeramente en el cliente puede resolver resets relacionados con la fragmentación.

Si administras el sitio

1. Revisa los registros de la aplicación y del sistema por si hay una caída o un cierre por falta de memoria alrededor del momento del reset. Un proceso worker que muere a mitad de la petición es una de las causas más habituales.
2. Revisa las reglas de WAF e IDS y sus registros. Una regla que resetea conexiones que coinciden con ciertas cargas útiles o tasas puede parecer idéntica a un fallo de red aleatorio hasta que revisas específicamente el registro de seguridad.
3. Alinea los tiempos de espera de keep-alive en toda la pila. En nginx, fija el tiempo de espera del lado del proxy para que iguale o supere el del propio backend:

   keepalive_timeout 65s;
   proxy_read_timeout 65s;

   Un desajuste aquí es una causa frecuente de resets bajo carga, cuando el frontend cierra una conexión que el backend todavía espera usar.
4. Vigila los mensajes de reset del upstream en el registro del proxy inverso, como upstream prematurely closed connection while reading response header from upstream, que apunta directamente a la aplicación del backend y no a la red.
5. Recarga después de cualquier cambio en lugar de editar en caliente: nginx -t && systemctl reload nginx valida la configuración antes de que entre en vigor.

Cómo prevenir ERR_CONNECTION_RESET

Un reset que solo aparece bajo carga, o solo para respuestas grandes, rara vez se manifiesta durante una comprobación manual rápida, ya que depende de umbrales de tiempo o tamaño que una sola petición puede no alcanzar. La monitorización continua de HTTP que comprueba el código de estado y el contenido del cuerpo según un horario desde más de 300 puntos de control en 158 ciudades detecta un patrón de reset intermitente que una prueba puntual pasaría por alto, y alerta por correo, SMS, llamada de voz, Slack, Telegram y más en cuanto empieza.

Errores relacionados

• ERR_CONNECTION_REFUSED ocurre cuando la conexión nunca llega a establecerse en absoluto.
• ERR_CONNECTION_TIMED_OUT ocurre cuando nada responde en absoluto al intento de conexión.
• This site can't be reached cubre todo el conjunto de errores de conexión que Chrome agrupa bajo un único título.

Preguntas frecuentes

¿ERR_CONNECTION_RESET significa que me han hackeado?

No. Casi siempre apunta a un dispositivo de red, a una regla de firewall, a una interceptación de antivirus, o a una caída del lado del servidor, no a un ataque a tu dispositivo.

¿Por qué ocurre esto solo con descargas de archivos grandes?

Las transferencias grandes tienen más probabilidad de toparse con un desajuste de MTU, un tiempo de espera de proxy, o un límite de tamaño configurado en un firewall o balanceador de carga, todos los cuales pueden terminar una conexión a mitad de flujo que una petición pequeña terminaría antes de dispararlos.

¿Puede causar esto mi propio antivirus?

Sí. Las funciones de escaneo HTTPS que interceptan y vuelven a cifrar el tráfico TLS a veces fallan en sitios concretos o respuestas grandes y resetean la conexión en lugar de dejarla pasar.

¿Es un reset peor que un tiempo de espera agotado?

No inherentemente. Un reset significa que algo terminó activamente la conexión, lo que suele ser más fácil de diagnosticar que un tiempo de espera agotado, donde no ocurre nada y no puedes saber si el paquete llegó a algún sitio.

¿Por qué el reset ocurre siempre en el mismo punto?

Una cantidad de bytes o un tiempo transcurrido constante antes del reset suele apuntar a un límite fijo, como un tiempo de espera de proxy, un tamaño máximo de respuesta, o un ajuste de keep-alive, en lugar de a un fallo aleatorio.

¿Puede un operador móvil resetear mis conexiones?

Algunos operadores sí resetean conexiones de larga duración como parte de la gestión de su red, sobre todo en celdas congestionadas o para transferencias de mucho ancho de banda como el streaming de vídeo. Si la misma petición funciona de forma fiable por wifi pero se resetea con datos móviles, la interferencia a nivel de operador es una explicación razonable.