Das Netzwerk läuft, aber Windows sagt „Kein Internet“ — NCSI, DNS, Proxy und VPN unter Windows eingrenzen

Websites gehen auf. Chatnachrichten kommen durch. Und trotzdem meldet allein die Windows-Anzeige „Kein Internet“.

Man denkt sich leicht: „Ich nutze das Netzwerk doch gerade, warum heißt es dann, es gebe keines?“ Dafür gibt es einen Grund. Windows hat eine eigene Konnektivitätsprüfung, und deren Ergebnis ist getrennt vom Ergebnis des Verkehrs, den die von Ihnen gerade genutzte Anwendung sendet. Ihre gewohnten Websites können erreichbar sein, während allein das Ziel, gegen das Windows prüft, es nicht ist.¹

Bevor Sie also die WLAN-Einstellungen löschen oder das gesamte Netzwerk zurücksetzen, trennen Sie die Frage: Ist nur die Anzeige falsch, oder scheitert auch der Verkehr, den Sie nutzen wollen?

Dieser Artikel erklärt zuerst den Mechanismus hinter der Abweichung und geht dann zu häufigen Situationen, zur Deutung nach Symptom und zu den eigentlichen Untersuchungsschritten über. Wenn Sie den Mechanismus wollen, lesen Sie bis einschließlich Kapitel 3; wenn Sie untersuchen, lesen Sie Kapitel 4 und 5; Entwicklerinnen und Entwickler von Windows-Anwendungen lesen zusätzlich Kapitel 6. Der Schwerpunkt liegt auf Windows 11, die Unterschiede zu Windows 10 werden ebenfalls behandelt, und die Beispiele nutzen Windows PowerShell 5.1 und curl.exe.

1. Windows sieht nicht nur auf die Website, die Sie gerade betrachten

Stellen Sie sich vor, Sie öffnen auf einem Firmen-PC Ihre gewohnte Website. Kann der Browser mit dieser Site sprechen, erscheint die Seite. Getrennt davon holt Windows eine kleine Datei, die für die Konnektivitätsprüfung genutzt wird.

Was wäre nun, wenn das Firmennetz so eingerichtet wäre, dass es Verkehr zu den üblicherweise genutzten Sites erlaubt, aber nicht Verkehr zum Ziel der Konnektivitätsprüfung? Der Verkehr des Browsers gelingt, während der Prüfverkehr von Windows scheitert. Selbst auf demselben PC können die Ergebnisse abweichen, wenn sich unterscheidet, wogegen geprüft wird.¹

flowchart TB
    accTitle: Ein Beispiel, in dem die Website funktioniert und nur die Konnektivitätsprüfung scheitert
    accDescr: Ein hypothetisches Beispiel, in dem der Browser auf demselben PC die gewohnte Website erreicht, während die NCSI-Prüfanfrage ein anderes Prüfziel nicht erreicht. Es ist kein Diagramm, das NCSIs Endzustand aus einer einzelnen Anfrage festlegt.
    pc["Derselbe PC"] --> browser["Browserverkehr"]
    pc --> probe["Konnektivitätsprüfverkehr von Windows"]
    browser --> site["Gewohnte Website<br/>die Seite geht auf"]
    probe --> blocked["Ziel der Konnektivitätsprüfung<br/>nur dieser Verkehr scheitert"]

Abbildung 1: Ein hypothetisches Beispiel zum Verständnis des Mechanismus. Alltagsverkehr und Konnektivitätsprüfung gehen an verschiedene Gegenstellen.

Die für dieses Konnektivitätsurteil zuständige Komponente ist NCSI (Network Connectivity Status Indicator). Sie entscheidet, ob eine Verbindung zum Internet besteht oder nur lokale Konnektivität, und liefert die Informationen für die Netzwerkstatusanzeige und für Anwendungen. Sie überwacht nicht, ob eine einzelne Website oder ein Geschäftssystem erreichbar ist.¹

Sehen Sie darauf, ob der Prüfinhalt zurückkommt, nicht darauf, ob irgendetwas zurückkam

Seit Windows 10 Version 1607 ist die folgende URL das Standard-HTTP-Prüfziel. Der erwartete Inhalt ist Microsoft Connect Test. Auf von Unternehmen verwalteten PCs wird das Prüfziel mitunter geändert.²

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

Wenn Sie diese Datei holen wollen und stattdessen ein Hotel-Anmeldebildschirm oder eine Firmen-Sperrseite zurückkommt, dann ist zwar etwas vom Ziel eingetroffen, aber nicht das erwartete Prüfergebnis. Selbst bei HTTP-Status 200 muss der Inhalt nicht derselbe sein.³

