--- title: "err_connection_reset: qué es y cómo solucionarlo" description: "err_connection_reset: una señal de restablecimiento cortó una conexión abierta. Cómo saber quién la cortó y solucionarlo en el equipo, el teléfono y el código." url: https://proxynet.io/es/blog/err-connection-reset date: 2026-10-06 author: "Acar Diveroli" category: "Tutoriales" lang: es --- # err_connection_reset: qué es y cómo solucionarlo Estás a mitad de un pedido. Haces clic en el botón, la pestaña gira un segundo y Chrome muestra «No se puede acceder a este sitio web», debajo «Se ha restablecido la conexión.» y abajo del todo `ERR_CONNECTION_RESET`. Firefox lo dice en una línea: «La conexión ha sido reiniciada». Las demás webs se abren bien, y dentro de un minuto puede que esta también. A continuación: qué es un restablecimiento, quién puede enviarlo, cómo averiguar de dónde viene el tuyo, las soluciones en el equipo y en el teléfono, qué revisar si la web es tuya y el mismo error en código, donde se llama «connection reset by peer», `ECONNRESET` o `WinError 10054`. > **Nota: Respuesta breve** > > `ERR_CONNECTION_RESET` significa que había una conexión abierta con la web y algo la cortó de golpe con una señal de restablecimiento TCP (RST, del inglés «reset»). Quien la envía puede ser el servidor de la web, un software de seguridad de tu equipo, una extensión del navegador, una VPN o un proxy, o un filtro de la red, y el navegador no puede saber cuál. Recarga una vez y después prueba en una ventana de incógnito, en otro navegador y en tu teléfono con datos móviles; el lugar donde funcione te indica de dónde viene el restablecimiento. Si una web falla solo en una red, un dispositivo de esa red está cortando la conexión, y ningún ajuste de tu equipo lo cambia. ## ¿Qué significa ERR_CONNECTION_RESET? Antes de que cargue una página, tu navegador y el servidor de la web abren una conexión, una línea de ida y vuelta que sigue abierta mientras los datos van y vienen. Un restablecimiento corta esa línea a mitad de camino. La [lista de errores de red](https://chromium.googlesource.com/chromium/src/+/HEAD/net/base/net_error_list.h) de Chromium describe el código -101 como una conexión que «se restableció (corresponde a un TCP RST)». Chrome, Edge, Brave y Opera comparten esa lista, así que muestran el mismo código. Los textos que citamos son los de Chrome y Firefox en español de España; en Latinoamérica algunas frases cambian un poco, pero el código es el mismo. La diferencia con sus vecinos es el momento. Con `ERR_CONNECTION_REFUSED` la línea nunca se abrió; con `ERR_CONNECTION_TIMED_OUT` no respondió nadie. Un restablecimiento llega cuando la línea ya funcionaba. Los demás códigos de esta pantalla gris se comparan en [No se puede acceder a este sitio web](/es/blog/this-site-cant-be-reached). ## ¿Cómo se restablece una conexión? TCP, el protocolo que transporta las páginas web, puede terminar una conexión de dos formas: con un cierre ordenado, que primero termina de enviar, o con un restablecimiento, que lo detiene todo en el acto. El [RFC 9293, sección 3.5.2](https://www.rfc-editor.org/rfc/rfc9293.html#section-3.5.2) permite a un programa emitir un restablecimiento en cualquier momento, y TCP envía uno por su cuenta cuando llega un paquete de una conexión que la máquina ya no conoce. 1. Tu navegador abre una conexión y, en las webs `https://`, establece el cifrado (TLS). 2. Envía la petición y empieza a leer la respuesta. 3. En algún punto del camino, un programa decide que la conexión debe terminar, o una máquina recibe un paquete de una conexión que ha olvidado. Envía un restablecimiento. 4. Tu equipo descarta la conexión en cuanto llega el restablecimiento, y Chrome muestra el error. Un restablecimiento no lleva ningún motivo y parece enviado por la web, pero un dispositivo intermedio puede enviarlo en nombre de la web. Investigadores del ICSI y de UC Berkeley documentaron [restablecimientos TCP falsificados](https://www.icir.org/vern/papers/reset-injection.ndss09.pdf) procedentes de productos de control de tráfico que usan proveedores de internet, sistemas antivirus y filtros nacionales. El navegador puede decir «restablecida», nunca «restablecida por quién». ## ¿Quién puede enviar el restablecimiento? | Quién | Por qué | Señal típica | Primer paso | |---|---|---|---| | El servidor de la web | Reinicio, caída, límite de conexiones | Falla para todos, va y viene | Recarga más tarde | | Software de seguridad | «Protección web» o «análisis HTTPS» | Todos los navegadores de un equipo | Pausa la protección web para una prueba | | Una extensión del navegador | Complemento de VPN, proxy o bloqueo de anuncios | Un navegador; la ventana de incógnito funciona | Desactiva las extensiones | | Una VPN o un proxy | Túnel caído, conexiones inactivas cerradas | Solo mientras está activado | Desactívalo | | Un filtro de red | Una regla del trabajo, del centro educativo o del proveedor | Una web, todos los dispositivos de una red | Pregunta al administrador | | Router o línea | Fallo breve | Varias webs durante unos minutos | Reinicia el router | | Balanceador de carga delante de la web | Tiempo de espera por inactividad, regla de protección | Páginas abiertas mucho tiempo, subidas grandes | La configuración del propietario | También se suele culpar a un valor de MTU incorrecto, el tamaño máximo de paquete que admite un enlace, pero normalmente deja las páginas colgadas en lugar de restablecerlas: los paquetes demasiado grandes desaparecen sin ninguna señal. ## ¿El problema es de la web, de tu dispositivo o de la red? Cinco comprobaciones, de la más rápida a la más lenta. Detente en la primera que cambie el resultado. 1. **Recarga una vez.** Un restablecimiento aislado tras un reinicio del servidor o un cambio de Wi-Fi se resuelve solo. 2. **Prueba otro navegador.** Si Firefox abre lo que Chrome no puede, la causa está dentro de Chrome: una extensión o un ajuste. Un restablecimiento en todos los navegadores apunta a algo que comparte todo el equipo. 3. **Abre la web en tu teléfono con el Wi-Fi desactivado.** Si carga con datos móviles, la web funciona y el problema está en tu red o en tu equipo. Si no, el problema es de la web. 4. **Prueba otro dispositivo en el mismo Wi-Fi.** Si ahí funciona, revisa el primer equipo: software de seguridad, una VPN, un ajuste de proxy. 5. **Todos los dispositivos de este Wi-Fi fallan con esta web.** El corte ocurre en el camino: el router, el proveedor o un filtro. ## ¿Cómo se soluciona ERR_CONNECTION_RESET en el equipo? Recarga después de cada paso. 1. **Descarta las extensiones.** En Chrome, selecciona **Más > Nueva ventana de Incógnito**. Las extensiones solo funcionan ahí si activaste **Permitir en incógnito** para ellas, así que una página que se abre en esa ventana apunta a una extensión. Ve a **Más > Extensiones > Gestionar extensiones** y desactívalas de una en una, primero los complementos de VPN y proxy. En Firefox, **Ayuda > Modo de resolución de problemas…** lo inicia con los complementos desactivados. 2. **Desactiva la aplicación de VPN o de proxy.** Después busca un proxy que no hayas configurado tú: en Windows 11 abre **Configuración > Red e Internet > Proxy** y, en **Configuración manual del proxy**, selecciona **Configurar** junto a **Usar un servidor proxy**. Si está activado y no lo activaste tú, desactívalo y selecciona **Guardar**. Chrome abre la misma página desde **Configuración > Sistema > Abrir la configuración de proxy de tu ordenador**. El ajuste propio de Firefox debería decir **Sin proxy** o **Usar la configuración del proxy del sistema**, salvo que hayas elegido un proxy a propósito. 3. **Prueba tu software de seguridad.** Pausa solo su «protección web» o su «análisis HTTPS» durante un minuto. Si la web se abre, vuelve a activar la protección, actualiza el programa y añade la web a sus excepciones. No desactives el firewall. 4. **Reinicia el router.** Desenchúfalo durante 30 segundos; no pulses el botón de reset del agujerito, que restaura la configuración de fábrica. 5. **Restablece la configuración de red, como último paso.** Solo si todas las webs se restablecen en este equipo y los demás dispositivos del Wi-Fi funcionan: **Configuración > Red e Internet > Configuración de red avanzada > Restablecimiento de red**, después **Restablecer ahora** y **Sí**. Puede que luego tengas que volver a configurar el software de VPN. La lista **Prueba a:** de la pantalla de error de Chrome apunta en la misma dirección: «Comprobar el proxy y el cortafuegos» y «Ejecutar Diagnósticos de red de Windows». ### En Android y iPhone - **Cambio de red.** Un teléfono que pasa del Wi-Fi a los datos móviles pierde las conexiones abiertas; recarga tras unos segundos. - **Aplicaciones de VPN y de bloqueo de anuncios.** Muchas dirigen el tráfico a través de un perfil de VPN y restablecen las conexiones cuando fallan. En Android, abre **Ajustes > Redes e Internet > VPN** y desactívala; **VPN siempre activada** mantiene una funcionando en segundo plano. En el iPhone, los perfiles instalados están en **Ajustes > General > VPN y gestión de dispositivos**; no toques los perfiles del trabajo o del centro educativo. - **Wi-Fi de cafeterías y hoteles.** Estas redes pueden cortar conexiones hasta que inicies sesión en su página de acceso. ## ¿Por qué solo una web restablece la conexión? Si una web falla en todos los dispositivos de tu red pero se abre con datos móviles, lo más probable es que el remitente sea un filtro de la red. En las webs `https://` el contenido va cifrado, pero el nombre de la web viaja legible al principio de la conexión. Un filtro que inspecciona el tráfico, un método llamado inspección profunda de paquetes (DPI), puede comparar ese nombre con una lista y enviar un restablecimiento en nombre de la web. [¿Qué es la inspección profunda de paquetes (DPI)?](/es/blog/what-is-deep-packet-inspection) explica cómo funciona esa inspección. Estos filtros funcionan en redes de oficinas y centros educativos, en routers con control parental y en proveedores de internet cuando la ley ordena un bloqueo. En una red del trabajo o de un centro educativo, pregunta al administrador. Si el bloqueo está en tu proveedor, nada en tu dispositivo lo soluciona, y esta guía no trata formas de evitarlo. El otro caso de una sola web es la propia web, cuya protección puede restablecer una dirección que abre demasiadas conexiones a la vez. Espera unos minutos o envía a su soporte la hora y el código exacto. ## Avanzado: prueba la conexión fuera del navegador Puedes saltarte esta sección. Un comando en PowerShell en Windows 10 u 11 muestra si el restablecimiento depende del navegador: ```powershell curl.exe -sS -o NUL https://example.com/ ``` Pon la dirección que falla en lugar de `example.com`. curl no usa extensiones ni ajustes del navegador. Contra un servidor de pruebas local que envía un restablecimiento, una vez durante el establecimiento de la conexión segura y otra después de la petición, curl 8.21.0 en Windows 11 imprimió: ```text curl: (35) Recv failure: Connection was reset curl: (56) Recv failure: Connection was reset ``` Si no hay salida, curl cargó la página, así que la causa está dentro del navegador. Una línea `Connection was reset` significa que algo fuera del navegador cortó la conexión: software de seguridad, una VPN, la red o la web. ## Si la web es tuya: ¿de dónde vienen los restablecimientos? Los visitantes pueden ver restablecimientos que nunca aparecen en los registros de tu aplicación. Revisa las capas que la rodean: - **Reinicios sin drenar las conexiones.** Un despliegue que mata el proceso del servidor restablece todas las conexiones abiertas. Deja primero de aceptar conexiones nuevas y deja que terminen las peticiones en curso. - **Tiempos de espera por inactividad que no coinciden.** AWS documenta que su Network Load Balancer descarta los flujos TCP inactivos tras 350 segundos de forma predeterminada y responde con un restablecimiento a los datos que lleguen después. Para su Application Load Balancer recomienda que la aplicación tenga un tiempo de espera por inactividad más largo que el del balanceador. - **Reglas de protección.** Los firewalls, los filtros DDoS y los límites de conexiones a menudo restablecen en lugar de responder. Busca en sus registros la dirección del visitante y la hora. ## Si ves «connection reset by peer» en el código «Peer» es el otro extremo de la conexión y, como en el navegador, puede ser un dispositivo del camino. Cada herramienta nombra el evento de forma distinta. Provocamos los casos de Windows y Node.js en Windows 11 contra un servidor local que envía un restablecimiento: | Dónde | Qué ves | |---|---| | Python en Linux | `ConnectionResetError: [Errno 104] Connection reset by peer` | | Python en Windows | `ConnectionResetError: [WinError 10054] An existing connection was forcibly closed by the remote host` | | Python Requests | `requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(10054, ...))` | | Requests, cortado a mitad de descarga | `requests.exceptions.ChunkedEncodingError: ("Connection broken: ConnectionResetError(10054, ...)", ...)` | | Node.js `http` | `Error: read ECONNRESET` | | Node.js, cerrado antes de una respuesta | `Error: socket hang up` (código `ECONNRESET`) | | Node.js `fetch` | `TypeError: fetch failed`, `cause.code` es `ECONNRESET` | Windows imprime su parte en el idioma de visualización del sistema; el texto en inglés procede de la [lista de errores de Winsock](https://learn.microsoft.com/es-es/windows/win32/winsock/windows-sockets-error-codes-2) de Microsoft, que enumera las causas de 10054: el programa remoto se detuvo, el host se reinició o el otro lado usó un cierre forzado («hard close»). La línea de Linux es el texto estándar de ese sistema para el error 104. Las causas habituales en código: - **Una conexión reutilizada que el servidor acaba de cerrar.** Los clientes mantienen las conexiones abiertas entre peticiones (keep-alive). Si el servidor cierra una inactiva justo cuando envías por ella, recibes un restablecimiento. La documentación de Node sobre [`request.reusedSocket`](https://nodejs.org/api/http.html#requestreusedsocket) describe esta condición de carrera y sugiere reintentar exactamente ese caso. - **Demasiadas conexiones a la vez.** Un servidor o su firewall puede cortar a un cliente que abre decenas en paralelo. Reduce la concurrencia, respeta `429` y `Retry-After`, y usa la API de la web si existe. Rotar direcciones IP para saltarse un límite no es una solución. - **La negociación TLS.** Un restablecimiento en ese punto puede significar que el servidor o un filtro rechazó lo que ofreció el cliente, como una versión antigua de TLS; actualiza primero la biblioteca del cliente. - **Un proxy en medio.** Un proxy cierra los túneles inactivos y transmite los restablecimientos de la web. En nuestras pruebas, Requests etiquetó uno de esos restablecimientos como `ProxyError('Unable to connect to proxy', ConnectionResetError(...))` aunque lo había enviado la web; cuando el proxy cerró nuestro lado de forma ordenada, Python informó de `RemoteDisconnected` o, durante la negociación, de `SSLEOFError`. Envía la petición una vez con el proxy y otra sin él para ver qué tramo corta. [Max Retries Exceeded With URL: qué es y cómo solucionarlo](/es/blog/max-retries-exceeded-with-url) muestra cómo leer toda la cadena de errores. ### Reintentar con espera exponencial, solo cuando es seguro Un restablecimiento no te dice si el servidor ya ejecutó tu petición. Reintenta automáticamente solo las peticiones que se pueden repetir sin riesgo, como `GET`, espera más cada vez y detente tras unos pocos intentos: ```python """Obtiene una URL con GET a través de un proxy y reintenta los restablecimientos de conexión con espera exponencial.""" import random import time import requests PROXY = "http://user:pass@pr.proxynet.io:8000" PROXIES = {"http": PROXY, "https": PROXY} def was_reset(exc): """True si hay un ConnectionResetError en cualquier capa de la excepción.""" stack, seen = [exc], set() while stack: e = stack.pop() if id(e) in seen: continue seen.add(id(e)) if isinstance(e, ConnectionResetError): # RemoteDisconnected es una subclase return True inner = (*e.args, e.__cause__, e.__context__, getattr(e, "reason", None)) stack.extend(x for x in inner if isinstance(x, BaseException)) return False def get_with_retry(session, url, attempts=4, base=1.0, cap=30.0): """GET se puede repetir sin riesgo; espera unos 1, 2, 4 s (más jitter) entre intentos.""" for attempt in range(1, attempts + 1): try: return session.get(url, proxies=PROXIES, timeout=(5, 30)) except (requests.exceptions.ConnectionError, requests.exceptions.ChunkedEncodingError) as exc: if not was_reset(exc) or attempt == attempts: raise delay = min(cap, base * 2 ** (attempt - 1)) + random.uniform(0, base / 2) print(f"attempt {attempt}: connection reset, retrying in {delay:.1f} s") time.sleep(delay) if __name__ == "__main__": with requests.Session() as s: s.headers["User-Agent"] = "example-crawler/1.0 (+https://example.com/bot)" r = get_with_retry(s, "https://example.com/") print(r.status_code, len(r.content), "bytes") ``` - Solo reintenta los restablecimientos; una contraseña incorrecta, un puerto rechazado o un error de certificado se lanzan de inmediato. Requests esconde el restablecimiento dos o tres capas más abajo, de ahí la búsqueda. `RemoteDisconnected` («Remote end closed connection without response») es una subclase de `ConnectionResetError`, así que también cuenta. - La espera se duplica cada vez, más una parte aleatoria (jitter) para que los procesos en paralelo no reintenten al mismo ritmo, y cada intento abre una conexión nueva. Lo ejecutamos con Python 3.13 y Requests 2.34.2 a través de un proxy de pruebas local con autenticación `user:pass`, contra un servidor de pruebas que restablece las dos primeras conexiones: ```text attempt 1: connection reset, retrying in 1.2 s attempt 2: connection reset, retrying in 2.3 s 200 3 bytes ``` Contra un servidor que restablece siempre, se rindió tras cuatro intentos con el `ProxyError` de arriba. Con los [Proxies residenciales](https://proxynet.io/es/residential-proxy) en modo rotativo, cada reintento abre una conexión nueva y puede salir por una dirección IP nueva. Para una sesión iniciada que debe mantener una sola dirección, usa una sesión fija (de 1 a 60 minutos) y mantén los reintentos dentro de ella. ## Dónde aparece - Páginas de tiendas y bancos que se detienen en el paso de pago en una red de oficina o de un centro educativo. - Subidas grandes que se detienen en el mismo punto cada vez. - Tareas de scraping, monitorización y API que funcionan durante horas detrás de proxies y balanceadores de carga. ## Errores frecuentes - **Borrar la caché y las cookies.** La página nunca llegó, así que nada antiguo lo causó. - **Desactivar el firewall o el antivirus para siempre.** Pausa una función para una prueba. - **Reintentar un pago o el envío de un formulario en código.** El servidor puede haberlo procesado antes del restablecimiento. - **Subir el número de reintentos a 20.** Un restablecimiento que ocurre siempre es una decisión, no mala suerte. ## Guía de decisión | Situación | Qué hacer | |---|---| | Un restablecimiento y luego la página funciona | Nada; fue algo pasajero | | Solo falla Chrome y la ventana de incógnito funciona | Desactiva las extensiones de una en una | | Fallan todos los navegadores de un equipo | Revisa la VPN, el ajuste de proxy y la protección web | | Todos los dispositivos de tu Wi-Fi fallan con una web | Un filtro o el proveedor; pregunta al administrador | | Todas las redes fallan con esa web | Es un problema de la web; espera o contacta con ella | | Tu propia web restablece a los visitantes | Revisa los reinicios, los tiempos de inactividad y los registros del firewall | | Tu script recibe `Errno 104`, `10054` o `ECONNRESET` de vez en cuando | Reintenta las peticiones seguras con espera exponencial y reduce la concurrencia | ## Preguntas frecuentes ### ¿ERR_CONNECTION_RESET es problema mío o de la web? Puede ser de cualquiera de los dos. Abre la web en tu teléfono con datos móviles: si carga, el problema es tu red o tu equipo; si falla en todas partes, es de la web. ### ¿Por qué aparece ERR_CONNECTION_RESET en todos los navegadores? La causa es algo que todos comparten: software de seguridad, una VPN, el ajuste de proxy del sistema, el router o un filtro de red. Las extensiones y los ajustes del navegador quedan descartados. ### ¿Borrar la caché soluciona ERR_CONNECTION_RESET? Rara vez. La conexión se cortó antes de que llegara la página, así que la caché no guarda nada que lo haya causado. ### ¿Qué diferencia hay entre un restablecimiento y «ha cerrado la conexión de forma inesperada»? Un restablecimiento (`ERR_CONNECTION_RESET`) termina la conexión en el acto. «Ha cerrado la conexión de forma inesperada» (`ERR_CONNECTION_CLOSED`) significa que el otro lado la cerró de la forma normal, pero antes de que la página estuviera completa. Los dos se revisan igual. ### ¿Qué significa «connection reset by peer»? El otro extremo de la conexión, el peer, envió un restablecimiento. Linux lo indica como error 104, Windows como 10054 y Node.js como `ECONNRESET`. El peer puede ser el servidor o cualquier dispositivo intermedio. ### ¿Cómo soluciono ECONNRESET o «socket hang up» en Node.js? Los dos significan que la conexión se cortó; «socket hang up», además, antes de que llegara ninguna respuesta. Reintenta las peticiones idempotentes, es decir, las que se pueden repetir sin efectos secundarios, en una conexión nueva, sobre todo cuando `req.reusedSocket` es true, y reduce la concurrencia. ## En resumen `ERR_CONNECTION_RESET` y «connection reset by peer» nombran el mismo evento: una conexión abierta que terminó con una señal de restablecimiento enviada por la web, tu equipo, una VPN o un proxy, o la red intermedia. Encuentra al remitente cambiando una cosa cada vez: navegador, ventana de incógnito, dispositivo, red. Un bloqueo en la red no es algo que tu dispositivo pueda cambiar. En código, reintenta solo las peticiones seguras, con pausas crecientes y una conexión nueva. Si usas proxies para ese tipo de trabajo, [nuestra página de proxies](/es/proxy) explica qué tipos existen y para qué sirve cada uno.