KomuraSoft LLC
Nous contacter
Menu

Le réseau fonctionne mais Windows affiche « Pas d'Internet » — Isoler NCSI, DNS, proxy et VPN sous Windows

· · Windows, Développement Windows, Réseau, NCSI, DNS, Proxy, VPN, PowerShell

Les sites web s’ouvrent. Les messages de messagerie instantanée passent. Et pourtant, seul l’affichage de Windows indique « Pas d’Internet ».

Vous vous dites sans doute : « j’utilise le réseau en ce moment même, alors pourquoi dit-il qu’il n’y en a pas ? » Il y a une raison à cela. Windows possède sa propre vérification de connectivité, et son résultat est distinct du résultat du trafic qu’envoie l’application que vous utilisez à l’instant. Vos sites habituels peuvent être joignables alors que seule la destination contre laquelle Windows vérifie ne l’est pas.1

Avant de supprimer les paramètres Wi-Fi ou de réinitialiser tout le réseau, séparez donc la question : seul l’affichage est-il faux, ou le trafic que vous voulez utiliser échoue-t-il aussi ?

Cet article explique d’abord le mécanisme de cet écart, puis passe aux situations courantes, à la lecture par symptôme et aux étapes concrètes d’investigation. Si vous voulez le mécanisme, lisez jusqu’au chapitre 3 inclus ; si vous enquêtez, lisez les chapitres 4 et 5 ; les développeurs d’applications Windows liront également le chapitre 6. Il est centré sur Windows 11 et traite aussi les différences avec Windows 10, et les exemples utilisent Windows PowerShell 5.1 et curl.exe.

1. Windows ne regarde pas seulement le site que vous consultez à l’instant

Imaginez que vous ouvriez votre site habituel sur un PC d’entreprise. Si le navigateur peut dialoguer avec ce site, la page s’affiche. Indépendamment de cela, Windows va chercher un petit fichier utilisé pour la vérification de connectivité.

Or, que se passerait-il si le réseau de l’entreprise était configuré pour autoriser le trafic vers les sites que les gens utilisent habituellement, mais pas le trafic vers la destination de vérification de connectivité ? Le trafic du navigateur réussit tandis que le trafic de vérification de Windows échoue. Même sur un même PC, si ce contre quoi vous vérifiez diffère, les résultats peuvent diverger.1

Un exemple où le site web fonctionne et où seule la vérification de connectivité échoueUn exemple hypothétique dans lequel le navigateur du même PC atteint le site habituel tandis que la requête de vérification NCSI n'atteint pas une destination de vérification différente. Ce n'est pas un schéma qui fixe l'état final de NCSI à partir d'une seule requête.Le même PCTrafic du navigateurTrafic de vérification de connectivité de WindowsSite web habituella page s'ouvreDestination de vérification de connectivitéseul ce trafic échoue

Figure 1 : Un exemple hypothétique pour comprendre le mécanisme. Le trafic quotidien et la vérification de connectivité s’adressent à des interlocuteurs différents.

Le composant chargé de ce verdict de connectivité est NCSI (Network Connectivity Status Indicator). Il décide s’il existe une connexion à Internet ou seulement une connectivité locale, et il fournit les informations utilisées par l’affichage d’état du réseau et par les applications. Il ne surveille pas si tel site web ou tel système métier est opérationnel.1

Regardez si le contenu de vérification revient, pas si quelque chose est revenu

Depuis Windows 10 version 1607, la destination standard de vérification HTTP est l’URL suivante. Le corps attendu est Microsoft Connect Test. Sur les PC gérés par les entreprises, la destination de vérification est parfois modifiée.2

http://www.msftconnecttest.com/connecttest.txt

Si vous allez chercher ce fichier et qu’un écran de connexion d’hôtel ou une page de blocage d’entreprise revient, alors quelque chose est bien arrivé de la destination, mais ce n’est pas le résultat de vérification attendu. Même lorsque le statut HTTP est 200, le corps n’est pas nécessairement le même.3

Ce que vérifie la sonde HTTPPour la requête vers la destination de vérification, regardez si la réponse et le corps attendus reviennent.NonOuiOuiNonRequête HTTP vers la destination de vérificationUne réponse a-t-elle été reçueExaminer le transfert incomplet ou l'échecEst-ce la réponse et le corps attendusÉlément en faveur d'un verdict « connecté »Examiner l'authentification, le blocage ou le contenu modifié

Figure 2 : Gardez distincts « recevoir une réponse de la destination de vérification » et « récupérer le contenu attendu ».