flowchart TB
    accTitle: Was die HTTP-Prüfung prüft
    accDescr: Sehen Sie bei der Anfrage an das Prüfziel darauf, ob die erwartete Antwort und der erwartete Inhalt zurückkommen.
    start["HTTP-Anfrage an das Prüfziel"] --> response{"Wurde eine Antwort empfangen"}
    response -->|"Nein"| failed["Unvollständige Übertragung oder Fehler untersuchen"]
    response -->|"Ja"| content{"Ist es die erwartete Antwort samt Inhalt"}
    content -->|"Ja"| success["Beleg für ein Urteil „verbunden“"]
    content -->|"Nein"| changed["Authentifizierung, Sperrung oder geänderten Inhalt untersuchen"]

Abbildung 2: Halten Sie „eine Antwort vom Prüfziel erhalten“ getrennt von „den erwarteten Inhalt zurückbekommen“.

Beachten Sie, dass NCSI nicht allein von diesem Prüfverkehr lebt. Das Verfahren, bei dem es von sich aus prüft, heißt aktive Prüfung, das Verfahren, bei dem es aus Informationen wie empfangenen Paketen urteilt, passive Prüfung; es nutzt beide. Eine gescheiterte HTTP-Anfrage im Diagramm ist also nicht dasselbe wie ein Endzustand ohne Internet.¹

Der bisherige Punkt lautet: Die Verbindung zum WLAN, die Nutzbarkeit einer bestimmten Site und ein Urteil „Internet“ von Windows sind jeweils eine eigene Prüfung. Allein mit dem WLAN verbunden zu sein sagt nichts über den Weg nach außen oder über die Nutzungsauthentifizierung, und eine erreichbare Site ist keine Garantie, dass ein anderes Ziel oder eine andere Anwendung funktioniert.

In der Abbildung kennzeichnet eine durchgezogene Linie eine stets geltende Beziehung und eine gestrichelte Linie eine bedingte (die Bedingungen stehen bei jeder Beziehung auf der Detailseite). Die vollständige Liste der Beziehungen (5 insgesamt, mit Beleg und Sicherheitsgrad) und die Definitionen der wichtigsten Konzepte sind auf der Detailseite der Wissenskarte (auf Japanisch) zusammengestellt. Daten: JSON-LD / Turtle

2. Drei häufige Situationen, in denen Anzeige und Verkehr auseinandergehen

Im Büro können Browser und Konnektivitätsprüfung verschiedene Wege nehmen

Machen wir das Firmenbeispiel vom Anfang etwas konkreter. In Unternehmensnetzen gibt es Aufbauten, in denen man nicht direkt nach außen geht, sondern über ein Relais namens Proxy. Der Mechanismus, der dieses Relais nach der aufgerufenen URL und ähnlichen Kriterien auswählt, ist die PAC-Datei. Mitunter wird auch automatische Erkennung genutzt.⁴

In diesem Aufbau kann für die üblicherweise genutzten Sites ein passender Proxy gewählt werden, während allein das Ziel der Konnektivitätsprüfung aus den Regeln herausfällt. Auch Fälle, in denen die Proxy-Erkennung nicht rechtzeitig abschließt oder in denen allein der HTTP-Verkehr zum Prüfziel gesperrt ist, sind zu untersuchende Kandidaten.¹

flowchart TB
    accTitle: Browserweg und NCSI-Weg getrennt prüfen
    accDescr: Erfolg für den Verkehr des Browsers garantiert keinen Erfolg für NCSI, das ein anderes Ziel und eine andere Proxy-Auswahl nutzt.
    pc["Derselbe PC"] --> browser["Browseranfrage"]
    pc --> ncsi["NCSI-Prüfanfrage"]
    browser --> bpath["Proxy und Authentifizierung für diese Anfrage"]
    ncsi --> npath["Proxy und Authentifizierung für die Prüfanfrage"]
    bpath --> site["Genutzte Website"]
    npath --> probe["Ziel der Konnektivitätsprüfung"]

Abbildung 3: Auf demselben PC zu sein heißt nicht zwangsläufig derselbe Weg. Prüfen Sie Ziel, Proxy und Authentifizierung je Anfrage.

Sehen Sie also über die Frage hinaus, ob der Browser erfolgreich war, und finden Sie heraus, welcher Proxy für NCSIs Anfrage gewählt wurde und unter welchem Konto beziehungsweise welchen Authentifizierungsbedingungen sie kommuniziert hat. Dasselbe gilt für die später genutzte manuelle curl-Prüfung. Diese drei nicht als Verkehr unter identischen Bedingungen zu behandeln ist der Ausgangspunkt der Eingrenzung.

Im Hotel kann nach dem WLAN-Beitritt noch eine Anmeldung ausstehen

In WLANs von Hotels und ähnlichen Orten werden Sie nach dem Aufbau der Funkstrecke womöglich gebeten, Nutzungsbedingungen anzunehmen oder sich anzumelden. Dieses Authentifizierungsgateway ist ein Anmeldeportal (Captive Portal). Wird die Prüfanfrage auf die Authentifizierungsseite umgeleitet oder ein Anmeldebildschirm zurückgegeben, entsteht daraus nicht die normale Prüfantwort. Dass Windows einen Browser öffnet und Sie zur Anmeldung auffordert, hängt ebenfalls mit diesem Mechanismus zusammen.³

