Windows indique « Connecté, pas d’internet » ? Réparez-le sans tout réinitialiser

Playbook de diagnostic rapide (premières 3 minutes)

Voici l’ordre que j’utilise quand quelqu’un signale « internet down » et que j’ai besoin de la vérité rapidement. On traque le goulot d’étranglement : liaison, IP, route, DNS, politique ou la propre détection de connectivité de Windows.

1) Le réseau est‑il vraiment en panne, ou Windows se plaint‑il pour rien ?

• Ouvrez un navigateur sur un site HTTPS connu. S’il se charge, votre internet fonctionne ; l’état Windows peut être erroné (souvent NCSI/proxy/VPN). Passez aux vérifications NCSI/proxy.
• Essayez un ping d’IP (par exemple une IP DNS publique). Si l’IP répond mais que les noms ne passent pas, c’est DNS.

2) Confirmez que vous avez une IP, une passerelle et des routes sensées

• Vérifiez la config IP : avez‑vous une adresse non‑APIPA (pas 169.254.x.x), une passerelle par défaut et des serveurs DNS ?
• Vérifiez la table de routage : y a‑t‑il une route par défaut (0.0.0.0/0) vers la bonne interface ?

3) Décidez quelle couche est en panne

• Pas d’IP / APIPA : problème DHCP ou L2.
• IP mais pas de route par défaut : problème de passerelle/route, souvent métrique VPN, ICS ou confusion d’adaptateurs.
• IP + route mais DNS échoue : serveur DNS injoignable, DoH/NRPT/politique, ou interception par un portail captif.
• Tout fonctionne sauf le statut Windows : NCSI bloqué/modifié par un proxy, un pare‑feu ou un durcissement.

Ne « réinitialisez pas tout » tant que vous ne pouvez pas dire laquelle de ces couches échoue. Sinon vous ne faites qu’ajouter de l’entropie. L’entropie gagne toujours ; elle a plus de financement.

Ce que signifie réellement « Connecté, pas d’internet »

Windows affiche « Connecté, pas d’internet » quand il estime que votre chemin réseau vers l’internet public est rompu. Cette estimation repose en partie sur NCSI (Network Connectivity Status Indicator), un composant qui effectue des vérifications de connectivité.

Deux points clés qui vous feront gagner des heures :

• Le message peut être faux. Vous pouvez avoir un internet fonctionnel alors que Windows prétend le contraire (fréquent avec les proxies, VPN, pare‑feu stricts et certains filtrages DNS).
• Le message peut être vrai pour une mauvaise raison. Par exemple, votre réseau local fonctionne bien, mais le DNS est cassé — Windows le qualifie de « pas d’internet », et beaucoup d’apps se comportent comme si vous étiez hors‑ligne.

En interne, Windows se soucie de plusieurs couches :

• Couches 1–2 : état de la liaison (association Wi‑Fi, lien Ethernet).
• Couche 3 : adresse IP, sous‑réseau, passerelle par défaut et routage.
• Couches 4–7 : accessibilité DNS, accès HTTP/HTTPS (y compris détection de portail captif), comportement du proxy.
• Politique et sécurité : règles de pare‑feu, kill switches VPN, sécurité endpoint en entreprise, et réglages « utiles ».

Une citation utile quand vous êtes tenté de multiplier les correctifs au hasard : L’espoir n’est pas une stratégie. — Gene Kranz

Blague #1 : le réseau Windows, c’est comme une réunion de comité — tout le monde a un avis, et personne ne se parle.

Faits intéressants et contexte historique (pourquoi ça revient)

Voici des faits courts et concrets qui rendent le problème « connecté, pas d’internet » moins mystérieux et plus prévisible :

1. NCSI est arrivé avec les changements réseau de l’ère Vista. Windows a commencé à sonder activement la connectivité internet au lieu de se fier uniquement à l’état de la liaison.
2. « Pas d’internet, sécurisé » concerne surtout la sécurité Wi‑Fi, pas celle d’internet. Le label « sécurisé » fait référence au chiffrement du lien Wi‑Fi (WPA2/WPA3), pas à l’état de la voie vers internet.
3. Les portails captifs cassent volontairement le comportement normal. Beaucoup de réseaux hôteliers/guest interceptent le DNS/HTTP tant que vous n’avez pas accepté les conditions ; HTTPS moderne complexifie cela.
4. APIPA (169.254.0.0/16) est le fallback Windows quand DHCP échoue. Il permet la communication sur le lien local mais signifie généralement pas de passerelle, donc pas d’internet.
5. WPAD (découverte auto de proxy) est un classique corporate—et un casse‑tête récurrent. Un WPAD mal configuré peut casser la navigation alors que les pings continuent de fonctionner.
6. Les kill switches des VPN sont conçus pour provoquer des coupures. Leur but est de bloquer le trafic si le tunnel tombe, et ils ressemblent souvent exactement à un « pas d’internet ».
7. Windows maintient des métriques par interface pour la préférence de route. Une interface « plus rapide » ou un VPN peut voler la route par défaut même quand il ne devrait pas.
8. Le cache DNS est à la fois utile et amplificateur d’échec. De mauvaises réponses peuvent persister jusqu’à l’expiration du TTL ou un flush du cache.
9. IPv6 est souvent accusé à tort. Un IPv6 mal configuré peut nuire, mais le désactiver est un bricolage grossier qui peut casser des environnements d’entreprise modernes.

