Diagnóstico por capas de una web: DNS, puertos, TLS y HTTP

Un proyecto puede estar completamente subido al servidor, con el código listo y probado en local, y aun así no estar preparado para producción. La causa no siempre está en la aplicación en sí. Puede estar en el DNS que todavía apunta al servidor equivocado, en un puerto que el firewall mantiene cerrado, en un certificado TLS mal encadenado, en un CDN mal configurado o en un proveedor de hosting que no soporta la carga esperada.

Antes de anunciar que un sitio está “en producción”, conviene recorrer una checklist ordenada capa por capa, desde la resolución del dominio hasta la respuesta final de la aplicación: un método de diagnóstico técnico para administradores y equipos de desarrollo que necesitan validar un proyecto antes del lanzamiento.

Por qué diagnosticar por capas antes del lanzamiento

Es habitual que, ante un problema de disponibilidad, alguien empiece a mirar los logs de la aplicación sin haber verificado antes si el tráfico siquiera llega al servidor. El resultado es tiempo perdido: se revisa código que funciona perfectamente, mientras el problema real está varios niveles por debajo.

La lógica de un diagnóstico ordenado es simple: primero se valida que el dominio resuelve a la IP correcta, después que la red y los puertos permiten el tráfico, luego que la capa TLS establece un handshake seguro, y solo entonces tiene sentido revisar el comportamiento HTTP de la aplicación. Es el mismo principio de troubleshooting por capas que se aplica en redes: si una capa inferior falla, no tiene sentido analizar la capa superior hasta resolver la de abajo. No hace falta memorizar el modelo OSI completo para aplicar esta idea; basta con entender que existe una jerarquía de dependencias y que conviene respetarla al investigar un problema.

Capa DNS: registros, TTL y resolución del dominio

El primer punto de control es el DNS, porque si el dominio no resuelve al servidor correcto, todo lo demás es irrelevante.

• A/AAAA: Definen a qué dirección IPv4 o IPv6 apunta el dominio. Un error clásico es dejar el registro A apuntando al servidor de staging en lugar del de producción.
• CNAME: Se usan para alias y subdominios, delegando la resolución hacia otro nombre.
• NS: Indican qué servidores de nombres son autoritativos para el dominio. Un NS mal configurado hace que los cambios en el resto de los registros no tengan efecto.
• TTL: determina cuánto tiempo se cachea una respuesta DNS. Un TTL alto (por ejemplo, 24 horas) antes de una migración puede retrasar la propagación de un cambio crítico durante ese mismo tiempo.
• DNSSEC: Añade firmas criptográficas a las respuestas DNS, reduciendo el riesgo de spoofing o cache poisoning. No es obligatorio, pero suma como factor de seguridad.
• Propagación: Los cambios de DNS no se ven igual en todo el mundo al mismo tiempo, porque distintos resolvers cachean con TTLs distintos hasta que expiran.

Errores frecuentes: dejar un registro apuntando a un servidor de pruebas, olvidar un subdominio (como www o api) o subir el TTL justo antes de una migración en lugar de bajarlo con anticipación.

Herramientas útiles: dig, nslookup, MXToolbox y DNS Checker, que permiten comparar la resolución desde distintas ubicaciones.

Capa de red y puertos: comprobar que el tráfico llega

Aunque el DNS resuelva correctamente, el tráfico todavía tiene que atravesar la capa de red y llegar a un puerto abierto.

El puerto 80 suele usarse para HTTP y, en la mayoría de configuraciones actuales, solo para redirigir a HTTPS. El puerto 443 es el que recibe el tráfico HTTPS real. Si alguno de los dos está bloqueado por el firewall, por un security group mal configurado, por reglas de un WAF demasiado agresivas o por un load balancer que no tiene el backend registrado correctamente, el usuario final puede ver un timeout aunque el servidor esté funcionando.

Un caso frecuente: el proxy o load balancer responde con normalidad, pero el backend detrás no es alcanzable, ya sea porque el servicio no está escuchando en el puerto esperado o porque una regla de red interna lo bloquea. Por eso conviene probar la conectividad desde distintas redes o ubicaciones, no solo desde la máquina donde se está administrando el servidor.

