Les applications perdent l’accès Internet de façon aléatoire : la réinitialisation Winsock expliquée

février 24, 2026 • février 24, 2026 • Lecture : 26 min • Views: 0

Cet article vous a aidé ?

Votre ordinateur portable indique que le Wi‑Fi est connecté. Teams se reconnecte comme s’il s’entraînait pour un marathon. Votre navigateur tourne, puis annonce que l’internet est « indisponible », alors que ping fonctionne et qu’un collègue sur le même réseau est OK. Vous redémarrez, tout revient. Puis ça recommence — en général juste avant que vous ne présentiez.

C’est le type de panne qui rend les ingénieurs méfiants : le routeur, le FAI, les mises à jour Windows, la lune. Souvent, ce n’est rien de tout cela. C’est la pile réseau de Windows qui s’emmêle — fréquemment autour de Winsock, de son catalogue et d’extensions comme les VPN, la sécurité endpoint, les proxys et les « optimiseurs » prétendument utiles.

Ce qu’est réellement Winsock (et ce que ce n’est pas)

Winsock (Windows Sockets) est l’API et la tuyauterie que les applications utilisent pour parler TCP/UDP sous Windows. Votre navigateur ne « fait pas le réseau » en inventant des trames Ethernet ; il appelle des fonctions Winsock, et le système gère le reste : résolution de noms, routage, établissement de connexions, options de sockets et interactions avec les pilotes réseau.

En pratique, Winsock est la couche d’interface « socket » entre les applications en espace utilisateur et la pile réseau inférieure. Il prend aussi en charge un modèle de plug‑in : des fournisseurs peuvent s’insérer dans le chemin pour inspecter/modifier le trafic. Ce modèle est utile — jusqu’à ce qu’il ne le soit plus.

La réinitialisation Winsock corrige une classe spécifique de problèmes : corruption ou mauvais état du catalogue Winsock, souvent causés par des Layered Service Providers (LSP) ou des fournisseurs réseau installés par des VPN, antivirus, shapeurs de trafic, contrôles parentaux, bloqueurs de pubs ou agents d’« prévention des fuites de données » d’entreprise.

La réinitialisation Winsock ne corrige pas tout. Si le pilote NIC plante, votre Wi‑Fi se déplace mal ou votre routeur fond, réinitialiser Winsock revient à changer les essuie‑glaces pour réparer un problème de moteur. Vous aurez l’air productif, mais vous n’aurez pas résolu le bon problème.

Faits intéressants et contexte historique (parce que le passé continue de casser le présent)

Fait 1 : Winsock 1.1 est apparu au début des années 1990 pour standardiser la programmation de sockets sur Windows ; Winsock 2 a introduit des capacités plus modernes (comme une meilleure extensibilité et l’E/S chevauchée).
Fait 2 : Les LSP étaient largement utilisés à l’époque de Windows XP pour les antivirus et la « protection web », et aussi abusés par des adwares. Cet héritage compte encore.
Fait 3 : Le « catalogue Winsock » est une liste de fournisseurs et de leur ordre, stockée dans le registre. Quand l’ordre se casse, les applications peuvent échouer de manière étrangement sélective.
Fait 4 : La résolution de noms sous Windows n’est pas que DNS ; c’est une chaîne (fichier hosts, cache client DNS, multicast, NetBIOS dans certains environnements), et différentes applications empruntent des chemins différents.
Fait 5 : Beaucoup de rapports « l’internet est en panne » sont en réalité des échecs TLS — dérive d’heure, certificats interceptés ou SChannel cassé — parce que les applications modernes interprètent « impossibilité d’établir la poignée de main » comme « pas d’internet ».
Fait 6 : Les paramètres de proxy HTTP peuvent être par utilisateur et par application ; WinHTTP et WinINET ne sont pas la même pile proxy. C’est pour cela qu’un navigateur fonctionne pendant qu’un service échoue (ou inversement).
Fait 7 : Windows a plusieurs couches de pare‑feu : la stratégie du Pare‑feu Windows Defender, WFP (Windows Filtering Platform) callouts, et des filtres tiers. « Désactivé » dans l’interface ne signifie pas toujours « pas de filtrage ».
Fait 8 : « Réinitialisation TCP/IP » et « réinitialisation Winsock » sont des opérations différentes ; l’une cible les paramètres d’interface et de pile, l’autre l’état du catalogue de fournisseurs de sockets.

