Siga una solicitud desde DNS hasta su aplicación.

Anote la ruta que espera

Este recorrido asume un VPS Linux que usted administra, una sesión SSH en funcionamiento, una aplicación con un punto de enlace inofensivo /healthz y acceso a la configuración DNS autoritativa de un dominio que controla. La aplicación de ejemplo escucha en 127.0.0.1:3000; Caddy es el proxy inverso público. Si su aplicación usa un supervisor o proxy diferente, mantenga el orden de diagnóstico y use su documentación.

api.example.com y 203.0.113.10 son marcadores de posición de documentación, no un servicio en vivo. Reemplace ambos antes de ejecutar comprobaciones contra su propio sistema. Anote el nombre de host real, la dirección IP prevista, el puerto de la aplicación y el nombre del servicio en un solo lugar. Establecer un nombre de host de VPS en el configurador no crea un registro DNS público.

1. DNS devuelve la dirección prevista.
2. La conexión llega al servidor y puerto previstos.
3. TLS autentica el nombre de host solicitado.
4. El proxy reenvía la solicitud al upstream correcto.
5. La aplicación devuelve la respuesta esperada.

Compruebe ambas familias de direcciones

Desde una máquina fuera del VPS, consulte los registros que pretende publicar. dig pertenece a las herramientas DNS de BIND; los nombres de los paquetes varían. Estos comandos solicitan la sección de respuesta para que pueda ver el tipo de registro, la dirección y el tiempo de vida restante en caché. Consulte la referencia de dig de BIND.

dig api.example.com A +noall +answer
dig api.example.com AAAA +noall +answer

Compare cada dirección devuelta con su destino previsto. Publique un registro AAAA solo cuando el enrutamiento, la escucha y el filtrado de IPv6 funcionen para esa dirección. Un registro AAAA antiguo puede enviar a algunos clientes a un lugar diferente del registro A. Si usa intencionalmente una CDN o un proxy DNS, sus direcciones pueden ser correctas; registre ese salto adicional en lugar de asumir que el VPS debe aparecer.

Una respuesta en blanco necesita una mirada más cercana a la dig respuesta completa: puede significar que no hay registro de ese tipo, un nombre inexistente o un problema de resolución. Verifique qué servicio DNS es autoritativo antes de editar. Registre el valor antiguo y el TTL, haga el cambio previsto allí, luego compare resultados nuevos después de que expiren las cachés existentes. Las ediciones repetidas no relacionadas hacen que la línea de tiempo sea más difícil de entender.

Separe los fallos de conexión de los fallos de certificado

Solicite el punto de enlace pequeño desde fuera del servidor. Use GET en lugar de asumir que su aplicación implementa HEAD. Las opciones de tiempo de espera de curl acotan la comprobación; su salida detallada muestra el progreso de conexión y TLS. Curl documenta estas opciones y la verificación de certificados.

curl --verbose --connect-timeout 5 --max-time 10 https://api.example.com/healthz

Un error de resolución apunta de vuelta a DNS. Una conexión rechazada significa que la conexión fue rechazada activamente; un tiempo de espera puede implicar enrutamiento o filtrado y no identifica qué firewall lo causó. Un error de certificado significa que no se estableció la conexión segura esperada. No haga de deshabilitar las comprobaciones de certificado su solución permanente.

Para comparar un origen específico mientras mantiene el nombre de host en la solicitud TLS, use la anulación de dirección de curl:

curl --verbose --connect-timeout 5 --max-time 10 --resolve api.example.com:443:203.0.113.10 https://api.example.com/healthz

Si esto funciona mientras la solicitud ordinaria falla, compara DNS y cualquier intermediario. Esta anulación no edita DNS. Cuando existan registros A y AAAA, repite la solicitud ordinaria con --ipv4 y --ipv6 desde un cliente que realmente admita la red correspondiente.

Inspeccione el extremo del servidor de la conexión

En el VPS, inspecciona los sockets TCP en escucha y consulta la app directamente:

sudo ss -ltnp
curl --silent --show-error --max-time 5 http://127.0.0.1:3000/healthz

ss muestra los listeners y, con permisos suficientes, sus procesos. Un listener de loopback es alcanzable localmente; su presencia por sí sola no dice nada sobre el acceso externo. Consulta el manual de ss upstream. Si la solicitud directa a la app falla, pasa a la guía de diagnóstico de procesos antes de cambiar DNS.

Para esta disposición de una sola app, el bloque relevante del Caddyfile es:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

El hostname y el upstream deben coincidir con tu aplicación. La directiva reverse proxy de Caddy reenvía las solicitudes al upstream configurado; poner un dominio arbitrario aquí no te da control sobre él. Conserva la configuración existente antes de editar. Con el servicio empaquetado y esta ruta de archivo, valida primero y luego recarga solo cuando la validación tenga éxito:

sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

Los comandos tienen propósitos distintos: la validación comprueba la carga de la configuración, mientras que la recarga aplica el cambio. Comprueba la ruta de archivo y los permisos reales del servicio instalado. La referencia de comandos de Caddy explica el comportamiento de validación y recarga.

Verifique la ruta completa y luego conserve la evidencia

Para la automatización de certificados públicos ordinaria, Caddy necesita DNS correcto, puertos de challenge alcanzables externamente, permiso para enlazar sus listeners y almacenamiento de certificados persistente y escribible. Los challenges HTTP y TLS-ALPN usan los puertos 80 y 443 respectivamente; un challenge DNS es una configuración aparte. Consulta los requisitos previos de HTTPS de Caddy. Mantén intacto el acceso administrativo al revisar las reglas del firewall.

Resultado ilustrativo: el endpoint local devuelve {"status":"ok"}, la solicitud externa HTTPS devuelve el mismo cuerpo pequeño, y curl informa una verificación de certificado exitosa. Estas son observaciones esperadas para este ejemplo, no resultados registrados de un servidor OffVPS. Ejercita también una acción normal de la aplicación: un endpoint de salud superficial puede pasar mientras una ruta dependiente de base de datos falla.

Registra la hora de la solicitud, el hostname, la familia de direcciones y la primera capa que falla. Ese resumen es más útil que “el dominio está roto”. Una vez que la ruta funcione, usa la guía de release repetible para convertir estas mismas comprobaciones en parte de cada despliegue.