Comandos útiles: ping para verificar conectividad básica (aunque muchos servidores bloquean ICMP), traceroute para ver el camino de los paquetes, telnet dominio.com 443 o nc -zv dominio.com 443 para comprobar si un puerto específico acepta conexiones, nmap para escaneos más completos, y ss o netstat en el propio servidor para ver qué puertos están realmente escuchando. Ten en cuenta que esta prueba de puerto solo confirma alcanzabilidad TCP: no valida por sí sola que el handshake TLS sea correcto, que el certificado coincida con el nombre solicitado ni que la aplicación responda bien por HTTP.

Capa TLS: certificados, cadena y handshake seguro

Con el tráfico llegando al puerto correcto, el siguiente punto de control es TLS.

El certificado debe coincidir exactamente con el dominio (o incluir el nombre correcto en el campo SAN si cubre varios subdominios). Un certificado válido para midominio.com no cubre automáticamente api.midominio.com a menos que esté explícitamente incluido.

También hay que revisar la cadena de certificación que presenta el servidor: el certificado del dominio y los intermedios necesarios para construir una ruta de validación hasta una CA raíz de confianza. El certificado raíz actúa como trust anchor del lado del cliente, así que normalmente no hace falta que el servidor lo envíe. Si falta un intermedio, algunos navegadores y clientes pueden completar la ruta por caché o por mecanismos propios, pero otros rechazarán el certificado, generando errores intermitentes difíciles de reproducir.

Otros puntos a verificar: fecha de expiración y si existe renovación automática configurada, qué versiones de TLS están habilitadas (hoy en día lo recomendable es TLS 1.2 y 1.3, evitando versiones antiguas) y errores de handshake que suelen aparecer cuando el servidor y el cliente no coinciden en el conjunto de cifrados soportados. Una configuración mixta —donde parte de la infraestructura sirve por HTTPS y otra parte todavía por HTTP— también genera advertencias de seguridad en el navegador.

Herramientas útiles: openssl s_client -connect dominio.com:443 -servername dominio.com -showcerts para inspeccionar el handshake y la cadena completa de certificados en detalle, SSL Labs Server Test para una auditoría completa y calificada, y curl -Iv para ver las cabeceras junto con detalles de la conexión TLS.

Capa HTTP: códigos de estado, cabeceras y redirecciones

Una vez confirmado que DNS, red y TLS funcionan, recién corresponde mirar cómo responde la aplicación por HTTP.

Los códigos de estado son el primer indicador: 200 confirma una respuesta correcta, 301/302 indican una redirección (permanente o temporal), 403 suele señalar un bloqueo por permisos o por WAF, 404 indica un recurso inexistente, y los 500, 502 o 503 apuntan a errores del lado del servidor o del proxy que está delante de él.

Conviene revisar también las redirecciones: que HTTP redirija correctamente a HTTPS, que exista una decisión consistente entre www y sin www, y que no haya cadenas largas de redirects ni loops infinitos. Un redirect loop suele aparecer cuando el servidor de origen y un proxy o CDN delante de él tienen configuraciones de HTTPS que no coinciden entre sí.

Las cabeceras de seguridad también forman parte del diagnóstico: HSTS obliga a los navegadores a usar siempre HTTPS con ese dominio, CSP restringe qué recursos puede cargar la página y X-Content-Type-Options evita que el navegador intente adivinar el tipo de contenido de una respuesta. Cache-Control define cómo se cachean los recursos, algo relevante tanto para rendimiento como para evitar servir contenido desactualizado.

Por último, el mixed content —recursos cargados por HTTP dentro de una página servida por HTTPS— es un error común que suele detectarse fácilmente revisando la consola de DevTools del navegador.

Comando básico para empezar: curl -I https://dominio.com, que devuelve únicamente las cabeceras de respuesta sin descargar el cuerpo completo.

Latencia, TTFB y ubicación del servidor

Latencia y TTFB (Time To First Byte) no son lo mismo. La latencia es el tiempo que tarda un paquete en viajar entre cliente y servidor; el TTFB incluye además el tiempo que el servidor tarda en procesar la solicitud y empezar a enviar la respuesta.