Tâches pratiques avec commandes : quoi lancer, ce que ça signifie, quoi faire ensuite

Ces tâches sont conçues pour être exécutées sur une machine Windows, mais je les présente sous forme de transcription terminale afin que vous puissiez copier les commandes exactement. Chaque tâche inclut : commande, sortie exemple, ce que cela signifie, et la décision suivante.

Task 1: Check IP, gateway, and DNS in one shot

cr0x@server:~$ ipconfig /all
Windows IP Configuration

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection
   Physical Address. . . . . . . . . : 00-11-22-33-44-55
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.24.18.73(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1
   DHCP Server . . . . . . . . . . . : 10.24.16.10
   DNS Servers . . . . . . . . . . . : 10.24.0.53
                                       10.24.0.54

Ce que ça signifie : Vous avez une vraie adresse IPv4, une passerelle et des serveurs DNS. Si l’internet est toujours « down », le problème est probablement le routage, l’accessibilité DNS, le proxy/VPN, le pare‑feu ou NCSI.

Décision : Si vous voyez 169.254.x.x ou pas de passerelle par défaut, passez aux corrections DHCP/L2. Si les serveurs DNS sont vides ou étranges (comme une IP statique ancienne), corrigez cela en premier.

Task 2: Detect APIPA (DHCP failure) quickly

cr0x@server:~$ ipconfig
Windows IP Configuration

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . . : 169.254.77.12
   Subnet Mask . . . . . . . . . . . : 255.255.0.0
   Default Gateway . . . . . . . . . :

Ce que ça signifie : DHCP ne vous a pas attribué d’adresse. Vous vous auto‑attribuez. Ce n’est pas un « problème internet » ; c’est un « je ne suis jamais monté sur le réseau ».

Décision : Vérifiez le câble/l’authentification Wi‑Fi/VLAN, puis renouvelez DHCP. En entreprise, suspectez 802.1X ou un profil de port commutateur.

Task 3: Renew DHCP lease (without resetting the world)

cr0x@server:~$ ipconfig /release
Windows IP Configuration

No operation can be performed on Ethernet while it has its media disconnected.

Ce que ça signifie : Windows pense que l’interface est déconnectée (ou le câble est sorti, ou le Wi‑Fi est désactivé). C’est votre premier mode d’échec : la liaison.

Décision : Réparez la liaison physique / l’association Wi‑Fi avant d’essayer quelque chose de plus fin.

cr0x@server:~$ ipconfig /renew
Windows IP Configuration

Ethernet adapter Ethernet:
   Connection-specific DNS Suffix  . : corp.example
   IPv4 Address. . . . . . . . . . . : 10.24.18.73
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Default Gateway . . . . . . . . . : 10.24.16.1

Ce que ça signifie : Le DHCP a réussi. Vous êtes revenu à la couche L3.

Décision : Si l’internet échoue encore, passez aux vérifications de routage/DNS/proxy.

Task 4: Ping the default gateway (is your local network alive?)

cr0x@server:~$ ping 10.24.16.1

Pinging 10.24.16.1 with 32 bytes of data:
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64
Reply from 10.24.16.1: bytes=32 time=1ms TTL=64

Ping statistics for 10.24.16.1:
    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss)

Ce que ça signifie : Votre hôte peut atteindre la passerelle. L2/L3 sur le segment local semble OK.

Décision : Si le ping de la passerelle échoue, investiguez l’isolation Wi‑Fi, un mismatch VLAN, un port de switch défaillant, ou des règles locales de pare‑feu bloquant ICMP (moins fréquent sur les passerelles, mais possible).

Task 5: Ping an external IP (bypass DNS)

cr0x@server:~$ ping 1.1.1.1

Pinging 1.1.1.1 with 32 bytes of data:
Reply from 1.1.1.1: bytes=32 time=18ms TTL=56

Ping statistics for 1.1.1.1:
    Packets: Sent = 1, Received = 1, Lost = 0 (0% loss)

Ce que ça signifie : Le routage vers l’internet fonctionne au moins pour ICMP. Si les sites web échouent, c’est probablement DNS, proxy, interception TLS, ou pare‑feu.

Décision : Testez immédiatement la résolution DNS et la connectivité HTTPS ensuite.

Task 6: DNS resolution test (simple and decisive)

cr0x@server:~$ nslookup example.com
Server:  dns1.corp.example
Address:  10.24.0.53