Pourquoi seules certaines applications échouent : modes de défaillance qui semblent aléatoires

« Perte aléatoire d’internet » signifie généralement : certains chemins sont cassés, et le chemin que chaque application utilise est différent. Vos symptômes sont une empreinte digitale. Apprenez à la lire.

1) Le DNS semble OK, mais les connexions échouent

Vous pouvez résoudre les noms, mais les connexions TCP expirent ou sont réinitialisées. Cela pointe vers du filtrage (pare‑feu/WFP), des problèmes MTU/PMTUD, ou une chaîne de fournisseurs réseau cassée. Si seuls certains ports échouent, suspectez une politique ou une inspection. Si seules certaines destinations échouent (surtout via VPN), suspectez le routage/MTU.

2) Les pings fonctionnent, mais les navigateurs indiquent « Pas d’internet »

Ping est ICMP. Les navigateurs utilisent TCP+TLS+HTTP. Dans les réseaux d’entreprise, l’ICMP peut être autorisé alors que l’inspection TLS échoue ou qu’un proxy est mal configuré. Ou vous atteignez une IP, mais la résolution DNS/le proxy/la poignée de main TLS est cassée. Ping est une couverture réconfortante, pas un test de santé complet.

3) Le navigateur fonctionne, mais des « applications » échouent (Outlook, Teams, applications du Store)

Piles d’API différentes. Les navigateurs utilisent souvent WinINET avec leur propre logique de proxy ; les services et composants système utilisent souvent WinHTTP. Si le proxy WinHTTP est erroné, les services d’arrière‑plan meurent alors que votre navigateur discute joyeusement.

4) Tout plante après la déconnexion d’un VPN

Classique. Les clients VPN installent des pilotes et des callouts WFP et peuvent ajouter des fournisseurs de type LSP ou des fournisseurs de namespace. Si une désinstallation/mise à jour laisse une entrée obsolète, l’OS peut continuer d’essayer d’envoyer le trafic via un fournisseur qui n’existe plus. Résultat : échecs sélectifs et délais bizarres.

5) Ça marche pendant des minutes, puis échoue pendant des minutes

Cette périodicité hurle « renouvellement de bail », « roaming », « gestion d’alimentation » ou « quelque chose qui scanne ». Windows peut mettre les NIC en veille. Les agents de sécurité interceptent des flux. Les renouvellements DHCP et les portails captifs peuvent faire rebondir les routes. Cherchez des éléments d’état avec des timers.

Une citation utile à garder : idée paraphrasée : le succès dans les opérations repose sur d’innombrables petits ajustements, pas sur un grand design. C’est le réseau sous Windows : ça marche parce qu’une douzaine de sous‑systèmes coopèrent généralement. Quand l’un cesse de coopérer, vous obtenez des histoires de fantômes.

Blague 1 : L’internet n’est pas en panne. Il prend juste un jour de congé personnel et ne le dit pas à vos sockets.

Ce que change « Winsock reset » en coulisses

Quand vous exécutez :

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

Vous dites à Windows de reconstruire le catalogue Winsock vers un état de base connu et sain. Cet état de base inclut les fournisseurs de sockets par défaut (typiquement MSAFD Tcpip [TCP/UDP over IPv4/IPv6]) et supprime les entrées LSP tierces de la chaîne (ou au moins supprime l’enregistrement de registre qui y pointe).

Dans les anciennes générations de Windows, c’était un correctif courant pour des malwares qui s’étaient insérés comme LSP. Aujourd’hui, c’est tout aussi pertinent — sauf que le « malware » est souvent un agent d’entreprise légitime qui a mal évolué.

Ce que cela affecte :

L’ordre des fournisseurs et leur enregistrement pour les opérations de socket.
Comment les applications en espace utilisateur obtiennent leurs sockets et où ces appels sont routés.
Potentiellement, les fournisseurs de résolution de noms (selon ce qui a été installé).

Ce que cela ne corrige pas directement :

Les pilotes NIC cassés, le Wi‑Fi instable ou les mauvais ports de commutateur.
Mauvaises routes, passerelles erronées ou erreurs de routage split‑tunnel VPN.
Problèmes d’inspection TLS/confiance de certificats.
Paramètres proxy dans WinHTTP/WinINET (bien que certaines recettes de « réinitialisation complète » réinitialisent aussi le proxy séparément).

