KomuraSoft LLC
Contatti
Menu

La rete funziona ma Windows dice «Nessuna connessione Internet» — Circoscrivere NCSI, DNS, proxy e VPN su Windows

· · Windows, Sviluppo Windows, Rete, NCSI, DNS, Proxy, VPN, PowerShell

I siti web si aprono. I messaggi di chat passano. Eppure solo la visualizzazione di Windows dice «Nessuna connessione Internet».

Verrebbe da pensare: «sto usando la rete proprio adesso, allora perché dice che non c’è?» Una ragione c’è. Windows ha un proprio controllo di connettività, e il suo risultato è separato dal risultato del traffico che l’applicazione che state usando in questo momento sta inviando. I vostri soliti siti possono essere raggiungibili mentre solo la destinazione contro cui Windows effettua il controllo non lo è.1

Quindi, prima di eliminare le impostazioni Wi-Fi o di reimpostare l’intera rete, separate la domanda: è sbagliata solo la visualizzazione, oppure sta fallendo anche il traffico che volete usare?

Questo articolo spiega prima il meccanismo dietro la discrepanza, poi passa alle situazioni comuni, alla lettura per sintomo e ai passi concreti di analisi. Se vi interessa il meccanismo, leggete fino al capitolo 3 incluso; se state indagando, leggete i capitoli 4 e 5; chi sviluppa applicazioni Windows legga anche il capitolo 6. È incentrato su Windows 11 e copre anche le differenze rispetto a Windows 10, e gli esempi usano Windows PowerShell 5.1 e curl.exe.

1. Windows non guarda soltanto il sito che state visitando adesso

Immaginate di aprire il vostro sito abituale su un PC aziendale. Se il browser riesce a dialogare con quel sito, la pagina compare. Separatamente da questo, Windows va a recuperare un piccolo file usato per il controllo di connettività.

Ora, che cosa accadrebbe se la rete aziendale fosse configurata per consentire il traffico verso i siti che le persone usano normalmente ma non il traffico verso la destinazione del controllo di connettività? Il traffico del browser riesce mentre il traffico di controllo di Windows fallisce. Anche sullo stesso PC, se ciò contro cui si effettua il controllo è diverso, i risultati possono divergere.1

Un esempio in cui il sito web funziona e fallisce solo il controllo di connettivitàUn esempio ipotetico in cui il browser sullo stesso PC raggiunge il sito abituale mentre la richiesta di controllo NCSI non raggiunge una destinazione di controllo diversa. Non è un diagramma che stabilisce lo stato finale di NCSI da una singola richiesta.Lo stesso PCTraffico del browserTraffico di controllo della connettività di WindowsSito web abitualela pagina si apreDestinazione del controllo di connettivitàfallisce solo questo traffico

Figura 1: Un esempio ipotetico per capire il meccanismo. Traffico quotidiano e controllo di connettività si rivolgono a interlocutori diversi.

Il componente responsabile di questo verdetto di connettività è NCSI (Network Connectivity Status Indicator). Decide se esista una connessione a Internet o solo connettività locale, e fornisce le informazioni usate dalla visualizzazione dello stato della rete e dalle applicazioni. Non sta monitorando se un singolo sito web o un sistema gestionale sia attivo.1

Guardate se torna il contenuto di controllo, non se è tornato qualcosa

Da Windows 10 versione 1607, la destinazione standard del controllo HTTP è il seguente URL. Il corpo atteso è Microsoft Connect Test. Sui PC gestiti dalle aziende la destinazione di controllo viene talvolta cambiata.2

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

Se andate a recuperare questo file e torna una schermata di accesso di un hotel o una pagina di blocco aziendale, allora qualcosa è effettivamente arrivato dalla destinazione, ma non è il risultato di controllo atteso. Anche quando lo stato HTTP è 200, il corpo non è necessariamente lo stesso.3

Che cosa verifica la sonda HTTPPer la richiesta alla destinazione di controllo, guardate se tornano la risposta e il corpo attesi.NoSìSìNoRichiesta HTTP alla destinazione di controlloÈ stata ricevuta una rispostaAnalizzare il trasferimento incompleto o l'erroreSono la risposta e il corpo attesiElemento a favore di un verdetto «connesso»Analizzare autenticazione, blocco o contenuto modificato

