Browser Works but Apps Won’t Connect? Why Windows Treats Them Differently

by
TL;DR — Key Takeaways
  • This is not your router. Other devices work, so the fault is a per-PC software layer rather than the network.
  • Browsers cheat. They ship their own DNS, their own proxy handling, and their own certificate checks. Apps use Windows for all three.
  • Four causes cover almost every case. A stale WinHTTP proxy, a broken OS resolver, a dead IPv6 path, or half-removed security software.
  • Disabling antivirus proves nothing. The kernel filter driver stays loaded until you properly uninstall it.
  • An in-place Windows upgrade preserves all of it, which is why moving to Windows 11 changes nothing.

Why the browser works when apps won’t connect

When apps won’t connect and the browser is fine, the reason is that your browser barely uses Windows networking. It brings its own DNS resolver, its own proxy logic, and often its own certificate store. Desktop apps hand all of that to the operating system. Break the operating system path and the browser never notices.

The symptom is specific and worth stating clearly. Web pages load. Online games work. Streaming in a browser tab is fine.

Meanwhile Discord, Spotify, the Microsoft Store, and game launchers all fail to connect. The web versions of those same services work in a tab.

When apps won’t connect in that exact pattern, most of the usual suspects are already ruled out. Your cable, your router, and your ISP are all doing their job. Other devices on the network prove it.

The one-line diagnosis

If the browser works and apps won’t connect, stop testing the network. The fault is in a Windows software layer that browsers bypass. That narrows the search enormously.

Your PC does not have one network stack

Windows offers several separate HTTP stacks, and every program picks one. Microsoft documents at least five options for developers. Each reads its own configuration. A setting that breaks one stack can leave the others working perfectly.

Microsoft’s own guidance on choosing a Windows HTTP stack lays this out plainly. Services should use WinHTTP. Interactive desktop apps that need Internet Options settings should use WinINet.

Modern apps often use Windows.Web.Http or .NET’s HttpClient instead. Cross-platform apps frequently bundle libcurl or Chromium’s networking code.

What browsers do differently

Chrome, Edge, and Firefox use none of those Windows stacks. They ship a complete network implementation inside the browser.

That gives them four escape hatches your apps do not have:

  • DNS. All three can resolve names over DNS over HTTPS, skipping the Windows resolver entirely.
  • Proxy. They read system proxy settings, but not the separate machine-level WinHTTP configuration.
  • IPv6. They race IPv6 and IPv4 concurrently and drop the loser within milliseconds.
  • Certificates. Firefox validates against its own certificate store rather than the Windows one.

Each of those maps to one of the four causes below. Work through them in order.

Cause 1: A stale WinHTTP proxy

Windows keeps a second proxy configuration that never appears in the Settings app. It is called the WinHTTP proxy, and services read it. A leftover entry from a VPN or a removed tool sends app traffic to a proxy that no longer answers.

This one is the most commonly missed, because nothing in the normal troubleshooting path touches it. It survives app reinstalls, driver updates, and DNS flushes.

How to check it

Open Command Prompt as administrator and run the check below.

netsh winhttp show proxy

A healthy machine reports direct access with no proxy server. Anything else deserves attention, especially an address you do not recognize.

How to fix it

Clear it back to the default. Microsoft documents the reset in its netsh winhttp reference.

netsh winhttp reset proxy

If you legitimately need a proxy, import the one your browser already uses instead.

netsh winhttp import proxy source=ie

Restart the machine afterward. Then retest the failing apps before moving on.

Cause 2: The browser resolves names and Windows does not

Browsers can resolve names using their own encrypted DNS. If the resolver Windows is configured to use has failed, apps lose name resolution while the browser carries on. Flushing the cache does not help, because the cache is not the problem.

This is the trap in ipconfig /flushdns. It empties cached answers. It does not change which server Windows asks.

How to check it

Query a name twice, once through your configured resolver and once through a known-good one.

nslookup discord.com
nslookup discord.com 1.1.1.1