L’obligation de redémarrer est réelle. Le catalogue n’est pas juste un fichier que l’on édite ; la pile réseau et les services mettent en cache l’état. Si vous lancez la commande sans redémarrer, vous demandez essentiellement à Windows d’oublier quelque chose alors qu’il s’en souvient encore activement.

Playbook de diagnostic rapide (premier/deuxième/troisième)

Ceci est la section « arrêter de deviner ». L’objectif est de répondre rapidement à une question : Où se situe la défaillance — résolution de noms, routage, transport ou politique/interception ?

Premier : Prouver le chemin de base (liaison, IP, route)

Vérifier que vous avez une IP valide, une passerelle et des serveurs DNS.
Vérifier que la route vers 0.0.0.0/0 et ::/0 est cohérente (surtout après connexion/déconnexion VPN).
Vérifier si le problème concerne seulement IPv6 ou seulement IPv4.

Second : Séparer DNS et connectivité

Résoudre un nom vers une IP.
Se connecter à l’IP sur un port connu (443) sans dépendre du DNS si nécessaire.
Si DNS résout mais que la connexion TCP échoue, cessez d’accuser le DNS.

Troisième : Identifier l’interception (proxy, pare‑feu, agent de sécurité, LSP/WFP)

Vérifier le proxy WinHTTP et les paramètres proxy utilisateur.
Vérifier le profil du Pare‑feu Windows et les événements récents de blocage.
Vérifier si une pile VPN/logiciel de sécurité est installée et récemment mise à jour.
Si les symptômes sont « applications sélectives », « après VPN » ou « après mise à jour de sécurité », Winsock/WFP/chaîne de fournisseurs est un suspect principal.

Si vous effectuez ces trois passes, vous tomberez presque toujours sur l’un des cas : (a) routage, (b) DNS/proxy, (c) filtrage/interception, (d) liaison instable.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches sont conçues pour être exécutées dans un terminal Windows élevé (PowerShell/CMD). Je les montre dans des blocs de code avec des sorties réalistes. Votre travail est de lire la sortie et de prendre une décision, pas de collecter des captures d’écran comme des Pokémon.

Task 1: Confirm interface state and IP config

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

