The Network Works but Windows Says "No internet" — Isolating NCSI, DNS, Proxy, and VPN on Windows

Web sites open. Chat messages get through. And yet the Windows display alone says “No internet”.

You may well think, “I am using the network right now, so why does it say there is none?” There is a reason for it. Windows has its own connectivity check, and its result is separate from the result of the traffic the application you are using right now is sending. Your usual web sites may be reachable while only the destination Windows checks against is not.¹

So before you delete the Wi-Fi settings or reset the whole network, separate the question: is only the display wrong, or is the traffic you want to use failing too?

This article first explains the mechanism behind the mismatch, then moves on to common situations, how to read things by symptom, and the actual investigation steps. If you want the mechanism, read through Chapter 3; if you are investigating, read Chapters 4 and 5; Windows application developers should read Chapter 6 as well. It focuses on Windows 11 and also covers the differences from Windows 10, and the examples use Windows PowerShell 5.1 and curl.exe.

1. Windows Is Not Looking Only at the Site You Are Viewing Right Now

Picture opening your usual web site on a company PC. If the browser can talk to that site, the page appears. Separately from that, Windows goes and fetches a small file used for the connectivity check.

Now, what if the company network were configured to allow traffic to the sites people normally use but not traffic to the connectivity check destination? The browser’s traffic succeeds while Windows’ check traffic fails. Even on the same PC, if what you are checking against differs, the results can disagree.¹

flowchart TB
    accTitle: An example where the web site works but only the connectivity check fails
    accDescr: A hypothetical example in which the browser on the same PC can reach the usual web site while the NCSI check request does not reach a different check destination. It is not a diagram that settles NCSI's final state from a single request.
    pc["The same PC"] --> browser["Browser traffic"]
    pc --> probe["Windows connectivity check traffic"]
    browser --> site["Usual web site<br/>the page opens"]
    probe --> blocked["Connectivity check destination<br/>only this traffic fails"]

Figure 1: A hypothetical example for understanding the mechanism. Everyday traffic and the connectivity check go to different parties.

The component responsible for this connectivity verdict is NCSI (Network Connectivity Status Indicator). It decides whether there is a connection to the internet or only local connectivity, and it supplies the information used by the network status display and by applications. It is not monitoring whether any individual web site or business system is up.¹

Look at Whether the Check Content Comes Back, Not at Whether Something Came Back

Since Windows 10 version 1607, the standard HTTP check destination is the following URL. The expected body is Microsoft Connect Test. On PCs that companies manage, the check destination is sometimes changed.²

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

If you go to fetch this file and a hotel sign-in screen or a corporate block page comes back, then something did arrive from the destination, but it is not the check result you expected. Even when the HTTP status is 200, the body is not necessarily the same.³

flowchart TB
    accTitle: What the HTTP probe checks
    accDescr: For the request to the check destination, look at whether the expected response and body come back.
    start["HTTP request to the check destination"] --> response{"Was a response received"}
    response -->|"No"| failed["Investigate the incomplete transfer or failure"]
    response -->|"Yes"| content{"Is it the expected response and body"}
    content -->|"Yes"| success["Evidence for a connected verdict"]
    content -->|"No"| changed["Investigate authentication, blocking, or changed content"]

Figure 2: Keep receiving a response from the check destination separate from getting the expected content back.

Note that NCSI does not run on this check traffic alone. The method where it checks on its own initiative is called the active probe, and the method where it judges from information such as received packets is called the passive probe; it uses both. So one failed HTTP request in the diagram is not the same thing as the final connectivity state ending up as no internet.¹