Notez que NCSI ne fonctionne pas sur ce seul trafic de vérification. La méthode où il vérifie de sa propre initiative s’appelle la sonde active, et celle où il juge à partir d’informations telles que les paquets reçus la sonde passive ; il utilise les deux. Une requête HTTP échouée dans le schéma n’équivaut donc pas à un état de connectivité final sans Internet.1

Ce qu’il faut retenir jusqu’ici : se connecter au Wi-Fi, pouvoir utiliser un site donné et voir Windows rendre un verdict « Internet » sont chacun une vérification distincte. Être connecté au Wi-Fi ne vous dit rien sur la route vers l’extérieur ni sur l’authentification d’usage, et atteindre un site ne garantit pas qu’une autre destination ou une autre application fonctionnera.

Dans le diagramme, un trait continu marque une relation qui vaut toujours et un trait pointillé une relation conditionnelle (les conditions figurent dans l’explication de chaque relation sur la page de détail). La liste complète des relations (5 au total, avec preuve et niveau de certitude) et les définitions des concepts principaux sont rassemblées sur la page de détail de la carte des connaissances (en japonais). Données : JSON-LD / Turtle

2. Trois situations courantes où l’affichage et le trafic divergent

Au bureau, le navigateur et la vérification de connectivité peuvent emprunter des chemins différents

Rendons l’exemple d’entreprise du début un peu plus concret. Sur les réseaux d’entreprise, il existe des configurations où l’on ne sort pas directement mais où l’on passe par un relais appelé proxy. Le mécanisme qui choisit ce relais selon l’URL consultée et des critères analogues est le fichier PAC. La détection automatique est parfois utilisée aussi.4

Dans cette configuration, un proxy approprié peut être sélectionné pour les sites habituellement utilisés tandis que seule la destination de vérification de connectivité échappe aux règles. Les cas où la détection de proxy n’aboutit pas à temps, ou où seul le trafic HTTP vers la destination de vérification est bloqué, sont eux aussi des pistes à examiner.1

Vérifier séparément le chemin du navigateur et celui de NCSILa réussite du trafic du navigateur ne garantit pas celle de NCSI, qui utilise une autre destination et une autre sélection de proxy.Le même PCRequête du navigateurRequête de vérification NCSIProxy et authentification pour cette requêteProxy et authentification pour la requête de vérificationSite web utiliséDestination de vérification de connectivité

Figure 3 : Être sur le même PC ne signifie pas nécessairement le même chemin. Vérifiez destination, proxy et authentification pour chaque requête.

Allez donc au-delà de la réussite du navigateur et déterminez quel proxy a été sélectionné pour la requête de NCSI, et sous quel compte ou quelles conditions d’authentification elle a communiqué. Il en va de même pour la vérification manuelle avec curl utilisée plus loin. Ne pas traiter ces trois éléments comme du trafic dans des conditions identiques est le point de départ de l’isolement du problème.

À l’hôtel, une connexion peut rester à faire après avoir rejoint le Wi-Fi

Sur le Wi-Fi des hôtels et lieux analogues, on peut vous demander d’accepter des conditions d’utilisation ou de vous connecter une fois la liaison radio établie. Cette passerelle d’authentification est un portail captif. Si la requête de vérification est redirigée vers la page d’authentification, ou qu’un écran de connexion est renvoyé, cela ne constitue pas la réponse de vérification normale. Le fait que Windows ouvre un navigateur pour vous inviter à vous connecter est lié à ce mécanisme.3

La différence entre rejoindre le Wi-Fi et l'authentification au portailMême après la réussite de la connexion sans fil, le trafic vers l'extérieur peut rester restreint tant que l'authentification côté réseau n'est pas terminée.Non terminéeTerminéeConnecté au Wi-FiL'authentification d'usage est-elle terminéeS'authentifier depuis la page officielleRevérifier le trafic réel et le verdict

Figure 4 : Terminer la connexion au Wi-Fi ne signifie pas avoir terminé l’authentification permettant d’utiliser ce réseau.

Comme il existe des cas où seule la page d’information du lieu est consultable, ne concluez pas d’une page qui s’ouvre que tout le trafic sortant est autorisé. Authentifiez-vous en suivant les instructions officielles du lieu, puis vérifiez le trafic réel et l’affichage de Windows. N’entrez pas de données de compte ou de carte dans un écran de connexion suspect.

Avec un VPN, « de quelle connexion vient le résultat » change