Ethernet adapter Ethernet:

   Connection-specific DNS Suffix  . : corp.example
   Description . . . . . . . . . . . : Intel(R) Ethernet Connection
   Physical Address. . . . . . . . . : 3C-52-82-11-22-33
   DHCP Enabled. . . . . . . . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.42.18.57(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : Monday, February 5, 2026 9:10:01 AM
   Lease Expires . . . . . . . . . . : Monday, February 5, 2026 5:10:01 PM
   Default Gateway . . . . . . . . . : 10.42.18.1
   DNS Servers . . . . . . . . . . . : 10.42.0.10
                                       10.42.0.11

Ce que cela signifie : Vous avez un bail DHCP valide, une passerelle et des DNS. Si vous voyez 169.254.x.x, le DHCP a échoué ; si la passerelle est vide, vous ne routez pas hors‑sous‑réseau.

Décision : Si IP/passerelle/DNS sont manquants ou incorrects, corrigez cela d’abord (DHCP, VLAN, Wi‑Fi). Ne touchez pas Winsock pour l’instant.

Task 2: Check routing table for default routes (IPv4/IPv6)

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      10.42.18.1     10.42.18.57     25
       10.42.18.0    255.255.255.0         On-link     10.42.18.57    281
===========================================================================
IPv6 Route Table
===========================================================================
Active Routes:
::/0                     fe80::1           On-link      25

Ce que cela signifie : Une route par défaut existe. Si le VPN laisse derrière lui une route par défaut à métrique plus élevée pointant vers nulle part, une partie du trafic sera noyée.

Décision : Si la route par défaut est manquante ou pointe vers une interface VPN obsolète, corrigez le routage/la configuration VPN avant de faire des réinitialisations.

Task 3: Test DNS resolution explicitly

cr0x@server:~$ nslookup www.microsoft.com
Server:  dns01.corp.example
Address:  10.42.0.10

Non-authoritative answer:
Name:    www.microsoft.com
Addresses:  13.107.246.45
           13.107.213.45

Ce que cela signifie : Le DNS répond et renvoie des enregistrements A. Si ceci expire, vous avez un problème d’accessibilité DNS ou un blocage UDP/TCP 53.

Décision : Si le DNS échoue, vérifiez les serveurs DNS, les règles de pare‑feu ou le portail captif. Ne blâmez pas Winsock tant que le DNS ne répond pas de façon cohérente.

Task 4: Bypass DNS and test TCP 443 to an IP

cr0x@server:~$ powershell -Command "Test-NetConnection 13.107.246.45 -Port 443"
ComputerName     : 13.107.246.45
RemoteAddress    : 13.107.246.45
RemotePort       : 443
InterfaceAlias   : Ethernet
SourceAddress    : 10.42.18.57
TcpTestSucceeded : True

Ce que cela signifie : La connectivité transport vers le port 443 fonctionne. Si le DNS fonctionne mais que ceci échoue, vous regardez du côté du routage/MTU/pare‑feu/interception.

Décision : Si TcpTestSucceeded est False, passez aux vérifications pare‑feu/WFP et aux suspicions MTU/VPN.

Task 5: Check whether IPv6 is the culprit

cr0x@server:~$ powershell -Command "Test-NetConnection www.microsoft.com -Port 443"
ComputerName     : www.microsoft.com
RemoteAddress    : 2603:1020:201:10::10f
InterfaceAlias   : Ethernet
SourceAddress    : 2001:db8:42:18::57
TcpTestSucceeded : False

Ce que cela signifie : Le DNS a renvoyé d’abord une adresse IPv6 ; le chemin IPv6 a échoué. Beaucoup d’applications privilégieront IPv6 et se comporteront « aléatoirement » si IPv6 est partiellement cassé.

Décision : Corrigez le routage/RA/DHCPv6 ou désactivez IPv6 seulement en diagnostic temporaire. À long terme, un IPv6 partiel est pire que pas d’IPv6 du tout.

Task 6: Inspect WinHTTP proxy (common “apps fail, browser works” cause)

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

    Proxy Server(s) : http=proxy.corp.example:8080;https=proxy.corp.example:8080
    Bypass List     : (none)

Ce que cela signifie : Les services système et beaucoup d’apps d’entreprise utiliseront ce proxy. S’il pointe vers un proxy mort ou un PAC erroné, la connectivité d’arrière‑plan mourra.

Décision : Si vous êtes hors réseau ou que le proxy est inatteignable, définissez WinHTTP en accès direct ou importez les bons paramètres.

Task 7: Reset WinHTTP proxy to direct (diagnostic, not ideology)

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

    Direct access (no proxy server).

Ce que cela signifie : WinHTTP se connectera maintenant directement. Si les applications fonctionnent soudainement, votre configuration ou l’accessibilité du proxy est le problème.

Décision : Soit corriger l’accessibilité du proxy (VPN, DNS, routes), soit restaurer les paramètres corrects via la politique/PAC.

Task 8: Check user-level proxy settings (WinINET)

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 cela signifie : L’utilisateur a un proxy activé. Un proxy obsolète peut faire échouer les navigateurs et certaines apps tandis que d’autres réussissent.

Décision : Si vous ne devriez pas utiliser de proxy, désactivez‑le. Si vous devez l’utiliser, confirmez que le PAC/hôte/port sont corrects.

Task 9: Dump Winsock catalog to spot third-party providers

cr0x@server:~$ netsh winsock show catalog
Catalog Entries:
------------------------------------
Entry #0000000001
-----------------
Service Provider : MSAFD Tcpip [TCP/IP]
Provider Path    : %SystemRoot%\system32\mswsock.dll

Entry #0000000009
-----------------
Service Provider : Contoso Security LSP
Provider Path    : C:\Program Files\Contoso\NetFilter\contosolsp.dll

Ce que cela signifie : Des fournisseurs tiers existent. Si la DLL est manquante, non assortie ou cassée, les applications échoueront de façons non évidentes.

Décision : Si vous voyez des fournisseurs issus d’un VPN/AV désinstallé, planifiez une réinitialisation Winsock (et probablement une réinstallation/nettoyage du produit en cause).

Task 10: Perform Winsock reset (and accept the reboot)

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

Ce que cela signifie : Réinitialisation du catalogue mise en file ; redémarrage nécessaire pour appliquer complètement.

Décision : Redémarrez maintenant si vous êtes en incident. Si vous ne pouvez pas redémarrer, arrêtez de faire semblant d’avoir réparé et continuez le diagnostic.

Task 11: Reset TCP/IP stack parameters (useful when interfaces get “sticky”)

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 cela signifie : Cela réinitialise les paramètres TCP/IP liés à l’interface, pas les fournisseurs Winsock. Utile après des bizarreries de VPN/driver ou des réglages manuels.

Décision : Utilisez‑le lorsque le comportement de routage/interface est étrange (passerelle/MTU/cache voisin). Nécessite aussi un redémarrage pour plein effet.

Task 12: Flush DNS client cache (low-risk, sometimes decisive)

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

Successfully flushed the DNS Resolver Cache.

Ce que cela signifie : Les entrées DNS en cache sont supprimées. Utile quand le split‑DNS change (VPN on/off) et que le cache contient des réponses périmées.

Décision : Si le problème n’apparaît qu’après changement de réseau ou basculement VPN, faites ceci tôt.

Task 13: Check for firewall profile and state

cr0x@server:~$ netsh advfirewall show allprofiles
Domain Profile Settings:
----------------------------------------------------------------------
State                                 ON

Private Profile Settings:
----------------------------------------------------------------------
State                                 ON

Public Profile Settings:
----------------------------------------------------------------------
State                                 ON

Ce que cela signifie : Le pare‑feu est activé pour tous les profils. C’est normal. La question est de savoir si des politiques bloquent les sorties ou forcent l’inspection.

Décision : Si la machine est sur un réseau d’entreprise mais coincée en profil Public, corrigez la détection de l’emplacement réseau ; ne désactivez pas le pare‑feu comme « test » à moins d’aimer les rapports d’incident.

Task 14: Identify whether NCSI is lying about internet connectivity

cr0x@server:~$ reg query "HKLM\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet" /v EnableActiveProbing

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet
    EnableActiveProbing    REG_DWORD    0x1

Ce que cela signifie : Windows utilise des sondes actives pour décider s’il y a « internet ». Si les points de sondage sont bloqués, Windows peut afficher « Pas d’internet » alors que la connectivité existe.

Décision : Si les utilisateurs se plaignent de l’icône mais que les applications fonctionnent, vous avez un problème de NCSI/sondage, pas un problème de transport.

Task 15: Quick check for MTU issues (symptom: TLS stalls, some sites fail)

cr0x@server:~$ ping -f -l 1472 8.8.8.8
Pinging 8.8.8.8 with 1472 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Ping statistics for 8.8.8.8:
    Packets: Sent = 2, Received = 0, Lost = 2 (100% loss)

Ce que cela signifie : Le MTU du chemin est inférieur à 1500 (1472 octets de charge utile + 28 d’en‑têtes). Les VPN et tunnels réduisent souvent le MTU ; une PMTUD cassée fait que de gros paquets disparaissent.

Décision : Si cela arrive, baissez le MTU de l’interface ou corrigez PMTUD/le filtrage ICMP sur le chemin. La réinitialisation Winsock n’agira pas sur ceci.

Blague 2 : Si votre « optimiseurs réseau » promet 300% d’internet plus rapide, il optimise généralement le temps que vous passez à redémarrer.

Trois mini‑histoires d’entreprise issues du terrain

Mini‑histoire 1 : L’incident causé par une fausse hypothèse

Dans une entreprise de taille moyenne, le helpdesk avait un rituel : chaque fois qu’une application ne pouvait pas se connecter, ils vidaient le cache DNS et redémarraient. Cela fonctionnait assez souvent pour devenir une doctrine. Puis un nouveau client VPN a été déployé, et en quelques jours, les tickets « perte d’internet aléatoire » ont explosé. Le schéma était étrange : les navigateurs fonctionnaient principalement, mais Teams, Outlook et les outils internes qui utilisaient les services système échouaient.

Quelqu’un a assumé « le DNS est cassé » parce que des noms étaient en jeu. Ils ont poussé un changement pour échanger les serveurs DNS, puis un autre pour augmenter la taille du cache DNS. Rien n’a aidé. En réalité, cela a rendu le dépannage plus difficile, car plusieurs variables ont changé à la fois. Mouvement corporatif classique : si c’est flou, changez plus de choses.

Le vrai problème : l’installeur VPN avait ajouté une configuration de proxy WinHTTP, censée être utilisée uniquement lorsqu’on est connecté au réseau d’entreprise. Mais il ne l’a pas supprimée correctement lorsqu’on se déconnectait. Les utilisateurs hors site se sont retrouvés avec des composants système essayant de passer par un hôte injoignable. Le trafic du navigateur n’empruntait pas ce chemin de façon cohérente, donc le navigateur restait « OK », renforçant la mauvaise hypothèse.

La correction a été ennuyeuse : réinitialiser le proxy WinHTTP en accès direct pour les utilisateurs hors réseau et ajuster la politique VPN pour le définir et le supprimer de façon fiable. Ils ont aussi rédigé un runbook d’une page : « Le navigateur fonctionne, les apps échouent : vérifier le proxy WinHTTP. » Les tickets ont chuté rapidement.

Mini‑histoire 2 : L’optimisation qui a mal tourné

Une équipe sécurité a déployé un module d’inspection de trafic pour attraper l’exfiltration. Il s’est inséré dans la pile réseau, parce que c’est là que passe le trafic. Le déploiement était phasé, et les premiers utilisateurs juraient que rien n’avait changé. Puis le cycle de patch trimestriel est arrivé.

Après le Patch Tuesday, un sous‑ensemble de machines a commencé à perdre la connectivité « aléatoirement », surtout après la mise en veille/réveil. Ce n’était pas une panne totale ; c’était pire. Certaines apps expiraient, d’autres se connectaient lentement, et les échecs n’étaient pas cohérents entre les machines. Les ingénieurs ont perdu des jours à traquer les pilotes Wi‑Fi et les points d’accès.

L’« optimisation » était un réglage de performance : le module d’inspection a activé un pool de connexions agressif et modifié certains comportements de socket pour réduire la charge. Sous un timing particulier — mise en veille/réveil et changements rapides de réseau — la chaîne de fournisseurs finissait dans un mauvais état, faisant bégayer les appels connect() jusqu’à l’expiration. Cela ressemblait à « internet en panne » mais ne l’était pas. C’était la création de sockets et l’évaluation de la politique qui bloquaient.

La réinitialisation Winsock réparait temporairement les machines affectées en reconstruisant le catalogue et en purgeant l’état de la chaîne de fournisseurs, ce qui facilitait un mauvais diagnostic de « Windows est instable ». La vraie correction a été un module patché et un changement de pratique de déploiement : plus d’« optimisation silencieuse au niveau pilote » sans rollback planifié et tests explicites pour les transitions veille/réveil et VPN.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une autre organisation était bien cadrée. Pas parfaite, mais disciplinée. Ils conservaient un script standard de « sanity bundle » réseau qui collectait : config IP, routes, tests de résolution DNS, état du proxy et dump du catalogue Winsock. Chaque fois qu’un utilisateur signalait une connectivité intermittente, ils lançaient le même bundle avant toute réinitialisation.

Une semaine, une vague de tickets est arrivée : « L’app interne ne peut pas atteindre l’API, mais internet fonctionne. » Le bundle montrait un indice constant : la route par défaut était correcte, le DNS aussi, mais TCP 443 vers le load balancer interne échouait uniquement lorsque IPv6 était préféré. La route IPv6 existait, mais le chemin était cassé au‑delà du premier saut. Les apps qui utilisaient IPv4 continuaient de fonctionner ; celles qui préféraient IPv6 échouaient « aléatoirement ».

Parce qu’ils avaient des sorties de référence depuis des machines saines, ils ont pu comparer rapidement et escalader vers l’équipe réseau avec des preuves. La cause racine était une publicité de route IPv6 mal configurée sur un segment, annonçant une connectivité qui n’était pas réellement routée vers le datacenter. La correction était côté réseau, pas endpoints.

La pratique ennuyeuse — collecter avant de réinitialiser — les a empêchés de déployer un « correctif Winsock » à l’échelle qui n’aurait rien changé. Ça a aussi évité à l’équipe réseau le ticket classique et inutile : « internet cassé pls fix ». Ils ont reçu un ticket précis : « Route IPv6 par défaut présente ; TCP 443 échoue sur IPv6 seulement ; voici traceroute et interface. » C’est comme ça qu’on obtient des réparations rapides en milieu corporate.

Erreurs courantes : symptôme → cause racine → correctif

Voici la section où vous arrêtez la danse interprétative avec la pile réseau.

1) Symptom: “Connected, no internet” icon, but browser works