Figura 2: Tenete distinti «ricevere una risposta dalla destinazione di controllo» e «riottenere il contenuto atteso».

Notate che NCSI non si regge solo su questo traffico di controllo. Il metodo con cui verifica di propria iniziativa si chiama sonda attiva, quello con cui giudica da informazioni come i pacchetti ricevuti si chiama sonda passiva; li usa entrambi. Una richiesta HTTP fallita nel diagramma non equivale quindi a uno stato di connettività finale senza Internet.1

Il punto fin qui è che connettersi al Wi-Fi, poter usare un dato sito e ottenere da Windows un verdetto «Internet» sono ciascuno un controllo a sé. Essere connessi al Wi-Fi non dice nulla sul percorso verso l’esterno né sull’autenticazione d’uso, e raggiungere un sito non garantisce che un’altra destinazione o un’altra applicazione funzionino.

Nel diagramma, una linea continua indica una relazione che vale sempre e una linea tratteggiata indica una relazione condizionale (le condizioni sono nella spiegazione di ciascuna relazione nella pagina di dettaglio). L’elenco completo delle relazioni (in totale 5, con evidenza e livello di certezza) e le definizioni dei concetti principali sono raccolti nella pagina di dettaglio della mappa della conoscenza (in giapponese). Dati: JSON-LD / Turtle

2. Tre situazioni comuni in cui visualizzazione e traffico divergono

In ufficio, browser e controllo di connettività possono prendere percorsi diversi

Rendiamo un po’ più concreto l’esempio aziendale iniziale. Nelle reti aziendali esistono configurazioni in cui non si esce direttamente ma si passa per un relay chiamato proxy. Il meccanismo che sceglie quel relay in base all’URL visitato e a criteri analoghi è il file PAC. Talvolta si usa anche il rilevamento automatico.4

In questa configurazione può essere selezionato un proxy adatto per i siti usati di solito, mentre solo la destinazione del controllo di connettività cade fuori dalle regole. Anche i casi in cui il rilevamento del proxy non si completa in tempo, o in cui è bloccato solo il traffico HTTP verso la destinazione di controllo, sono piste da esaminare.1

Verificare separatamente il percorso del browser e quello di NCSIIl successo del traffico del browser non garantisce il successo di NCSI, che usa una destinazione diversa e una diversa selezione del proxy.Lo stesso PCRichiesta del browserRichiesta di controllo NCSIProxy e autenticazione per questa richiestaProxy e autenticazione per la richiesta di controlloSito web utilizzatoDestinazione del controllo di connettività

Figura 3: Trovarsi sullo stesso PC non significa necessariamente lo stesso percorso. Verificate destinazione, proxy e autenticazione per ciascuna richiesta.

Andate quindi oltre il fatto che il browser abbia avuto successo e scoprite quale proxy sia stato selezionato per la richiesta di NCSI e con quale account o quali condizioni di autenticazione abbia comunicato. Lo stesso vale per il controllo manuale con curl usato più avanti. Non trattare i tre come traffico in condizioni identiche è il punto di partenza per circoscrivere il problema.

In hotel, dopo essersi uniti al Wi-Fi può restare un accesso da fare

Nei Wi-Fi di hotel e luoghi simili, dopo che il collegamento radio è attivo può esservi chiesto di accettare condizioni d’uso o di effettuare l’accesso. Questo gateway di autenticazione è un portale captive. Se la richiesta di controllo viene reindirizzata alla pagina di autenticazione, o viene restituita una schermata di accesso, non diventa la normale risposta di controllo. Anche il fatto che Windows apra un browser per invitarvi ad accedere è legato a questo meccanismo.3

La differenza fra unirsi al Wi-Fi e autenticarsi al portaleAnche dopo la riuscita della connessione wireless, il traffico verso l'esterno può restare limitato finché l'autenticazione lato rete non è completata.Non completataCompletataConnesso al Wi-FiL'autenticazione d'uso è completataAutenticarsi dalla pagina ufficialeRicontrollare il traffico reale e il verdetto

Figura 4: Completare la connessione al Wi-Fi non significa aver completato l’autenticazione per usare quella rete.