flowchart TB
    accTitle: Der Unterschied zwischen WLAN-Beitritt und Portalauthentifizierung
    accDescr: Auch nach erfolgreicher Funkverbindung kann der Verkehr nach außen eingeschränkt bleiben, bis die Authentifizierung auf Netzwerkseite abgeschlossen ist.
    wifi["Mit dem WLAN verbunden"] --> portal{"Ist die Nutzungsauthentifizierung abgeschlossen"}
    portal -->|"Nicht abgeschlossen"| signin["Über die offizielle Seite authentifizieren"]
    portal -->|"Abgeschlossen"| test["Tatsächlichen Verkehr und Urteil erneut prüfen"]
    signin --> test

Abbildung 4: Die Verbindung zum WLAN abzuschließen heißt nicht, die Authentifizierung zur Nutzung dieses Netzes abgeschlossen zu haben.

Da es Fälle gibt, in denen nur die Informationsseite des Veranstaltungsorts abrufbar ist, schließen Sie nicht aus einer aufgehenden Seite, dass jeglicher ausgehender Verkehr erlaubt ist. Authentifizieren Sie sich nach den offiziellen Anweisungen des Orts und prüfen Sie danach den tatsächlichen Verkehr und die Windows-Anzeige. Geben Sie keine Konto- oder Kartendaten in einen verdächtigen Anmeldebildschirm ein.

Mit VPN ändert sich, „aus welcher Verbindung das Ergebnis kam“

Vor und nach einer VPN-Verbindung können sich der Verkehrsweg und die Bedingungen für die DNS-Nutzung ändern. Dass Einstellungen unmittelbar nach dem Verbinden noch nicht greifen oder dass Prüfverkehr einen unbeabsichtigten Weg nimmt, sind ebenfalls Kandidaten für einen NCSI-Fehlschlag.²

Betrachten Sie den PC in dem Fall nicht als einen einzigen Zustand „verbunden oder nicht“, sondern trennen Sie physisches LAN oder WLAN vom VPN. Sieht der Entwurf etwa die physische Seite auf LocalNetwork vor, während Sie über die VPN-Seite ins Internet gehen, genügt eine Zeile über die physische Seite nicht, um etwas für fehlerhaft zu erklären. Lesen Sie die Verbindungsprofile aus Kapitel 4 zusammen mit dem tatsächlich genutzten Weg.⁵⁶

flowchart TB
    accTitle: Verbindungsweg und IP-Familie trennen
    accDescr: Trennen Sie physisches LAN vom VPN und IPv4 von IPv6 und ordnen Sie jedem Urteil den vom Verkehr genutzten Weg zu.
    pc["Die Verbindungen auflisten"] --> physical["Physisches LAN und WLAN"]
    pc --> vpn["VPN-Adapter"]
    physical --> p["IPv4- und IPv6-Urteile"]
    vpn --> v["IPv4- und IPv6-Urteile"]
    p --> route["Mit dem tatsächlichen Verkehrsweg abgleichen"]
    v --> route

Abbildung 5: Halten Sie physische Verbindung gegenüber VPN und IPv4 gegenüber IPv6 auseinander und vergleichen Sie mit dem tatsächlichen Verkehrsweg.

Dasselbe gilt für IPv4 und IPv6. NCSI führt die aktiven Prüfungen für beide parallel aus, und ein Erfolg bei einer von beiden genügt für den Schluss auf eine Internetverbindung. Dass eine davon nicht „Internet“ meldet, heißt für sich genommen nicht, dass der gesamte PC offline ist. Welche der beiden eine bestimmte Anwendung genutzt hat, beobachten Sie für diesen Verkehr gesondert.¹

Wollen Sie durch Trennen des VPN vergleichen, tun Sie das auf einem von Ihrer Organisation freigegebenen Testrechner oder in einem genehmigten Änderungsfenster. Trennen Sie ein dauerhaft aktives VPN nicht ohne Erlaubnis, nur um zu untersuchen.

3. Die erste Trennung lautet: „Nur die Anzeige oder auch der Verkehr kaputt?“

Sobald Sie die Ursachenkandidaten kennen, wenden Sie sie auf Ihre eigenen Symptome an. Bestätigen Sie zuerst, ob neuer Verkehr gerade funktioniert, indem Sie etwa eine neue Seite auf einer Site öffnen, die Sie nutzen dürfen. Ein Bildschirm, der seit vorhin offen ist, sagt nichts über den aktuellen Zustand der Verbindung.

Statt „das Netzwerk funktioniert“ werden Sie so konkret, dass Sie schreiben können: „zu dieser Zeit, in dieser Anwendung, zu diesem Ziel, ist dieser Vorgang gelungen“. Das grenzt ein, was zu untersuchen ist.