Non-authoritative answer:
Name:    example.com
Addresses:  93.184.216.34

Ce que ça signifie : Le DNS répond et renvoie des données sensées.

Décision : Si le DNS est bon mais la navigation échoue, suspectez proxy/VPN/pare‑feu ou problèmes de certificats. Si nslookup expire, suspectez l’accessibilité DNS ou une politique.

cr0x@server:~$ nslookup example.com 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

DNS request timed out.
    timeout was 2 seconds.

Ce que ça signifie : Votre réseau peut bloquer le DNS public (courant en entreprise et chez certains FAI), ou vous ne pouvez pas atteindre ce résolveur à cause du routage/politiques VPN.

Décision : Ne « corrigez » pas en forçant un DNS public sur un réseau corporate à moins d’aimer les tickets de support. Réparez plutôt l’accès aux serveurs DNS prévus.

Task 7: Check the route table for a default route

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0        10.24.16.1     10.24.18.73     25
        10.24.16.0    255.255.252.0        On-link      10.24.18.73    281

Ce que ça signifie : Vous avez une route par défaut via votre passerelle. Bien.

Décision : Si la route 0.0.0.0 est manquante ou pointe vers une interface VPN de façon inattendue, vous avez trouvé le coupable.

Task 8: Verify which interface Windows prefers (metrics matter)

cr0x@server:~$ netsh interface ipv4 show interfaces
Idx     Met         MTU          State                Name
---  ----------  ----------  ------------  ---------------------------
  12          5        1400  connected     CorpVPN
  10         25        1500  connected     Ethernet

Ce que ça signifie : La métrique la plus basse gagne. Ici, le VPN est préféré et peut voler le routage par défaut.

Décision : Si le VPN est down/à moitié connecté ou bloqué, déconnectez‑le ou corrigez la politique de split tunneling. Si c’est voulu, arrêtez ici et escaladez vers le responsable de la config VPN.

Task 9: Check WinHTTP proxy settings (the invisible kind)

cr0x@server:~$ netsh winhttp show proxy
Current WinHTTP proxy settings:

    Proxy Server(s) : 127.0.0.1:8080
    Bypass List     : (none)

Ce que ça signifie : Les services système (y compris certains composants Microsoft) peuvent essayer d’atteindre internet via un proxy local qui n’existe peut‑être plus.

Décision : Si vous n’avez pas configuré cela explicitement (ou si votre agent de sécurité a supprimé son proxy local), réinitialisez le proxy WinHTTP en accès direct.

cr0x@server:~$ netsh winhttp reset proxy
Current WinHTTP proxy settings:

    Direct access (no proxy server).

Ce que ça signifie : HTTP au niveau système passe maintenant directement.

Décision : Retestez NCSI et les problèmes de connexion Microsoft. Si la politique d’entreprise impose un proxy, ne « corrigez » pas en contournant — obtenez la configuration correcte.

Task 10: Check user-level proxy (Settings/Internet Options equivalent)

cr0x@server:~$ reg query "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyEnable

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings
    ProxyEnable    REG_DWORD    0x1

Ce que ça signifie : Le proxy utilisateur est activé.

Décision : Si vous n’êtes pas sur un réseau qui en a besoin, désactivez‑le. Si vous l’êtes, confirmez que la valeur du serveur proxy et la liste d’exceptions sont correctes.

Task 11: Test HTTP reachability without a browser (proxy/captive portal clues)

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty StatusCode"
200

Ce que ça signifie : Vous pouvez atteindre le endpoint HTTP que Windows utilise souvent pour la détection de connectivité.

Décision : Si cela renvoie 200 mais que Windows dit toujours « pas d’internet », suspectez des problèmes de sonde HTTPS, de manipulation DNS, ou des réglages/politiques NCSI.

cr0x@server:~$ powershell -NoProfile -Command "Invoke-WebRequest -UseBasicParsing -Uri http://www.msftconnecttest.com/connecttest.txt | Select-Object -ExpandProperty Content"
Microsoft Connect Test

Ce que ça signifie : Le contenu renvoyé est correct. Les portails captifs retournent souvent une page HTML de connexion à la place.

Décision : Si vous obtenez du HTML ou des redirections, vous êtes derrière un portail captif. Authentifiez‑vous (ou demandez à votre équipe réseau pourquoi un SSID « corporate » en utilise un).

Task 12: Flush DNS cache (fix stale/bad answers)

cr0x@server:~$ ipconfig /flushdns
Windows IP Configuration

Successfully flushed the DNS Resolver Cache.

Ce que ça signifie : Tout cache DNS local est effacé.

Décision : Si la résolution de noms recommence à fonctionner, votre problème était un cache obsolète ou un événement temporaire de poisoning DNS (mauvaise config bénigne ou portail captif). Si rien ne change, continuez l’investigation.

Task 13: Reset Winsock (targeted “TCP/IP plumbing” fix)

