Un site inaccessible « seulement depuis l’étranger », ou seulement depuis un pays, n’a pas la même cause qu’un site en panne partout. Le serveur peut répondre à votre bureau et refuser un pays entier, le DNS peut envoyer certains visiteurs vers une mauvaise adresse, ou un seul opérateur local peut échouer. Avant de changer d’hébergeur, il faut l’erreur exacte vue là-bas, et un essai qui ne passe pas par votre box.
Demander le symptôme, pas « ça ne marche pas »
Faites préciser, par une capture :
- le message :
DNS_PROBE_FINISHED_NXDOMAIN, délai dépassé,403, erreur de certificat, page blanche ; - l’URL exacte, avec ou sans
www; - le réseau : téléphone en 4G, Wi-Fi d’un bureau, VPN ;
- si un autre site hébergé ailleurs s’ouvre sur le même réseau.
NXDOMAIN ou « serveur introuvable » oriente vers le DNS. Un délai oriente vers un filtrage ou un serveur qui ne répond pas à cette route. Un 403 oriente vers une règle (pays, IP, user-agent). Une erreur de certificat oriente vers un vhost ou un IPv6 qui ne présente pas le bon nom.
Un VPN commercial pointé vers ce pays est un indice faible. Son adresse est souvent classée « centre de données » et bloquée par une règle anti-bots, alors que les habitants ne le sont pas. À l’inverse, un VPN qui passe ne prouve pas que le fournisseur d’accès local passe.
Les causes qui ne touchent qu’une partie du monde
Règle géographique. Cloudflare, un pare-feu d’hébergeur ou une extension peut bloquer une liste de pays. Le visiteur reçoit alors une réponse du proxy, pas de PHP. Regardez les règles « country », les défis, et les journaux filtrés sur le pays. Une règle posée pour couper du trafic abusif bloque aussi les clients de ce pays.
DNS différent selon l’endroit. GeoDNS ou un ancien enregistrement encore en cache chez un opérateur. Comparez la réponse A et AAAA avec un résolveur public (par exemple dig contre 1.1.1.1 et contre 8.8.8.8) et, si vous l’avez, depuis une machine dans le pays. La méthode générale est dans vérifier la propagation DNS. Deux adresses IP différentes ne sont un problème que si l’une ne sert pas le site.
IPv6 cassé. Le poste préfère l’enregistrement AAAA. S’il pointe vers un serveur sans le vhost, ou avec un certificat qui ne couvre pas le nom, la connexion échoue alors que l’IPv4 est sain. Testez en forçant IPv4 et IPv6 (curl -4 et curl -6). Si seul l’un des deux échoue, corrigez cet enregistrement ou retirez le AAAA tant qu’il n’est pas prêt.
Point de présence CDN. Une région du CDN peut renvoyer une erreur pendant que les autres servent le site. La page de statut du CDN et un essai depuis cette région le montrent. Le correctif est chez le CDN ou en contournant ce point, pas dans le thème.
Un seul opérateur. Si une seule personne, sur un seul réseau, échoue, et que d’autres dans le même pays passent, le blocage est sur le chemin (pare-feu d’entreprise, DNS local, malware du poste). Ce n’est pas une panne de votre origine.
Vérifier sans extrapoler un cas
- Reproduisez depuis au moins deux réseaux du pays concerné, dont un téléphone en données mobiles si le premier essai était un bureau.
- Notez le code HTTP et l’IP de connexion vue dans vos journaux ou dans le CDN. Aucune ligne venant de ce pays peut vouloir dire « bloqué avant l’origine » ou « ils n’ont pas essayé ».
- Contrôlez les règles pays du pare-feu et du CDN. Retirez la règle le temps d’un essai, puis remettez-la seulement si vous assumez de couper ce marché.
- Comparez IPv4 et IPv6, et les réponses DNS.
- Si vous vendez dans ce pays, faites contrôler l’URL critique depuis l’extérieur de votre pays, pas seulement depuis l’agence. Un contrôle lancé d’un autre réseau, comme avec SiteGarde, évite de conclure à partir du Wi-Fi du bureau.
Le cas « personne ne l’ouvre, nulle part » est un autre diagnostic, dans pourquoi un site est inaccessible. Ne mélangez pas : un blocage France/étranger se corrige mal en redémarrant PHP.