Avant et après une connexion VPN, le chemin du trafic et les conditions d’utilisation du DNS peuvent changer. Des paramètres pas encore en place juste après la connexion, ou du trafic de vérification empruntant un chemin non prévu, sont eux aussi des pistes d’échec de NCSI.2

Dans ce cas, ne voyez pas le PC comme un unique état connecté ou non connecté : séparez le LAN physique ou le Wi-Fi du VPN. Par exemple, si la conception place le côté physique sur LocalNetwork alors que vous sortez vers Internet par le VPN, une ligne sur le côté physique ne suffit pas à déclarer un dysfonctionnement. Lisez les profils de connexion du chapitre 4 en regard du chemin réellement emprunté.56

Séparer le chemin de connexion et la famille IPSéparez le LAN physique du VPN et IPv4 d'IPv6, et associez à chaque verdict le chemin emprunté par le trafic.Lister les connexionsLAN physique et Wi-FiCarte VPNVerdicts IPv4 et IPv6Verdicts IPv4 et IPv6Mettre en regard du chemin réel du trafic

Figure 5 : Gardez distincts connexion physique et VPN, IPv4 et IPv6, tout en comparant avec le chemin réel du trafic.

Il en va de même pour IPv4 et IPv6. NCSI mène les sondes actives pour les deux en parallèle, et la réussite de l’une suffit pour conclure à une connexion à Internet. Le fait que l’une des deux ne soit pas « Internet » ne signifie pas à soi seul que tout le PC est hors ligne. Laquelle des deux une application donnée a utilisée, vous l’observez séparément pour ce trafic.1

Si vous voulez comparer en déconnectant le VPN, faites-le sur une machine de test approuvée par votre organisation ou durant une fenêtre de changement approuvée. Ne déconnectez pas un VPN permanent sans autorisation simplement pour enquêter.

3. La première séparation est « seulement l’affichage, ou le trafic aussi ? »

Une fois les causes candidates connues, appliquez-les à vos propres symptômes. Confirmez d’abord si du trafic nouveau fonctionne à l’instant, par exemple en ouvrant une nouvelle page sur un site que vous avez le droit d’utiliser. Un écran ouvert depuis tout à l’heure ne vous dit rien de l’état actuel de la connexion.

Au lieu de « le réseau fonctionne », soyez assez précis pour écrire « à cette heure, dans cette application, vers cette destination, cette opération a réussi ». Cela circonscrit ce qu’il faut examiner.

Ce qui se passe maintenant Où vérifier en premier
Ni le web ni l’application métier ne fonctionnent Ne vous limitez pas à NCSI ; vérifiez la configuration IP, le DNS, le routage et l’authentification d’usage
Le web fonctionne, mais seul Windows dit « Pas d’Internet » Regardez la destination de vérification NCSI et les traces de l’échec de ce trafic
L’affichage ne change que lorsque le VPN est connecté Comparez cartes réseau, IPv4/IPv6, DNS et routes avant et après la connexion
Un écran d’authentification apparaît après avoir rejoint le Wi-Fi Terminez l’authentification d’usage officielle, puis vérifiez le trafic et la réévaluation
Le HTTP manuel réussit, mais NCSI échoue Examinez les différences d’heure, de compte d’exécution, de proxy et de route
Windows indique « Internet », mais une application échoue Examinez la destination, l’authentification, TLS et les délais d’expiration de cette application

Ce n’est pas un tableau qui identifie la cause ; c’est un tableau pour choisir où vérifier ensuite. Même si une anomalie d’affichage est à l’origine de la démarche, si l’application métier que vous voulez utiliser échoue, consignez aussi ce résultat de trafic séparément.

À partir d’ici viennent les étapes d’investigation. Procédez dans cet ordre : capturer l’état, lire les paramètres de destination de vérification, comparer avec du trafic manuel, puis confirmer avec les traces propres à NCSI. Ne modifiez pas les paramètres de proxy, de VPN ou de sécurité de l’entreprise sans autorisation ; commencez par une inspection en lecture seule et un petit nombre de vérifications de trafic.

4. Avant de modifier des paramètres, établissez où cela a échoué

4.1 Consigner l’heure de survenue et l’état de la connexion

Consignez d’abord l’heure de survenue, la build du système, votre mode de connexion, l’usage éventuel d’un VPN et l’application qui échoue. Vous pouvez vérifier la version du système avec winver. Affichez ensuite les profils de connexion dans PowerShell.5