cr0x@server:~$ netsh winsock show catalog
Catalog entry #0000000001
------------------------------------------------------------
Entry Type:  Provider
Description: MSAFD Tcpip [TCP/IP]
...output truncated...

Ce que ça signifie : Vous inspectez le catalogue Winsock (où les LSPs s’accrochaient autrefois). Les logiciels de sécurité y coincent parfois le trafic.

Décision : Si vous suspectez une pile réseau cassée après la désinstallation d’un VPN/AV, faites un reset Winsock. Attendez‑vous à un redémarrage.

cr0x@server:~$ netsh winsock reset
Successfully reset the Winsock Catalog.
You must restart the computer in order to complete the reset.

Ce que ça signifie : Winsock est réinitialisé aux valeurs par défaut.

Décision : Redémarrez, puis retestez. Si votre agent endpoint dépend d’un composant de type LSP, coordonnez‑vous avec l’informatique avant d’exécuter cela sur des machines gérées.

Task 14: Reset TCP/IP stack (still not “reset everything”)

cr0x@server:~$ netsh int ip reset
Resetting Global, OK!
Resetting Interface, OK!
Resetting Neighbor, OK!
Resetting Path, OK!
Restart the computer to complete this action.

Ce que ça signifie : Vous avez réinitialisé des paramètres clés TCP/IP aux valeurs par défaut.

Décision : C’est un bon correctif de dernier recours pour corruption/mauvaise config. Si vous dépendez d’IPs statiques ou de routes personnalisées, documentez‑les d’abord.

Task 15: Check whether a VPN created persistent routes

cr0x@server:~$ route print -4
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0         10.10.0.1     10.10.0.55      1
         10.10.0.0    255.255.0.0         On-link       10.10.0.55    261

Ce que ça signifie : La route par défaut pointe vers une passerelle 10.10.0.1 (probablement un adaptateur virtuel VPN). Si le VPN est déconnecté mais que la route subsiste, vous aurez rapidement « pas d’internet ».

Décision : Déconnectez/reconnectez proprement le VPN, ou supprimez la route persistante si vous êtes sûr qu’elle est incorrecte. Sur des endpoints gérés, escaladez ; ne vous battez pas avec votre client VPN à la hache.

Task 16: Check Windows Firewall profile and state

cr0x@server:~$ netsh advfirewall show allprofiles state

Domain Profile Settings:
State                                 ON

Private Profile Settings:
State                                 ON

Public Profile Settings:
State                                 ON

Ce que ça signifie : Le pare‑feu est activé (c’est normal). Cela seul n’explique pas « pas d’internet », mais des règles peuvent le faire.

Décision : Si un produit de sécurité a récemment changé des règles de pare‑feu, testez en désactivant temporairement uniquement si autorisé. Préférez la revue des règles ou des logs de sécurité ; la désactivation aveugle, c’est comment on gagne un incident secondaire.

Task 17: Check for name resolution policy / NRPT (common with VPN split DNS)

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Format-Table -AutoSize"

Namespace          NameServers     DirectAccessDNS
---------          -----------     ---------------
.corp.example      {10.24.0.53}    False

Ce que ça signifie : Les requêtes pour certains espaces de noms sont forcées vers des serveurs DNS spécifiques. Excellent quand c’est correct ; catastrophique quand le VPN ne route pas réellement vers ces serveurs.

Décision : Si NRPT pointe vers des DNS injoignables, vous aurez « certains sites fonctionnent, d’autres non ». Corrigez le routage VPN ou mettez à jour la politique ; ne supprimez pas NRPT si vous n’êtes pas propriétaire de la politique.

Task 18: Validate which DNS servers are actually in use per interface

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | Format-Table -AutoSize"

InterfaceAlias  ServerAddresses
--------------  ---------------
Ethernet        {10.24.0.53, 10.24.0.54}
CorpVPN         {10.99.0.10}

Ce que ça signifie : Différents adaptateurs peuvent avoir des serveurs DNS différents. Windows peut choisir le « mauvais » DNS pour des requêtes générales selon les métriques et les politiques.

Décision : Si le DNS du VPN est injoignable (tunnel down) mais préféré, vous aurez des échecs de résolution. Corrigez la préférence/métrique ou réparez le tunnel.

Portails captifs et bizarreries du Wi‑Fi d’entreprise

Les portails captifs sont le producteur classique de « Connecté, pas d’internet » parce qu’ils se placent entre vous et l’internet en disant : « Oui, vous pouvez vous connecter… après avoir coché cette case écrite par un avocat. » Windows tente de détecter cela et d’afficher une page de connexion, mais les réseaux modernes et les outils de sécurité peuvent bloquer le mécanisme.

Comment reconnaître un portail captif (sans deviner)

