Pourquoi un site Web fonctionne-t-il avec les données mobiles mais pas avec le Wi-Fi ?

Si un le site Web fonctionne avec les données mobiles mais pas avec le Wi-Fi, le site Web n'est pas universellement hors ligne. La variable changeante est le chemin depuis votre appareil via le réseau Wi-Fi. Le défaut le plus probable est donc un DNS local, le routeur, un VPN ou un filtre, l'état du navigateur ou l'itinéraire du fournisseur haut débit. Tout d’abord, exécutez l’URL via le ClockTools Vérificateur de site Web en panne. Testez ensuite la même URL sur le même appareil via Wi-Fi et données mobiles, en modifiant une seule variable à la fois.

Que prouve ce symptôme ?

Cela prouve qu'au moins un chemin réseau peut atteindre le site à ce moment-là. C'est le cas pas prouver que chaque page, action de compte, région ou réseau peut y accéder. Les données mobiles et le Wi-Fi domestique peuvent utiliser différents résolveurs DNS, adresses IP publiques, routes, filtres de contenu et chemins IPv4/IPv6.

Utilisez cette petite matrice de preuves avant de modifier les paramètres :

L'expression « même URL » est importante. Une page d'accueil et un tableau de bord authentifié peuvent parcourir différents chemins d'application. Copiez l'adresse complète plutôt que de saisir uniquement le domaine.

Le site Web est-il réellement en panne ?

Vérifiez-le depuis l'extérieur de votre réseau local avant de redémarrer quoi que ce soit. ClockTools effectue une vérification externe DNS et HTTP et rapporte le verdict, la résolution A/AAAA, les redirections, l'URL finale, l'état de la réponse, les en-têtes sélectionnés et le timing. Lors d'un contrôle contrôlé sur 2026-08-31, https://example.com revenu en ligne, HTTP 200, DNS résolus et aucune redirection depuis le bord MAA. Un projet volontairement inexistant .invalide nom d'hôte renvoyé inaccessible, avec DNS non résolu et aucun résultat HTTP.

Ces deux sondes montrent pourquoi l'ordre est important : une recherche DNS échouée et un serveur HTTP accessible nécessitent des correctifs différents. Ils montrent également les limites de l'outil. Un avantage externe constitue une preuve solide, et non une preuve de disponibilité dans chaque ville ou ISP.

Si le résultat externe est accessible mais que votre Wi-Fi échoue toujours, continuez localement. S'il est inaccessible en externe et sur les données mobiles, attendez ou contactez le propriétaire du site avant de changer de routeur.

Où devriez-vous tester ensuite ?

Suivez l'arbre de diagnostic dans le schéma ci-joint :

1. Gardez l'appareil et l'URL exacte fixes ; basculer uniquement entre le Wi-Fi et les données mobiles.

2. Sur Wi-Fi, essayez une fenêtre privée ou un deuxième navigateur.

3. Essayez un autre appareil sur le même réseau Wi-Fi.

4. Suspendez temporairement un VPN ou un proxy juste assez longtemps pour exécuter une comparaison, puis restaurez-le.

5. Comparez le comportement de DNS avant de remplacer le résolveur.

6. Redémarrez le routeur uniquement après avoir enregistré les preuves que vous auriez autrement effacées.

Une fenêtre privée peut contourner certains cookies et extensions mis en cache, mais elle ne crée pas de nouvelle route ISP. Un deuxième appareil sur le même réseau Wi-Fi est plus utile pour séparer l'état de l'appareil de l'état du réseau. Pour un indice au niveau de l'itinéraire, utilisez Tracer l'itinéraire; pour votre identité de sortie, comparez Quelle est mon adresse IP ? sur chaque réseau.

DNS pourrait-il faire la différence ?

Oui. Votre routeur Wi-Fi peut annoncer le résolveur de ISP tandis que les données mobiles utilisent le résolveur de l'opérateur. Un résolveur peut avoir un enregistrement obsolète, une politique de filtrage ou un échec que l'autre n'a pas.

Commencez par l’observation, pas par un remplacement permanent. Notez si la vérification externe résout les enregistrements A ou AAAA. Sur l'appareil concerné, déconnectez-vous et reconnectez-vous au Wi-Fi, puis réessayez. Si votre système d'exploitation fournit un vidage du cache DNS, utilisez sa méthode documentée. Ensuite seulement, comparez avec un autre résolveur réputé. Cloudflare documente son Interface DNS-over-HTTPS JSON pour une comparaison explicite des résolveurs.

N'interprétez pas « DNS works » comme « la page doit s'afficher ». DNS mappe uniquement le nom. TLS, le routage, la politique du serveur et l'application doivent encore réussir.

Le routeur VPN ou ISP pourrait-il bloquer le chemin ?

Chacun peut créer exactement cette répartition :

• Un routeur peut conserver un mauvais état, appliquer des contrôles parentaux, préférer un chemin IPv6 cassé ou bloquer une catégorie.
• Un VPN, un proxy, un bouclier Web antivirus ou un profil d'entreprise peut modifier DNS et le routage.
• Un ISP peut avoir un incident de routage ou de résolution affectant une destination.
• Un site peut limiter le débit ou bloquer l'adresse IP publique du réseau Wi-Fi tout en acceptant l'adresse IP de l'opérateur mobile.

Vérifiez la portée avant de désactiver les protections. Si chaque appareil ne tombe en panne que sur un seul réseau Wi-Fi, concentrez-vous sur ce réseau. Si un seul périphérique géré tombe en panne, ne supprimez pas ses contrôles de sécurité ; demandez à l'administrateur. de Microsoft Séquence de dépannage Windows Wi-Fi et celui de Google Dépannage de connexion Android les deux commencent par des vérifications de connexion de base et isolent progressivement l’état du périphérique et du réseau.

Que devez-vous réinitialiser et dans quel ordre ?

Utilisez en premier le changement le moins perturbateur :

Évitez de réinitialiser le routeur en usine à moins que vous ne disposiez de sa configuration et de ses informations d'identification. Évitez de laisser un pare-feu, VPN ou un produit de sécurité désactivé simplement parce que la page s'est chargée une seule fois. Si la page s'ouvre mais semble incomplète, exécutez le Test de rendu de site Web car les actifs ou scripts statiques peuvent échouer même lorsque la réponse principale HTTP réussit.

Quand devez-vous arrêter le dépannage localement ?

Arrêtez-vous et intensifiez votre action lorsque les preuves échappent à votre contrôle : le vérificateur externe et les données mobiles échouent tous deux ; les résultats de trace disparaissent systématiquement au-delà de votre routeur ; chaque appareil sur un ISP tombe en panne pendant qu'un autre réseau fonctionne ; ou le site affiche une réponse de politique d'accès liée à votre adresse IP publique. Donnez au fournisseur l'URL exacte, les horodatages avec le fuseau horaire, le verdict externe, le résultat DNS, le réseau concerné et les étapes déjà testées. Cette preuve est bien plus utile que « Internet est en panne ».