Get-Date -Format o
Get-NetConnectionProfile |
    Select-Object Name, InterfaceAlias, InterfaceIndex,
        NetworkCategory, IPv4Connectivity, IPv6Connectivity |
    Format-Table -AutoSize

Ce qu’il faut lire, c’est le nom de la connexion, InterfaceAlias et InterfaceIndex, ainsi que IPv4Connectivity et IPv6Connectivity. Lorsqu’il y a plusieurs lignes, lisez-les en gardant trace de la connexion à laquelle appartient chaque résultat. L’objectif est de comparer des résultats de la même heure et de la même connexion avec les tests manuels et les journaux qui suivent.

Les valeurs Public / Private / DomainAuthenticated de NetworkCategory sont un classement distinct du verdict de connectivité à Internet. Passer de Public à Private n’est pas une étape de réparation générale pour « Pas d’Internet ». La sortie peut contenir des éléments comme des noms de réseaux internes : masquez toute information d’identification inutile avant de la transmettre à un tiers.5

4.2 Lire quelle destination ce PC est configuré pour vérifier

Avant d’essayer la destination de vérification standard, confirmez si ce PC utilise les mêmes paramètres. Le code suivant se contente d’afficher des valeurs ; il ne modifie pas le registre. Il lit les destinations de vérification côté IPv4 et côté IPv6 et le corps attendu, ainsi que les stratégies qui contrôlent des éléments tels que le test actif.17

$internetKey = 'HKLM:\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet'
Get-ItemProperty -LiteralPath $internetKey |
    Select-Object EnableActiveProbing, ActiveWebProbeHost,
        ActiveWebProbePath, ActiveWebProbeContent,
        ActiveWebProbeHostV6, ActiveWebProbePathV6,
        ActiveWebProbeContentV6 |
    Format-List

$policyKey = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator'
if (Test-Path -LiteralPath $policyKey) {
    Get-ItemProperty -LiteralPath $policyKey |
        Select-Object NoActiveProbe, DisablePassivePolling |
        Format-List
} else {
    'Il n''y a aucune stratégie NCSI à ce chemin de registre.'
}

ActiveWebProbeHost et ActiveWebProbePath sont la destination de vérification, et ActiveWebProbeContent le corps attendu. Consignez aussi les valeurs dont le nom comporte V6. Si une destination de vérification personnalisée est configurée, alignez les tests manuels ci-dessous sur ce paramètre et sur votre politique de gestion.

Une sortie indiquant qu’il n’y a pas de clé de stratégie signifie qu’il n’y a pas de paramètres à ce chemin. Ce n’est pas la preuve qu’aucune configuration de gestion n’existe, y compris via MDM. Ne devinez pas et ne créez pas une clé que vous n’avez pas trouvée ; confirmez auprès de votre administrateur.

Pour les proxys, vérifiez les écrans de paramètres Windows et les stratégies de gestion. Pour les paramètres WinHTTP, netsh winhttp show advproxy dans les environnements qui le prennent en charge, ou netsh winhttp show proxy dans les environnements plus anciens, vous donne matière à comparaison. Ce que vous y apprenez, toutefois, est la configuration. La route que NCSI a réellement choisie via PAC ou détection automatique doit être mise en regard des traces de trafic décrites plus loin.84

4.3 Séparer la résolution du nom de l’établissement de la connexion TCP

À partir d’ici viennent les tests manuels de comparaison vers la destination de vérification standard. Ce que vous voulez savoir, c’est si le nom de la destination ne peut pas être résolu, ou si les choses s’arrêtent à la connexion qui suit. Vérifiez d’abord séparément la résolution de nom et la connexion TCP.

Resolve-DnsName -Name 'www.msftconnecttest.com' -Type A -DnsOnly
Test-NetConnection -ComputerName 'www.msftconnecttest.com' -Port 80 -InformationLevel Detailed

Le -Type A de Resolve-DnsName indique de rechercher l’adresse IPv4. Observez d’abord avec vos paramètres DNS habituels en place. Basculer directement vers un serveur DNS public change aussi la résolution de noms internes et votre politique de gestion, ce qui rend le problème initial plus difficile à suivre.9

Ce que Test-NetConnection -Port 80 vous indique, c’est la connexion TCP vers la destination donnée. Il ne vérifie ni le corps HTTP ni l’authentification du proxy. Dans un environnement où les connexions directes sont interdites et où seul le trafic passant par un proxy HTTP est autorisé, un échec de ce test TCP peut être normal. Sauvegardez aussi InterfaceAlias et SourceAddress, et confirmez de quel chemin est venu le résultat.6