Das ist keine Tabelle, die die Ursache bestimmt; es ist eine Tabelle zur Wahl der nächsten Prüfstelle. Auch wenn eine Anzeigeauffälligkeit der Anlass war: Wenn die gewünschte Geschäftsanwendung scheitert, halten Sie dieses Verkehrsergebnis zusätzlich gesondert fest.

Ab hier folgen die Untersuchungsschritte. Gehen Sie in dieser Reihenfolge vor: Zustand erfassen, Prüfzieleinstellungen lesen, mit manuellem Verkehr vergleichen, dann mit NCSIs eigenen Aufzeichnungen bestätigen. Ändern Sie Firmen-Proxy-, VPN- oder Sicherheitseinstellungen nicht ohne Erlaubnis; beginnen Sie mit rein lesender Prüfung und wenigen Verkehrsproben.

4. Bestätigen Sie vor einer Einstellungsänderung, wo es gescheitert ist

4.1 Zeitpunkt des Auftretens und Verbindungszustand festhalten

Halten Sie zuerst Zeitpunkt, OS-Build, Art der Verbindung, VPN-Nutzung und die scheiternde Anwendung fest. Die Betriebssystemversion sehen Sie mit winver. Lassen Sie dann in PowerShell die Verbindungsprofile anzeigen.⁵

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

Zu lesen sind der Verbindungsname, InterfaceAlias und InterfaceIndex sowie IPv4Connectivity und IPv6Connectivity. Bei mehreren Zeilen lesen Sie sie so, dass klar bleibt, zu welcher Verbindung jedes Ergebnis gehört. Es geht darum, Ergebnisse derselben Zeit und derselben Verbindung mit den folgenden manuellen Tests und Protokollen zu vergleichen.

Die Werte Public / Private / DomainAuthenticated von NetworkCategory sind eine von der Internetkonnektivität getrennte Einstufung. Public auf Private zu ändern ist kein allgemeiner Reparaturschritt für „Kein Internet“. Die Ausgabe kann etwa interne Netzwerknamen enthalten; maskieren Sie unnötige Kennungen, bevor Sie sie weitergeben.⁵

4.2 Lesen, welches Ziel dieser PC laut Konfiguration prüft

Bevor Sie das Standard-Prüfziel ausprobieren, bestätigen Sie, ob dieser PC dieselben Einstellungen nutzt. Der folgende Code zeigt nur Werte an; er ändert die Registrierung nicht. Er liest die Prüfziele der IPv4- und der IPv6-Seite sowie den erwarteten Inhalt und dazu die Richtlinien, die etwa die aktive Prüfung steuern.¹⁷

$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 {
    'Unter diesem Registrierungspfad gibt es keine NCSI-Richtlinie.'
}

ActiveWebProbeHost und ActiveWebProbePath sind das Prüfziel, ActiveWebProbeContent ist der erwartete Inhalt. Halten Sie auch die Werte mit V6 im Namen fest. Ist ein eigenes Prüfziel konfiguriert, richten Sie die folgenden manuellen Tests an dieser Einstellung und an Ihrer Verwaltungsrichtlinie aus.

Eine Ausgabe, dass es keinen Richtlinienschlüssel gibt, bedeutet, dass es an diesem Pfad keine Einstellungen gibt. Sie ist kein Beweis, dass überhaupt keine Verwaltungskonfiguration besteht, auch nicht über MDM. Raten Sie nicht und legen Sie keinen Schlüssel an, den Sie nicht gefunden haben; klären Sie es mit Ihrer Administration.

Für Proxys prüfen Sie die Windows-Einstellungsseiten und die Verwaltungsrichtlinien. Für die WinHTTP-Einstellungen liefert netsh winhttp show advproxy in unterstützenden Umgebungen oder netsh winhttp show proxy in älteren Umgebungen Vergleichsmaterial. Was Sie dort erfahren, ist jedoch die Konfiguration. Den Weg, den NCSI über PAC oder automatische Erkennung tatsächlich gewählt hat, müssen Sie mit den später beschriebenen Verkehrsaufzeichnungen abgleichen.⁸⁴

4.3 Trennen, ob der Name aufgelöst wird und ob TCP verbindet

Ab hier folgen manuelle Vergleichstests gegen das Standard-Prüfziel. Sie wollen wissen, ob der Zielname nicht aufgelöst werden kann oder ob es bei der Verbindung dahinter hakt. Prüfen Sie zuerst Namensauflösung und TCP-Verbindung getrennt.

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

Das -Type A in Resolve-DnsName gibt an, die IPv4-Adresse nachzuschlagen. Beobachten Sie zunächst mit Ihren gewohnten DNS-Einstellungen. Sofort auf einen öffentlichen DNS-Server umzuschalten ändert auch die interne Namensauflösung und Ihre Verwaltungsrichtlinie, was das ursprüngliche Problem schwerer verfolgbar macht.⁹