Cause racine : Les sondes actives NCSI bloquées par la politique pare‑feu/proxy ; Windows étiquette mal la connectivité.

Correctif : Autoriser le mécanisme de sondage via les contrôles d’entreprise ou configurer la politique convenablement. Ne « corrigez » pas cela en désactivant NCSI à moins d’aimer casser le comportement VPN et la confiance des utilisateurs.

2) Symptom: Browser works, Teams/Outlook/store apps fail

Cause racine : Proxy WinHTTP mal configuré ou injoignable ; WinINET (navigateur) utilise un chemin proxy différent.

Correctif : netsh winhttp show proxy, réinitialiser/importer le proxy correct, s’assurer que le VPN définit/supprime le proxy de façon cohérente.

3) Symptom: DNS resolves, but TCP connect times out across many sites

Cause racine : Interception par pare‑feu/WFP bloquant les sorties, ou route par défaut pointant vers une interface obsolète.

Correctif : Vérifier la politique/les événements du pare‑feu, valider route print, supprimer les adaptateurs/routes VPN obsolètes, puis envisager une réinitialisation Winsock si la chaîne de fournisseurs est corrompue.

4) Symptom: Works until VPN disconnects; then nothing connects

Cause racine : Pilote/fournisseur de filtre VPN resté en mauvais état ; paramètres proxy ou routes non restaurés ; suffixe DNS/ordre de recherche bloqué.

