Windows 11/10 Public Wi-Fi Login Page Missing? Restore Captive Portal Sign-In

Before changing settings​

Have the venue’s exact Wi-Fi name, wireless password if required, and any room number or access code ready. Ask staff to confirm the network name rather than choosing a similarly named hotspot. Mozilla specifically recommends checking that both the network and its sign-in page belong to the intended provider.

Use these precautions throughout:

Quick walkthrough

• On a work or school PC, do not override managed VPN, proxy, or DNS settings. Ask IT for an approved guest-network sign-in method.
• Record existing settings before changing them. Change one thing at a time, then repeat the browser test.
• Do not install an unexpected certificate, browser extension, or “Wi-Fi repair” application to make a login page appear.
• Do not bypass a certificate warning or enter sensitive information on an unverified page.

The procedures below apply to Windows 11 and Windows 10, but that is not a statement that every installation remains supported. Microsoft ended standard Windows 10 support on October 14, 2025. Fixing Wi-Fi does not change the operating system’s servicing status.

1. Request the login page manually​

Start here rather than clearing settings or resetting adapters.

• Confirm that you are connected to the venue’s official Wi-Fi.
• Disconnect and reconnect once. If Windows or your browser presents a network sign-in prompt, open it.
• Otherwise, open a browser and enter this exact address in the address bar, not a search box:

[Microsoft Connect Test](http://www.msftconnecttest.com/connecttest.txt)

• Press Enter and inspect the result. Microsoft documents this HTTP endpoint as a Windows connectivity test; when reached normally, it returns Microsoft Connect Test. The endpoint applies to Windows 10 version 1607 and later, including Windows 11.

Interpret the result before continuing:

• The venue’s login page appears: Complete its terms, voucher, or guest authentication process.
• Microsoft Connect Test appears: That test endpoint is reachable. Try an unrelated website next; do not assume access to one endpoint proves unrestricted internet access.
• The request times out or reports a name-resolution error: Continue with the browser, proxy, and DNS checks below.
• A certificate warning appears after redirection: Stop and ask staff to verify the portal rather than bypassing the warning.

These are diagnostic distinctions, not guarantees about a particular hotspot. Microsoft notes that a browser test can succeed even when Windows’ own connectivity checks fail, including because of proxy differences.

2. Test a private window before deleting browser data​

A private window is a useful first browser test because it avoids immediately deleting your normal browsing data.

• Open Microsoft Edge.
• Press Ctrl + Shift + N, or select Settings and more > New InPrivate window.
• Repeat the HTTP test from section 1.
• If the login page appears, complete it in that window, then test normal browsing.

Microsoft documents the InPrivate shortcut, and Mozilla recommends a private-window test when cached sessions might obstruct captive-portal sign-in. InPrivate is a browser-session test, not a replacement for network security.

If the normal browser keeps showing an old or broken portal​

Only clear browser data if the private-window test suggests a browser-specific problem.

Warning: Deleting cookies can sign you out of websites. Deleted browsing data cannot simply be restored. Microsoft also warns that synced data types can be deleted across devices when sync is enabled. For a local-only cleanup, first use Edge Settings > Profiles > Sync > Turn off sync.

• In Edge, press Ctrl + Shift + Delete.
• Choose a time range covering the failed sign-in attempts.
• Select Cached images and files. Add Cookies and other site data if you need to remove the failed login session.
• Leave passwords, autofill data, and unrelated categories unchecked.
• Select Clear now, then repeat the portal test. Restore your previous sync setting afterward if you changed it.

Do not keep deleting data if the same failure occurs in another browser or a fresh private window. Move to the connection checks instead.

3. Check whether a VPN or proxy is blocking sign-in​

Mozilla documents a common catch: the network requires portal authentication before allowing the VPN or proxy connection, while that connection prevents the browser from reaching the portal.

Warning: Temporarily disconnecting a VPN removes its protection. Close sensitive applications first, restrict the test to guest-network sign-in, and reconnect the VPN afterward. If your organization requires an always-on VPN, stop here and contact IT rather than weakening its controls.

• For a personally managed VPN, use the VPN application’s Disconnect control.
• Repeat the portal test.
• If unsuccessful, inspect Windows proxy settings:
• Windows 11: Settings > Network & internet > Proxy.
• Windows 10: Settings > Network & Internet > Proxy.

• Record any manually configured proxy address, port, exceptions, and setup-script address before changing them. Microsoft distinguishes manual proxy settings, automatic detection, and setup scripts; they are not interchangeable.

For a proxy you configured yourself and do not need on this guest network:

• In Windows 11, open the control beside Use a proxy server, switch it off, and select Save.
• In Windows 10, switch Use a proxy server off under Manual proxy setup.
• If you personally enabled Use setup script, record its address before temporarily switching it off.

Do not erase an unfamiliar organizational configuration or indiscriminately disable automatic detection. Repeat the browser test, then restore the recorded proxy settings and reconnect the VPN after authentication—or immediately if the test does not help.

4. Review custom DNS settings​

Use this step when you previously configured a static address or custom DNS, particularly if the browser reports that it cannot find a server. Microsoft identifies incorrect DNS configuration as a possible reason connectivity probes fail. Treat automatic addressing as a diagnostic test, not a guaranteed portal fix.

Warning: Record manual IP, gateway, and DNS values first. Switching to automatic configuration can interrupt access to networks that require those values. Do not change managed settings.

• Open Settings > Network & internet in Windows 11, or Settings > Network & Internet in Windows 10.
• Select Wi-Fi > Manage known networks, then choose the guest network.
• Beside IP assignment, select Edit.
• If it is manually configured, choose Automatic (DHCP) and Save.
• Repeat the browser test.

Microsoft documents automatic configuration as obtaining IP and DNS settings from the router or access point. If your Windows interface exposes a separate DNS assignment control, check it as well rather than assuming an IP change removed a separate DNS override. Restore your recorded manual configuration if the test fails or when returning to a network that requires it.

Check browser-level Secure DNS separately​

Changing Windows settings does not necessarily address a custom DNS provider selected inside the browser.

In Chrome, Google documents that automatic Secure DNS can fall back to unencrypted DNS, whereas a custom provider does not use that fallback. This makes a custom setting worth testing when you see name-resolution errors.

Warning: Turning Secure DNS off reduces DNS-query privacy during the test. Record the existing provider and restore it afterward.

• Open Chrome > More > Settings > Privacy and security > Security.
• Find Use secure DNS.
• If you selected a custom provider, temporarily turn the feature off.
• Repeat the portal test, complete authentication if available, then restore the previous setting.

If the setting is controlled by your organization, do not try to unlock it through registry or policy changes.

5. Refresh cached DNS and the Wi-Fi address​

Try a targeted refresh before a system-wide reset.

• Search Start for Command Prompt, then select Run as administrator.
• Run:

ipconfig /flushdns

• Repeat the browser test.

This clears the Windows DNS resolver cache, including cached lookup failures. It does not choose a different DNS provider. No manual rollback of cached entries is needed.

If access still fails, renew the DHCP configuration for the Wi-Fi adapter.

Warning: Releasing its address interrupts connectivity. Do not do this during a remote-support session that depends on that connection.

• Run ipconfig and identify the Wi-Fi adapter name.
• If its name is Wi-Fi, run:

 ipconfig /release "Wi-Fi"
 ipconfig /renew "Wi-Fi"

Substitute the actual adapter name if different.

• Retry the browser test after renewal.

These commands target the named adapter and require automatic DHCP addressing. Renewal requests configuration again; if it fails, reconnect to the hotspot and ask its operator for help rather than inventing an IP address.

6. Verify that authentication actually succeeded​

Do not stop at a portal’s “success” message. Use this check:

• Open a new tab and load an unrelated HTTPS website.
• Load a second site to distinguish general access from one reachable destination.
• Reconnect your VPN and restore any temporarily changed browser or proxy settings.
• Repeat the browsing test.

If browsing works but Windows still reports no internet, do not repeatedly reset a working connection merely to change the icon. Microsoft documents that Windows connectivity detection can fail independently of a browser test. It also advises against disabling NCSI probes: Windows components and applications depend on them.

When to stop troubleshooting the PC​

Use the pattern of failure to choose the next action:

• The portal never appears on multiple devices: Ask venue staff to check the guest network.
• The portal appears but rejects your voucher or guest details: Ask staff to verify authorization; resetting Windows is not the appropriate next test.
• Sign-in works only with a VPN or proxy disconnected: Consult that provider’s captive-portal guidance before using the connection for sensitive work.
• The same portal message keeps returning despite working browsing: Ask the network operator whether its redirection or connectivity checks are malfunctioning.

Mozilla’s guidance similarly directs persistent public-hotspot failures to the network operator and VPN-dependent failures to the VPN or proxy provider.

Use Network reset only as a last resort​

Reserve this for a PC that also fails on other networks—not merely one hotel login page.

Warning: Network reset removes network adapters and their settings, then reinstalls adapters after restarting. VPN software and Hyper-V virtual switches may need reconfiguration. Save your work, record custom settings, and ensure you have a recovery connection or required installers before proceeding. There is no simple one-button undo.

• Open the appropriate path:
• Windows 11: Settings > Network & internet > Advanced network settings > Network reset.
• Windows 10: Settings > Network & Internet > Status > Network reset.
• Select Reset now > Yes.
• Allow Windows to restart.
• Reconnect to Wi-Fi and repeat the HTTP portal test.
• Restore necessary networking software and recorded settings.

If the guest login still fails, give the operator the exact Wi-Fi name, failure time, browser error, whether another device can sign in, and which test first failed. Keep access codes and personal guest details out of public troubleshooting posts.