Was Test-NetConnection -Port 80 Ihnen sagt, ist die TCP-Verbindung zum angegebenen Ziel. Es prüft weder den HTTP-Inhalt noch die Proxy-Authentifizierung. In einer Umgebung, in der Direktverbindungen untersagt sind und nur Verkehr über einen HTTP-Proxy erlaubt ist, kann ein Fehlschlag dieses TCP-Tests normal sein. Sichern Sie auch InterfaceAlias und SourceAddress und bestätigen Sie, von welchem Weg das Ergebnis kam.⁶

flowchart TB
    accTitle: Die Fragen, die die manuellen Tests beantworten
    accDescr: Namensauflösung, TCP-Verbindung und HTTP-Antwort decken verschiedene Bereiche ab, behandeln Sie den Erfolg des einen also nicht als Garantie für die nächste Schicht.
    name["Den Namen per DNS auflösen"] --> tcp["Die TCP-Verbindung zum Ziel prüfen"]
    tcp --> http["HTTP-Antwort und Inhalt prüfen"]
    http --> own["Mit NCSIs eigenen Aufzeichnungen vergleichen"]
    tcp -.-> proxy["Ein anderer Weg, auf dem ein Proxy zwingend ist"]

Abbildung 6: Namensauflösung, TCP-Verbindung und HTTP-Antwort bestätigen in dieser Reihenfolge jeweils etwas anderes.

4.4 Sehen Sie bei HTTP auf den Inhalt, nicht nur auf den Status

Sehen Sie als Nächstes, ob der in Kapitel 1 beschriebene Prüfinhalt zurückkommt. Führen Sie auf einem Rechner mit verfügbarem curl.exe Folgendes einige wenige Male aus. Schreiben Sie das .exe aus, damit es nicht mit dem PowerShell-Alias verwechselt wird.

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

--include ist die Option, die die Kopfzeilen zusammen mit dem Inhalt anzeigt. Zeitüberschreitungen sind für die Verbindung und für den Vorgang insgesamt gesetzt, und da -L nicht angegeben ist, folgt es keiner Umleitung automatisch, sodass Sie die erste Antwort sehen. Das führende -q weist curl an, seine Standardkonfigurationsdatei nicht zu lesen, löscht aber keine proxybezogenen Umgebungsvariablen.¹⁰

Ein minimales Beispiel des erwarteten Inhalts folgt. Es dient der Erklärung; es ist kein gemessenes Protokoll aus diesem Artikel. In der Praxis sind weitere Kopfzeilen vorhanden.²

HTTP/1.1 200 OK
...

Microsoft Connect Test

Wichtig ist hier: Der manuelle Test ersetzt NCSI nicht; er ist Vergleichsmaterial. curl ist kein Test, der Windows’ PAC-Einstellungen oder den Authentifizierungszustand des Browsers auf dieselbe Weise erbt. Ein Ergebnis „der Browser war erfolgreich, curl nicht“ allein belegt keine Fehlfunktion von NCSI.

Klären Sie mit Ihrer Administration, wie Proxys genutzt werden sollen, und schreiben Sie keine Anmeldedaten direkt in Ihren Befehlsverlauf. Und selbst wenn diese HTTP-Prüfung gelingt, ist das keine Garantie, dass HTTPS und die Authentifizierung für eine Geschäfts-API gelingen.

4.5 Suchen Sie zuletzt die Aufzeichnungen über das tatsächliche Scheitern von NCSI

Sobald die manuellen Tests Kandidaten sichtbar gemacht haben, prüfen Sie NCSIs eigenes Verhalten. Der Zugang ist die Ereignisanzeige unter Anwendungs- und Dienstprotokolle → Microsoft → Windows → NCSI. Prüfen Sie das Betriebsprotokoll rund um den Zeitpunkt des Auftretens.¹¹

Lesen Sie statt einer einzelnen Fehlerzeile weiter: auf welcher Schnittstelle es startete und ob es abschloss, was der Fehlergrund war und wie sich der Konnektivitätszustand danach änderte. Gleichen Sie zur selben Zeit und auf demselben Weg wie die manuellen Tests ab und kombinieren Sie bei Bedarf mit einer genehmigten Paketaufzeichnung.¹¹

flowchart TB
    accTitle: Die Reihenfolge, in der die NCSI-Protokolle zu lesen sind
    accDescr: Verbinden Sie Start, Abschluss, Fehlergrund und Zustandsänderung über Zeit und Schnittstelle.
    start["Auf welchem Weg es startete"] --> finish["Ob es abschloss"]
    finish --> reason["Ergebniscode und Fehlergrund"]
    reason --> state["Der Konnektivitätszustand danach"]
    state --> correlate["Mit Verkehrsaufzeichnungen derselben Zeit abgleichen"]

Abbildung 7: Start bis Zustandsänderung zu verbinden erleichtert es nachzuvollziehen, was sich zwischen manuellem Test und NCSI unterschied.

