Hours after the release of iOS 6 on Wednesday, quite a few folks began noticing that their newly upgraded iPhones and iPads were having trouble staying connected to WiFi networks. The behavior was odd, too—after selecting the WiFi network to which you wanted to connect, iOS would spin for a bit and then produce what looked like a WiFi captive portal log-in window, except the actual webpage displayed inside that window contained nothing but an Apple-styled "Page not found" error.

Fixes abounded—one popular one which originated from a MacRumors forum post and was picked up by Gizmodo and others suggested turning on auto HTTP proxy resolution in the iOS WiFi network settings. This appears to have produced middling success, but it didn't help everyone.

The behavior eventually cleared up as quickly and as mysteriously as it started. Was it a stealth iOS update? Can Apple alter your device's settings remotely without your consent? Should we all don tinfoil hats?

The answer is a bit more mundane. As pointed out on Twitter by @tylerc and echoed by our own Senior Apple Editor Jacqui Cheng, the root cause of the problem was a combination of iOS's default behavior of connecting to a WiFi network, coupled with some trouble on Apple's end. When iOS attaches to a WiFi network, it checks to see if that network requires additional credentials by attempting to access this file on Apple's website. If it sees the file, iOS knows it has Internet connectivity and it will remember that WiFi network. If it can't see the file, iOS assumes that the network requires some additional form of authentication (like a user name and password, or a WiFi access code).

To understand what happens next, consider the behavior of most password- or code-protected WiFi networks. When you try to access any webpage at all, you're redirected to a login screen, called a captive portal page. There, you put in some form of credentials, and after that you're passed on to the Internet in general. iOS assumes that if it can't get to its Apple-hosted success.html file that you're being redirected to a captive portal, and so it displays the Web server's response in a special "Log in" window separate from the Web browser.

This is fine, but things kind of fell down yesterday. The success.html file was missing or otherwise unavailable; if you tried to hit its URL directly with a Web browser, you were redirected to Apple's generic "Page not found" 404 error page (which you can see by typing "http://www.apple.com/" into your browser's address bar, adding some nonsense characters after the trailing slash, and hitting enter). iOS was interpreting the Web server's 404 redirect as the same kind of redirect a captive portal would produce when you're redirected to it on a protected WiFi network, and was dutifully displaying Apple's resultant 404 page, nicely wrapped in its standard captive portal "Log in" window. Because no successful "log in" was possible, iOS would interpret the network as an invalid or inaccessible one, and wouldn't remember it and wouldn't connect automatically. Wash, rinse, repeat.

The problem behavior manifested for several hours, it appeared, but Apple eventually addressed whatever issue caused success.html to be missing in the first place, and sanity returned.