Qué hacer si el sitio dejó de abrirse después de cambiar el DNS
Qué hacer si el sitio dejó de abrirse después de cambiar el DNS
Cambiar el DNS es algo engañoso. El sitio parece que ya se ha trasladado, pero en el navegador está vacío, hay un error o la dirección antigua. Y luego comienza el pánico: primero se culpa al hosting, luego al registrador, y después a uno mismo.
No se necesita ruido, sino una verificación paso a paso. A menudo, el problema radica en un solo registro, un solo NS o en la caché del proveedor, y no en el sitio mismo. Si necesita entender qué hacer si el sitio dejó de abrirse después de cambiar el DNS, comience con el hecho: qué exactamente cambió y en qué minuto lo hizo.
Verificar si el problema está realmente relacionado con el DNS
Primero, separe el efecto del DNS de todo lo demás. Si antes de cambiar el DNS el sitio se abría y después de 5 minutos dejó de hacerlo, eso aún no es una prueba. La coincidencia en el tiempo es engañosa.
Mire cómo se comporta el sitio con diferentes síntomas: no se abre en absoluto, redirige a otro dominio, muestra un error SSL o simplemente se queda cargando. Estos son 4 escenarios diferentes, y cada uno tiene su propia fuente. A veces, el problema parece ser DNS, pero en realidad se ha roto la redirección a https o ha expirado el certificado.
Hay una prueba simple: intente abrir el sitio a través de la IP directa, si la conoce, o a través de otro canal de comunicación donde ya se haya guardado la dirección antigua. Si el servidor responde por IP, pero no por dominio, el DNS está realmente en la lista de sospechosos. Si no responde por nada, entonces ya no se trata de DNS, sino del servidor, el host virtual o la propia plataforma.
Verifique también los factores externos. Por ejemplo, si recientemente se cambió el SSL o las redirecciones en el sitio, el navegador puede mostrar un error completamente diferente al que espera. Aquí es útil mirar no por conjetura, sino por el mensaje exacto. A veces, un texto de error ahorra 30 minutos de búsqueda innecesaria.
Asociar el nuevo DNS con lo que debe abrirse
Después de cambiar el DNS, abra la lista de registros y compárela con lo que realmente necesita abrirse. Para la raíz del dominio, generalmente se verifica el registro A, para IPv6 — AAAA, para el subdominio a menudo se necesita CNAME. Un error en una letra convierte un sitio normal en un callejón sin salida.
Es necesario mirar no solo el dominio en sí, sino también el subdominio. Por ejemplo, www puede apuntar a un host, mientras que sin www — a otro. Y si uno de los puntos apunta a un servidor antiguo, los usuarios verán diferentes resultados dependiendo de cómo ingresen la dirección.
La verificación con el plan de migración ayuda mucho. Si ha trasladado el sitio, el nuevo DNS debe apuntar a la dirección donde ya está levantado el sitio, y no a un espacio de prueba vacío. El error aquí suele ser simple: se creó el registro, pero se dejó la meta antigua.
Si necesita verificar la conexión más a fondo, compare los valores actuales con lo que debería ser según la tarea. Aquí hay 3 cosas importantes: el nombre del registro, el tipo de registro y la dirección de destino. Un símbolo de más en CNAME o una IP de una red ajena — y el sitio deja de abrirse solo para parte de las solicitudes.
Verificar si la transición al nuevo proveedor de DNS está rota
Cuando se transfiere un dominio a un nuevo proveedor de DNS, es necesario asegurarse de que la delegación se haya completado por completo. El dominio debe tener los NS correctos, y la zona debe ser realmente atendida por el nuevo servidor. De lo contrario, en el panel todo se ve bien, pero en internet sigue viviendo la configuración antigua.
Verifique si los NS en el registrador coinciden con los que ha configurado en el nuevo proveedor. Si queda una dirección antigua, el dominio puede comportarse de manera impredecible. Esto es especialmente notable cuando se cambió el registro por la noche y por la mañana el sitio ya "se abre o no".
Otra trampa común es que la zona se ha creado, pero no está activa. El nuevo proveedor de DNS puede aceptar el dominio en el panel, pero no gestionar los registros. En ese caso, usted ve la configuración, pero el mundo exterior no la ve. Desagradable, ¿verdad?
Una buena manera de verificar es ver la respuesta a la consulta NS desde varias fuentes. Si parte de las respuestas va al antiguo proveedor, la transición no se ha completado. Y aquí no importa una sola captura de pantalla, sino 2-3 verificaciones independientes.
Tenga en cuenta la demora en la actualización a nivel mundial y para los usuarios.
Después de cambiar el DNS, algunas personas verán la nueva dirección y otras la antigua. Esto es normal. El proveedor, el enrutador y el dispositivo tienen caché, y no se restablece a su voluntad.
La demora en la actualización a nivel mundial puede variar, así que no saque conclusiones basadas en un solo teléfono o una sola oficina. Verifique el sitio a través de internet en casa, en la red móvil y al menos una herramienta externa. Cuando diferentes puntos muestran resultados diferentes, casi siempre es un rastro de caché, no un fallo del sitio.
Si el dominio ha estado recientemente en la configuración antigua, algunos resolutores aún la recordarán. Entonces, un usuario ve el nuevo servidor, otro ve el antiguo y un tercero recibe un error debido a la discrepancia de los registros. Este comportamiento es especialmente notable al cambiar el registro A a otro host.
Aquí ayuda una simple disciplina: no cambies el DNS de un lado a otro 5 veces seguidas. Cada nueva modificación descompone la imagen más, y luego nadie entiende cuál es el último registro. Es mejor fijar un cambio y esperar, que estar saltando entre tres opciones.
Verificar conflicto entre IPv4 e IPv6
A veces el registro A ya es correcto, pero el AAAA apunta a ningún lado. Para algunos dispositivos esto no es un detalle menor, sino una señal de alto. Los navegadores y redes modernos prefieren IPv6, y si está roto, el sitio puede parecer inaccesible incluso con un IPv4 funcional.
Verifica ambos registros por separado. Si el dominio debe funcionar solo en IPv4, es mejor no dejar accidentalmente el AAAA. Una dirección IPv6 vacía o antigua a menudo crea una imagen extraña: desde una internet el sitio se abre, desde otra no.
A veces es al revés. IPv6 ya está activo, pero el registro A apunta a un servidor antiguo. Entonces algunos usuarios acceden sin problemas, mientras que otros reciben un tiempo de espera. Externamente esto parece un caos, pero la razón suele ser una: dos registros miran en direcciones diferentes.
Si tienes acceso a la configuración de DNS, compara ambas direcciones con la dirección del sitio en funcionamiento. Aquí no hay que adivinar. Se necesitan 2 números: IPv4 e IPv6. Y ambos deben llevar a donde el sitio realmente responde.
Asegurarse de que el sitio responde a la dirección de destino
Incluso el DNS perfecto no salvará si el servidor al otro lado está en silencio. Después de cambiar el registro, es necesario verificar si el host está vivo, si el servidor web está activo y si no se ha perdido la vinculación con el dominio correcto. A veces el sitio está en su lugar, pero el host virtual está configurado con un nombre antiguo.
Si hay varios sitios en el servidor, el host virtual correcto lo resuelve todo. La misma IP puede atender 10 dominios, y sin una vinculación precisa, el servidor entregará el proyecto incorrecto o un error. Esto es especialmente notable después de la migración a una nueva plataforma, cuando aparentemente se copió la configuración, pero se olvidó el nombre de dominio.
Verifique también la respuesta del servidor: 200, 301, 302, 404 o 500. Estos códigos dicen más que cualquier chat con soporte. Si la dirección de destino devuelve 404, significa que el DNS ya ha llegado, pero el sitio en el host no coincide con las expectativas.
A veces es útil abrir no la página principal, sino una ruta específica, como /login o /admin. Así se puede ver si el sitio funciona en su totalidad o solo la página de inicio. Cuando se trata de migración, una pequeña verificación es mejor que una gran confianza de 'parece que se abre'.
Por cierto, si necesitas una pausa recreativa entre las verificaciones, puedes echar un vistazo anécdotas sobre estudiantes. Anécdotas gratis. Cortas — son 1-2 minutos, no más. A veces, tal pausa ayuda a no confundir el servidor antiguo con el nuevo.
Verificar HTTPS y el certificado después de cambiar el registro
El DNS puede ya estar apuntando al host correcto, pero el navegador sigue quejándose de HTTPS. Entonces, el problema está en el certificado, HSTS o redirección. Es una historia muy común después de migrar a una nueva IP.
Verifique si el certificado fue emitido específicamente para este dominio y subdominio. Si la nueva dirección apunta a un servidor donde el certificado fue emitido para otro nombre, el navegador no permitirá que el usuario continúe. Y aquí no ayudarán ni la caché ni el reinicio.
HSTS añade rigidez. Si el sitio funcionaba antes por HTTPS y hay una regla fijada en el navegador, intentar abrirlo con una configuración antigua o incorrecta resultará en un bloqueo inmediato. No es un error del navegador, sino su memoria, y se mantiene más tiempo del que gustaría.
Otra pequeña cosa: redirigir de http a https. Si apunta a un dominio antiguo, el nuevo DNS parece estar correcto, pero el sitio aún no va a donde debería. Verifique la dirección final después de la redirección, no solo el punto de partida.
Si después de todos los pasos aún no está claro si el sitio se abre para otros, tiene sentido verificar la cuestión con el material. cómo verificar un sitio por fraude. A veces, las personas confunden el error del certificado con un intento de suplantación, aunque en realidad es solo una discrepancia entre los registros y el dominio.
Preparar lo que se debe transmitir al soporte de hosting o DNS.
Cuando haya terminado sus verificaciones, reúna un paquete corto para el soporte. Se necesitan el dominio, los nuevos NS, el tiempo exacto de cambio, una captura de pantalla del error y una lista de lo que ya se ha verificado. Son 5 puntos, y ahorran más tiempo que una larga carta de 'no nos funciona nada'.
No olvide indicar desde qué dispositivo y red se ve el problema. Para el soporte, no es una formalidad, sino un detalle útil: el mismo dominio puede abrirse desde una red móvil y fallar desde una red doméstica. También es útil adjuntar los registros A, AAAA y CNAME actuales, si han cambiado.
Si cambió de proveedor de DNS, indique quién tenía el dominio antes y quién lo tiene ahora. A veces, la ayuda se ve obstaculizada porque la zona ya está delegada, pero el servidor antiguo aún responde en parte a algunos resolutores. Cuanto más preciso describa la ruta, menos vueltas dará la respuesta.
Es de buen tono adjuntar de inmediato el resultado de la verificación de 2 a 3 fuentes, y no solo una captura de pantalla del navegador. Es más fácil para el soporte ver dónde se desvía la imagen: en la zona, en el registrador o en el servidor. Y cuanto menos se adivine, más rápido se encuentra el punto crítico.
Si quieres despejar un poco la cabeza después de la rutina técnica, puedes distraerte con los experimentos más crueles de los psicólogos — el material no es sencillo, pero ayuda a desviar la sensación de que un DNS roto mantiene el mundo en su lugar. Y luego regresa a los registros y a los registros NS.
Qué más verificar si el problema es intermitente
Si el sitio solo se abre para algunos usuarios, no mires un solo factor, sino una combinación de 3 cosas: DNS, caché y servidor. Cuando los tres están desincronizados, los síntomas cambian cada hora. Este es precisamente el caso en el que un mismo dominio se comporta de manera diferente por la mañana y por la noche.
A veces ayuda verificar a través de un servicio externo de resolución y hacer una prueba separada en el navegador sin datos guardados. No porque sea magia, sino porque separas la imagen local de la general. Si localmente está mal, pero externamente está bien, el problema está más cerca del dispositivo o del proveedor.
Si después de la migración también cambiaste la estructura del sitio, no olvides los enlaces antiguos. Un usuario puede llegar a una página inexistente y pensar que el dominio está completamente roto. En la práctica, solo se rompe 1 camino de 20.
Y sí, a veces es útil ver el problema como una cadena. El DNS lleva al servidor, el servidor entrega el sitio, el certificado confirma el dominio, y el navegador decide si permitir al usuario o no. Si uno de los 4 elementos falla, el sitio ya no se abre como debería.
Cuando todo está verificado y el acceso sigue siendo inestable, registra los últimos 2 cambios y no hagas nuevos hasta recibir respuesta del soporte. De lo contrario, te estás obstaculizando a ti mismo para ver dónde se rompió la cadena.