Correctif : Mise à jour/réparation correcte du client VPN, réinitialiser le proxy en direct, vider le DNS, puis réinitialisation Winsock + redémarrage si les fournisseurs sont coincés.

5) Symptom: Only large downloads or some HTTPS sites fail; small pings work

Cause racine : MTU/PMTUD en blackhole, souvent via VPN ou tunnels GRE/IPsec avec ICMP bloqué.

Correctif : Diagnostiquer avec un ping DF, ajuster le MTU de l’interface ou corriger la gestion ICMP fragmentation‑needed dans la politique réseau.

6) Symptom: After security software update, random timeouts and resets

Cause racine : Callout WFP cassé ou chaîne de fournisseurs de type LSP ; les entrées du catalogue pointent vers des versions de DLL non assorties.

Correctif : Correctif/rollback du fournisseur par le vendeur ; la réinitialisation Winsock peut nettoyer la corruption du catalogue mais ne corrigera pas un pilote de filtrage buggy.

7) Symptom: Internal names resolve to wrong environment (prod vs dev), intermittently

Cause racine : Split DNS et ordre des suffixes de recherche changeant lors des transitions réseau ; cache DNS périmé.

Correctif : Vider le DNS, s’assurer que les paramètres DNS du VPN sont corrects, vérifier la liste de suffixes de recherche, éviter de coder en dur des serveurs DNS sur les endpoints.