• Le DNS fonctionne, mais HTTP renvoie un contenu inattendu. Votre test de connexion renvoie du HTML au lieu du texte attendu.
• Les sites HTTPS échouent avec des avertissements de certificat ou ne se chargent jamais. Les portails ne peuvent pas facilement intercepter le HTTPS moderne sans faire des choses désagréables.
• Seules certaines apps échouent. Les apps qui utilisent un pinning TLS strict refuseront le trafic intercepté.

Que faire

• Utilisez une URL HTTP simple (oui, volontairement) juste pour déclencher le portail et vous authentifier. Ensuite, revenez au HTTPS comme une personne civilisée.
• Désactivez temporairement le VPN si le portail a besoin que votre trafic ne soit pas tunnellisé. Beaucoup de VPN bloquent les flux de portail captif par conception.
• Ne forcez pas un DNS public pour « régler » un portail. Certains portails reposent sur une interception DNS ; vous ne ferez qu’embrouiller la situation.

VPN, proxies et fonctions « sécurité » qui vous coupent les jambes

Beaucoup de situations « pas d’internet » ne sont pas des pannes. Ce sont des politiques. Des politiques appliquées à moitié, obsolètes, ou conçues pour un réseau sur lequel vous n’êtes plus.

Modes de panne VPN qui ressemblent à « pas d’internet »

• Détournement de route par défaut : le VPN devient la route préférée mais le tunnel ne transmet pas réellement le trafic.
• Mismatch DNS en split‑tunnel : les requêtes DNS vont vers le DNS du VPN, mais le VPN ne les route pas (ou le serveur DNS vous bloque).
• Kill switch engagé : le client VPN bloque tout le trafic quand il se déconnecte. Ce n’est pas un bug ; c’est une fonctionnalité tranchante.
• Politique NRPT obsolète : suffixes de domaine forcés vers des serveurs injoignables, cassant des applis internes et parfois la connexion Windows.

Modes de panne proxy qui ressemblent à « pas d’internet »

• WinHTTP proxy laissé en place après la désinstallation d’un outil de sécurité, de sorte que les services système ne peuvent plus atteindre le web.
• Proxy utilisateur activé avec un fichier PAC erroné ou un nom d’hôte de proxy mort.
• Paramètres auto‑détection (WPAD) qui découvrent un proxy sur un réseau puis continuent à l’essayer sur un autre où il n’existe pas.

Blague #2 : un serveur proxy, c’est comme ce collègue qui insiste pour être en copie — jusqu’à ce qu’il parte en vacances et que vos mails cessent de fonctionner.

Pilotes, économie d’énergie et la violence silencieuse de « l’optimisation »

Si vous êtes sur un portable, il y a une chance non nulle que Windows fasse de la « gestion d’alimentation » sur votre adaptateur réseau. Les fournisseurs livrent aussi des pilotes qui se comportent parfaitement en labo et étrangement dans le monde réel, surtout au travers des cycles veille/veille prolongée.

Schémas d’échec qui hurlent « pilote/énergie »

• L’internet meurt après un réveil de veille, mais un redémarrage le répare.
• L’Ethernet affiche connecté, mais aucun trafic ne passe jusqu’à ce que vous désactiviez/réactiviez l’adaptateur.
• Le Wi‑Fi se connecte, puis tombe en « pas d’internet » alors que le signal est fort.

Que faire (et quoi éviter)

• Privilégiez un retour à un pilote connu‑bon si le souci a commencé après une mise à jour. Nouveau n’est pas toujours mieux ; parfois c’est juste plus récent.
• Évitez de désactiver IPv6 en premier lieu. Cela peut masquer le symptôme tout en cassant des services d’entreprise, le comportement DNS moderne et les futures enquêtes.
• Vérifiez les paramètres d’alimentation de l’adaptateur si le problème est lié à la veille. Si votre image corporate impose des réglages via politique, corrigez‑les centralement.

Trois mini‑histoires d’entreprise du terrain

1) L’incident causé par une mauvaise hypothèse : « Si DHCP marche, internet marche »

Une entreprise de taille moyenne avait une plainte récurrente : tous les quelques jours, un étage aléatoire signalait « Connecté, pas d’internet. » Le script helpdesk était prévisible : redémarrer le point d’accès, demander aux utilisateurs de reboot, et passer à autre chose. Ça « fonctionnait », ce qui est une autre façon de dire que personne n’a rien appris.

Quand la SRE a été impliquée, la première hypothèse qu’ils ont challengée fut le classique : succès DHCP implique réseau utilisable. Les utilisateurs avaient des adresses, des passerelles et du DNS. Les pings passerelle fonctionnaient. Les pings IP externes fonctionnaient. Le DNS répondait aussi. Pourtant les navigateurs échouaient.

La pièce manquante : le proxy corporate était obligatoire pour la sortie web, et le proxy reposait sur un fichier PAC servi par un hôte interne. Ce nom d’hôte se résolvait, mais le port proxy était bloqué de façon intermittente par une ACL de firewall mal appliquée sur un switch de distribution. Le réseau « marchait », l’internet « marchait », mais le web ne marchait pas — et Windows a interprété cela comme « pas d’internet ».