Ist der Ergebniscode ein WinHTTP-Fehler, schlagen Sie seine Bedeutung in der WinHTTP-Tabelle nach. 12007 bedeutet etwa, dass der Name nicht aufgelöst werden konnte, und 12002 ist eine Zeitüberschreitung. Was Sie erfahren, ist jedoch ein Hinweis auf die gescheiterte Stufe; das allein legt nicht fest, dass ein DNS-Server ausgefallen oder die Leitung tot ist.¹²

Reichen die Details nicht, aktiviert eine Administratorin oder ein Administrator das Analyseprotokoll über „Analytische und Debugprotokolle einblenden“. Das ist eine Änderung an Diagnoseeinstellungen: Halten Sie den Zeitpunkt der Aktivierung fest, reproduzieren Sie das Problem und stellen Sie nach dem Sammeln den ursprünglichen Zustand wieder her. Das Aktivieren lässt Sie keine detaillierten Ereignisse aus der Zeit davor abrufen.¹¹

Außerdem kann das Neuverbinden des WLANs oder das Deaktivieren eines Adapters zum Reproduzieren Verwaltungsverbindungen wie RDP abreißen lassen. Führen Sie das nicht unangekündigt auf einem Produktivrechner oder auf einem Rechner aus, den Sie aus der Ferne bedienen. Verkehrsaufzeichnungen können Hostnamen, IP-Adressen und authentifizierungsbezogene Informationen enthalten; beschränken Sie daher Speicherort und Empfängerkreis.

Im Firmenbeispiel vom Anfang gleichen Sie an dieser Stelle die 403 aus dem manuellen HTTP, das NCSI-Protokoll derselben Zeit und die Proxy-Ablehnungsaufzeichnungen ab, die Ihre Administration einsehen kann. Wurde nur das Prüfziel abgelehnt, korrigieren Sie diese Regel und testen erneut. Nahm nur der manuelle Test einen anderen Weg, überdenken Sie die Vergleichsbedingungen. Entscheiden Sie nicht allein aus der Zahl 403, es sei „ein NCSI-Fehler“ oder „ein Problem unseres Proxys“; wählen Sie die nächste Maßnahme anhand der Aufzeichnungen. Das ist ein hypothetisches Eingrenzungsbeispiel, nicht das Ergebnis eines realen Projekts.

5. Versuchen Sie nicht, mit alten Behelfen nur die Anzeige zu reparieren

Verwechseln Sie den DNS-Verkehr von Windows 11 nicht mit der alten DNS-Prüfung

In älteren Darstellungen kommt eine DNS-Prüfung an dns.msftncsi.com vor. Die offizielle NCSI-FAQ erläutert jedoch, dass die aktive Prüfung ab Windows 11 HTTP verwendet. Selbst wenn in einer Windows-11-Aufzeichnung DNS-Verkehr auftaucht, kann es sich um die Namensauflösung für das HTTP-Ziel handeln.²

flowchart TB
    accTitle: Die Rolle des DNS-Verkehrs unterscheiden
    accDescr: Lesen Sie die Namensauflösung für das HTTP-Ziel unter Windows 11 und die alte DNS-Prüfung als Verschiedenes.
    dns["In der Aufzeichnung ist DNS-Verkehr"] --> purpose{"Wofür ist der Verkehr"}
    purpose --> http["Namensauflösung für das HTTP-Ziel"]
    purpose --> legacy["Die alte DNS-Prüfung"]
    http --> win11["Kann auch unter Windows 11 nötig sein"]
    legacy --> version["Betriebssystemversion und tatsächliche Protokolle prüfen"]

Abbildung 8: Der DNS-Verkehr, der das HTTP-Ziel nachschlägt, und die DNS-Prüfung selbst sind verschiedene Dinge.

Die ältere Erklärung, „jede von HTTP getrennte DNS-Abfrage muss gelingen“, lässt sich also nicht zur für alle Windows-Versionen gemeinsamen Regel machen. Lesen Sie die untersuchte Betriebssystemversion zusammen mit den tatsächlichen Protokollen.

Ein weiterer verwirrender Punkt ist der Name des Einstellungsorts. Unter Windows 11 ist die Komponente, die NCSI ausführt, vom herkömmlichen NLA auf die Seite des Netzwerklisten-Managers gewandert, aber Einstellungen wie das Prüfziel nutzen weiterhin den Registrierungspfad mit NlaSvc aus Kapitel 4. Entscheiden Sie nicht allein anhand des Pfads mit NlaSvc, welcher Dienst es ausführt.¹

Die Prüfung zu stoppen repariert keinen Verkehr, der nicht durchkam

