Suite à la mise à niveau du site Web vers l'équilibrage de charge, certains utilisateurs signalent régulièrement des erreurs DNS !

Bonjour Alex, la surveillance indique que tout est vert, mais les utilisateurs signalent des erreurs DNS d'origine ? Il s'agit d'un scénario classique : en substance, tout semble normal en arrière-plan, mais les utilisateurs rencontrent des problèmes d'accès réels. La cause profonde ne réside souvent pas dans le fait que votre serveur soit actif ou non, mais dans la destination finale de la résolution de l'utilisateur. Les raisons les plus courantes se répartissent en trois catégories : Les enregistrements DNS ne sont pas synchronisés : différentes régions ou différents FAI peuvent résoudre vers différentes adresses IP.Peut-être que votre équilibreur de charge vient de changer et que certains emplacements pointent encore vers d'anciennes adresses IP désactivées. Les paramètres TTL sont délicats : les durées TTL sont trop longues, ou les couches de mise en cache du DNS cloud, du CDN et du FAI local empêchent la propagation complète des nouveaux enregistrements. Problèmes liés au CDN ou au backend : les nœuds CDN d'une région spécifique ne parviennent pas à atteindre votre serveur d'origine (ou LB).Cela peut se produire si les nouveaux nœuds ne sont pas ajoutés à la liste blanche, si les pare-feu bloquent les plages d'adresses IP d'origine, etc. Pourquoi cela fonctionne-t-il au bureau, mais pas pour les utilisateurs ? C'est crucial, car cela indique que le problème n'est pas universel. Le DNS de votre bureau a peut-être été mis à jour avec la bonne adresse IP, mais le DNS du FAI des utilisateurs externes pointe toujours vers des nœuds défectueux, ou un nœud CDN régional a échoué. 👉 Par conséquent, pour ce type de problèmes, 90% ne consiste pas à déterminer « si le service est défectueux », mais plutôt « qui est résolu vers où ». Il est plus efficace d'effectuer les vérifications dans l'ordre suggéré ci-dessous : Commencez par tester la résolution DNS dans plusieurs régions. Ne vous contentez pas d'envoyer une commande ping depuis votre propre ordinateur et de considérer que le problème est résolu. Utilisez des outils en ligne ou demandez à des amis situés à différents endroits d'exécuter des commandes dig pour vérifier si les adresses IP renvoyées sont cohérentes.Portez une attention particulière à la présence d'adresses IP obsolètes ou désactivées. Ensuite, vérifiez que tous les nœuds backend sont « identiques ». Pour chaque serveur derrière le répartiteur de charge, vérifiez : - Les certificats sont-ils présents et corrects ? - La configuration de l'hôte virtuel est-elle correctement liée à ce domaine ? - Le code métier/la structure des fichiers est-il cohérent (une nouvelle machine n'a-t-elle pas réussi à transférer les fichiers ?) - La configuration Nginx/Apache a-t-elle été correctement rechargée ?Il est fréquent de rencontrer des situations où les « contrôles de santé sont réussis » (simple test des ports), mais où l'accès réel échoue en raison de certificats ou de fichiers de site web manquants. Ensuite, examinez les journaux backend du fournisseur CDN/cloud. Recherchez les erreurs 5xx, « origine inaccessible » ou les échecs de délai d'attente provenant de régions spécifiques. Cela permet d'identifier le nœud qui rencontre des problèmes backend. Enfin, vérifiez les paramètres DNS TTL et de mise en cache.Si vous avez récemment changé d'architecture, portez une attention particulière aux valeurs TTL des enregistrements DNS et vérifiez que la résolution DNS du cloud et les paramètres de mise en cache du CDN sont appropriés. Parfois, vous pensez avoir changé, mais une entrée mise en cache à un certain niveau de la chaîne de recherche persiste. Je vous suggère donc d'arrêter de regarder les graphiques de surveillance pour l'instant et de remonter à la source en vous demandant « à quelle adresse IP l'utilisateur est-il réellement redirigé ? ».