Sigue una solicitud desde el DNS hasta tu app.

Anota la ruta que esperas

Este recorrido asume un VPS Linux que administras, una sesión SSH funcional, una aplicación con un /healthz endpoint inofensivo, y acceso a la configuración DNS autoritativa de un dominio que controlas. La app de ejemplo escucha en 127.0.0.1:3000; Caddy es el proxy inverso público. Si tu app usa un supervisor o proxy diferente, mantén el orden de diagnóstico y usa su documentación.

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

1. El DNS devuelve la dirección prevista.
2. La conexión llega al servidor y al 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.

Comprueba ambas familias de direcciones

Desde una máquina fuera del VPS, consulta los registros que piensas 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 puedas ver el tipo de registro, la dirección y el tiempo de vida restante en caché. Consulta la referencia de BIND dig.

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

Compara cada dirección devuelta con tu destino previsto. Publica 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 distinto del registro A. Si usas intencionadamente un CDN o un proxy DNS, sus direcciones pueden ser correctas; registra ese salto adicional en lugar de asumir que el VPS debe aparecer.

Una respuesta en blanco requiere mirar más de cerca la dig respuesta completa: puede significar que no hay registro de ese tipo, un nombre inexistente o un problema de resolución. Comprueba qué servicio DNS es autoritativo antes de editar. Registra el valor antiguo y el TTL, haz el cambio previsto allí, luego compara resultados nuevos después de que caduquen las cachés existentes. Ediciones repetidas no relacionadas hacen que la cronología sea más difícil de entender.

Separa los fallos de conexión de los fallos de certificado

Solicita el endpoint pequeño desde fuera del servidor. Usa GET en lugar de asumir que tu aplicación implementa HEAD. Las opciones de timeout de Curl acotan la comprobación; su salida verbose 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 al DNS. Una conexión rechazada significa que la conexión fue rechazada activamente; un timeout 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 conviertas desactivar las comprobaciones de certificado en tu solución permanente.

Para comparar un origen específico manteniendo el nombre de host en la solicitud TLS, usa 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

Se questo riesce mentre la richiesta ordinaria fallisce, confronta DNS e qualsiasi intermediario. Questa sovrascrittura non modifica il DNS. Quando esistono sia record A che AAAA, ripeti la richiesta ordinaria con --ipv4 y --ipv6 da un client che supporta effettivamente la rete corrispondente.

Inspecciona el extremo servidor de la conexión

Sul VPS, ispeziona i socket TCP in ascolto e interroga direttamente l'app:

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

ss mostra i listener e, con permessi sufficienti, i loro processi. Un listener di loopback è raggiungibile localmente; la sua presenza da sola non dice nulla sull'accesso esterno. Consulta il manuale di ss upstream. Se la richiesta diretta all'app fallisce, passa alla guida alla diagnosi dei processi prima di modificare il DNS.

Per questa configurazione single-app, il blocco Caddyfile rilevante è:

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Il nome host e l'upstream devono corrispondere alla tua applicazione. La direttiva reverse proxy di Caddy inoltra le richieste all'upstream configurato; inserire un dominio arbitrario qui non ti dà il controllo su di esso. Conserva la configurazione esistente prima di modificare. Con il servizio pacchettizzato e questo percorso file, valida prima, poi ricarica solo dopo che la validazione è riuscita:

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

I comandi hanno scopi diversi: la validazione controlla il caricamento della configurazione, mentre il reload applica la modifica. Controlla il percorso file effettivo e i permessi del servizio installato. Il riferimento ai comandi di Caddy spiega il comportamento di validazione e ricarica.

Verifica la ruta completa y luego conserva la evidencia

Per l'automazione ordinaria dei certificati pubblici, Caddy necessita di DNS corretto, porte di challenge raggiungibili dall'esterno, permesso di associare i suoi listener e archiviazione persistente e scrivibile dei certificati. Le challenge HTTP e TLS-ALPN usano rispettivamente le porte 80 e 443; una challenge DNS è una configurazione separata. Vedi prerequisiti HTTPS di Caddy. Mantieni intatto l'accesso amministrativo quando rivedi le regole del firewall.

Risultato illustrativo: l'endpoint locale restituisce {"status":"ok"}, la richiesta esterna HTTPS restituisce lo stesso piccolo body, e curl segnala una verifica del certificato riuscita. Queste sono osservazioni attese per questo esempio, non risultati registrati da un server OffVPS. Esegui anche una normale azione dell'applicazione: un endpoint di health superficiale può passare mentre una rotta che dipende dal database fallisce.

Registra l'ora della richiesta, il nome host, la famiglia di indirizzi e il primo livello che fallisce. Quel brief è più utile di "il dominio è rotto". Una volta che il percorso funziona, usa la guida al rilascio ripetibile per rendere gli stessi controlli parte di ogni distribuzione.