Los cuatro significan lo mismo en el nivel que importa: la conversación nunca llegó lo bastante lejos como para tener un resultado. Chrome intentó abrir una conexión con un servidor, y la conexión fue rechazada, cortada, cerrada o nunca contestada, así que no hay página, no hay código de estado y no hay nada del sitio que leer.
Eso es lo que los separa de los errores con los que se suelen comparar. Un 404 o un
504 significa que un servidor
te contestó, en HTTP, con algo. Un ERR_CONNECTION_ cualquiera significa que el intercambio falló
por debajo de HTTP, antes de que nada de eso pudiera ocurrir. Chrome se inventa estos nombres él
mismo, y por eso no se parecen en nada a un código de estado.
Los cuatro se diferencian en cómo falló, y esa diferencia es la mayor parte del diagnóstico.
ERR_CONNECTION_REFUSED
Algo contestó, y lo que dijo fue que no.
La máquina que hay en esa dirección es alcanzable, y rechazó activamente la conexión en ese puerto. Ahí no hay nada escuchando, o un cortafuegos está rechazando la conexión de inmediato en lugar de descartarla en silencio.
Las causas más habituales, en el orden en que deberías comprobarlas: el servidor no está en
marcha; está en marcha en un puerto distinto del que hay en la dirección; está enlazado a
127.0.0.1, así que solo acepta conexiones desde su propia máquina; o pediste https en un puerto
que sirve http a secas.
Si eres desarrollador y ves esto contra localhost, casi siempre es una de esas cuatro y casi
nunca es el navegador.
ERR_CONNECTION_TIMED_OUT
No contestó nada en absoluto.
Chrome envió paquetes a oscuras y esperó. Esta es la firma de algo que descarta el tráfico en silencio en lugar de rechazarlo: un cortafuegos configurado para descartar y no para rechazar, una dirección que ya no lleva a ninguna parte, una VPN que manda tu tráfico a algún sitio desde el que no se llega al destino.
La señal es la espera. Un rechazo vuelve al instante; un tiempo de espera agotado tarda lo que dure la paciencia del navegador.
ERR_CONNECTION_RESET
La conexión estaba abierta, y luego la mataron a media frase.
Algo envió un reset: el servidor, o más a menudo algo que hay entre tú y él. Proxies corporativos que inspeccionan el tráfico, software de seguridad en la máquina, un enlace inestable, o un dispositivo de red que decidió que la conexión no estaba permitida después de que ya hubiera empezado.
Este es el que tiene más probabilidades de estar causado por algo que no es el sitio. Si pasa en una red y en otra no, has encontrado tu respuesta sin tocar el sitio en absoluto.
ERR_CONNECTION_CLOSED
La misma forma que un reset, terminada con más educación: el otro extremo cerró la conexión mientras el navegador todavía esperaba más.
En la práctica apunta al servidor, o a algo que hay delante de él, rindiéndose a medio camino: un
proceso que se reinicia, un balanceador de carga que suelta una conexión inactiva, un desajuste de
protocolo. En esta familia también verás ERR_CONNECTION_ABORTED, que normalmente significa que la
petición se canceló antes de terminar, a veces por la propia página al navegar a otro sitio.
Cuatro preguntas que lo localizan en aproximadamente un minuto
Sea cual sea de los cuatro el que tengas, el mismo triaje lo estrecha. Hazlas en orden y para cuando una conteste.
- ¿Funcionan otros sitios? No, y el problema es tu conexión, no el sitio.
- ¿Funciona en una ventana privada? Sí, y es una extensión, una cookie o un recurso en caché más que la red.
- ¿Funciona en otro dispositivo de la misma red? Sí, y es esa máquina: su software de seguridad, su configuración de proxy, su VPN.
- ¿Funciona con datos móviles en lugar de con wifi? Sí, y es esa red, que es la explicación habitual de un reset que solo está viendo una persona.
Dos de esas cuatro preguntas descartan el sitio por completo, lo cual merece la pena saber antes de que alguien se pase una tarde leyendo registros de servidor en busca de un fallo que nunca llegó al servidor.
Session Replay
Extensión gratuita de Chrome. Un clic en la página que se está portando mal captura la captura de pantalla, la consola y el registro de red, y te devuelve un enlace para pegar en el ticket.
Por qué se informa tan mal de estos
Un error de conexión no produce ningún estado HTTP y a menudo nada útil en la consola. O la página no carga en absoluto, o - mucho peor de diagnosticar - carga bien mientras una petición de dentro falla de esta manera, así que el sitio parece roto de una forma concreta e inexplicable.
Ese segundo caso es el que llega como “el botón de guardar no hace nada”. Ningún error en pantalla, ningún texto en rojo, nada que la persona pueda citarte. En el panel de red es evidente y es una línea: una petición en estado fallido, sin estado, y un host al lado.
Qué host sea importa más que ninguna otra cosa del informe. Si todas las peticiones que fallan nombran tu propio dominio, es tu infraestructura o la ruta hasta ella. Si nombran una pasarela de pago, un servicio de mapas o un servidor de fuentes, la página se está comportando correctamente y algo de lo que depende no, y quien lee puede ir a mirar la página de estado de ese proveedor en lugar de la tuya.
El registro de red de un informe de error lleva exactamente eso, que es la diferencia entre que esta clase de fallo sea reproducible y que sea una historia sobre algo que pasó un martes.
La versión corta
- Refused: algo dijo que no, de inmediato. Normalmente no hay nada escuchando en ese puerto.
- Timed out: nada dijo nada. Normalmente algo descarta el tráfico en silencio.
- Reset: la conexión murió en pleno vuelo. Normalmente la red intermedia, no el sitio.
- Closed: el otro extremo colgó pronto. Normalmente el servidor o algo delante de él.
Y ninguno de los cuatro es un error HTTP, que es la razón de que no aparezca ningún código de estado a su lado y de que el servidor puede que no tenga registro alguno del intento.