Listes de contrôle / plan étape par étape

Checklist A: One-machine triage (10 minutes, no heroics)

Exécuter ipconfig /all. Confirmer IP, passerelle, DNS, bail. Si cassé : corriger d’abord le lien/DHCP.
Exécuter route print. Confirmer les routes par défaut, surtout après transitions VPN.
Exécuter nslookup pour un domaine connu. Si échec : se concentrer sur l’accessibilité DNS.
Exécuter Test-NetConnection vers une IP:443. Si échec : se concentrer sur routage/pare‑feu/MTU.
Vérifier le proxy WinHTTP : netsh winhttp show proxy. Si incorrect : réinitialiser/importer le proxy correct.
Dump du catalogue Winsock : netsh winsock show catalog. Chercher des fournisseurs tiers liés à des installations/mises à jour récentes.
Si la chaîne de fournisseurs semble suspecte et que les symptômes correspondent : netsh winsock reset puis redémarrer.

Checklist B: “I ran Winsock reset and it still fails” (good, now we do real work)

Re‑vérifier les paramètres proxy (WinHTTP et proxy utilisateur). La réinitialisation Winsock ne répare pas l’état proxy.
Tester IPv4 vs IPv6 séparément. Préférer désactiver IPv6 seulement en confirmation temporaire.
Vérifier le MTU via ping DF ; confirmer que l’overhead VPN/tunnel n’occasionne pas de blackhole.
Valider les profils du pare‑feu et si un filtrage de sécurité tiers est installé.
Chercher des problèmes de pilote : journaux d’événements, gestion d’alimentation du NIC, triggers veille/réveil.

Checklist C: Fleet practice (what to standardize so this stops being “random”)

