IPv4 fonctionne mais IPv6 échoue : démarche de diagnostic

Le navigateur peut masquer le chemin défaillant

Les enregistrements AAAA publient des adresses IPv6 ; ils ne prouvent pas que le service web y fonctionne. Les clients utilisant Happy Eyeballs peuvent réussir via une autre famille d’adresses alors que le chemin IPv6 est défaillant. Testez explicitement IPv4 et IPv6 au lieu de considérer une visite réussie dans le navigateur comme une preuve pour les deux.

Comparer le même nom d’hôte et la même URL

Remplacez example.com par votre site et lancez les deux commandes depuis un hôte doté d’IPv6 fonctionnel. Dans PowerShell, utilisez curl.exe. Ces requêtes GET limitées préservent la vérification TLS par nom d’hôte et ne suivent pas les redirections. Comparez le statut, l’IP sélectionnée et le contenu enregistré ; examinez séparément la destination d’une redirection.

curl -4 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv4.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/
curl -6 --silent --show-error --connect-timeout 5 --max-time 15 --output ipv6.html --write-out "HTTP %{http_code}; IP %{remote_ip}\n" https://example.com/

Vérifier la sonde avant de mettre le site en cause

La section IPv6 de check.uk.app teste l’URL soumise depuis sa sonde. Si celle-ci n’a pas de route IPv6, le résultat est indisponible, pas une panne du site. Un délai dépassé depuis un seul emplacement n’identifie pas non plus, à lui seul, le réseau responsable. Recommencez depuis une autre connexion IPv6 dont le fonctionnement est confirmé.

Localiser la panne par couche

Comparez les réponses AAAA faisant autorité et récursives avec les adresses qui vous sont attribuées. Confirmez que l’adresse est configurée, que le routage fonctionne et que le serveur web ou le proxy écoute en IPv6 sur le port prévu. Examinez les règles du pare-feu IPv6 indépendamment d’IPv4.

Si la connexion réussit mais que TLS échoue, vérifiez la couverture du nom d’hôte, la chaîne de certificats et l’hôte virtuel choisi sur le point d’écoute IPv6. Si HTTP diffère, comparez les backends du proxy et le routage applicatif. Pour les transferts bloqués après connexion, examinez la MTU du chemin et le traitement nécessaire d’ICMPv6 ; ne désactivez pas TLS pour masquer une panne.

Vérifier le rétablissement sans perturber IPv4

Sauvegardez les valeurs DNS, TTL et réglages du serveur avant de changer quoi que ce soit. Modifiez la couche identifiée, puis répétez les deux requêtes et les parcours importants. Confirmez que les deux familles renvoient le site attendu avec un TLS valide. Les caches DNS peuvent continuer à utiliser l’ancien AAAA jusqu’à expiration.

Les options des commandes ont été testées sur des points d’écoute loopback IPv4 et IPv6 isolés, y compris un échec sur port fermé. Cela valide la procédure de diagnostic, pas l’accessibilité IPv6 mondiale. Publiez AAAA après la configuration du service et un test externe réussi, pas avant.