Les questions auxquelles répondent les tests manuelsLa résolution de nom, la connexion TCP et la réponse HTTP couvrent des périmètres différents : ne traitez donc pas la réussite de l'une comme une garantie pour la couche suivante.Résoudre le nom par DNSVérifier la connexion TCP vers la destinationVérifier la réponse HTTP et le corpsComparer aux traces propres à NCSIUn autre chemin où un proxy est obligatoire

Figure 6 : La résolution de nom, la connexion TCP et la réponse HTTP confirment chacune une chose différente, dans cet ordre.

4.4 Avec HTTP, regardez le corps, pas seulement le statut

Regardez ensuite si le corps de vérification décrit au chapitre 1 revient. Sur une machine où curl.exe est disponible, exécutez la commande suivante un petit nombre de fois. Écrivez le .exe pour ne pas le confondre avec l’alias PowerShell.

curl.exe -q --connect-timeout 5 --max-time 15 --include 'http://www.msftconnecttest.com/connecttest.txt'

--include est l’option qui affiche les en-têtes avec le corps. Des délais d’expiration sont fixés pour la connexion et pour l’opération dans son ensemble, et comme -L n’est pas donné, curl ne suit pas automatiquement une redirection, ce qui vous permet de voir la première réponse. Le -q initial demande à curl de ne pas lire son fichier de configuration par défaut, mais il n’efface pas les variables d’environnement liées aux proxys.10

Un exemple minimal du contenu attendu suit. Il est donné à titre d’explication ; ce n’est pas un journal mesuré pour cet article. En pratique, d’autres en-têtes sont présents.2

HTTP/1.1 200 OK
...

Microsoft Connect Test
Résultat obtenu Ce qu’il faut regarder ensuite
Aucune réponse Où cela s’est arrêté : résolution de nom, connexion ou délai dépassé
Une redirection telle que 302 Vers où elle redirige, et si l’authentification d’usage reste à faire
403 Qui a renvoyé le refus, et s’il existe une trace de blocage du trafic vers la destination de vérification
407 Si un proxy demande une authentification
200, mais le corps est un écran de connexion ou assimilé Qui renvoie un contenu qui n’est pas le fichier de vérification
Le statut et le corps attendus Cette requête manuelle a réussi. Comparez ensuite aux traces propres à NCSI

Ce qui compte ici, c’est que le test manuel ne remplace pas NCSI ; c’est matière à comparaison. curl n’est pas un test qui hérite des paramètres PAC de Windows ou de l’état d’authentification du navigateur de la même façon. Un résultat « le navigateur a réussi, curl a échoué » n’établit pas à lui seul un dysfonctionnement de NCSI.

Confirmez auprès de votre administrateur la manière dont les proxys doivent être utilisés, et n’écrivez pas d’identifiants directement dans votre historique de commandes. Et même si cette vérification HTTP réussit, ce n’est pas une garantie que HTTPS et l’authentification d’une API métier réussiront.

4.5 Enfin, cherchez les traces de l’échec réel de NCSI

Une fois que les tests manuels ont fait apparaître des pistes, vérifiez le comportement propre à NCSI. La porte d’entrée est l’Observateur d’événements, sous Journaux des applications et des services → Microsoft → Windows → NCSI. Consultez le journal Opérationnel autour de l’heure de survenue.11

Plutôt qu’une seule ligne d’erreur, lisez la suite : sur quelle interface cela a démarré et si cela s’est terminé, quelle était la raison de l’échec et comment l’état de connectivité a changé ensuite. Mettez en regard la même heure et le même chemin que les tests manuels, et combinez au besoin avec une capture de paquets approuvée.11

L'ordre dans lequel lire les journaux NCSIReliez le démarrage, la fin, la raison de l'échec et le changement d'état par l'heure et l'interface.Sur quel chemin cela a démarréSi cela s'est terminéCode de résultat et raison de l'échecL'état de connectivité ensuiteMettre en regard des traces de trafic de la même heure

Figure 7 : Relier le démarrage jusqu’au changement d’état facilite le repérage de ce qui différait entre le test manuel et NCSI.

Si le code de résultat est une erreur WinHTTP, cherchez sa signification dans la table WinHTTP. Par exemple, 12007 signifie que le nom n’a pas pu être résolu, et 12002 est un délai dépassé. Ce que vous apprenez, toutefois, est un indice sur l’étape qui a échoué ; cela seul n’établit pas qu’un serveur DNS est en panne ni que la ligne est coupée.12