La correction n’était pas une refonte grandiose. Elle était ennuyeuse : aligner les ACL entre switches, surveiller l’accessibilité du port proxy, et apprendre au support à tester l’accessibilité du proxy au lieu de juste ping. La mauvaise hypothèse avait transformé un bug de politique simple en mois de « pannes fantômes ».

2) L’optimisation qui s’est retournée contre eux : « Forçons un DNS public pour accélérer »

Une équipe IT en avait assez des plaintes sur la latence DNS interne. Quelqu’un a proposé une optimisation simple : pousser une GPO qui configure les clients pour utiliser un résolveur public bien connu « pour la performance ». Ça a été déployé discrètement, car qui a besoin de gestion des changements pour le DNS, non ?

En un jour, les portables Windows ont commencé à afficher « Connecté, pas d’internet » au bureau — alors que certains sites web se chargeaient et que des applis internes ne fonctionnaient plus. Le schéma était chaotique : les nouveaux embauchés allaient bien, les anciens non, et les utilisateurs VPN souffraient le plus.

La réalité : le pare‑feu d’entreprise bloquait le DNS sortant vers internet par politique. Les clients forcés vers un DNS public ne résolvaient rien sauf s’ils étaient sur un réseau permissif. Pendant ce temps, les zones internes existant seulement sur le DNS corporate ont cessé de se résoudre, cassant les flux de connexion, la découverte d’imprimantes et les portails internes. La détection de connectivité Windows a aussi échoué parce que la résolution de noms et l’accès HTTP étaient incohérents.

Le rollback a été douloureux car il a fallu agir vite et parce que « le remettre comme avant » a heurté des utilisateurs nomades et des configs mises en cache. Le postmortem fut brutal : n’optimisez pas une dépendance en contournant le système prévu pour la fournir. Réparez la performance et la résilience du DNS interne — cachez, scalez, monitorisez — sans transformer les clients en petits résolveurs renégats.

3) La pratique ennuyeuse mais correcte qui a sauvé la mise : baselines connus et deux tests

Une organisation globale avait une petite pratique réseau disciplinée : chaque bureau disposait d’une configuration d’endpoint « connue‑bonne » documentée pour Ethernet et Wi‑Fi, plus deux tests standards : (1) ping de la passerelle par défaut, (2) résolution et récupération d’un fichier de test de connectivité via HTTP. Ce n’était pas glamour. C’était cohérent.

Un matin, un site a signalé « Connecté, pas d’internet » sur plusieurs équipes. Les gens ont commencé à accuser le FAI, puis les mises à jour Windows, puis la machine à café (injuste). L’ingénieur d’astreinte a demandé les deux tests. Le ping passerelle a réussi. Le fetch HTTP a retourné une page HTML au lieu du texte attendu.

Cela a immédiatement réduit le champ : portail captif ou interception. Le bureau n’utilisait pas de portail captif. Il s’est avéré qu’une nouvelle politique d’appliance de sécurité avait été poussée la nuit précédente, redirigeant des user agents inconnus vers une page d’authentification. La sonde NCSI de Windows était maintenant traitée comme « inconnue » et redirigée, donc Windows déclarait pas d’internet. Certains navigateurs fonctionnaient car ils géraient différemment l’authentification ; certaines apps échouaient car elles attendaient une réponse HTTP propre.

La correction fut une règle allow simple pour les endpoints de vérification de connectivité et une exception de politique pour les clients gérés. La raison de la résolution rapide n’était pas du génie. C’était l’existence d’une baseline et de deux tests qui ont séparé « réseau en panne » de « détection cassée » en quelques minutes.

Erreurs courantes : symptôme → cause racine → correctif

Voici les récidivistes. Lisez‑les comme un guide de terrain.

1) « Connecté, pas d’internet » mais les sites s’ouvrent

• Symptôme : Le navigateur marche ; l’icône Windows indique pas d’internet ; certaines apps Microsoft se plaignent.
• Cause racine : Les sondes NCSI sont bloquées/redirigées par un proxy, pare‑feu, filtrage DNS, ou la détection de portail captif échoue.
• Correctif : Testez le fichier de connectivité via PowerShell. Vérifiez le proxy WinHTTP. En entreprise, demandez la mise en liste blanche des endpoints NCSI et la configuration correcte du proxy.

2) Adresse IP 169.254.x.x

• Symptôme : La connexion locale montre connecté ; pas d’internet ; parfois « Réseau non identifié ».
• Cause racine : Échec DHCP (pas de réponse, bloqué, mauvais VLAN, échec 802.1X).
• Correctif : Renouvelez DHCP ; vérifiez la liaison ; essayez un autre port/SSID ; en entreprise, validez le profil de port switch et les logs d’authentification.

