Suivez une requête du DNS à votre application.

Écrivez la route que vous attendez

Cette procédure pas à pas suppose un VPS Linux que vous administrez, une session SSH fonctionnelle, une application avec un point de terminaison /healthz inoffensif, et l'accès aux paramètres DNS faisant autorité pour un domaine que vous contrôlez. L'application exemple écoute sur 127.0.0.1:3000; Caddy est le proxy inverse public. Si votre application utilise un superviseur ou un proxy différent, conservez l'ordre de diagnostic et utilisez sa documentation.

api.example.com et 203.0.113.10 sont des espaces réservés de documentation, pas un service en direct. Remplacez les deux avant d'exécuter des vérifications sur votre propre système. Notez le nom d'hôte réel, l'adresse IP prévue, le port de l'application et le nom du service en un seul endroit. Définir un nom d'hôte de VPS dans le configurateur ne crée pas d'enregistrement DNS public.

1. Le DNS renvoie l'adresse prévue.
2. La connexion atteint le serveur et le port prévus.
3. TLS authentifie le nom d'hôte demandé.
4. Le proxy transmet la requête au bon upstream.
5. L'application renvoie la réponse attendue.

Vérifiez les deux familles d'adresses

Depuis une machine extérieure au VPS, interrogez les enregistrements que vous comptez publier. dig appartient aux outils DNS de BIND ; les noms de paquets varient. Ces commandes demandent la section de réponse afin que vous puissiez voir le type d'enregistrement, l'adresse et la durée de vie restante en cache. Voir la référence BIND dig.

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

Comparez chaque adresse renvoyée avec votre destination prévue. Publiez un enregistrement AAAA uniquement lorsque le routage, l'écoute et le filtrage IPv6 fonctionnent pour cette adresse. Un ancien enregistrement AAAA peut envoyer certains clients ailleurs que l'enregistrement A. Si vous utilisez intentionnellement un CDN ou un proxy DNS, ses adresses peuvent être correctes ; enregistrez ce saut supplémentaire au lieu de supposer que le VPS doit apparaître.

Une réponse vide nécessite un examen plus attentif de la dig réponse complète : cela peut signifier l'absence d'enregistrement de ce type, un nom inexistant ou un problème de résolution. Vérifiez quel service DNS fait autorité avant de modifier. Enregistrez l'ancienne valeur et le TTL, effectuez la modification prévue à cet endroit, puis comparez les nouveaux résultats après l'expiration des caches existants. Des modifications répétées non liées rendent la chronologie plus difficile à comprendre.

Séparez les échecs de connexion des échecs de certificat

Demandez le petit point de terminaison depuis l'extérieur du serveur. Utilisez GET plutôt que de supposer que votre application implémente HEAD. Les options de délai d'attente de Curl limitent la vérification ; sa sortie verbeuse montre la progression de la connexion et de TLS. Curl documente ces options et la vérification des certificats.

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

Une erreur de résolution renvoie au DNS. Une connexion refusée signifie que la connexion a été activement rejetée ; un délai d'attente peut impliquer un routage ou un filtrage et n'identifie pas quel pare-feu en est la cause. Une erreur de certificat signifie que la connexion sécurisée attendue n'a pas été établie. Ne faites pas de la désactivation des vérifications de certificat votre correctif permanent.

Pour comparer une origine spécifique tout en conservant le nom d'hôte dans la requête TLS, utilisez la substitution d'adresse 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 cela réussit alors que la requête ordinaire échoue, comparez le DNS et tout intermédiaire. Cette option ne modifie pas le DNS. Lorsque les enregistrements A et AAAA existent tous deux, répétez la requête ordinaire avec --ipv4 et --ipv6 depuis un client qui prend réellement en charge le réseau correspondant.

Inspectez le côté serveur de la connexion

Sur le VPS, inspectez les sockets TCP en écoute et interrogez directement l'application :

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

ss affiche les écouteurs et, avec des permissions suffisantes, leurs processus. Un écouteur loopback est joignable localement ; sa seule présence ne dit rien sur l'accès externe. Consultez le manuel ss en amont. Si la requête directe à l'application échoue, passez au guide de diagnostic des processus avant de modifier le DNS.

Pour cette configuration à application unique, le bloc Caddyfile pertinent est :

api.example.com {
    reverse_proxy 127.0.0.1:3000
}

Le nom d'hôte et l'amont doivent correspondre à votre application. La directive de proxy inverse de Caddy transmet les requêtes à l'amont configuré ; placer un domaine arbitraire ici ne vous en donne pas le contrôle. Préservez la configuration existante avant de modifier. Avec le service packagé et ce chemin de fichier, validez d'abord, puis rechargez uniquement après la réussite de la validation :

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

Les commandes ont des objectifs différents : la validation vérifie le chargement de la configuration, tandis que le rechargement applique la modification. Vérifiez le chemin de fichier réel et les permissions du service installé. La référence des commandes de Caddy explique le comportement de validation et de rechargement.

Vérifiez le chemin complet, puis conservez les preuves

Pour l'automatisation ordinaire des certificats publics, Caddy a besoin d'un DNS correct, de ports de challenge joignables de l'extérieur, de la permission de lier ses écouteurs et d'un stockage de certificats persistant et inscriptible. Les challenges HTTP et TLS-ALPN utilisent respectivement les ports 80 et 443 ; un challenge DNS est une configuration distincte. Voir les prérequis HTTPS de Caddy. Maintenez l'accès administratif intact lors de la revue des règles de pare-feu.

Résultat illustratif : le point de terminaison local renvoie {"status":"ok"}, la requête externe HTTPS renvoie le même petit corps, et curl signale une vérification de certificat réussie. Ce sont des observations attendues pour cet exemple, et non des résultats enregistrés provenant d'un serveur OffVPS. Exercez aussi une action applicative normale : un point de terminaison de santé superficiel peut réussir alors qu'une route dépendant de la base de données échoue.

Notez l'heure de la requête, le nom d'hôte, la famille d'adresses et la première couche en échec. Ce compte rendu est plus utile que « le domaine est cassé ». Une fois le chemin fonctionnel, utilisez le guide de publication reproductible pour intégrer ces mêmes vérifications à chaque déploiement.