According to https://www.google.com/chrome/browser/privacy/whitepaper.html
In the event that Chrome detects SSL connection timeouts, certificate
errors, or other network issues that might be caused by a captive
portal (a hotel's WiFi network, for instance), Chrome will make a
cookieless request to http://www.gstatic.com/generate_204 and check
the response code. If that request is redirected, Chrome will open the
redirect target in a new tab on the assumption that it's a login page.
Requests to the captive portal detection page are not logged.
You can disable navigation error tips by unchecking the box in the
"Privacy" section of Google Chrome's options.
About Chromium OS
https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection explains :
Shill, the connection manager for Chromium OS, attempts to detect services that are within a captive portal whenever a service
transitions to the ready state. This determination of being in a
captive portal or being online is done by attempting to retrieve the
webpage http://clients3.google.com/generate_204. This well known URL
is known to return an empty page with an HTTP status 204. If for any
reason the web page is not returned, or an HTTP response other than
204 is received, then shill marks the service as being in the portal
Many, or perhaps most, captive portals found in Hotels, Coffee Shops,
Airports, etc, either run their own DNS server which returns IP
address for all queries which point to their webserver, or they
intercept all HTTP web traffic and return a 302 (redirect) response.
The captive portal detection works very reliably with these types of
portal to indicate that the service is not fully online.