Poiché esistono casi in cui è consultabile solo la pagina informativa della struttura, non concludete da una pagina che si apre che tutto il traffico in uscita sia consentito. Autenticatevi seguendo le istruzioni ufficiali della struttura e verificate poi il traffico reale e la visualizzazione di Windows. Non inserite dati di account o di carta in una schermata di accesso sospetta.

Con una VPN cambia «da quale connessione è arrivato il risultato»

Prima e dopo una connessione VPN, il percorso del traffico e le condizioni d’uso del DNS possono cambiare. Impostazioni non ancora attive subito dopo la connessione, o traffico di controllo che prende un percorso non previsto, sono anch’essi candidati per un fallimento di NCSI.2

In tal caso non vedete il PC come un unico stato connesso o non connesso: separate la LAN fisica o il Wi-Fi dalla VPN. Per esempio, se la progettazione prevede il lato fisico su LocalNetwork mentre uscite verso Internet dal lato VPN, una riga sul lato fisico non basta a dichiarare qualcosa di guasto. Leggete i profili di connessione del capitolo 4 insieme al percorso effettivamente usato.56

Separare il percorso di connessione e la famiglia IPSeparate la LAN fisica dalla VPN e IPv4 da IPv6, e associate a ciascun verdetto il percorso usato dal traffico.Elencare le connessioniLAN fisica e Wi-FiScheda VPNVerdetti IPv4 e IPv6Verdetti IPv4 e IPv6Confrontare con il percorso reale del traffico

Figura 5: Tenete distinti connessione fisica e VPN, IPv4 e IPv6, confrontando con il percorso reale del traffico.

Lo stesso vale per IPv4 e IPv6. NCSI esegue in parallelo le sonde attive per entrambi, e il successo di una delle due basta per concludere che c’è una connessione a Internet. Il fatto che una delle due non sia «Internet» non significa di per sé che l’intero PC sia offline. Quale delle due abbia usato una determinata applicazione lo osservate separatamente per quel traffico.1

Se volete confrontare disconnettendo la VPN, fatelo su una macchina di prova approvata dalla vostra organizzazione o durante una finestra di modifica approvata. Non disconnettete una VPN sempre attiva senza permesso solo per indagare.

3. La prima separazione è «solo la visualizzazione, o anche il traffico?»

Una volta note le cause candidate, applicatele ai vostri sintomi. Verificate prima se del traffico nuovo funziona in questo momento, per esempio aprendo una nuova pagina su un sito che vi è consentito usare. Una schermata aperta da prima non vi dice nulla sullo stato attuale della connessione.

Invece di «la rete funziona», siate abbastanza precisi da poter scrivere «a quest’ora, in questa applicazione, verso questa destinazione, questa operazione è riuscita». Ciò restringe che cosa indagare.

Che cosa sta accadendo ora Dove verificare per primo
Non funzionano né il web né l’applicazione gestionale Non limitatevi a NCSI; verificate configurazione IP, DNS, instradamento e autenticazione d’uso
Il web funziona, ma solo Windows dice «Nessuna connessione Internet» Guardate la destinazione di controllo NCSI e le registrazioni del fallimento di quel traffico
La visualizzazione cambia solo con la VPN connessa Confrontate schede, IPv4/IPv6, DNS e route prima e dopo la connessione
Dopo essersi uniti al Wi-Fi compare una schermata di autenticazione Completate l’autenticazione d’uso ufficiale, poi verificate traffico e rivalutazione
L’HTTP manuale riesce, ma NCSI fallisce Indagate su differenze di orario, account di esecuzione, proxy e route
Windows dice «Internet», ma un’applicazione fallisce Indagate su destinazione, autenticazione, TLS e timeout di quell’applicazione

Non è una tabella che individua la causa; è una tabella per scegliere dove verificare dopo. Anche se l’occasione è stata un’anomalia della visualizzazione, se l’applicazione gestionale che volete usare fallisce, registrate separatamente anche quel risultato di traffico.

Da qui in poi ci sono i passi di analisi. Procedete in quest’ordine: rilevare lo stato, leggere le impostazioni della destinazione di controllo, confrontare con traffico manuale, poi verificare con le registrazioni proprie di NCSI. Non modificate impostazioni aziendali di proxy, VPN o sicurezza senza permesso; iniziate con un’ispezione in sola lettura e un numero ridotto di prove di traffico.