If the second command succeeds and the first fails, your configured resolver is the fault. Set a public resolver manually and retest.

Our guide on DNS server not responding walks through changing the resolver on Windows. Our DNS Lookup tool gives you an independent third-party answer to compare against.

Encrypted DNS in the browser is worth understanding here. Our article on why DNS over HTTPS bypasses Pi-hole explains the same mechanism from the filtering side.

Cause 3: A broken IPv6 path the browser hides

Browsers try IPv6 and IPv4 at the same time and keep whichever answers first. Many desktop apps try only IPv6 and wait for a timeout. A half-broken IPv6 configuration therefore breaks apps while costing the browser a quarter of a second.

The browser behavior has a name and a standard. RFC 8305 defines Happy Eyeballs version 2.

The numbers in that document explain why you never notice. It recommends a Connection Attempt Delay of 250 milliseconds between families. It also recommends waiting only 50 milliseconds for an IPv6 answer after an IPv4 one arrives.

The RFC even has a section devoted to hostnames with broken AAAA records. That scenario is common enough to standardize around.

How to check it

Ping a well-known host over each protocol and compare.

ping -4 discord.com
ping -6 discord.com

If the IPv4 test succeeds and the IPv6 test fails, you have found a strong suspect. Disable IPv6 on the adapter temporarily and retest the apps.

Turn IPv6 back on afterward

Disabling IPv6 is a diagnostic step, not a fix. If it resolves the problem, the real repair is at the router or the ISP. Leaving IPv6 off long-term causes its own issues.

Cause 4: Security software that is disabled but not gone

Turning off antivirus in its interface stops scanning. It does not unload the kernel driver that inspects your traffic. That driver sits inside the Windows network stack and keeps filtering, which is why disabling protection so often changes nothing.

Security products hook the network using the Windows Filtering Platform. Microsoft describes it as hooks into the network stack plus a filtering engine.

Older products install a Winsock layered service provider instead. Both survive a UI toggle.

How to check it

Inspect the Winsock catalog for entries that are not from Microsoft.

netsh winsock show catalog

If the vendor is a security product you removed months ago, reset the catalog and restart.

netsh winsock reset

Our Windows network reset commands guide covers what each reset does and the safe order to run them.

For a true test of the antivirus itself, uninstall it with the vendor’s removal tool. Most major vendors publish one specifically because a normal uninstall leaves drivers behind. If you are rebuilding your security stack afterward, our roundup of network security software covers what is worth running.

Why Microsoft Store apps can fail on their own

Store apps run inside AppContainer, a sandbox that denies network access by default. An app must declare a capability to reach the internet or the local network. When only Store apps fail, the sandbox is a more likely cause than your network settings.

Microsoft documents this as AppContainer isolation. Packaged apps declare capabilities such as internetClient or privateNetworkClientServer in their manifest.

Windows ships a tool for inspecting the exemptions. Run it from an administrator prompt.

CheckNetIsolation LoopbackExempt -s

This matters as a discriminator more than as a fix. Use the split to narrow why your apps won’t connect.

Which programs fail tells you which layer is broken.
What fails What works Most likely cause
Store apps only Discord, Spotify, launchers AppContainer sandbox or Store cache
Everything except the browser Browser WinHTTP proxy, resolver, IPv6, or filter driver
One app only All others That app’s own settings or account state
Everything including the browser Nothing Ordinary connectivity fault

That last row is a different problem entirely. Our network troubleshooting guide covers it step by step.

Why upgrading to Windows 11 changed nothing

An in-place upgrade is built to preserve your apps, drivers, and settings. That preservation includes every layer discussed above. The WinHTTP proxy, the Winsock catalog, installed certificates, and third-party filter drivers all carry straight across.

People reasonably expect a new operating system to be a fresh start. The upgrade path is the opposite by design.

Only two things actually clear these layers. A clean install wipes them. A targeted reset removes them individually, which is faster and far less disruptive.