Standardiser les versions du client VPN et imposer des processus propres de désinstallation/réinstallation.
Interdire les outils « optimiseurs internet » dans les images d’entreprise. Ils n’optimisent rarement ce dont vous avez besoin.
Maintenir un script de diagnostic et collecter les sorties avant toute réinitialisation.
Définir une stratégie proxy claire : PAC vs statique, WinHTTP vs WinINET, on‑network vs off‑network.
Suivre les changements : mises à jour sécurité endpoints, mises à jour VPN, mises à jour drivers. Corréler avec les pics de tickets.

FAQ

1) Does Winsock reset delete my network adapters?

Non. Cela réinitialise le catalogue Winsock (fournisseurs). Vos adaptateurs restent. Mais vous devez redémarrer, et certains logiciels qui ont inséré des fournisseurs peuvent nécessiter une réparation/réinstallation.

2) Why does rebooting “fix it” even when nothing changed?

Le redémarrage efface l’état en cache : enregistrements de fournisseurs, état des pilotes, caches voisins et services bloqués en échec. C’est un instrument brutal qui masque les causes racines.

3) Should I run both `netsh winsock reset` and `netsh int ip reset`?

Seulement quand vous avez des preuves de bizarreries à la fois dans la chaîne de fournisseurs (Winsock) et dans les paramètres d’interface/pile (TCP/IP). Les exécuter tous les deux aveuglément est la façon de perdre la trace de ce qui a réparé quoi.

4) Why do only some apps fail, not all?

Les applications utilisent des piles différentes (WinHTTP vs WinINET), des paramètres proxy différents, des comportements DNS différents et des préférences IPv4/IPv6 différentes. Les pannes sélectives sont attendues dans les systèmes en couches.

5) Can a VPN cause Winsock issues even after it’s uninstalled?

Oui. Si la désinstallation laisse des enregistrements de fournisseurs obsolètes ou des pilotes de filtre, la pile réseau peut encore tenter de faire passer des appels via quelque chose qui n’existe plus ou ne fonctionne plus.

6) Is this a DNS problem if `nslookup` works?

Pas nécessairement. La résolution DNS peut réussir tandis que le transport échoue. Séparez « puis‑je résoudre ? » de « puis‑je me connecter ? » en utilisant un test TCP direct sur un port.

7) Why does “No internet” show in Windows when I can browse?

Windows utilise des vérifications de connectivité (NCSI) qui peuvent être bloquées par politique ou proxy. L’icône est un indice, pas un verdict.

8) When should I suspect MTU/PMTUD instead of Winsock?

Si le petit trafic fonctionne (DNS, petites requêtes HTTP) mais que de gros transferts HTTPS bloquent, ou si seuls certains sites échouent, surtout via VPN. Testez avec un ping DF et ajustez le MTU ou la gestion ICMP.

9) Is disabling the firewall a good diagnostic step?

Pas en environnement d’entreprise. Vous changerez la posture sécurité et vous ne contournerez peut‑être pas les filtres tiers WFP. Préférez des vérifications ciblées : profil, règles et tests de port contrôlés.

10) What’s the safest “reset sequence” if I’m stuck?

Dans l’ordre : vider le DNS, réinitialiser le proxy WinHTTP vers une valeur connue, puis réinitialisation Winsock + redémarrage. N’ajoutez le reset TCP/IP que si le comportement d’interface est clairement corrompu.

Prochaines étapes à suivre réellement

Si des applications perdent l’accès Internet de façon aléatoire sous Windows, arrêtez de traiter cela comme un mystère et commencez à le traiter comme un système en couches avec une couche cassée.

Exécutez le playbook de diagnostic rapide et séparez DNS vs transport vs politique.
Vérifiez les proxys (WinHTTP et proxy utilisateur). C’est le correctif à plus fort ROI pour « apps échouent, navigateur fonctionne ».
Inspectez le catalogue Winsock lorsque vous suspectez une interception tierce. S’il est pollué ou obsolète, réinitialisez‑le et redémarrez.
Ne répandez pas aveuglément des réinitialisations sur une flotte. Collectez d’abord des sorties de référence, puis corrigez la couche réellement défaillante.
Escaladez avec des preuves : table de routage, état du proxy, tests IPv4/IPv6, et corrélation avec des mises à jour VPN/sécurité.

La réinitialisation Winsock est un bon outil. Ce n’est pas un mode de vie. Utilisez‑la quand la chaîne de fournisseurs est le suspect probable, et ayez la discipline de le prouver.