How about captive portal check?

When an android phone connects to a wifi network a check is done if internet is usable by that network. It checks as well if there’s a paywall installed.

For that it requests a special webservice and expects a http result code of 204. This service is provided by several google servers ( for http and for https). It is called “captive portal check” and implemented in

Even LineageOS (base of /e/ as i understand) does so. If /e/ is really degoogled it means that either these checkes are disabled or the domains are changed and the service is be provided elsewhere.

How is it done?

1 Like

What has been done to de-google /e/ is described here:

Google is still fallback solution but only if /e/'s servers are unreachable.

Thank you for the fast feedback.

I understand that a fallback is needed but don’t like that google is again used for that. And in fact /e/ shouldn’t be used either.

Maybe /e/ should switch CAPTIVE_PORTAL_MODE to
CAPTIVE_PORTAL_MODE_IGNORE to entirely disable that check?

(i have no clue if one can do so on a running system?)


is the related gitlab issue (closer to the developers than the forum). Feel free to comment there, to bring your ideas into development.


Hello, I’m not sure when exactly the captive portal check is running.
Is it running each time the phone connect to internet ?
Or it’s just for connect to a public wifi ?
Please let me know

In Android, a connectivity check is done to check that Internet can be reached on available networks. The request is expecting a 204 HTTP error code in return and is done against Google FQDNs.

Looking at AOSP source code: android_frameworks_base ▸ services ▸ core ▸ java ▸ com ▸ android ▸ server ▸ connectivity ▸

private static final String DEFAULT_HTTPS_URL = “”;private static final String DEFAULT_HTTP_URL = “”;private static final String DEFAULT_FALLBACK_URL = “”;private static final String DEFAULT_OTHER_FALLBACK_URLS = “”;

This means that Google can log a ping from any Android device anytime their network interface goes up, which is a common situation after boot.

Solution: we have replaced the Google server addresses in AOSP source by our own servers that do not logs the connectivity checks, for default calls, and a fallback to a Google server.




Merged to the following branches:

  • Nougat
  • Oreo
  • Pie

This is a temporary, not ideal, situation because this solution relies on the confidence users can have in our project and infrastructure.

This will need to be improved using pings to servers FQDN choose randomely from a long list of trustworthy servers, using something different than the 204 HTTP error code check.

References: – issue 268 on /e/’s bugtracker

:point_up_2: :point_up_2: :point_up_2: See bold above. I don’t have a silver bullet to answer your question but it seems that it happens when you boot the device and I would assume that some additional Google logging shenanigans are happening when you don’t disable Settings > Network & Internet > WiFi > WiFi preferences > “Turn on Wi-Fi automatically”, “Open network notification” as well as Settings > Location > Wi-Fi and Bluetooth scanning > Wi-Fi scanning (I also disable Bluetooth scanning).

I too would love a more in depth answer as to when exactly your question is happening and in addition, what information is shared with Google regarding my device’s specific information (ie IMEI, OS info, or anything else that could build a fingerprint).

*Also, has this been merged to the Q builds? Guessing it was and the article was written pre Android 10 launch.

*Seems from some internet searching there are ways to disable captive portal checks with some adb shell commands or root commands. Anyone know how this impacts the OS? Will it cause any issues?

1 Like

Here it’s what i understood about captive portal and connectivity check.
Each time android connect to the network, it send a request to google in order to know if it’s a public network. If it’s a public network, the android system app named “CaptivePortalLogin” will run so you can log into the public network.

What i do not understand, it’s why the connectivity check should occur on a mobile network ? Because there is no captive portal on a mobile network.

Here it’s how you can avoid connectivity check to google :

I did it on my phone and it work perfectly. Even though i didn’t try yet to connect to a public network.

PS : I spent some time to explain the process in detail, but when i tried to “reply”, i had this message :
“new users can’t put more than 2 links…”

Pretty sad…

1 Like

You also can follow this tuto, it’s the same thing but in english :

You don’t need any root access to the phone.
Just plug the phone and run adb.

1 Like

"2. Why is this problematic?

That’s a good question because this answer from Google doesn’t much hold data. But every time when this connection is done Google get the following information:
- IP-adress
- Time of the internet access
- the Browser which you use"

:point_up_2:Interesting. I don’t see directions for builds based on Q/10 or R/11, assuming they are the same as Pie/9? I need to find a good nonGoogle webpage translator for @Yaum 's your first link.

*Also the original question on this thread seems to be a non issue for eOS users since /e/ has in fact done this, correct? :point_down:

"1. What is the Captive Portal Checkin?

Every time your android phone connects to the internet via mobile connection or wlan it sends a request to the following url: (Google URL).

After that your gets device gets http 204 answer from the mentioned url and at that point the x-symbol at your network icon in the status bar disappears.
The reason for that behavior is that Android wants to be sure that your connection has internet access.
If you block that request via AfWall for example the dns fails in some cases and you can’t go into the Internet."

If XDA dhacky is correct there is your answer👆(bold). And thanks for shading this info @Yaum :+1:.

Is this still working? I seems that this URL does not exists anymore, but works. So what is the default HTTPS URL for the /e/ captive portal check nowadays?


1 Like

the linked gitlab issue in the #4 comment has the current list of 204 urls

I think I have found it, thanks @tcecyk.

1 Like