What Msftconnecttest.com Actually Is#
Msftconnecttest.com is not a site anyone chooses to visit. It is the endpoint Windows contacts on its own to answer one question every time the network changes: does this connection reach the internet, or is something standing in the way? The component asking is the Network Connectivity Status Indicator, written NCSI, and Microsoft's NCSI documentation calls what it sends an active probe.
The sequence is short. Windows resolves www.msftconnecttest.com, sends a plain HTTP GET to http://www.msftconnecttest.com/connecttest.txt, and checks that the body of that file is the exact text it expects. Windows 10 also resolves dns.msftncsi.com; from Windows 11 the HTTP probe is what decides. In the recorded lab behind this article, that file answered 200 with the body Microsoft Connect Test, exactly 22 bytes, and set no cookies.
Comparing the body is the entire mechanism, and it is what separates this from a ping. Reachability proves nothing on its own: a hotel network cheerfully answers every request with 200 and its own sign-in page. So Windows does not ask whether the file arrived, it asks whether the file is the right file. Microsoft's captive-portal rule is exactly that: a probe sent outside a known proxy, a response received, a payload that did not match. That is the no-internet warning in the tray and the sign-in prompt.
The probe travels unencrypted for the same reason: a portal cannot rewrite an HTTPS response without producing certificate errors, so a check designed to be intercepted has to be interceptable. Every major platform ships a version of it.
Is It Malware? Run the Check Yourself#
No, and you do not have to take that on trust. Two requests reproduce the whole basis for the answer. Run them from Command Prompt, or type curl.exe in PowerShell so you get the real binary rather than a shell alias.
curl.exe -sS -i http://www.msftconnecttest.com/connecttest.txt
curl.exe -sS -i http://www.msftconnecttest.com/redirectThe recorded run on 2026-07-29, from a network with no portal and no filtering, produced this:
connecttest.txt status 200, body Microsoft Connect Test, 22 bytes, no Set-Cookie
/redirect status 302
Location: http://go.microsoft.com/fwlink/?LinkID=219472&clcid=0x409Three details carry the rest of this article. The body is the literal string Windows compares against, 22 bytes with no trailing newline, which leaves nowhere to hide a payload or a tracker. The response set no Set-Cookie header, so the probe stores nothing and follows nothing. And /redirect, the URL behind the mystery tab, is a plain 302 into go.microsoft.com, Microsoft's own link-forwarding service.
Now the caveat, because reassurance is not evidence. The guarantee attaches to the registered domain, the two labels immediately before the first slash: anything can be placed in front of a dot, and near-miss spellings are cheap to register. Judge the page by what it asks for as well. This endpoint's entire vocabulary is 22 bytes of text and one redirect: no login form, no password prompt, no download, nothing for sale. A page that wants credentials, a card number, or an installer is the portal of the network you just joined, or something worse. Neither is Microsoft.
Why a Tab Opens by Itself and Lands on MSN#
Windows opens a browser window for two different reasons, and conflating them is why most advice on this subject misfires.
The first is the feature working. When a network requires a sign-in, the probe comes back wrong, Windows concludes a portal is in the way, and it opens your default browser so you can authenticate. Microsoft records that behavior as by design: it replaced a small notification users kept missing.
The second explains the MSN tab on a network with no portal at all. When the active probe cannot complete, Windows opens http://www.msftconnecttest.com/redirect deliberately. Microsoft's support article describes the resulting network trace precisely: a connection to that URL followed by a connection to the MSN portal, opened, in Microsoft's phrasing, for the benefit of the passive probe process, and if the page loads then NCSI concludes that the computer has internet access. Windows is not confused and not advertising at you: it is borrowing your browser as a second opinion, because a browser can often reach what the probe could not. Nothing intercepts that request on a portal-free network, so it reaches Microsoft, returns the 302 recorded above, and forwarding carries you to MSN.
The triggers explain the timing. Active probes fire on interface or network condition changes, proxy detection, and hotspot detection: joining a network, waking from sleep, roaming between access points, a link that flaps, a VPN connecting and rewriting the routing table.
One tab after joining hotel Wi-Fi is the system working. A tab that returns several times a day on your own network means the probe keeps failing, and the fault sits upstream of the browser.
What the Probe's Answer Rules In#
A status code on its own settles nothing here. Match what came back against the table and the fault narrows to one layer.
| What comes back | What it means | Where the fix lives |
|---|---|---|
| 200 with the exact probe text | The probe path is healthy right now | Not NCSI: check VPNs, tunnels, link stability |
| 200 with another body, or a 302 elsewhere | Something answered in Microsoft's place: a portal is intercepting | Sign in through that network's portal |
| 403 | A proxy on the path refused the probe | Proxy or PAC configuration |
| The hostname does not resolve | A resolver problem, the most common cause | DNS settings on the device or the network |
| Nothing: it hangs or is refused | Port 80 is blocked or dropped | Firewall rules on the path |
The second row is the one people misread: a captive portal returns a perfectly valid 200, so a browser looks satisfied while Windows correctly concludes the opposite. Microsoft's taxonomy names it a hotspot-detected probe failure, a 200 whose payload is not the expected text or a non-200 in its place. If that page belongs to a network you do not run, the probe worked as designed: sign in, or ask its operator.
For the machine's own verdict, read the Microsoft-Windows-NCSI channels in Event Viewer, where every connectivity change records a reason. The NCSI FAQ decodes them: a DNS probe failure, an HTTP probe that failed after the name resolved, or no route on the interface, the case a forced-tunnel VPN produces. One triage rule saves hours: applications insisting there is no internet while your browser loads pages normally is an NCSI fault rather than an outage, because Office and others ask Windows through a connectivity API instead of testing the network. If you cannot browse either, the fault is the network itself and none of this applies.
Fixes, in the Order That Works#
Ranked by how often each is the real cause, not by how easy it is to type. First, sign in if the network wants you to; if the login page will not load, disconnect any VPN and turn off encrypted DNS until you have, because both prevent the interception the portal depends on.
Second, and usually the answer on a network that otherwise works, DNS. Microsoft lists resolution failures for the NCSI lookup names among the reasons a probe fails, and notes they are most often intermittent rather than missing records, which is what a tab appearing twice a day looks like. Run ipconfig /flushdns, then resolve both names yourself:
nslookup www.msftconnecttest.com
nslookup dns.msftncsi.comThe FAQ gives 131.107.255.255 as the expected answer for the second name; anything else, a filter page, or no answer at all has found your fault, with no registry key touched. On equipment you control, fix the resolver; on a managed network it is the operator's.
Third, rejoin: forget the Wi-Fi and reconnect, or disable and re-enable the adapter, which reruns detection from scratch. Restarting the router only helps when the router is broken.
Fourth, VPNs, tunnels, and filtering software. A forced-tunnel VPN rewrites the routing table at connect time, and security suites that inspect HTTP sometimes catch connectivity-check hosts, as do broad blocklists. Turn one off at a time and watch; the proxy versus VPN comparison covers why a device-wide tunnel changes what the local network can see.
Fifth, on a managed machine, the proxy. Microsoft's list is specific: a proxy not yet discovered, a proxy unreachable when the probe runs, and a PAC file that does not map www.msftconnecttest.com to the correct proxy. One that refuses the probe answers 403. The proxy server guide covers why the system's proxy scope is not your browser's, and the proxy checker confirms an exit reaches the internet. That allowlist belongs to the network, not to the laptop.
The EnableActiveProbing Switch and Its Cost#
Nearly every page on this subject, and Google's own AI summary, ends on the same instruction: open HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc\Parameters\Internet, set EnableActiveProbing to 0, restart. It works by switching off the detection instead of repairing what the detection found, and that cost is almost never stated.
Microsoft states that cost three times. The NCSI overview warns against disabling active probing to resolve an NCSI issue, because passive polling alone cannot determine all connectivity issues. The support article is blunter: several operating system components and applications rely on NCSI, and it names Outlook unable to reach a mail server and Windows unable to download updates on a computer that is online. The managed Connectivity policy agrees that with active tests off, NCSI runs neither test, which may reduce the ability of NCSI and other components to determine internet access.
Priced honestly, you trade one browser tab for three things: captive-portal detection, so hotel Wi-Fi hands you a connection that looks healthy and carries nothing; an accurate answer for every application that asks Windows instead of testing the network itself; and the input NCSI feeds into the profile that decides which Windows Firewall profile applies.
That does not make the switch illegitimate. On a managed fleet permanently behind a proxy, where the probe can never succeed and the tabs carry a real support cost, it is defensible. Make it deliberately: back up the registry first, as Microsoft instructs, and prefer the supported policy under Computer Configuration, Administrative Templates, System, Internet Communication Management, Internet Communication settings, which writes NoActiveProbe instead. A policy is auditable and reversible without visiting machines one at a time; a hand edit is neither, and it outlives whoever typed it. What the switch is not is a repair. It silences a working alarm and leaves the fault the alarm was reporting.
If You Run the Network#
Two rules, and they are opposites, which is why guest networks get this wrong.
On a network with no captive portal, let the probes through untouched. Blocking msftconnecttest.com, sinkholing it in a DNS filter, or catching it in a broad blocklist does not make Windows machines trust your network; it convinces every one of them that your network is broken, with no-internet icons on working Ethernet and a tab opening at the redirect URL on every join. Allow the hosts by name, not by address: Microsoft moved the public probe servers to Akamai on 20 June 2023 and address-pinned rules broke that day, which is why the standing recommendation is that NCSI rules should not be IP-based. Allow plain HTTP on port 80, the port the probe uses rather than the one your proxy stack listens on, as the proxy ports guide explains. Do the same for the Apple and Android equivalents.
On a network with a captive portal the rule inverts: the probe hosts must be intercepted before sign-in, not allowlisted. Working correctly, the mechanism does your job: the client probes, your portal intercepts, the check fails, and your login page is what Windows opens. Guests landing on msftconnecttest.com/redirect instead means the portal missed that request. The usual cause is the pre-authentication walled garden: an administrator adds the probe hosts to it to stop no-internet complaints, so the one request the portal needed sails through to Microsoft, returns the 302 recorded earlier, and delivers the guest to MSN. After sign-in, allow the hosts fully.
Longer term, stop relying on interception alone. RFC 8910 defines a DHCP and router-advertisement option that tells a client it is behind a portal and where the portal lives, so a compliant client is informed instead of inferring it. And never advise a guest to switch off connectivity checking: that hides the prompt they need in order to sign in. The goal is making the legitimate login appear on the first try.