EnableActiveProbing auf 0 zu setzen oder die aktive Prüfung per Richtlinie zu untersagen sind Einstellungen, die die Konnektivitätsprüfung einschränken. Es sind keine Maßnahmen, die einen DNS-Ausfall oder eine Proxy-Route reparieren. Halten Sie die Übernahme als Verwaltungsrichtlinie für ein abgeschottetes Netz getrennt von einer Änderung, die nur eine Warnung verschwinden lassen soll. Microsoft empfiehlt das Abschalten der aktiven Prüfung ebenfalls nicht als Lösung für NCSI-Probleme.⁷¹

Aus demselben Grund sind eine vorgetäuschte Erfolgsantwort, das pauschale Abschalten der Firewall oder das grundlose Deaktivieren von IPv6 keine ersten Schritte. Dass sich die Anzeige ändert und dass sich der gewünschte Verkehr verbessert, sind zweierlei.

flowchart TB
    accTitle: Beurteilen Sie eine Reparatur nicht allein an der Anzeige
    accDescr: Bestätigen Sie nach einer Konfigurationsänderung nicht nur die Änderung der Anzeige, sondern auch die Fehlerstelle und die Verbesserung des benötigten Verkehrs.
    change["Eine begründete Änderung"] --> probe["Konnektivitätsprüfverkehr erneut prüfen"]
    change --> app["Benötigten Verkehr erneut prüfen"]
    probe --> judge["Die Verbesserung aus beiden Ergebnissen beurteilen"]
    app --> judge

Abbildung 9: Bestätigen Sie auch nach einer begründeten Änderung sowohl den Prüfverkehr als auch den gewünschten Verkehr.

Auch beim Korrigieren von Firmen-Zulassungsregeln beenden Sie es nicht damit, die IP-Adressen aus einem alten Artikel statisch einzutragen. Die Auslieferungsinfrastruktur hinter NCSIs öffentlichem Prüfziel kann sich ändern, und Microsoft rät von Zulassungsregeln ab, die von bestimmten IP-Adressen abhängen. Erarbeiten Sie mit Ihrer Administration Regeln, die zum tatsächlichen Prüfziel, Dienst und Weg passen.²

6. Für Entwickler: Entscheiden Sie „nicht kommunizieren“ nicht allein anhand von NCSI

All das bisher Gesagte berührt auch den Entwurf von Windows-Anwendungen. Wenn das Betriebssystem „Kein Internet“ meldet und Sie die Anwendung daraufhin als offline markieren, ohne die benötigte Anfrage auch nur einmal zu versuchen, halten Sie womöglich Verkehr auf, der tatsächlich funktionieren würde. Umgekehrt ist es ebenso falsch anzunehmen, eine Geschäfts-API müsse gelingen, weil das Betriebssystem „Internet“ meldet.

INetworkListManager::get_IsConnectedToInternet, das das systemweite Konnektivitätsurteil abruft, ist eine API, die den Internetkonnektivitätszustand des lokalen Rechners zurückgibt. Sie garantiert nicht, dass eine einzelne API oder Dateifreigabe läuft, dass die Authentifizierung gelingt oder dass Sie die Berechtigung zur Nutzung haben.¹³

Entwurfsseitig lässt es sich so zusammenfassen: Nutzen Sie den Konnektivitätszustand des Betriebssystems als Hinweis für Anzeige und Neuverbindung und verwalten Sie Erfolg oder Fehlschlag des benötigten Verkehrs gesondert. Ziel ist, zwei Tatsachen gleichzeitig halten zu können: „Windows’ Urteil lautet LocalNetwork, und die Geschäfts-API war erreichbar“.

flowchart TB
    accTitle: Urteil des Betriebssystems und Ergebnis des Geschäftsverkehrs getrennt verwalten
    accDescr: Nutzen Sie die Konnektivitätsinformation des Betriebssystems als Hinweis und geben Sie dem benötigten Verkehr eine eigenständige Behandlung von Erfolg und Fehlschlag.
    status["Konnektivitätszustand des Betriebssystems"] --> hint["Hinweis für Anzeige und Neuverbindung"]
    request["Die benötigte Anfrage"] --> outcome{"Das tatsächliche Ergebnis"}
    outcome --> ok["Als Erfolg behandeln"]
    outcome --> error["Fehlergrund festhalten"]
    error --> retry["Wiederholen, nachdem die Sicherheit bestätigt ist"]

Abbildung 10: Nutzen Sie das Urteil des Betriebssystems als Hinweis und geben Sie dem Geschäftsverkehr eine eigene Behandlung von Erfolg und Fehlschlag.

Verdichten Sie auch das Protokoll nicht auf das eine Wort „offline“; halten Sie die beobachtbare Fehlerstufe fest, etwa DNS, Verbindung, TLS, Authentifizierung oder die HTTP-Antwort. Geben Sie Anfragen Zeitüberschreitungen und Abbruchmöglichkeiten, damit die Oberfläche nicht wartend zurückbleibt.