Si le détail est insuffisant, un administrateur active le journal Analytique via « Afficher les journaux d’analyse et de débogage ». C’est une modification des paramètres de diagnostic : notez l’heure d’activation, reproduisez le problème et rétablissez l’état initial après la collecte. L’activation ne permet pas de récupérer des événements détaillés antérieurs à celle-ci.11

Par ailleurs, reconnecter le Wi-Fi ou désactiver une carte pour reproduire le problème peut couper des connexions d’administration telles que RDP. Ne le faites pas sans prévenir sur une machine de production ou sur une machine que vous pilotez à distance. Les traces de trafic peuvent contenir des noms d’hôtes, des adresses IP et des informations liées à l’authentification : restreignez donc leur lieu de stockage et les personnes avec qui elles sont partagées.

Dans l’exemple d’entreprise du début, c’est ici que vous mettez en regard le 403 du HTTP manuel, le journal NCSI de la même heure et les traces de refus du proxy que votre administrateur peut consulter. Si seule la destination de vérification était refusée, corrigez cette règle et retestez. Si seul le test manuel a emprunté un autre chemin, revoyez les conditions de comparaison. Ne décidez pas à partir du seul nombre 403 qu’il s’agit d’« un bogue de NCSI » ou d’« un problème de notre proxy » ; choisissez l’action suivante d’après les traces. C’est un exemple d’isolement hypothétique, non le résultat d’une mission réelle.

5. N’essayez pas de réparer seulement l’affichage avec de vieux contournements

Ne confondez pas le trafic DNS de Windows 11 avec l’ancienne sonde DNS

D’anciens articles mettent en avant une sonde DNS vers dns.msftncsi.com. La FAQ officielle de NCSI explique toutefois que la sonde active à partir de Windows 11 utilise HTTP. Même lorsqu’une trace Windows 11 contient du trafic DNS, il peut s’agir de la résolution de nom de la destination HTTP.2

Distinguer le rôle du trafic DNSLisez la résolution de nom de la destination HTTP sous Windows 11 et l'ancienne sonde DNS comme deux choses différentes.Il y a du trafic DNS dans la traceÀ quoi sert ce traficRésolution de nom de la destination HTTPL'ancienne sonde DNSPeut être nécessaire sous Windows 11 aussiVérifier la version du système et les journaux réels

Figure 8 : Le trafic DNS qui recherche la destination HTTP et la sonde DNS elle-même sont deux choses différentes.

L’explication ancienne selon laquelle « toute requête DNS distincte de HTTP doit réussir » ne peut donc pas devenir une règle commune à toutes les versions de Windows. Lisez la version du système que vous examinez en regard des journaux réels.

Autre point prêtant à confusion : le nom de l’emplacement des paramètres. Sous Windows 11, le composant qui exécute NCSI est passé du NLA traditionnel au Gestionnaire de listes de réseaux, mais des paramètres tels que la destination de vérification utilisent toujours le chemin de registre contenant NlaSvc du chapitre 4. Ne décidez pas quel service l’exécute au seul motif que le chemin dit NlaSvc.1

Arrêter la vérification ne répare pas un trafic qui ne passait pas

Mettre EnableActiveProbing à 0, ou interdire le test actif par stratégie, sont des paramètres qui restreignent la vérification de connectivité. Ce ne sont pas des opérations qui réparent une panne de DNS ou une route de proxy. Gardez distincts le fait d’adopter cela comme politique de gestion pour un réseau isolé et celui de le modifier pour faire disparaître un avertissement. Microsoft ne recommande pas non plus la désactivation de la sonde active comme solution aux problèmes NCSI.71

Pour la même raison, renvoyer une fausse réponse de réussite, désactiver le pare-feu en bloc ou désactiver IPv6 sans fondement ne sont pas des premières étapes. Que l’affichage change et que le trafic que vous voulez utiliser s’améliore sont deux choses différentes.

Ne jugez pas une réparation d'après le seul affichageAprès une modification de configuration, confirmez non seulement le changement d'affichage mais aussi le point d'échec et l'amélioration du trafic dont vous avez besoin.Une modification fondéeRevérifier le trafic de vérification de connectivitéRevérifier le trafic dont vous avez besoinJuger l'amélioration à partir des deux résultats

Figure 9 : Même après une modification fondée, confirmez à la fois le trafic de vérification et le trafic que vous voulez utiliser.

