Usa esta lista de comprobación para dominios personalizados para diagnosticar problemas de registros DNS, retrasos de propagación y tiempos de emisión de SSL, con pasos simples de verificación.
“El dominio personalizado no funciona” es una frase comodín para varios fallos distintos. Tu navegador muestra el síntoma, no la causa. Antes de cambiar nada, nombra exactamente lo que estás viendo.
Síntomas típicos incluyen:
La mayoría de las veces, solo hay una cosa mal:
Antes de solucionar, asegúrate de tener acceso a dos sitios: donde editas los registros DNS (registrador o proveedor DNS) y donde adjuntas el dominio en el hosting. Por ejemplo, si conectas una app desplegada en Koder.ai a un dominio personalizado, necesitas acceso DNS para el dominio y acceso a la configuración de dominio en el panel de hosting o despliegue de la app.
Algunas correcciones son instantáneas (como corregir una errata). Otras toman tiempo. Los cambios en DNS pueden tardar en mostrarse y SSL normalmente no terminará hasta que el DNS apunte correctamente y el dominio sea accesible. El objetivo es dejar de adivinar y confirmar cada capa en orden.
La mayoría de los problemas de dominio se reducen a una desalineación entre (1) el nombre de host que estás probando, (2) dónde se gestiona el DNS y (3) a qué apunta realmente el registro. Una vez que esos tres coinciden, SSL suele ser el último paso.
Los dominios tienen dos formas comunes: el dominio raíz (example.com, también llamado apex) y subdominios (www.example.com, app.example.com). Están relacionados, pero pueden tener distintos registros DNS. Por eso es normal que www funcione mientras el apex falla, o al revés.
Los nameservers deciden quién está a cargo de tu zona DNS. Si compraste el dominio en una compañía pero los nameservers apuntan a otra, debes editar el DNS donde apunten los nameservers. Muchos casos de “lo actualicé pero nada cambió” ocurren porque los registros se editaron en el panel equivocado.
Esto es lo que hacen los tipos principales:
www)TTL es el temporizador de “por cuánto tiempo almacenar en caché esto”. Un TTL bajo significa que las cachés se actualizan más rápido. Un TTL alto significa que puede que tengas que esperar más, incluso después de corregir el registro. Ver el valor antiguo por un tiempo puede ser normal.
Cuando un dominio personalizado falla, normalmente puedes clasificarlo en uno de cuatro grupos: DNS no resuelve, DNS resuelve al lugar equivocado, SSL no está listo, o solo falla para algunas personas por caché.
Usa este árbol de decisiones:
www funciona pero el dominio raíz no (o al revés), probablemente configuraste solo un hostname o tienes reglas de redirección en conflicto.Avanza más rápido anotando el nombre de host exacto que falla (apex vs www) y el mensaje de error exacto. En plataformas de hosting que automatizan dominios y certificados, la diferencia entre “no se encuentra el host” y “certificado pendiente” te indica si debes arreglar registros DNS o simplemente esperar SSL después de que el DNS sea visible.
Muchos fallos de dominio empiezan por una descoincidencia simple: configuras DNS para un hostname, pero estás probando otro.
Primero, apunta el nombre de host exacto que quieres tener activo. El dominio raíz se ve como example.com. Un subdominio se ve como www.example.com o app.example.com. Son entradas DNS separadas, así que “www funciona” no significa que el dominio raíz también lo haga.
A continuación, encuentra el objetivo esperado desde tu plataforma de hosting. Algunas plataformas te dan una dirección IP (para un registro A o AAAA). Otras dan un hostname de destino (para un CNAME). Si tu host proporciona un valor en la pantalla de configuración de dominio, trátalo como la fuente de la verdad.
Antes de cambiar nada, captura lo que está configurado ahora. Manténlo simple:
También confirma que estás editando la zona DNS correcta. Es fácil actualizar el dominio equivocado, el entorno equivocado o la cuenta de proveedor equivocada.
Muchos problemas son simplemente el tipo de registro equivocado para el hostname que intentas conectar. Empieza separando dos casos: el dominio raíz (example.com) y un subdominio (www.example.com). Se comportan distinto en muchos proveedores DNS.
Un registro A apunta un nombre a una dirección IPv4. Muchas configuraciones usan un A para el dominio raíz porque algunos proveedores no permiten un CNAME en el apex. Si tu host te da una IP, un A suele ser correcto.
Un registro AAAA es la versión IPv6. Un AAAA sobrante apuntando a un destino antiguo puede crear un comportamiento confuso de “a mí me funciona”, porque algunos visitantes llegarán por IPv6 y otros por IPv4. Si tu host no te dio un objetivo IPv6, eliminar un AAAA incorrecto a menudo corrige fallas inconsistentes.
Un CNAME apunta un subdominio a otro hostname (a menudo usado para www). Es útil cuando el host quiere que apuntes a un endpoint nombrado que puede cambiar detrás de escenas.
Un TXT es para verificación y desafíos (incluyendo algunas verificaciones de SSL). Errores comunes incluyen colocarlo en el nombre incorrecto (raíz vs _acme-challenge vs un subdominio), agregar espacios extra o pegar un valor incorrecto.
Antes de seguir, busca conflictos. Estos son los que causan más problemas:
www o el dominio raízMuchos casos de “el dominio personalizado no funciona” no tienen que ver con el valor del registro. Ocurren porque el registro se añadió en el proveedor equivocado. Si tu dominio usa los nameservers del Proveedor A, cambiar registros en el panel del Proveedor B no hará nada, aunque los registros se vean correctos allí.
Comprueba qué nameservers está usando realmente tu dominio. Normalmente puedes verlo en la configuración del dominio en tu registrador bajo “Nameservers”. Para una segunda opinión, pregunta al DNS directamente desde tu equipo:
dig NS example.com
Los nameservers que devuelva ese comando son los autoritativos.
Una comprobación rápida:
ns1... y ns2..., esos valores exactos deben aparecer en el registrador.Si actualizas registros en el proveedor equivocado, a menudo verás dos paneles que no coinciden. Solo los nameservers autoritativos importan.
También vigila los retrasos tras cambiar nameservers en el registrador. Durante la ventana de transición, los resultados pueden verse inconsistentes según desde dónde pruebes. Si los nameservers aún están cambiando, pausa las ediciones de registros hasta que el conjunto de nameservers sea estable y luego continúa.
“Propagación” no es un interruptor único. Es una cadena de cachés DNS (ISP, operador móvil, resolvers públicos y tus propios dispositivos) que se actualizan a distintas velocidades. Por eso tu dominio puede funcionar para un compañero y fallar para ti.
TTL (time to live) indica cuánto tiempo pueden conservar una respuesta. Si el TTL antiguo fue 1 hora, algunas personas seguirán viendo el valor antiguo durante casi una hora. Bajar el TTL ayuda solo si lo hiciste antes de hacer el cambio.
Para separar retrasos por caché de errores reales, haz unas comprobaciones rápidas:
www)Si el registro está mal en cualquiera de los lugares donde pruebas (IP equivocada, falta www, CNAME antiguo), arréglalo. Si los registros se ven correctos en la mayoría de sitios pero una red aún muestra el valor antiguo, suele ser un retraso por caché.
Los certificados SSL fallan normalmente por una razón básica: el proveedor del certificado no puede validar el dominio hasta que el DNS apunte al lugar correcto de forma consistente.
La secuencia normal es simple:
Los bloqueadores comunes son fáciles de pasar por alto. Un A o CNAME equivocado envía las comprobaciones de validación al servidor errado. Un AAAA obsoleto puede sobreescribir tu A funcional para algunos visitantes, de modo que HTTPS falla solo para ellos. No tener un TXT requerido puede impedir que la plataforma emita un certificado.
Usa los síntomas para separar “aún emitiéndose” de “configuración errónea”:
Mientras esperas, no sigas cambiando registros. Cada cambio reinicia el reloj y puede crear un mundo dividido donde distintas redes ven respuestas diferentes. Ajusta los registros correctamente una vez, luego vuelve a comprobar la resolución y la verificación hasta que el certificado se emita.
Si usas una plataforma como Koder.ai, el flujo más seguro es el mismo: confirma que el DNS apunta al objetivo esperado, elimina registros AAAA incorrectos si existen y deja tiempo para SSL una vez que el DNS esté estable.
Una buena solución de problemas es mayormente comparación: lo que ves frente a lo que esperas. No te fíes de “a mí en el móvil carga”. Usa comprobaciones repetibles.
Usa una herramienta de consulta DNS (como nslookup o dig) y confirma que el valor devuelto coincide con lo que pretendías (una IP para A o AAAA, un hostname para CNAME, un token para TXT).
# Apex (root) domain
dig example.com A
dig example.com AAAA
# www subdomain
dig www.example.com CNAME
# TXT (often used for verification)
dig example.com TXT
Comprueba ambos nombres que puedas estar usando: el apex (example.com) y www (www.example.com). Es común que uno esté correcto mientras el otro aún apunta a un lugar antiguo.
Abre tanto http:// como https:// para el apex y para www. Quieres un dominio “principal” claro y una redirección limpia.
www) y redirige el otro hacia él.Si los resultados difieren por red de prueba, probablemente estás viendo caché o propagación. Mantén un registro pequeño: qué cambiaste, dónde lo cambiaste, la hora y lo que observaste.
La mayoría de los problemas de DNS y SSL no son misterios. Son errores pequeños que te mantienen comprobando lo incorrecto o cambiando cosas demasiado rápido para tener una lectura clara.
El mayor tiempo perdido es editar DNS en dos sitios. Esto ocurre tras cambiar nameservers: actualizas registros en el registrador, pero el DNS está realmente hospedado en otro lado (o viceversa). Todo se ve correcto en un panel, pero nada cambia públicamente.
Otro error clásico es intentar poner un CNAME en el dominio raíz con un proveedor que no lo soporta. Puede que necesites un registro A, o un registro tipo ALIAS o ANAME si tu proveedor DNS lo ofrece.
IPv6 también puede dar dolores de cabeza. Dejar un AAAA viejo puede enviar a algunos visitantes al servidor equivocado mientras otros llegan por IPv4 correctamente.
Ten cuidado con los registros “por si acaso”. Varios registros A pueden comportarse como balanceo de carga accidental si uno de los destinos está mal, especialmente al apuntar un dominio personalizado a una app hospedada.
Una regla final: deja de reiniciar el reloj.
Cambios pequeños y tranquilos ganan a retocar constantemente.
www funciona pero el dominio raíz noLanzas una app nueva y configuras example.com y www.example.com. Unos minutos después, www.example.com carga bien, pero el dominio raíz muestra un error DNS, carga un sitio antiguo o HTTPS queda pendiente. Este patrón es común y suele tener una causa pequeña.
Empieza con la pregunta aburrida: ¿estás editando DNS en el lugar correcto? Si tu dominio está registrado en una compañía pero el DNS está hospedado en otra, puedes cambiar registros todo el día y nada pasará. Verifica nameservers primero y luego abre el panel DNS del proveedor al que esos nameservers apuntan.
Luego, compara los dos hostnames. www suele ser un CNAME. El dominio raíz es más delicado: muchos proveedores no permiten un CNAME en el apex, así que a menudo necesita un A a una IP o un registro ALIAS/ANAME si el proveedor lo soporta.
Un camino de decisión que funciona en la práctica:
example.com no tiene registro (o apunta a otro sitio)? Corrige el registro del apex.El estado final correcto es aburrido: tanto example.com como www.example.com apuntan a la misma app, uno es canónico (el otro redirige) y HTTPS es válido.
Cuando una configuración de dominio falla, la mayoría de las soluciones vienen de unas pocas comprobaciones rápidas. Ejecuta estas antes de cambiar cualquier otra cosa.
Después de que DNS esté claramente correcto, revisa SSL. Muchas plataformas emiten el certificado solo después de poder resolver tu dominio al objetivo esperado de forma consistente. Si compruebas demasiado pronto, puedes confundir un retraso normal con un error real.
Si estás añadiendo un dominio personalizado a una app desplegada en Koder.ai, trata la pantalla de configuración de dominio de la app como referencia para el objetivo DNS esperado y luego vuelve a comprobar el estado solo después de que el DNS haya tenido tiempo de propagarse.
La forma más rápida de evitar repetir errores de DNS y SSL es mantener una nota corta de “configuración de dominio” para cada proyecto. Es un runbook reutilizable que puedes copiar la próxima vez que lances.
Guárdala en la documentación del proyecto y complétala antes de tocar el DNS:
Durante el lanzamiento, asigna una persona como responsable del DNS. El DNS suele romperse cuando dos personas “arreglan” cosas distintas al mismo tiempo (por ejemplo, una cambia nameservers mientras otra edita registros).
En el lado del hosting, planea reversiones seguras. Si tu plataforma soporta snapshots o rollback, haz una snapshot antes de cambiar el enrutamiento para poder volver rápidamente al último estado conocido bueno. Si construyes en Koder.ai, puedes usar Planning Mode para anotar los pasos del dominio, aplicarlos en orden y revertir si un cambio rompe producción.
Si confirmaste que el DNS es correcto y aún ves fallos, deja de adivinar y escala con evidencia:
Cuando escales, incluye el hostname, los registros esperados, los resultados actuales de los resolvers y marcas de tiempo. Convierte un intercambio lento en un arreglo rápido.
Suele significar que una capa de la cadena está fallando: DNS que no resuelve, DNS que resuelve al destino equivocado, el servidor/host no reconoce tu nombre de host o HTTPS/SSL no ha terminado de emitirse. Empieza por anotar el error exacto que ves y el nombre de host que escribiste (apex vs www).
Porque example.com (el apex) y www.example.com son nombres de host distintos con registros DNS separados. Es frecuente tener un CNAME correcto para www mientras que el apex no tiene un registro A, tiene un A incorrecto o tu proveedor DNS no soporta la configuración que intentas.
Revisa los nameservers del dominio en tu registrador y compáralos con el proveedor DNS donde estás editando. Solo el proveedor listado en los nameservers activos es el autoritativo; editar registros en otro sitio no cambiará lo que ve Internet.
Usa un registro A cuando tu host te dé una dirección IPv4, un registro AAAA solo si te dan una dirección IPv6, y un CNAME cuando tu host te dé otro nombre de host (lo más habitual para www). Los registros TXT son para verificación y desafíos y deben crearse exactamente en el nombre que indique tu host.
Un registro AAAA obsoleto o incorrecto puede enviar a algunos visitantes por IPv6 a un servidor viejo mientras que otros van al destino IPv4 correcto, lo que genera la confusión de “a mí me funciona”. Si tu host no te dio un objetivo IPv6, eliminar un AAAA incorrecto suele ser la solución más simple.
Normalmente significa que solo has configurado un hostname en el hosting (solo apex o solo www), o que hay reglas de redirección contradictorias que rebotan entre HTTP y HTTPS o entre apex y www. Elige un nombre canónico, configura ambos nombres y asegúrate de que exista una sola ruta de redirección limpia.
Sí. Esperar es lo correcto solo después de comprobar que DNS apunta correctamente desde varios lugares. La emisión de certificados suele completarse solo cuando el dominio resuelve de forma consistente al destino esperado; cambiar DNS de un lado a otro reinicia ese proceso.
TTL es cuánto tiempo los resolvers almacenan una respuesta en caché, así que incluso después de arreglar un registro, algunas redes seguirán sirviendo el valor antiguo hasta que venza la ventana de TTL. Prueba desde dos redes diferentes (por ejemplo, Wi‑Fi y datos móviles) y evita cambiar DNS cada pocos minutos para observar correctamente la propagación.
Usa una comprobación repetible como dig o nslookup para confirmar que las respuestas A/AAAA/CNAME/TXT coinciden con el destino esperado, y luego prueba tanto http:// como https:// para el apex y para www. Si una red muestra respuestas DNS distintas a otra, trátalo como caché; si todas muestran respuestas equivocadas, es un error de configuración.
En Koder.ai, considera la pantalla de configuración de dominio de la app como la fuente de verdad para el destino DNS esperado; haz que el DNS coincida exactamente en el proveedor autoritativo. Tras cambiar DNS, da tiempo a que se estabilice antes de volver a comprobar SSL y usa snapshots/rollback si ajustas el enrutamiento en un proyecto en producción para volver rápidamente al estado conocido bueno.