The point so far is that connecting to Wi-Fi, being able to use a given site, and Windows returning a verdict of Internet are each a separate check. Connecting to Wi-Fi alone tells you nothing about the route to the outside or about usage authentication, and reaching one site is no guarantee that another destination or another application will work.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (5 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. Three Common Situations Where the Display and the Traffic Disagree

At the Office, the Browser and the Connectivity Check May Take Different Paths

Let us make the company example from the opening a little more concrete. On corporate networks there are setups where you do not connect to the outside directly but go through a relay called a proxy. The mechanism that picks that relay according to the URL being accessed and similar criteria is the PAC file. Automatic detection is sometimes used as well.⁴

In this setup, an appropriate proxy may be selected for the sites people normally use while only the connectivity check destination falls outside the rules. Cases where proxy detection does not complete in time, or where only the HTTP traffic to the check destination is blocked, are also candidates to investigate.¹

flowchart TB
    accTitle: Check the browser path and the NCSI path separately
    accDescr: Success for the browser's traffic does not guarantee success for NCSI, which uses a different destination and proxy selection.
    pc["The same PC"] --> browser["Browser request"]
    pc --> ncsi["NCSI check request"]
    browser --> bpath["Proxy and authentication for that request"]
    ncsi --> npath["Proxy and authentication for the check request"]
    bpath --> site["Web site that was used"]
    npath --> probe["Connectivity check destination"]

Figure 3: Being on the same PC does not necessarily mean the same path. Check the destination, proxy, and authentication for each request.

So look beyond whether the browser succeeded, and find out which proxy was selected for NCSI’s request, and under which account or authentication conditions it communicated. The same goes for the manual curl check used later. Not treating the three as traffic under identical conditions is the starting point for isolating the problem.

At a Hotel, a Sign-In May Still Be Pending After You Join the Wi-Fi

On Wi-Fi at hotels and similar places, you may be asked to accept terms of use or to sign in after the radio link is up. This authentication gateway is a captive portal. If the check request is redirected to the authentication page, or a sign-in screen is returned, it does not become the normal check response. Windows opening a browser to prompt you to sign in is also related to this mechanism.³

flowchart TB
    accTitle: The difference between joining Wi-Fi and portal authentication
    accDescr: Even after the wireless connection succeeds, traffic to the outside can stay restricted until the network side authentication is complete.
    wifi["Connected to Wi-Fi"] --> portal{"Is usage authentication complete"}
    portal -->|"Not complete"| signin["Authenticate from the official page"]
    portal -->|"Complete"| test["Recheck the actual traffic and the verdict"]
    signin --> test

Figure 4: Finishing the connection to Wi-Fi does not mean you have finished authenticating to use that network.

Because there are cases where only the venue’s information page is viewable, do not conclude from one page opening that all outbound traffic has been permitted. Authenticate by following the venue’s official instructions, and then confirm the actual traffic and the Windows display. Do not enter account or card details into a suspicious sign-in screen.

With a VPN, “Which Connection the Result Came From” Changes

Before and after a VPN connection, the traffic path and the conditions for using DNS can change. Settings not being in place right after connecting, or check traffic heading down an unintended path, are also candidates for an NCSI failure.²

In that case, do not view the PC as a single connected or not connected state; separate the physical LAN or Wi-Fi from the VPN. For example, if the design has the physical side at LocalNetwork while you go out to the internet through the VPN side, one line about the physical side is not enough to declare something wrong. Read the connection profiles in Chapter 4 together with the path that was actually used.⁵⁶

flowchart TB
    accTitle: Separate the connection path and the IP family
    accDescr: Separate the physical LAN from the VPN and IPv4 from IPv6, and map the path the traffic used to each verdict.
    pc["List the connections"] --> physical["Physical LAN and Wi-Fi"]
    pc --> vpn["VPN adapter"]
    physical --> p["IPv4 and IPv6 verdicts"]
    vpn --> v["IPv4 and IPv6 verdicts"]
    p --> route["Correlate with the actual traffic path"]
    v --> route

Figure 5: Keep physical connection versus VPN, and IPv4 versus IPv6, distinct while comparing against the actual traffic path.

The same goes for IPv4 and IPv6. NCSI handles the active probes for both in parallel, and success on either one is enough to conclude there is a connection to the internet. The fact that one of them is not Internet does not by itself mean the whole PC is offline. Which of the two a particular application used is something you observe separately for that traffic.¹

If you want to compare by disconnecting the VPN, do it on a test machine your organization has approved or during an approved change window. Do not disconnect an always-on VPN without permission just to investigate.

3. The First Split Is “Only the Display, or Is the Traffic Broken Too?”

Once you know the candidate causes, apply them to your own symptoms. First confirm whether new traffic works right now, for example by opening a new page on a site you are permitted to use. A screen that has been open since earlier tells you nothing about the current state of the connection.

Instead of “the network works”, get specific enough to write “at this time, in this application, to this destination, this operation succeeded”. That narrows down what to investigate.

This is not a table that identifies the cause; it is a table for choosing where to check next. Even if a display anomaly is what prompted this, if the business app you want to use is failing, record that traffic result separately as well.

From here on are the investigation steps. Proceed in this order: capture the state, read the check destination settings, compare against manual traffic, then confirm with NCSI’s own records. Do not change corporate proxy, VPN, or security settings without permission; start with read-only inspection and a small number of traffic checks.

4. Before Changing Settings, Confirm Where It Failed

4.1 Record the Time of Occurrence and the Connection State

First, record the time of occurrence, the OS build, how you are connected, whether a VPN is in use, and which application fails. You can check the OS version with winver. Then display the connection profiles in PowerShell.⁵

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

What to read is the connection name, InterfaceAlias and InterfaceIndex, and IPv4Connectivity and IPv6Connectivity. When there are several rows, read them while keeping track of which connection each result belongs to. The point is to compare results from the same time and the same connection against the manual tests and logs that follow.

The Public / Private / DomainAuthenticated values of NetworkCategory are a classification separate from the internet connectivity verdict. Changing Public to Private is not a general repair step for “No internet”. The output can contain things like internal network names, so mask any unnecessary identifying information before handing it to a third party.⁵

4.2 Read Which Destination This PC Is Configured to Check

Before trying the standard check destination, confirm whether this PC uses the same settings. The following code only displays values; it does not modify the registry. It reads the IPv4-side and IPv6-side check destinations and the expected body, along with the policies that control things such as the active test.¹⁷

$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 {
    'There is no NCSI policy at this registry path.'
}

ActiveWebProbeHost and ActiveWebProbePath are the check destination, and ActiveWebProbeContent is the expected body. Record the values with V6 in the name as well. If a custom check destination is configured, align the manual tests below with that setting and with your management policy.

Output saying there is no policy key means there are no settings at that path. It is not proof that no management configuration exists at all, including through MDM. Do not guess and create a key you could not find; confirm with your administrator.

For proxies, check the Windows Settings screens and the management policies. For the WinHTTP settings, netsh winhttp show advproxy in environments that support it, or netsh winhttp show proxy in older environments, gives you material for comparison. What you learn there, however, is the configuration. The route NCSI actually selected through PAC or automatic detection has to be correlated with the traffic records described later.⁸⁴

4.3 Separate Whether the Name Resolves from Whether TCP Connects

From here on are manual comparison tests against the standard check destination. What you want to know is whether the destination name cannot be resolved, or whether things stop at the connection beyond it. First, check name resolution and the TCP connection separately.

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

The -Type A in Resolve-DnsName specifies looking up the IPv4 address. Observe with your usual DNS settings in place at first. Switching straight to a public DNS server changes internal name resolution and your management policy too, which makes the original problem harder to follow.⁹

What Test-NetConnection -Port 80 tells you is the TCP connection to the given destination. It does not check the HTTP body or proxy authentication. In an environment where direct connections are prohibited and only traffic through an HTTP proxy is allowed, a failure of this TCP test can be normal. Save InterfaceAlias and SourceAddress too, and confirm which path the result came from.⁶

flowchart TB
    accTitle: The questions the manual tests answer
    accDescr: Name resolution, the TCP connection, and the HTTP response cover different scopes, so do not treat success at one as a guarantee for the next layer.
    name["Resolve the name with DNS"] --> tcp["Check the TCP connection to the destination"]
    tcp --> http["Check the HTTP response and body"]
    http --> own["Compare against NCSI's own records"]
    tcp -.-> proxy["A different path where a proxy is mandatory"]

Figure 6: Name resolution, the TCP connection, and the HTTP response each confirm a different thing, in that order.

4.4 With HTTP, Look at the Body, Not Just the Status

Next, look at whether the check body described in Chapter 1 comes back. On a machine where curl.exe is available, run the following a small number of times. Write out the .exe so it is not confused with the PowerShell alias.

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

--include is the option that displays the headers along with the body. Timeouts are set for the connection and for the operation as a whole, and because -L is not given, it does not follow a redirect automatically, so you can see the first response. The leading -q tells curl not to read its default configuration file, but it does not clear proxy-related environment variables.¹⁰

A minimal example of the expected content follows. This is for explanation; it is not a measured log from this article. In practice, other headers are present as well.²

HTTP/1.1 200 OK
...

Microsoft Connect Test

What matters here is that the manual test is not a substitute for NCSI; it is material for comparison. curl is not a test that inherits Windows’ PAC settings or the browser’s authentication state in the same way. A result of “the browser succeeded, curl failed” alone does not establish that NCSI is malfunctioning.

Confirm with your administrator how proxies are meant to be used, and do not write credentials directly into your command history. And even when this HTTP check succeeds, it is no guarantee that HTTPS and authentication for a business API will succeed.

4.5 Finally, Look for the Records of NCSI Actually Failing

Once the manual tests have brought candidates into view, check NCSI’s own behavior. The way in is Event Viewer, under Applications and Services Logs → Microsoft → Windows → NCSI. Check the Operational log around the time of occurrence.¹¹

Rather than a single error line, read on through which interface it started on and whether it completed, what the failure reason was, and how the connectivity state changed afterward. Correlate at the same time and on the same path as the manual tests, and combine with an approved packet capture if needed.¹¹

flowchart TB
    accTitle: The order in which to read the NCSI logs
    accDescr: Connect the start, the completion, the failure reason, and the state change by time and interface.
    start["Which path it started on"] --> finish["Whether it completed"]
    finish --> reason["Result code and failure reason"]
    reason --> state["The connectivity state afterward"]
    state --> correlate["Correlate with traffic records from the same time"]

Figure 7: Connecting the start through to the state change makes it easier to trace what differed between the manual test and NCSI.

If the result code is a WinHTTP error, look up its meaning in the WinHTTP table. For example, 12007 means the name could not be resolved, and 12002 is a timeout. What you learn, however, is a clue about the stage that failed; that alone does not settle that a DNS server has failed or that the line is down.¹²

If the detail is insufficient, an administrator enables the Analytic log from “Show Analytic and Debug Logs”. This is a change to diagnostic settings, so record the time you enabled it, reproduce the problem, and restore the original state after collecting. Enabling it does not let you retrieve detailed events from before it was enabled.¹¹

Also, reconnecting Wi-Fi or disabling an adapter to reproduce the problem can drop management connections such as RDP. Do not run these without warning on a production machine or on a machine you are operating remotely. Traffic records can contain host names, IP addresses, and authentication-related information, so restrict where they are stored and who they are shared with.

In the company example from the opening, this is where you correlate the 403 from manual HTTP, the NCSI log from the same time, and the proxy denial records your administrator can see. If only the check destination was being denied, fix that rule and retest. If only the manual test took a different path, revisit the comparison conditions. Do not decide from the number 403 alone that it is “an NCSI bug” or “a problem with our proxy”; choose the next action according to the records. This is a hypothetical isolation example, not the findings of a real engagement.

5. Do Not Try to Fix Only the Display with Old Workarounds

Do Not Confuse Windows 11 DNS Traffic with the Legacy DNS Probe

Older write-ups feature a DNS probe to dns.msftncsi.com. The official NCSI FAQ, however, explains that the active probe on Windows 11 and later uses HTTP. Even when there is DNS traffic in a Windows 11 record, it may be the name resolution for the HTTP destination.²

flowchart TB
    accTitle: Distinguish the role of the DNS traffic
    accDescr: Read the name resolution for the Windows 11 HTTP destination and the legacy DNS probe as different things.
    dns["There is DNS traffic in the record"] --> purpose{"What is the traffic for"}
    purpose --> http["Name resolution for the HTTP destination"]
    purpose --> legacy["The legacy DNS probe"]
    http --> win11["Can be needed on Windows 11 as well"]
    legacy --> version["Check the OS version and the actual logs"]

Figure 8: The DNS traffic that looks up the HTTP destination and the DNS probe itself are different things.

So the older explanation that “every DNS query separate from HTTP has to succeed” cannot be made a rule common to all versions of Windows. Read the OS version you are investigating together with the actual logs.

Another confusing point is the name of the settings location. On Windows 11, the component that runs NCSI has moved from the traditional NLA to the Network List Manager side, but settings such as the check destination still use the registry path that includes NlaSvc from Chapter 4. Do not decide which service runs it merely because the path says NlaSvc.¹

Stopping the Check Does Not Repair Traffic That Was Not Getting Through

Setting EnableActiveProbing to 0, or prohibiting the active test by policy, are settings that restrict the connectivity check. They are not operations that repair a DNS failure or a proxy route. Keep adopting this as a management policy for an isolated network separate from changing it in order to make a warning go away. Microsoft does not recommend disabling the active probe as a solution to NCSI problems either.⁷¹

For the same reason, returning a fake success response, turning off the firewall wholesale, or disabling IPv6 without grounds are not first steps. The display changing and the traffic you want to use improving are two different things.

flowchart TB
    accTitle: Do not judge a repair by the display alone
    accDescr: After a configuration change, confirm not only the change in the display but also the failure point and the improvement in the traffic you need.
    change["A change with grounds"] --> probe["Recheck the connectivity check traffic"]
    change --> app["Recheck the traffic you need"]
    probe --> judge["Judge the improvement from both results"]
    app --> judge

Figure 9: Even after making a change that has grounds, confirm both the check traffic and the traffic you want to use.

When fixing corporate allow rules too, do not finish by statically registering the IP addresses from an old article. The delivery infrastructure behind NCSI’s public check destination can change, and Microsoft advises against allow rules that depend on specific IP addresses. Work with your administrator on rules that match the actual check destination, service, and route.²

6. For Developers: Do Not Decide “Do Not Communicate” from NCSI Alone

Everything so far also bears on Windows application design. If the OS says “No internet” and you therefore mark the app offline without trying the request you need even once, you may be stopping traffic that would actually work. Conversely, it is also a mistake to think that a business API is bound to succeed because the OS says Internet.

INetworkListManager::get_IsConnectedToInternet, which retrieves the OS-wide connectivity verdict, is an API that returns the local machine’s internet connectivity state. It does not guarantee that an individual API or file share is running, that authentication succeeds, or that you have permission to use it.¹³

In design terms, you can sum it up as use the OS connectivity state as a hint for display and reconnection, and manage the success or failure of the traffic you need separately. The aim is to be able to hold two facts at the same time: “Windows’ verdict is LocalNetwork, and the business API was reachable”.

flowchart TB
    accTitle: Manage the OS verdict and the business traffic result separately
    accDescr: Use the OS connectivity information as a hint, and give the traffic you need its own independent handling of success and failure.
    status["OS connectivity state"] --> hint["Hint for display and reconnection"]
    request["The request you need"] --> outcome{"The actual result"}
    outcome --> ok["Handle as success"]
    outcome --> error["Record the failure reason"]
    error --> retry["Retry after confirming it is safe"]

Figure 10: Use the OS verdict as a hint while giving business traffic its own handling of success and failure.

Do not collapse the log into the single word “offline” either; record the stage of the failure you were able to observe, such as DNS, the connection, TLS, authentication, or the HTTP response. Give requests timeouts and cancellation so the UI is not left waiting.

Retrying after a timeout, though, comes with a separate caveat. An update operation such as placing an order or transferring money may already have executed on the far end even when the reply did not arrive in time. Do not decide “it timed out, so it did not run” and resend; make whether a retry is allowed, the mechanism that prevents duplicates, and the result lookup part of the application’s specification. This is not a problem NCSI will solve for you.

7. Summary: Read the Display and the Traffic as Separate Facts

“The network works but Windows says No internet” is not necessarily a contradiction. Connecting to Wi-Fi, communicating with the party you want to reach, and Windows’ own NCSI verdict are each checking something different.

First, separate whether only the display disagrees or the traffic you need is failing too. When investigating, use the check destination settings and the manual tests as material for comparison, and confirm the actual behavior in NCSI’s own logs. And after a change, look beyond the icon at whether the check traffic and the traffic you need have improved.

From “it should be connected” to “which traffic failed, and where”. Thinking in that order lets you narrow down where to look before you start changing settings at random.

Related Articles

• The Windows Firewall and Business Applications
• The Windows Certificate Store in Practice

References

Checked on September 11, 2026. For OS differences, the NCSI-specific official FAQ takes precedence, and the procedures in older client-oriented documentation are not treated as fixed specifications for Windows 11. Also confirm log display names and the available commands against your actual OS build and management configuration.

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Why does Windows show "No internet" when I am connected to Wi-Fi?

Because connecting to Wi-Fi, communicating with the service you want, and the connectivity verdict Windows reaches through NCSI are three different things. The display can disagree not only when the line itself is down, but also because of DNS, proxy, VPN, or captive portal problems that affect the check traffic. Start by confirming what can actually communicate.

If a site opens in the browser, can I conclude that NCSI is fine too?

You cannot. The destination, the proxy that gets selected, the authentication state, IPv4 versus IPv6, and the time of the request may all differ. Treat manual access as material for comparison, and confirm with NCSI's own event logs and, where needed, a packet capture.

Is a DNS probe to dns.msftncsi.com still required on Windows 11?

The official NCSI FAQ explains that the active probe on Windows 11 and later uses HTTP. Distinguish the DNS traffic that resolves the HTTP destination from the DNS probe used in older versions. The important thing is not to assume across the board that every request in an older procedure is mandatory.

Will setting EnableActiveProbing to 0 fix it?

That setting stops the check traffic; it is not a setting that repairs a cause such as DNS or routing. Except where you adopt it as a management policy for something like an isolated network, do not change it in order to make the display go away; investigate where the failure happens first.

If NCSI says Internet, am I guaranteed to reach our business systems?

Not necessarily. The OS connectivity verdict does not guarantee that an individual API or file share is running, that authentication succeeds, or that you have permission to use it. An application has to issue the traffic it actually needs and handle timeouts, cancellation, the kind of failure, and whether a retry is safe.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.