Für das Wiederholen nach einer Zeitüberschreitung gilt allerdings ein eigener Vorbehalt. Ein ändernder Vorgang wie eine Bestellung oder eine Überweisung kann auf der Gegenseite bereits ausgeführt worden sein, auch wenn die Antwort nicht rechtzeitig eintraf. Entscheiden Sie nicht „es lief in eine Zeitüberschreitung, also wurde es nicht ausgeführt“ und senden erneut; machen Sie die Frage, ob eine Wiederholung erlaubt ist, den Mechanismus gegen Doppelausführung und die Ergebnisabfrage zum Teil der Anwendungsspezifikation. Das ist kein Problem, das NCSI für Sie löst.

7. Zusammenfassung: Lesen Sie Anzeige und Verkehr als getrennte Tatsachen

„Das Netzwerk läuft, aber Windows sagt Kein Internet“ ist nicht zwangsläufig ein Widerspruch. Die Verbindung zum WLAN, die Kommunikation mit der gewünschten Gegenstelle und Windows’ eigenes NCSI-Urteil prüfen jeweils etwas anderes.

Trennen Sie zuerst, ob nur die Anzeige abweicht oder ob auch der benötigte Verkehr scheitert. Nutzen Sie bei der Untersuchung die Prüfzieleinstellungen und die manuellen Tests als Vergleichsmaterial und bestätigen Sie das tatsächliche Verhalten in NCSIs eigenen Protokollen. Und sehen Sie nach einer Änderung über das Symbol hinaus darauf, ob sich Prüfverkehr und benötigter Verkehr verbessert haben.

Von „es sollte doch verbunden sein“ zu „welcher Verkehr ist wo gescheitert“. In dieser Reihenfolge zu denken lässt Sie eingrenzen, wo zu suchen ist, bevor Sie planlos Einstellungen ändern.

Verwandte Artikel

• Die Windows-Firewall und Geschäftsanwendungen
• Der Windows-Zertifikatspeicher in der Praxis

Referenzlinks

Geprüft am 11. September 2026. Bei Unterschieden zwischen Betriebssystemversionen hat die NCSI-spezifische offizielle FAQ Vorrang, und die Verfahren in älterer, an Clients gerichteter Dokumentation werden nicht als feste Spezifikation für Windows 11 behandelt. Prüfen Sie auch Anzeigenamen von Protokollen und verfügbare Befehle gegen Ihren tatsächlichen OS-Build und Ihre Verwaltungskonfiguration.

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Warum zeigt Windows „Kein Internet“, obwohl ich mit dem WLAN verbunden bin?

Weil die Verbindung zum WLAN, die Kommunikation mit dem gewünschten Dienst und das Konnektivitätsurteil, zu dem Windows über NCSI kommt, drei verschiedene Dinge sind. Die Anzeige kann nicht nur bei einer ausgefallenen Leitung abweichen, sondern auch wegen DNS-, Proxy-, VPN- oder Anmeldeportalproblemen, die den Prüfverkehr betreffen. Stellen Sie zuerst fest, was tatsächlich kommunizieren kann.

Wenn eine Website im Browser aufgeht, ist dann auch NCSI in Ordnung?

Das können Sie nicht schließen. Ziel, ausgewählter Proxy, Authentifizierungszustand, IPv4 gegenüber IPv6 und der Zeitpunkt der Anfrage können sich alle unterscheiden. Behandeln Sie den manuellen Zugriff als Vergleichsmaterial und bestätigen Sie mit NCSIs eigenen Ereignisprotokollen und bei Bedarf einer Paketaufzeichnung.

Ist unter Windows 11 noch eine DNS-Prüfung an dns.msftncsi.com nötig?

Die offizielle NCSI-FAQ erläutert, dass die aktive Prüfung ab Windows 11 HTTP verwendet. Unterscheiden Sie den DNS-Verkehr, der das HTTP-Ziel auflöst, von der DNS-Prüfung älterer Versionen. Wichtig ist, nicht pauschal anzunehmen, dass jede Anfrage aus einem älteren Verfahren zwingend ist.

Behebt es das Problem, EnableActiveProbing auf 0 zu setzen?

Diese Einstellung stoppt den Prüfverkehr; sie behebt keine Ursache wie DNS oder Routing. Ändern Sie sie nicht, um die Anzeige verschwinden zu lassen — außer wenn Sie sie als Verwaltungsrichtlinie etwa für ein abgeschottetes Netz übernehmen —, sondern untersuchen Sie zuerst, wo der Fehler auftritt.

Wenn NCSI „Internet“ meldet, erreiche ich dann garantiert unsere Geschäftssysteme?

Nicht zwangsläufig. Das Konnektivitätsurteil des Betriebssystems garantiert nicht, dass eine einzelne API oder Dateifreigabe läuft, dass die Authentifizierung gelingt oder dass Sie die Berechtigung zur Nutzung haben. Eine Anwendung muss den tatsächlich benötigten Verkehr absetzen und Zeitüberschreitungen, Abbrüche, die Art des Fehlers und die Frage, ob eine Wiederholung sicher ist, behandeln.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.