4. Prima di cambiare impostazioni, stabilite dove è fallito

4.1 Registrare l’ora dell’evento e lo stato della connessione

Registrate anzitutto l’ora dell’evento, la build del sistema operativo, come siete connessi, se è in uso una VPN e quale applicazione fallisce. La versione del sistema si vede con winver. Visualizzate poi i profili di connessione in PowerShell.5

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

Ciò che va letto è il nome della connessione, InterfaceAlias e InterfaceIndex, oltre a IPv4Connectivity e IPv6Connectivity. Quando ci sono più righe, leggetele tenendo traccia di a quale connessione appartenga ciascun risultato. Il punto è confrontare risultati della stessa ora e della stessa connessione con i test manuali e i registri che seguono.

I valori Public / Private / DomainAuthenticated di NetworkCategory sono una classificazione separata dal verdetto di connettività a Internet. Passare da Public a Private non è un passo di riparazione generale per «Nessuna connessione Internet». L’output può contenere cose come nomi di reti interne: mascherate le informazioni identificative non necessarie prima di consegnarlo a terzi.5

4.2 Leggere quale destinazione questo PC è configurato per controllare

Prima di provare la destinazione di controllo standard, verificate se questo PC usa le stesse impostazioni. Il codice seguente si limita a visualizzare valori; non modifica il registro di sistema. Legge le destinazioni di controllo lato IPv4 e lato IPv6 e il corpo atteso, insieme ai criteri che controllano elementi come il test attivo.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 {
    'Non c''è alcun criterio NCSI in questo percorso del registro di sistema.'
}

ActiveWebProbeHost e ActiveWebProbePath sono la destinazione di controllo, e ActiveWebProbeContent è il corpo atteso. Registrate anche i valori con V6 nel nome. Se è configurata una destinazione di controllo personalizzata, allineate i test manuali qui sotto a quell’impostazione e al vostro criterio di gestione.

Un output che dice che non c’è alcun criterio significa che non ci sono impostazioni in quel percorso. Non è la prova che non esista alcuna configurazione di gestione, neppure tramite MDM. Non tirate a indovinare creando una chiave che non avete trovato; verificate con la vostra amministrazione.

Per i proxy, controllate le schermate delle impostazioni di Windows e i criteri di gestione. Per le impostazioni WinHTTP, netsh winhttp show advproxy negli ambienti che lo supportano, oppure netsh winhttp show proxy negli ambienti più vecchi, offre materiale di confronto. Ciò che apprendete lì, però, è la configurazione. Il percorso che NCSI ha effettivamente scelto tramite PAC o rilevamento automatico va confrontato con le registrazioni del traffico descritte più avanti.84

4.3 Separare se il nome si risolve dal se il TCP si connette

Da qui in poi ci sono test manuali di confronto verso la destinazione di controllo standard. Ciò che volete sapere è se il nome della destinazione non possa essere risolto, oppure se ci si fermi alla connessione successiva. Verificate prima separatamente la risoluzione del nome e la connessione TCP.

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

Il -Type A in Resolve-DnsName indica di cercare l’indirizzo IPv4. Osservate dapprima con le vostre impostazioni DNS abituali. Passare subito a un server DNS pubblico cambia anche la risoluzione dei nomi interni e il vostro criterio di gestione, il che rende più difficile seguire il problema originale.9

Ciò che Test-NetConnection -Port 80 vi dice è la connessione TCP verso la destinazione indicata. Non verifica il corpo HTTP né l’autenticazione del proxy. In un ambiente in cui le connessioni dirette sono vietate e in cui è consentito solo il traffico tramite un proxy HTTP, il fallimento di questo test TCP può essere normale. Salvate anche InterfaceAlias e SourceAddress e verificate da quale percorso sia arrivato il risultato.6

Le domande a cui rispondono i test manualiRisoluzione del nome, connessione TCP e risposta HTTP coprono ambiti diversi, quindi non trattate il successo di uno come garanzia per il livello successivo.Risolvere il nome con il DNSVerificare la connessione TCP verso la destinazioneVerificare risposta HTTP e corpoConfrontare con le registrazioni proprie di NCSIUn percorso diverso in cui un proxy è obbligatorio

