"No se puede acceder a este sitio web": los seis códigos detrás de una frase, y cuál es el suyo

Chrome muestra “No se puede acceder a este sitio web” para al menos seis fallos distintos, y casi no tienen nada en común salvo el orden en que ocurren. Uno significa que el nombre no existe. Otro significa que la máquina respondió y colgó. Otro significa que se cortó el wifi de su visitante.

La frase es la misma porque es lo único honesto que el navegador puede decir sobre una página que nunca llegó a recibir. Lo que los diferencia es el pequeño código gris que aparece debajo, y ese código es todo el diagnóstico.

El orden en que ocurren las cosas

Cargar una página pasa por cuatro pasos, y cada uno tiene su propia forma de fallar. Leer los códigos en ese orden es lo que hace que tengan sentido.

1. Encontrar la dirección. El navegador le pregunta a un resolutor a qué IP apunta el nombre de host.

2. Abrir una conexión. Intenta alcanzar esa IP en ese puerto.

3. Asegurarla. En HTTPS, valida un certificado.

4. Pedir la página. Envía la solicitud y espera una respuesta.

Un fallo en el paso uno no puede ser culpa de su servidor, porque nada ha llegado a él todavía. Un fallo en el paso cuatro casi con toda seguridad sí lo es. El código le dice a qué paso llegó, y eso vale más que cualquier cantidad de descripción del síntoma.

Los códigos, en ese orden

DNS_PROBE_FINISHED_NXDOMAIN y ERR_NAME_NOT_RESOLVED corresponden al paso uno. La descripción que da el propio Chromium para el segundo es “no se pudo resolver el nombre de host”. El nombre no existe, al menos para el resolutor que respondió. Relacionado, y más específico: ERR_NAME_RESOLUTION_FAILED, “se produjo un error al intentar realizar una resolución de nombres (DNS)”, que es la propia búsqueda fallando en lugar de devolver un resultado vacío.

Una errata produce esto. También lo hace un registro DNS que aún no se ha propagado, un dominio que caducó el fin de semana, o un filtro DNS corporativo o de control parental que se niega a responder por su dominio. Este último caso importa más de lo que parece: para la persona afectada, su sitio sencillamente no existe, y a usted le funciona perfectamente.

ERR_CONNECTION_REFUSED corresponde al paso dos, y es el fallo más informativo de esta lista. Algo respondió. Una máquina en esa dirección dijo que no de forma activa, lo cual significa que el DNS funcionó, que la ruta funcionó, y que hay un host ahí con nada escuchando en ese puerto. Un puerto equivocado, un servicio que murió, un contenedor que no volvió a levantarse tras un despliegue.

ERR_CONNECTION_TIMED_OUT es el paso dos fallando en silencio: “se agotó el tiempo de espera del intento de conexión”. Nada dijo que no, y nada dijo que sí. Un cortafuegos que descarta paquetes en lugar de rechazarlos tiene exactamente este aspecto, y lo mismo ocurre con un servidor demasiado ocupado para aceptar.

ERR_ADDRESS_UNREACHABLE es cuestión de enrutamiento: “la dirección IP es inalcanzable. Esto normalmente significa que no hay ninguna ruta hacia el host o la red especificados”. Los paquetes no tienen adónde ir.

ERR_INTERNET_DISCONNECTED es “se ha perdido la conexión a internet”, y es el único que puede dejar de investigar de inmediato. Es la propia red del visitante, y ningún reporte basado en él le dice nada sobre su sitio.

ERR_EMPTY_RESPONSE corresponde al paso cuatro: “el servidor cerró la conexión sin enviar ningún dato”. Este suele ser suyo. Algo aceptó la conexión y luego desapareció sin responder: un proceso que se cayó a mitad de la solicitud, un proxy que se rindió, un worker eliminado por falta de memoria.

Los fallos de certificado también viven en el paso tres, y tienen su propia pantalla en lugar de esta. Cuál de los cinco tiene usted es una pregunta aparte, y la familia ERR_CONNECTION_* tiene su propio artículo con la distinción entre refused y reset explicada en detalle.

Débil

El cliente dice que el sitio está caído. Desde aquí se ve bien. Le pedimos que borrara la caché.

Mejor

DNS_PROBE_FINISHED_NXDOMAIN, solo en la red de su oficina, funciona con datos móviles. Es su filtro DNS, no nuestro servidor. Confirmado que el registro resuelve desde tres resolutores públicos.

Qué mitad de la lista es realmente suya

Si los ordena según quién puede solucionarlos, la lista se divide casi por la mitad, y eso es lo útil que tiene.

Normalmente, del visitante: los fallos de DNS cuando hay un filtro o una caché local de por medio, la desconexión a internet, la dirección inalcanzable, y un tiempo de espera agotado causado por su red y no por la carga de su sitio.

Normalmente, suyos: la conexión rechazada, la respuesta vacía, y un tiempo de espera agotado cuando sus servidores están realmente saturados.

Genuinamente ambiguo, y lo primero que conviene comprobar: un fallo de DNS que se reproduce desde un resolutor público es su registro, no la red del visitante. Esa comprobación tarda diez segundos y resuelve la mayor categoría de la lista. En cualquier máquina:

nslookup example.com 1.1.1.1
nslookup example.com 8.8.8.8

Si ambos responden con su IP y el visitante sigue recibiendo NXDOMAIN, el problema está entre él y su resolutor. Si ninguno responde, es su registro, y el reloj de eso empezó a correr desde la última vez que cambió.

El problema de reportar esto, que es el verdadero problema

Todos los códigos anteriores aparecen en una página que generó el navegador. Su sitio nunca llegó a ejecutarse. No hay consola, no hay entrada en la pestaña de red, no hay ningún error que su tracker pueda capturar, y no hay nada que ninguna herramienta integrada en la página pueda registrar, incluida la nuestra.

Así que toda esta categoría solo le llega si una persona se lo cuenta, y se lo va a contar mal, porque no hay nada en pantalla que copiar salvo una frase y un código que no tiene ningún motivo para pensar que importa. La mayoría de estos reportes llegan como “su sitio está caído”, de alguien para quien realmente lo está.

Lo cual hace que la pregunta de seguimiento sea inusualmente valiosa, e inusualmente sencilla. No “reproduzca el problema con la consola abierta”, algo que aquí no se puede hacer. En su lugar, tres cosas:

• El código, del pequeño texto gris que aparece bajo el mensaje, completo.
• Si ocurre en otra red, siendo los datos móviles la prueba más fácil.
• Si alguien más puede acceder al sitio, lo cual distingue una caída global del resolutor de una sola persona en un solo mensaje.

Con esas tres respuestas suele bastar para saber cuál de los cuatro pasos falló antes de haber mirado siquiera un servidor. ¿Es un error suyo o una caída de ellos? cubre el mismo razonamiento para servicios que están activos pero degradados.

Qué sacar de todo esto

“No se puede acceder a este sitio web” es una categoría, no un diagnóstico, y los seis fallos que contiene se reparten de forma bastante pareja entre lo que usted puede arreglar y lo que no.

Lea el código, determine a cuál de los cuatro pasos pertenece, y compruebe el DNS desde un resolutor público antes de creer cualquier otra cosa. Y cuando no pueda reproducirlo, recuerde que no poder acceder a un sitio es el único fallo en el que su propia máquina es el instrumento menos útil que tiene: la suya resuelve, se conecta y funciona.

La lista de Chromium de estos errores, con la definición de una línea de cada uno, está en net_error_list.h.