3) Ping vers 1.1.1.1 fonctionne, mais DNS échoue

• Symptôme : La connectivité IP existe ; nslookup time‑out.
• Cause racine : Serveur DNS injoignable, DNS sortant bloqué, mauvais serveur DNS configuré, DNS VPN sélectionné alors que le tunnel est down.
• Correctif : Vérifiez ipconfig /all et Get-DnsClientServerAddress. Corrigez le DNS attendu par le réseau ; réparez le routage/métriques VPN.

4) Seuls les sites internes échouent, l’internet public marche

• Symptôme : Google se charge ; portail interne ne répond pas ; parfois le VPN est impliqué.
• Cause racine : Split DNS/NRPT mal configuré, ou DNS interne accessible seulement via VPN.
• Correctif : Connectez correctement le VPN ; vérifiez les politiques NRPT et l’accessibilité DNS ; ne « corrigez » pas en utilisant un DNS public.

5) L’internet meurt après la mise en veille/hibernation

• Symptôme : Marche après reboot ; échoue après réveil ; désactiver/activer l’adaptateur aide.
• Cause racine : Bug de pilote ou gestion d’alimentation de l’adaptateur, parfois aggravé par l’état du service VPN.
• Correctif : Mettre à jour ou revenir au pilote ; désactiver l’économie d’énergie agressive pour l’adaptateur ; assurer que le client VPN gère la reprise.

6) « Pas d’internet » apparaît seulement quand un VPN est installé (même déconnecté)

• Symptôme : Supprimer le VPN « fixe » le problème ; sinon le routage est étrange.
• Cause racine : Routes persistantes, drivers de filtrage, ou un kill switch encore actif.
• Correctif : Inspectez la table de routes et les métriques d’interface ; réparez ou réinstallez proprement le client VPN ; escaladez si la politique du kill switch est appliquée.

7) L’Ethernet indique connecté, mais il n’y a pas de trafic

• Symptôme : Voyants de lien allumés ; ping passerelle échoue ; DHCP peut marcher ou non.
• Cause racine : Mauvais VLAN sur le port switch, sécurité de port, échec 802.1X, ou négociation pilote.
• Correctif : Essayez un autre port/câble ; en entreprise, validez l’authentification du switchport et l’affectation VLAN ; envisagez de forcer vitesse/duplex seulement en dernier recours.

8) Le « correctif » consistant à désactiver IPv6 « marche » mais revient

• Symptôme : Désactiver IPv6 apporte un soulagement temporaire.
• Cause racine : Routage/DNS IPv6 cassé sur le réseau, ou RA mal configurées. Désactiver IPv6 force IPv4 et masque le vrai problème.
• Correctif : Corrigez la configuration IPv6 du réseau (annonces routeur, gestion des AAAA, pare‑feu). Sur un endpoint isolé, privilégiez la correction du DNS/passerelle plutôt que la désactivation d’un protocole.

Listes de vérification / plan pas à pas (sans tout nuker)

Ceci est le plan que je remettrais à un administrateur compétent ou à un power user obstiné. Il monte en charge prudemment.

Checklist A: Vérifier les bases (2–5 minutes)

1. Confirmez que vous êtes connecté au SSID ou au port Ethernet prévu (pas un VLAN invité).
2. Exécutez ipconfig /all. Notez : adresse IPv4, passerelle par défaut, serveurs DNS.
3. Pinger la passerelle par défaut.
4. Pinger une IP publique (exemple : 1.1.1.1).
5. Exécuter nslookup example.com.

Point de décision :

• Si DHCP échoue (APIPA), arrêtez et corrigez DHCP/L2/802.1X.
• Si l’IP marche mais le DNS échoue, corrigez le DNS ou la sélection DNS VPN.
• Si le DNS marche mais le web échoue, vérifiez proxy/VPN/pare‑feu/portail captif.

Checklist B: Attraper les coupables usuels (5–10 minutes)

1. Vérifier le proxy WinHTTP : netsh winhttp show proxy. Réinitialiser si incorrect.
2. Vérifier le proxy utilisateur via le registre (ou Paramètres) : confirmer que ProxyEnable est cohérent.
3. Vérifier les métriques d’interface : netsh interface ipv4 show interfaces.
4. Inspecter la table de routage : route print pour des surprises de route par défaut.
5. Tester la sonde de connectivité Windows via PowerShell Invoke-WebRequest vers le fichier de test de connectivité.

Checklist C: Réparer la pile (10–20 minutes, dommages contrôlés)

1. Vider le DNS : ipconfig /flushdns.
2. Release/renew : ipconfig /release puis ipconfig /renew.
3. Réinitialiser Winsock : netsh winsock reset (reboot).
4. Réinitialiser la pile IP : netsh int ip reset (reboot).

Point de décision : Si cela n’aide pas, le problème est probablement externe (politique réseau, backend VPN, proxy, pare‑feu, portail captif, bug pilote). Ne continuez pas à randomiser votre endpoint.