Figura 6: Risoluzione del nome, connessione TCP e risposta HTTP verificano ciascuna una cosa diversa, in quest’ordine.

4.4 Con HTTP, guardate il corpo, non solo lo stato

Guardate poi se torna il corpo di controllo descritto nel capitolo 1. Su una macchina in cui curl.exe è disponibile, eseguite quanto segue poche volte. Scrivete per esteso il .exe per non confonderlo con l’alias di PowerShell.

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

--include è l’opzione che mostra le intestazioni insieme al corpo. Sono impostati timeout per la connessione e per l’operazione complessiva e, poiché -L non è indicato, non segue automaticamente un reindirizzamento, così potete vedere la prima risposta. Il -q iniziale dice a curl di non leggere il proprio file di configurazione predefinito, ma non azzera le variabili d’ambiente relative ai proxy.10

Segue un esempio minimo del contenuto atteso. È a scopo esplicativo; non è un registro misurato per questo articolo. In pratica sono presenti anche altre intestazioni.2

HTTP/1.1 200 OK
...

Microsoft Connect Test
Risultato ottenuto Che cosa guardare dopo
Nessuna risposta Dove si è fermato: risoluzione del nome, connessione o timeout
Un reindirizzamento come 302 Dove reindirizza e se l’autenticazione d’uso sia ancora in sospeso
403 Chi ha restituito il rifiuto e se esista una registrazione di blocco del traffico verso la destinazione di controllo
407 Se un proxy stia richiedendo un’autenticazione
200, ma il corpo è una schermata di accesso o simile Chi stia restituendo contenuti che non sono il file di controllo
Lo stato e il corpo attesi Questa richiesta manuale è riuscita. Confrontate poi con le registrazioni proprie di NCSI

Ciò che conta qui è che il test manuale non sostituisce NCSI; è materiale di confronto. curl non è un test che eredita le impostazioni PAC di Windows o lo stato di autenticazione del browser allo stesso modo. Un risultato «il browser è riuscito, curl no» da solo non dimostra un malfunzionamento di NCSI.

Verificate con la vostra amministrazione come vadano usati i proxy e non scrivete credenziali direttamente nella cronologia dei comandi. E anche se questo controllo HTTP riesce, non è una garanzia che riescano HTTPS e l’autenticazione di un’API gestionale.

4.5 Infine, cercate le registrazioni del fallimento reale di NCSI

Una volta che i test manuali hanno fatto emergere delle piste, verificate il comportamento proprio di NCSI. La porta d’ingresso è il Visualizzatore eventi, in Registri applicazioni e servizi → Microsoft → Windows → NCSI. Controllate il registro Operativo intorno all’ora dell’evento.11

Anziché una singola riga di errore, proseguite leggendo: su quale interfaccia è iniziato e se si è completato, quale fosse il motivo dell’errore e come sia cambiato in seguito lo stato di connettività. Confrontate alla stessa ora e sullo stesso percorso dei test manuali, e combinate se serve con una cattura di pacchetti approvata.11

L'ordine in cui leggere i registri di NCSICollegate avvio, completamento, motivo dell'errore e cambio di stato per orario e interfaccia.Su quale percorso è iniziatoSe si è completatoCodice di risultato e motivo dell'erroreLo stato di connettività successivoConfrontare con registrazioni di traffico della stessa ora

Figura 7: Collegare l’avvio fino al cambio di stato rende più facile capire che cosa differisse fra il test manuale e NCSI.

Se il codice di risultato è un errore WinHTTP, cercatene il significato nella tabella WinHTTP. Per esempio, 12007 significa che il nome non ha potuto essere risolto, e 12002 è un timeout. Ciò che apprendete, però, è un indizio sulla fase fallita; da solo non stabilisce che un server DNS sia guasto o che la linea sia caduta.12

Se il dettaglio non basta, un amministratore abilita il registro Analitico da «Visualizza registri analitici e di debug». È una modifica alle impostazioni di diagnostica: annotate l’ora di abilitazione, riproducete il problema e ripristinate lo stato originale dopo la raccolta. Abilitarlo non consente di recuperare eventi dettagliati precedenti all’abilitazione.11

