Windows 8.1 and older did a better job of detecting “captive portals” (Wi-Fi networks that require logins) and determining whether the state of a computer’s internet connection than Windows 10. Android has never been good at it. I looked into how different operating systems interact with internet connectivity tests.
Every major operating system tries to fetch a test file over the web as soon as a new network interface comes online. This check is meant to detect whether the device is connected to the internet, and to detect whether something may have interfered with the fetch request. Some operating systems also repeat this test every few minutes.
These tests are used to determine the quality of a Wi-Fi network, determine whether a paid Wi-Fi hotspot is available, check whether the device is online, and to detect “captive portals” or networks that require you to login. the test also tests networking services such as DNS and routing.
These tests require any intermediary services to process the requests as expected. Unfortunately, due to a configuration problem with the test endpoints (the URLs used for testing), some intermediary services such as a web cache or accelerator may serve stale test results. Meaning that an Android device, Amazon Kindle, Xbox, or Windows 10 computer may think they’ve got a working internet connection when the network is down.
A transparent proxy cache (or “web accelerator”), works by intercepting unencrypted network traffic and storing files fetched over the network locally for later use. If the same or different device request the same file, it can be served from the cache without having to download the same file again. Caching proxies are more common on corporate networks, but can also be found in some residential routers or shared networks such as at an airport or café. It can also be installed on a local device as an add-on software. Whether a file is stored in the cache or not is controlled by the URL’s caching-policy (HTTP headers such as Cache-Control and Expires).
Some test endpoints allow caching, meaning that the full test won’t be performed and the test file can be served by a local cache. The below table shows caching policies for some popular operating systems and devices.
|http://www.msftconnecttest.com/connecttest.txt||default||Windows 10 and Xbox||Hosted on Microsoft Azure|
|http://www.msftncsi.com/ncsi.txt||revalidate||Windows 8.1 and older||Hosted on Akamai|
|http://captive.apple.com/hotspot-detect.html||5 min||macOS 10.10 and iOS 8 and newer||Hosted on Apple IP range on Apache Traffic Server|
|http://www.apple.com/library/test/success.html||0 sec||macOS 10.9 and iOS 7 and older||Hosted on Akamai|
|http://connectivitycheck.gstatic.com/generate_204||default||Android 5 and newer, Google Chrome browser|
|http://play.googleapis.com/generate_204||default||Android 7 and newer||(fallback 1)|
|http://clients3.google.com/generate_204||default||Android 4 and older||(fallback 2)|
|http://network-test.debian.org/nm||revalidate||Debian Linux||NetworkManager, not enabled by default|
|http://detectportal.firefox.com/success.txt||revalidate||Firefox browser||Hosted on Amazon S3|
|http://spectrum.s3.amazonaws.com/kindle-wifi/wifistub.html||default||Kindle||Hosted on Amazon S3|
A ”default” policy means any cache is free to set their own caching policy. Subsequent requests may be served from the cache for the next couple of minutes or even days, depending on the cache implementation and policies, and demand and available storage. Revalidating or short cache duration means any cache must reach out over the internet to the connectivity test endpoint, and thereby retest that the internet connection is indeed working every time rather than bypassing the actual check and serving from the cache.
Windows 8.1 and older did everything correct with test endpoints hosted by Akamai. Once Microsoft brought the testing endpoint in-house and over to their own Azure hosting platform — their knowledge of how to configure a test endpoint seems to have got lost along the way. During a network outage, a Windows 10 device will happily report that the internet connection is working as long as it got the test endpoint from a local cache. Windows 8.1 and older would have reported that the internet connection was broken. Notably this is the exact same issue that makes the Microsoft Network Speed Test app unreliable.
Newer versions of Apple’s macOS and iOS operating systems relies on a test endpoint hosted by Apple, whereas older versions relied on Akamai. Both versions are proxy-aware though newer versions of their operating systems test against an endpoint that can be cached for 5 minutes. This allows a corporate network or a school to rely the same test result to all devices within a five minute time slot before repeating the test. This can ease the load on Apple’s test endpoint as well as speed up testing on networks with many devices.
Android devices are blissfully unaware of the impact of caching on their test endpoints. What is more interesting is that Android is the only operating system with multiple test endpoints in case one is either blocked by a network administrator or has some other problem.
It’s interesting to note that Mozilla, the organization behind the Firefox web browser, has a firm grasp of how to do this correctly. Mozilla’s test endpoint is hosted by Amazon S3. Amazon uses their own hosting service to host the test endpoint they use for their own Amazon Kindle line of ereaders. However, Amazon haven’t configured their own endpoint as well as Mozilla. Further more, Amazon devices will disconnect from a network if the test service is unreachable. During an outage of the S3 hosting platform in , customers reported that their Kindle devices couldn’t join Wi-Fi networks at all.
In summary, older versions of Windows and iOS were more reliable than newer versions when it comes to detecting their internet connectivity status. It could seem know-how and familiarity with the HTTP specification is passing into oblivion, as newer test endpoints don’t announce any caching policies.