ERR_CONNECTION_RESET en un solo sitio

¿Un sitio falla con ERR_CONNECTION_RESET y el resto funciona? Revisa paso a paso red, extensiones, proxy, DNS, hora y filtrado por SNI con curl.

Publicado 9 min de lecturaLeer en inglés →

Todos los demás sitios cargan, pero uno sigue fallando con "No se puede acceder a este sitio" y ERR_CONNECTION_RESET. Recargar no sirve de nada. Esta guía es un árbol de decisiones. Cada paso encuentra la causa o descarta una, y el orden va de las comprobaciones más rápidas a la más reveladora.

Qué significa realmente "connection reset"

Una conexión TCP puede terminar de forma ordenada, o puede cortarse de golpe con un paquete de reinicio (RST). Chrome y otros navegadores basados en Chromium muestran ERR_CONNECTION_RESET cuando llega un reinicio antes de que se entregue la página. Firefox muestra una página parecida de "Se ha restablecido la conexión". El reinicio puede venir del servidor del sitio, de software de tu propio ordenador o de un dispositivo en medio de la red que se hace pasar por uno de los dos extremos.

Por eso el mismo error tiene causas tan distintas. La clave es averiguar quién envió el reinicio y cuándo.

Paso 1: ¿de verdad es solo un sitio?

Abre dos o tres sitios sin relación entre sí, incluido uno que visites poco. Si fallan varios, el problema es tu conexión, tu router o tu dispositivo, no ese sitio. Reinicia el router y comprueba si otros dispositivos de la misma red funcionan. Si solo falla un sitio, sigue adelante.

Paso 2: ¿es solo una red?

Esta es la prueba que más información da, y es gratis. Abre el sitio con datos móviles en lugar de Wi-Fi, o conecta tu portátil a la conexión compartida de tu teléfono. Si el sitio abre en una red y se reinicia en la otra, la red que falla está implicada. Las causas habituales se explican en ¿Por qué un sitio abre con datos móviles pero no con Wi-Fi? Si falla en todas partes, lo más probable es que la causa sea el propio sitio o tu dispositivo.

Paso 3: otro navegador, una ventana privada, sin extensiones

Prueba una ventana privada o de incógnito, donde la mayoría de las extensiones están desactivadas por defecto. Después prueba otro navegador. Los bloqueadores de anuncios, las extensiones de privacidad, los complementos de "navegación segura" y las políticas de navegador de las empresas pueden cerrar conexiones. Si el sitio funciona en una ventana privada, vuelve a activar tus extensiones una a una hasta que reaparezca el error.

Paso 4: desactiva otras VPN, proxies y el análisis de HTTPS

Cualquier cosa que se interponga en el camino de tu tráfico puede reiniciar una conexión que no le guste:

  • Otra app de VPN o de proxy. Desactívala por completo y vuelve a probar.
  • El "análisis de HTTPS" o la "protección web" del antivirus. Algunas suites de seguridad inspeccionan el tráfico cifrado y cortan las conexiones que consideran arriesgadas. Pausa esa función un momento para probar y vuelve a activarla después.
  • El proxy del sistema. En Windows, mira en Configuración → Red e Internet → Proxy. En macOS, mira en Ajustes del Sistema → Red → tu conexión → Detalles → Proxies. Un proxy que no reconoces, o uno que quedó de una app antigua, puede romper sitios concretos. Quita solo lo que sepas que configuraste tú, y en un ordenador gestionado pregunta a tu equipo de TI.

Paso 5: borra la caché de DNS y prueba el DNS cifrado

Si el sitio cambió de servidor, puede que tu dispositivo siga usando la dirección antigua, lo que puede provocar un reinicio o que se agote el tiempo de espera. Vacía las cachés:

# Windows (Command Prompt)
ipconfig /flushdns

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Chrome's own cache: open chrome://net-internals/#dns and click "Clear host cache"

Después, compara la respuesta de tu red con la de un resolvedor independiente: nslookup example.com y luego nslookup example.com 1.1.1.1. Si son distintas y solo funciona la respuesta independiente, el problema es el DNS de tu red. El DNS cifrado arregla ese tipo de bloqueo, como se explica en DoH y DoT. Que las direcciones sean distintas no basta como prueba, porque los sitios grandes reparten servidores diferentes según la red.

Paso 6: revisa la fecha y la hora

Un reloj incorrecto suele producir un error de certificado y no un reinicio, pero es una comprobación de diez segundos. Activa la fecha y hora automáticas y recarga. Nunca aceptes una advertencia de certificado para "saltarte" una página que falla.

Paso 7: ¿está caído el sitio?

Revisa la página de estado del sitio o su cuenta oficial en redes sociales, o usa un comprobador público del tipo "¿está caído para todos o solo para mí?". Si el sitio está caído, espera. Ten en cuenta que un comprobador prueba desde sus propios servidores, así que un "funciona" ahí no demuestra que se pueda llegar desde tu red.

Paso 8: lee el reinicio con curl

Si el sitio sigue reiniciándose solo en una red, mira el propio handshake. curl viene incluido en Windows 10 y 11, macOS y la mayoría de los sistemas Linux. Ejecútalo en una terminal con tu sitio en lugar de example.com:

curl -v https://example.com