Inoltre, riconnettere il Wi-Fi o disabilitare una scheda per riprodurre il problema può far cadere connessioni di gestione come RDP. Non eseguite queste operazioni senza preavviso su una macchina di produzione o su una macchina che state usando da remoto. Le registrazioni del traffico possono contenere nomi host, indirizzi IP e informazioni legate all’autenticazione: limitate quindi dove sono conservate e con chi sono condivise.

Nell’esempio aziendale iniziale, è qui che confrontate il 403 dell’HTTP manuale, il registro NCSI della stessa ora e le registrazioni di rifiuto del proxy che la vostra amministrazione può consultare. Se veniva rifiutata solo la destinazione di controllo, correggete quella regola e ripetete il test. Se solo il test manuale ha preso un percorso diverso, rivedete le condizioni di confronto. Non decidete dal solo numero 403 che si tratti di «un bug di NCSI» o di «un problema del nostro proxy»; scegliete l’azione successiva in base alle registrazioni. È un esempio ipotetico di circoscrizione, non il risultato di un incarico reale.

5. Non cercate di riparare solo la visualizzazione con vecchi espedienti

Non confondete il traffico DNS di Windows 11 con la vecchia sonda DNS

Scritti più vecchi presentano una sonda DNS verso dns.msftncsi.com. La FAQ ufficiale di NCSI spiega però che la sonda attiva da Windows 11 in poi usa HTTP. Anche quando in una registrazione di Windows 11 compare traffico DNS, può trattarsi della risoluzione del nome per la destinazione HTTP.2

Distinguere il ruolo del traffico DNSLeggete la risoluzione del nome per la destinazione HTTP di Windows 11 e la vecchia sonda DNS come cose diverse.Nella registrazione c'è traffico DNSA che cosa serve il trafficoRisoluzione del nome per la destinazione HTTPLa vecchia sonda DNSPuò servire anche su Windows 11Verificare la versione del sistema e i registri reali

Figura 8: Il traffico DNS che cerca la destinazione HTTP e la sonda DNS in sé sono cose diverse.

La vecchia spiegazione secondo cui «ogni query DNS separata da HTTP deve riuscire» non può quindi diventare una regola comune a tutte le versioni di Windows. Leggete la versione del sistema che state esaminando insieme ai registri reali.

Un altro punto che confonde è il nome della posizione delle impostazioni. Su Windows 11 il componente che esegue NCSI è passato dal tradizionale NLA al lato Gestione elenco reti, ma impostazioni come la destinazione di controllo usano ancora il percorso del registro con NlaSvc del capitolo 4. Non decidete quale servizio lo esegua solo perché il percorso dice NlaSvc.1

Fermare il controllo non ripara un traffico che non passava

Impostare EnableActiveProbing a 0, o vietare il test attivo tramite criterio, sono impostazioni che limitano il controllo di connettività. Non sono operazioni che riparano un guasto DNS o un percorso di proxy. Tenete distinti l’adottarlo come criterio di gestione per una rete isolata e il modificarlo per far sparire un avviso. Neppure Microsoft raccomanda di disattivare la sonda attiva come soluzione ai problemi di NCSI.71

Per lo stesso motivo, restituire una finta risposta di successo, spegnere in blocco il firewall o disattivare IPv6 senza fondamento non sono primi passi. Che la visualizzazione cambi e che il traffico che volete usare migliori sono due cose diverse.

Non giudicate una riparazione dalla sola visualizzazioneDopo una modifica alla configurazione, verificate non solo il cambiamento della visualizzazione ma anche il punto di errore e il miglioramento del traffico che vi serve.Una modifica fondataRicontrollare il traffico di controllo della connettivitàRicontrollare il traffico che vi serveGiudicare il miglioramento da entrambi i risultati

Figura 9: Anche dopo una modifica fondata, verificate sia il traffico di controllo sia il traffico che volete usare.

Anche quando correggete le regole di autorizzazione aziendali, non limitatevi a registrare staticamente gli indirizzi IP di un vecchio articolo. L’infrastruttura di distribuzione dietro la destinazione di controllo pubblica di NCSI può cambiare, e Microsoft sconsiglia regole di autorizzazione che dipendono da indirizzi IP specifici. Elaborate con la vostra amministrazione regole che corrispondano a destinazione di controllo, servizio e percorso reali.2