That is why the ordered approach below beats reinstalling Windows.

The diagnostic order for apps that won’t connect

When apps won’t connect, work from cheapest to most disruptive and retest after each step. Most cases resolve in the first three. Nothing here risks your files, and only the final step affects saved network settings.

  1. Run netsh winhttp show proxy and reset it if anything unexpected appears.
  2. Compare nslookup against your resolver and against 1.1.1.1.
  3. Compare ping -4 against ping -6 to test the IPv6 path.
  4. Check netsh winsock show catalog for leftover security software entries.
  5. Uninstall any security suite properly using the vendor’s removal tool.
  6. Run netsh winsock reset, then restart the computer.
  7. Run netsh int ip reset only if the earlier steps fail.

Note down any static IP or manual DNS values before step seven. That reset returns them to automatic.

Related tools and resources

NetworkCheckr has free tools that help confirm each step above. The DNS Lookup tool gives an independent answer to compare against your machine. The My IP Address tool shows whether you have a working IPv6 address at all.

Frequently asked questions

Why does my browser work but apps won’t connect to the internet?

Because browsers and desktop apps use different network paths on Windows. Browsers ship their own DNS, proxy handling, and certificate checks. Apps rely on Windows for all three. A stale proxy, a broken resolver, a dead IPv6 route, or leftover security software can break the app path. The browser stays untouched.

Does flushing DNS fix apps that will not connect?

Rarely. The command ipconfig /flushdns clears cached lookups, but it does not change which resolver Windows is configured to use. If the configured resolver is unreachable or wrong, flushing empties a cache and then refills it with the same failure. Check the resolver itself rather than the cache.

What does netsh winhttp show proxy do?

It displays the machine-level WinHTTP proxy, which is stored separately from the proxy shown in Windows Settings. Windows services and components such as Windows Update read this value. A leftover entry here routes app traffic to a proxy that no longer exists, while browsers ignore it entirely.

Why did upgrading from Windows 10 to Windows 11 not fix the problem?

An in-place upgrade is designed to keep your apps, drivers, and settings. That includes the WinHTTP proxy, the Winsock catalog, installed certificates, and any third-party network filter drivers. The upgrade carries the fault forward. Only a clean install or a targeted reset clears those layers.

Is disabling my antivirus enough to rule it out?

No. Turning off protection in the interface stops scanning, but the kernel-level filter driver usually stays loaded and keeps inspecting traffic. Ruling it out properly means uninstalling with the vendor’s own removal tool, then restarting. Many vendors publish a dedicated cleanup utility for exactly this reason.

Why do only Microsoft Store apps fail on some PCs?

Store apps run inside AppContainer, a sandbox that blocks network access unless the app declares a capability for it. Regular desktop programs have no such restriction. When Store apps fail but Discord and Spotify work, the sandbox is the likely cause rather than your network configuration.

Can a broken IPv6 connection stop apps from connecting?

Yes. Browsers race IPv6 and IPv4 at the same time using Happy Eyeballs. A dead IPv6 path costs them a fraction of a second. Apps that try IPv6 alone simply time out. Disabling IPv6 briefly is a fast way to test whether this is your cause.

References

  1. Microsoft Learn — About WinHTTP, including the guidance table on choosing a Windows HTTP stack
  2. Microsoft Learn — netsh winhttp command reference (show, import, reset)
  3. Microsoft Learn — netsh winsock command reference
  4. Microsoft Learn — About Windows Filtering Platform
  5. Microsoft Learn — AppContainer isolation
  6. Microsoft Learn — Capability element, UWP package manifest schema
  7. RFC 8305 — Happy Eyeballs Version 2: Better Connectivity Using Concurrency
  8. Mozilla Support — Configure DNS over HTTPS protection levels in Firefox
  9. Microsoft Learn — DnsOverHttpsMode policy for Microsoft Edge
  10. Microsoft Learn — Setting WinINet proxy configurations in WinHTTP
Secret Link