Lorsque vous corrigez les règles d’autorisation de l’entreprise, ne vous contentez pas non plus d’enregistrer statiquement les adresses IP d’un vieil article. L’infrastructure de diffusion derrière la destination de vérification publique de NCSI peut changer, et Microsoft déconseille les règles d’autorisation qui dépendent d’adresses IP précises. Élaborez avec votre administrateur des règles qui correspondent à la destination de vérification, au service et à la route réels.2

6. Pour les développeurs : ne décidez pas de « ne pas communiquer » d’après NCSI seul

Tout ce qui précède concerne aussi la conception d’applications Windows. Si le système indique « Pas d’Internet » et que vous marquez de ce fait l’application hors ligne sans tenter ne serait-ce qu’une fois la requête nécessaire, vous bloquez peut-être un trafic qui fonctionnerait vraiment. Inversement, croire qu’une API métier réussira forcément parce que le système indique « Internet » est aussi une erreur.

INetworkListManager::get_IsConnectedToInternet, qui récupère le verdict de connectivité à l’échelle du système, est une API qui renvoie l’état de connectivité Internet de la machine locale. Elle ne garantit pas qu’une API ou un partage de fichiers donné fonctionne, que l’authentification réussisse ni que vous ayez le droit de l’utiliser.13

En termes de conception, cela se résume ainsi : utilisez l’état de connectivité du système comme indication pour l’affichage et la reconnexion, et gérez séparément la réussite ou l’échec du trafic dont vous avez besoin. L’objectif est de pouvoir tenir deux faits à la fois : « le verdict de Windows est LocalNetwork, et l’API métier était joignable ».

Gérer séparément le verdict du système et le résultat du trafic métierUtilisez l'information de connectivité du système comme indication et donnez au trafic dont vous avez besoin sa propre gestion indépendante de la réussite et de l'échec.État de connectivité du systèmeIndication pour l'affichage et la reconnexionLa requête dont vous avez besoinLe résultat réelTraiter comme une réussiteConsigner la raison de l'échecRéessayer après avoir confirmé que c'est sûr

Figure 10 : Utilisez le verdict du système comme indication tout en donnant au trafic métier sa propre gestion de la réussite et de l’échec.

Ne réduisez pas non plus le journal au seul mot « hors ligne » ; consignez l’étape de l’échec que vous avez pu observer, par exemple DNS, la connexion, TLS, l’authentification ou la réponse HTTP. Donnez aux requêtes des délais d’expiration et une possibilité d’annulation pour que l’interface ne reste pas en attente.

Réessayer après un délai dépassé appelle toutefois une mise en garde distincte. Une opération de mise à jour telle qu’une commande ou un virement peut déjà avoir été exécutée à l’autre bout même si la réponse n’est pas arrivée à temps. Ne décidez pas « le délai est dépassé, donc cela n’a pas eu lieu » pour renvoyer la requête ; faites de la question de l’autorisation d’une reprise, du mécanisme empêchant les doublons et de la consultation du résultat une partie de la spécification de l’application. Ce n’est pas un problème que NCSI résoudra pour vous.

7. Résumé : lisez l’affichage et le trafic comme des faits distincts

« Le réseau fonctionne mais Windows dit Pas d’Internet » n’est pas nécessairement une contradiction. Se connecter au Wi-Fi, communiquer avec l’interlocuteur voulu et le verdict NCSI propre à Windows vérifient chacun quelque chose de différent.

Séparez d’abord le cas où seul l’affichage diverge de celui où le trafic dont vous avez besoin échoue aussi. Lors de l’investigation, utilisez les paramètres de destination de vérification et les tests manuels comme matière à comparaison, et confirmez le comportement réel dans les journaux propres à NCSI. Et après une modification, regardez au-delà de l’icône si le trafic de vérification et le trafic dont vous avez besoin se sont améliorés.

De « ça devrait être connecté » à « quel trafic a échoué, et où ». Penser dans cet ordre permet de circonscrire où chercher avant de modifier des paramètres au hasard.

Articles liés

Liens de référence