Una conexión sana muestra unas líneas como estas y luego las cabeceras de la página. El texto exacto depende de tu versión de curl y de la biblioteca TLS:

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
...
< HTTP/2 200

El patrón que apunta a un filtrado por nombre es este:

*   Trying 203.0.113.10:443...
* Connected to example.com (203.0.113.10) port 443
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer

Léelo línea a línea. "Connected" significa que la conexión TCP con la dirección IP del servidor funcionó, así que la dirección no está bloqueada del todo. "Client hello" es el primer mensaje de TLS, y lleva el nombre del sitio en texto plano en un campo llamado SNI. "Connection reset by peer" justo después significa que algo cortó la conexión en cuanto el nombre fue visible, antes de que el servidor pudiera responder. Algunas redes cierran la conexión en silencio, lo que curl muestra como un fin de archivo inesperado o un error SSL de "syscall", y Chrome puede mostrar ERR_CONNECTION_CLOSED.

Compáralo con otros resultados:

Lo que muestra curlSignificado probable
Could not resolve hostFallo de DNS o bloqueo por DNS. Vuelve al paso 5
Se queda en "Trying" y luego se agota el tiempoNo se llega a la dirección IP: un bloqueo por IP, un firewall o un servidor caído
Reinicio o cierre justo después del "Client hello", solo en una redProbablemente filtrado por SNI en esa red
El handshake termina y luego llega un código de error HTTPEl sitio respondió. El problema está de su lado o en tu cuenta

Para reforzar la conclusión, ejecuta el mismo comando en otra red. Si allí funciona, el filtro pertenece a la primera red. No es una suposición sobre un caso raro. Un estudio de 2020 de OONI y el Centre for Internet and Society encontró conexiones TLS cortadas justo después del ClientHello para ciertos sitios en Bharti Airtel, y el uso del SNI combinado con la dirección de destino en Reliance Jio. El CIS informó por separado de que Jio usaba inspección del SNI, y el informe se comentó en el foro ntc.party. Más contexto: Cómo comprobar si un sitio web está bloqueado.

Dónde ayuda GreenTunnel y dónde no

GreenTunnel es una VPN local que funciona en el dispositivo y que hacemos nosotros, así que lee esta parte sabiendo que no somos neutrales. Se ocupa de dos de las causas anteriores:

  • Filtrado por SNI. Reorganiza los primeros paquetes TLS de una conexión, por ejemplo dividiendo el Client hello o su registro TLS, para que un filtro que busca el nombre de un sitio no lo encuentre de una pieza. Cómo funciona: SNI, DPI y división de registros TLS.
  • Bloqueo por DNS. Las consultas van por DNS cifrado (DoH o DoT) a Cloudflare, Google o Quad9, así que la red no puede devolver en silencio una respuesta falsa.

Su herramienta Inspeccionar URL hace las comparaciones de los pasos 5 y 8 para un sitio en la red en la que estás, y te dice si el sitio está filtrado por nombre, recibe una respuesta DNS falsa, está bloqueado por dirección IP o está bien. Si una técnica funciona, puedes tocar Usar esta técnica.

No ayudará cuando:

  • el sitio está caído, o el reinicio viene del propio servidor del sitio o de su servicio de protección,
  • el bloqueo es por dirección IP, lo que se ve como un tiempo agotado en "Trying",
  • una red de trabajo, de un centro de estudios u otra red gestionada bloquea el sitio a propósito. Las reglas de esa red las pone su propietario. Respeta la política y pregunta al administrador si necesitas acceso para tu trabajo,
  • la causa es una extensión, un antivirus o un DNS desactualizado en tu propio dispositivo. Arréglalos directamente.

Límites honestos y uso responsable

GreenTunnel no oculta tu dirección IP y no es una herramienta de anonimato. No puede saltarse bloqueos por IP, cortes de red ni listas de permitidos, y no promete abrir ningún sitio concreto. Los filtros cambian con el tiempo y varían entre proveedores, así que un resultado de hoy puede ser distinto el mes que viene.

Preguntas frecuentes

¿ERR_CONNECTION_RESET siempre indica que un sitio está bloqueado?

No. Las extensiones, el análisis de HTTPS del antivirus, un proxy olvidado, un DNS desactualizado o el propio sitio pueden causarlo. El bloqueo solo es probable cuando el reinicio ocurre en una red, justo después del Client hello, y el sitio funciona en otras redes.

¿Por qué el sitio funciona con datos móviles pero se reinicia con Wi-Fi?

Las dos redes usan proveedores, resolvedores y filtros distintos. Una de ellas puede leer el nombre del sitio o responder al DNS de otra manera. Ejecuta curl -v en ambas y compara dónde se detiene cada una.

¿Borrar las cookies arreglará un reinicio de conexión?

Rara vez. Las cookies se envían después de establecer la conexión, y la mayoría de los reinicios ocurren antes. Borrar los datos del sitio puede ayudar cuando el propio sitio rechaza una sesión dañada, lo que normalmente muestra un error HTTP.

¿Puede GreenTunnel arreglar un reinicio causado por el firewall de mi empresa?

No está pensado para eso. Una red gestionada bloquea sitios según la política de su propietario. Pregunta al administrador en lugar de intentar saltártelo.

Fuentes

← Todos los artículos