6. Per chi sviluppa: non decidete «non comunicare» dal solo NCSI

Tutto quanto precede riguarda anche la progettazione di applicazioni Windows. Se il sistema operativo dice «Nessuna connessione Internet» e voi per questo segnate l’applicazione come offline senza tentare nemmeno una volta la richiesta che vi serve, potreste fermare traffico che in realtà funzionerebbe. Al contrario, è un errore anche pensare che un’API gestionale debba riuscire perché il sistema dice «Internet».

INetworkListManager::get_IsConnectedToInternet, che recupera il verdetto di connettività a livello di sistema, è un’API che restituisce lo stato di connettività a Internet della macchina locale. Non garantisce che una singola API o condivisione di file sia attiva, che l’autenticazione riesca o che abbiate il permesso di usarla.13

In termini di progettazione si riassume così: usate lo stato di connettività del sistema come suggerimento per la visualizzazione e la riconnessione, e gestite separatamente l’esito del traffico che vi serve. L’obiettivo è poter tenere insieme due fatti: «il verdetto di Windows è LocalNetwork, e l’API gestionale era raggiungibile».

Gestire separatamente il verdetto del sistema e l'esito del traffico gestionaleUsate l'informazione di connettività del sistema come suggerimento e date al traffico che vi serve una gestione indipendente di successo e fallimento.Stato di connettività del sistemaSuggerimento per visualizzazione e riconnessioneLa richiesta che vi serveL'esito realeTrattare come successoRegistrare il motivo dell'erroreRitentare dopo aver verificato che sia sicuro

Figura 10: Usate il verdetto del sistema come suggerimento dando al traffico gestionale una propria gestione di successo e fallimento.

Non riducete il registro alla sola parola «offline»; annotate la fase dell’errore che siete riusciti a osservare, per esempio DNS, connessione, TLS, autenticazione o risposta HTTP. Date alle richieste timeout e possibilità di annullamento, così che l’interfaccia non resti in attesa.

Ritentare dopo un timeout comporta però un’avvertenza a parte. Un’operazione di modifica come un ordine o un bonifico può essere già stata eseguita dall’altra parte anche se la risposta non è arrivata in tempo. Non decidete «è andato in timeout, quindi non è stato eseguito» e inviate di nuovo; rendete parte della specifica dell’applicazione la questione se un ritentativo sia consentito, il meccanismo che impedisce i duplicati e la consultazione dell’esito. Non è un problema che NCSI risolverà per voi.

7. Riepilogo: leggete visualizzazione e traffico come fatti distinti

«La rete funziona ma Windows dice Nessuna connessione Internet» non è necessariamente una contraddizione. Connettersi al Wi-Fi, comunicare con l’interlocutore desiderato e il verdetto NCSI proprio di Windows verificano ciascuno qualcosa di diverso.

Separate prima il caso in cui diverge solo la visualizzazione da quello in cui fallisce anche il traffico che vi serve. Nell’analisi usate le impostazioni della destinazione di controllo e i test manuali come materiale di confronto, e verificate il comportamento reale nei registri propri di NCSI. E dopo una modifica, guardate oltre l’icona per capire se traffico di controllo e traffico necessario siano migliorati.

Da «dovrebbe essere connesso» a «quale traffico è fallito, e dove». Ragionare in quest’ordine consente di circoscrivere dove guardare prima di mettersi a cambiare impostazioni a caso.

Articoli correlati