La ubicación física del servidor influye directamente en la latencia percibida: si la audiencia principal está en Latinoamérica y el servidor está en Europa, cada solicitud arrastra ese recorrido geográfico adicional. Un CDN ayuda a servir contenido estático más cerca del usuario, pero no soluciona un backend lento: si el TTFB del origen es alto, el CDN solo lo enmascara para el contenido cacheable, no para las respuestas dinámicas.

También es habitual que un VPS esté sobrecargado —por recursos compartidos insuficientes o por picos de tráfico no anticipados— y que eso se traduzca en un TTFB alto incluso con DNS, puertos, TLS y HTTP funcionando correctamente. Por eso conviene probar la velocidad desde la región donde realmente está la audiencia objetivo, no solo desde la ubicación del equipo de desarrollo.

El proveedor de hosting como parte del diagnóstico de infraestructura

El diagnóstico no termina en los comandos de dig, curl u openssl. Todos esos pasos verifican que la configuración actual funciona, pero no garantizan que la infraestructura subyacente aguante producción de forma sostenida.

Si el proveedor tiene una red inestable, un VPS con recursos insuficientes para el tráfico esperado, backups poco confiables, soporte técnico lento para incidencias críticas o límites poco transparentes en ancho de banda y recursos, el riesgo de producción no desaparece aunque DNS, puertos, TLS y HTTP estén perfectamente configurados hoy.

“Elegir un centro de datos lo más cercano posible a tu mercado objetivo reducirá la latencia.” — Sean Thompson, editor en Hostings.info, plataforma especializada en análisis y comparación de servicios de hosting.

Además de revisar DNS, puertos, TLS y respuesta HTTP, conviene evaluar la base de infraestructura: recursos asignados, ubicación de los servidores, política de copias de seguridad, soporte técnico, escalabilidad y postura de seguridad del proveedor. Comparar distintos proveedores de hosting VPS ayuda a tomar esa decisión con criterios técnicos antes de mover un proyecto a producción, en lugar de basarla únicamente en el precio.

Checklist final antes de producción

• [ ] DNS apunta a la IP correcta.
• [ ] TTL reducido antes del cambio de infraestructura.
• [ ] Registros A/AAAA/CNAME revisados y sin referencias a entornos de prueba.
• [ ] Puertos 80/443 abiertos y accesibles desde distintas redes.
• [ ] Firewall/WAF no bloquea tráfico legítimo.
• [ ] Certificado TLS válido, con cadena completa y SAN correcto.
• [ ] TLS 1.2/1.3 habilitado, versiones antiguas deshabilitadas.
• [ ] Redirecciones HTTP → HTTPS correctas, sin loops ni cadenas largas.
• [ ] No hay errores 4xx/5xx en las URLs clave del sitio.
• [ ] Cabeceras críticas (HSTS, CSP, X-Content-Type-Options, Cache-Control) revisadas.
• [ ] No hay mixed content en ninguna página relevante.
• [ ] Backups y logs activos y verificados.
• [ ] Proveedor de hosting validado para soportar el tráfico esperado en producción.

Herramientas útiles para el diagnóstico

• dig / nslookup — resolución y registros DNS.
• ping / traceroute — conectividad y ruta de red.
• nc / telnet / nmap — verificación de puertos.
• openssl — inspección de certificados y handshake TLS.
• curl — códigos de estado, cabeceras y redirecciones.
• SSL Labs — auditoría completa de configuración TLS.
• DevTools del navegador: mixed content, cabeceras, tiempos de carga.
• UptimeRobot / Dotcom-Monitor / StatusCake — monitoreo continuo desde distintas ubicaciones.

Un lanzamiento a producción rara vez falla por una sola causa aislada. Suele ser la combinación de una capa que no se revisó a tiempo —un TTL demasiado alto, un puerto cerrado, un certificado con la cadena incompleta— la que termina generando el incidente. Revisar cada capa en orden, con las herramientas correctas, es lo que permite encontrar el problema real en minutos en lugar de horas.