Android uses a built-in mechanism for captive portal detection and connectivity validation rather than a full “ping” to a server. Here’s how it typically works:
HTTP Request to a Known Endpoint:
The system sends a lightweight HTTP GET request to a predetermined URL (commonly something like http://connectivitycheck.gstatic.com/generate_204 or http://clients3.google.com/generate_204). This endpoint is chosen because it’s expected to return a specific response code (HTTP 204 No Content) when there’s unobstructed internet access.
Response Verification:
If the request returns a 204 response, Android assumes that the network is validated and has internet access. If the response is different—such as a redirect or an HTTP 200 with content—it may indicate the presence of a captive portal (a login page or some other form of interception) or that the connection is somehow limited.
Additional Checks:
While the primary mechanism is the HTTP check, Android may also perform DNS resolution checks or combine multiple signals to determine connectivity. These checks are handled in the background by system services like ConnectivityService and NetworkMonitor.
In summary, Android’s background checks rely on these HTTP requests and response validations (along with additional network tests) to assess whether a connection is truly internet-capable.
The i3CONNECT AllSync license server has no web interface, so when testing with a browser you will probably only get a security certificate error, but this is normal and is actually confirmation that the address was not blocked.