Verificato l’11 settembre 2026. Per le differenze fra versioni del sistema operativo prevale la FAQ ufficiale specifica di NCSI, e le procedure della documentazione più vecchia orientata ai client non sono trattate come specifica fissa per Windows 11. Verificate inoltre i nomi visualizzati dei registri e i comandi disponibili rispetto alla vostra build effettiva e alla vostra configurazione di gestione.

  1. Microsoft Learn, NCSI overview. Sonde attive e passive, il componente che esegue NCSI su Windows 11, dove risiedono le impostazioni, IPv4 e IPv6 e le avvertenze sulla disattivazione. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9

  2. Microsoft Learn, Answers to common questions about NCSI. La sonda HTTP su Windows 11, la destinazione di controllo, le piste di errore come VPN e DNS e le avvertenze sulle regole di autorizzazione basate su indirizzi IP fissi. ↩ ↩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. I portali di autenticazione e il browser che si apre, e la risposta HTTP usata per il controllo. Citato come spiegazione che copre anche le versioni precedenti. ↩ ↩2

  4. Microsoft Learn, WinHTTP AutoProxy Support. Dove si collocano PAC e il rilevamento automatico del proxy. ↩ ↩2

  5. Microsoft Learn, Get-NetConnectionProfile. I profili di connessione, NetworkCategory e gli stati IPv4 e IPv6. ↩ ↩2 ↩3

  6. Microsoft Learn, Test-NetConnection. La diagnostica per connessione TCP, percorso e indirizzo di origine. ↩ ↩2

  7. Microsoft Learn, Connectivity Policy CSP. Il criterio di gestione che controlla i test attivi di NCSI. ↩ ↩2

  8. Microsoft Learn, Netsh.exe commands. La visualizzazione delle impostazioni proxy di WinHTTP. Usate show advproxy negli ambienti che lo supportano. ↩

  9. Microsoft Learn, Resolve-DnsName. L’ambito della query DNS e i suoi parametri. ↩

  10. curl project, curl man page. La soppressione del file di configurazione, i timeout, la visualizzazione delle intestazioni e la gestione di reindirizzamenti e proxy. ↩

  11. Microsoft Learn, How to collect data to diagnose NCSI issues. Il confronto dei registri Operativo e Analitico con le registrazioni del traffico. ↩ ↩2 ↩3

  12. Microsoft Learn, Error Messages (Winhttp.h). Il significato dei codici di risultato di WinHTTP. ↩

  13. Microsoft Learn, INetworkListManager::get_IsConnectedToInternet. L’API che recupera lo stato di connettività a Internet del sistema operativo. ↩

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Sviluppo di applicazioni Windows

Parliamo della progettazione o della revisione di applicazioni gestionali Windows che non si appoggino troppo allo stato di connessione visualizzato e che gestiscano correttamente i risultati reali del traffico e i ritentativi.

Vedi il servizio Contattaci

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Perché Windows mostra «Nessuna connessione Internet» se sono connesso al Wi-Fi?
Perché connettersi al Wi-Fi, comunicare con il servizio desiderato e il verdetto di connettività a cui Windows arriva tramite NCSI sono tre cose diverse. La visualizzazione può divergere non solo quando la linea stessa è caduta, ma anche a causa di problemi di DNS, proxy, VPN o portale captive che riguardano il traffico di controllo. Iniziate stabilendo che cosa riesca davvero a comunicare.
Se un sito si apre nel browser, posso concludere che anche NCSI sia a posto?
No. Destinazione, proxy selezionato, stato di autenticazione, IPv4 rispetto a IPv6 e orario della richiesta possono essere tutti diversi. Trattate l'accesso manuale come materiale di confronto e verificate con i registri eventi propri di NCSI e, se serve, con una cattura di pacchetti.
Su Windows 11 serve ancora una sonda DNS verso dns.msftncsi.com?
La FAQ ufficiale di NCSI spiega che la sonda attiva da Windows 11 in poi usa HTTP. Distinguete il traffico DNS che risolve la destinazione HTTP dalla sonda DNS delle versioni precedenti. L'importante è non dare per scontato in blocco che ogni richiesta di una procedura più vecchia sia obbligatoria.
Impostare EnableActiveProbing a 0 risolverà il problema?
Quell'impostazione ferma il traffico di controllo; non è un'impostazione che ripara una causa come il DNS o l'instradamento. Salvo che la adottiate come criterio di gestione per una rete isolata, non modificatela per far sparire la visualizzazione: indagate prima su dove si verifica l'errore.
Se NCSI dice «Internet», sono certo di raggiungere i nostri sistemi gestionali?
Non necessariamente. Il verdetto di connettività del sistema operativo non garantisce che una singola API o condivisione di file sia attiva, che l'autenticazione riesca o che abbiate il permesso di usarla. Un'applicazione deve emettere il traffico che le serve davvero e gestire timeout, annullamento, tipo di errore e se un ritentativo sia sicuro.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.

Contattaci
Torna al blog