Checklist D: Sanity pilotes et alimentation (varie)

1. Si le souci a commencé après une mise à jour de pilote, revenez au pilote précédent.
2. Si c’est lié à la veille, ajustez les paramètres d’alimentation de l’adaptateur.
3. Si vous utilisez un dongle/dock Ethernet USB, testez un autre port ou branchez directement ; les docks peuvent être de petits routeurs sensibles.

FAQ

1) Pourquoi Windows dit « Pas d’internet » alors que je peux naviguer ?

Parce que Windows exécute une mécanique de détection de connectivité (NCSI) qui peut être bloquée ou redirigée. La navigation peut quand même fonctionner via un DNS en cache, un comportement proxy différent, ou des chemins alternatifs d’apps.

2) Quel est le moyen le plus rapide pour savoir si c’est DNS ?

Pinger une IP publique (test de routage), puis exécuter nslookup example.com (test DNS). IP marche + DNS échoue = problème DNS ou d’accessibilité DNS.

3) « Réinitialiser le réseau » est‑ce une bonne solution ?

Parfois. Mais c’est destructeur : ça supprime les réseaux enregistrés, les adaptateurs/profils VPN, les DNS/routes personnalisés, et peut casser l’authentification d’entreprise. Préférez des réinitialisations ciblées (winsock, int ip) d’abord.

4) Dois‑je désactiver IPv6 ?

Pas comme premier geste. Un IPv6 cassé sur le réseau peut provoquer de vrais problèmes, mais désactiver IPv6 sur le client masque souvent la mauvaise configuration sous‑jacente et peut casser des fonctionnalités Windows modernes et d’entreprise.

5) Pourquoi le problème n’arrive‑t‑il que sur le Wi‑Fi d’entreprise, pas à la maison ?

Les réseaux d’entreprise appliquent souvent des proxies, bloquent le DNS public, exigent 802.1X et effectuent des contrôles d’état endpoint. Un réseau domestique est essentiellement une anarchie bienveillante en comparaison.

6) Pourquoi des apps Microsoft (Store, OneDrive, Teams) échouent alors que le navigateur marche ?

Les composants système utilisent souvent les paramètres proxy WinHTTP et des chemins TLS/proxy différents de votre navigateur. Un mauvais réglage WinHTTP peut les casser alors que Chrome/Edge continue via ses propres paramètres.

7) Je suis sur VPN. Pourquoi perds‑je l’internet quand le VPN tombe ?

C’est généralement un kill switch ou une politique de routage : quand le tunnel meurt, le client bloque le trafic pour éviter les fuites. La correction passe par l’ajustement de la politique VPN, pas par « réparer Windows ».

8) Comment savoir si un portail captif est en cause ?

Récupérez un fichier HTTP connu et inspectez le contenu. Si vous obtenez une page HTML de connexion ou des redirections au lieu du texte attendu, vous êtes derrière un portail captif.

9) Pourquoi un redémarrage « règle » parfois le problème ?

Redémarrer efface des états transitoires : routes figées, services VPN coincés, état pilote après veille, et cache DNS. Ce n’est pas une cure ; c’est une remise à zéro d’état qui peut masquer la cause réelle.

10) Quand devrais‑je escalader vers l’équipe IT/réseau au lieu de continuer ?

Si vous avez une IP valide, pouvez atteindre votre passerelle, mais que des politiques proxy/VPN ou le comportement du pare‑feu semblent être le blocage — surtout sur des machines gérées. Se débattre côté endpoint ne réparera pas une politique centrale.

Conclusion : prochaines étapes qui ne ruineront pas votre journée

« Connecté, pas d’internet » est soit (a) vous ne pouvez vraiment pas atteindre l’internet, soit (b) Windows ne peut pas prouver que vous le pouvez. La solution consiste à arrêter de traiter cela comme une malédiction mystique du système d’exploitation et à le traiter comme un système en couches.

Faites ceci ensuite, dans l’ordre :

1. Exécutez ipconfig /all et confirmez : IP réelle, passerelle par défaut, serveurs DNS.
2. Pinger la passerelle, puis une IP publique, puis nslookup d’un domaine.
3. Si le comportement web/app est incohérent, vérifiez les proxies (WinHTTP + proxy utilisateur) et le routage/métriques VPN.
4. Si vous suspectez une corruption de la pile, utilisez netsh winsock reset et netsh int ip reset — puis redémarrez — avant de « réinitialiser le réseau ».
5. Si vous êtes en entreprise et que les preuves indiquent une politique (proxy bloquant, restrictions DNS, kill switch VPN), escaladez avec des données : sorties de commandes et couche précise en échec.

L’objectif n’est pas de rendre l’icône heureuse. L’objectif est de restaurer une connectivité fiable sans supprimer la moitié de votre configuration et espérer que l’univers approuve.