Vérifié le 11 septembre 2026. Pour les différences entre versions du système, la FAQ officielle propre à NCSI prévaut, et les procédures de la documentation ancienne orientée client ne sont pas traitées comme une spécification figée pour Windows 11. Vérifiez aussi les noms affichés des journaux et les commandes disponibles au regard de votre build réelle et de votre configuration de gestion.

  1. Microsoft Learn, NCSI overview. Les sondes active et passive, le composant qui exécute NCSI sous Windows 11, l’emplacement des paramètres, IPv4 et IPv6, et les mises en garde sur la désactivation. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. Microsoft Learn, Answers to common questions about NCSI. La sonde HTTP sous Windows 11, la destination de vérification, les pistes d’échec telles que le VPN et le DNS, et les mises en garde sur les règles d’autorisation fondées sur des adresses IP fixes. ↩ ↩2 ↩3 ↩4 ↩5

  3. Microsoft Learn, An Internet Explorer or Edge window opens when your computer connects to a corporate network or a public network. Les portails d’authentification et le navigateur qui s’ouvre, ainsi que la réponse HTTP utilisée pour la vérification. Cité comme explication couvrant aussi les versions antérieures. ↩ ↩2

  4. Microsoft Learn, WinHTTP AutoProxy Support. Où se situent PAC et la détection automatique de proxy. ↩ ↩2

  5. Microsoft Learn, Get-NetConnectionProfile. Les profils de connexion, NetworkCategory et les états IPv4 et IPv6. ↩ ↩2 ↩3

  6. Microsoft Learn, Test-NetConnection. Le diagnostic de la connexion TCP, de la route et de l’adresse source. ↩ ↩2

  7. Microsoft Learn, Connectivity Policy CSP. La stratégie de gestion qui contrôle les tests actifs de NCSI. ↩ ↩2

  8. Microsoft Learn, Netsh.exe commands. L’affichage des paramètres de proxy WinHTTP. Utilisez show advproxy dans les environnements qui le prennent en charge. ↩

  9. Microsoft Learn, Resolve-DnsName. Le périmètre de la requête DNS et ses paramètres. ↩

  10. curl project, curl man page. La suppression du fichier de configuration, les délais d’expiration, l’affichage des en-têtes et le traitement des redirections et des proxys. ↩

  11. Microsoft Learn, How to collect data to diagnose NCSI issues. La mise en regard des journaux Opérationnel et Analytique avec les traces de trafic. ↩ ↩2 ↩3

  12. Microsoft Learn, Error Messages (Winhttp.h). La signification des codes de résultat WinHTTP. ↩

  13. Microsoft Learn, INetworkListManager::get_IsConnectedToInternet. L’API qui récupère l’état de connectivité Internet du système. ↩

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi Windows affiche-t-il « Pas d'Internet » alors que je suis connecté au Wi-Fi ?
Parce que se connecter au Wi-Fi, communiquer avec le service voulu et le verdict de connectivité auquel Windows aboutit via NCSI sont trois choses distinctes. L'affichage peut diverger non seulement quand la ligne elle-même est coupée, mais aussi à cause de problèmes de DNS, de proxy, de VPN ou de portail captif qui touchent le trafic de vérification. Commencez par établir ce qui peut réellement communiquer.
Si un site s'ouvre dans le navigateur, puis-je conclure que NCSI va bien aussi ?
Non. La destination, le proxy sélectionné, l'état d'authentification, IPv4 contre IPv6 et l'heure de la requête peuvent tous différer. Traitez l'accès manuel comme matière à comparaison et confirmez avec les journaux d'événements propres à NCSI et, au besoin, une capture de paquets.
Une sonde DNS vers dns.msftncsi.com est-elle encore nécessaire sous Windows 11 ?
La FAQ officielle de NCSI explique que la sonde active à partir de Windows 11 utilise HTTP. Distinguez le trafic DNS qui résout la destination HTTP de la sonde DNS des versions antérieures. L'important est de ne pas supposer globalement que chaque requête d'une procédure ancienne est obligatoire.
Mettre EnableActiveProbing à 0 réglera-t-il le problème ?
Ce paramètre arrête le trafic de vérification ; ce n'est pas un paramètre qui répare une cause telle que le DNS ou le routage. Sauf si vous l'adoptez comme politique de gestion pour un réseau isolé, par exemple, ne le modifiez pas pour faire disparaître l'affichage : cherchez d'abord où se produit l'échec.
Si NCSI indique « Internet », suis-je certain d'atteindre nos systèmes métier ?
Pas nécessairement. Le verdict de connectivité du système d'exploitation ne garantit pas qu'une API ou un partage de fichiers donné fonctionne, que l'authentification réussisse ni que vous ayez le droit de l'utiliser. Une application doit émettre le trafic dont elle a réellement besoin et gérer les délais d'expiration, l'annulation, le type d'échec et la question de savoir si une reprise est sûre.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.

Nous contacter
Retour au blog