Change the blocking mode for adblock-style rules from REFUSED to custom IP (0.0.0.0) by default

[fdezsergio02]

Issue Details

In Android, there are more and more applications that, when faced with a block of any domain related to advertising or telemetry, start to make requests insistently, causing Adguard to be “saturated” with blocking requests and, consequently, consuming more battery.

I have seen this behavior both setting REFUSED and NXDOMAIN in the advanced settings of Adguard. However, if the block is set to a custom/zero IP (0.0.0.0.0), the block is performed only once, and the affected applications do not repeat the query again for some time.

For example, in Bluesky: if Adguard responds with REFUSED, the application will constantly retry to connect to that server. If instead it responds with a null IP, it will only make the request once.

Considering that this is the default setting in the Windows app, and after testing for several weeks the new setting, I think it would be good to suggest changing this setting in the Android app as well.

Proposed solution

Change hosts block from REFUSED to custom/zero IP address (0.0.0.0.0) just like Windows client

Alternative solution

No response

[YHSanSheng]

或许你能通过此处的设置达到对应的效果

[fdezsergio02]

或许你能通过此处的设置达到对应的效果

Yes, that's how I have it configured (no need to put 0.0.0.0 in the custom IP field, it is assumed to be 0.0.0.0.0). What I ask is to make this configuration by default in Adguard

[Versty]

@fdezsergio02 Hi! Blocking mode for hosts rules is set to Custom IP address by default. Do you mean the Blocking mode for adblock-style rules option?

[fdezsergio02]

@fdezsergio02 Hi! Blocking mode for hosts rules is set to Custom IP address by default. Do you mean the Blocking mode for adblock-style rules option?

Exactly! I mean that mode, which is set to REFUSED. I've noticed that in that default mode, many applications start asking for requests towards a blocked domain constantly, which makes Adguard end up working constantly to block that domain. Instead by setting an IP as 0.0.0.0 blocking instead of rejecting the connection, I understand that the application only requests a blocked domain once as it receives a response, even though it is invalid instead of rejecting the response attempt.

[TPS]

@maxikuzmin think this would be a good idea to change these for everyone

If I use "Zero IP adress" (0.0.0.0/::), sites simply freeze, half-loaded, but no log-spam. If using REFUSED or NXDOMAIN, log-spam (& probable increased AG CPU-use/possible resource exhaustion), but sites load.

YMMV; pick your poison?

Maybe it's possible for AG to detect this automatically, & adjust on-the-fly globally or even per site or request?

[fdezsergio02]

@maxikuzmin think this would be a good idea to change these for everyone

If I use "Zero IP adress" (0.0.0.0/::), sites simply freeze, half-loaded, but no log-spam. If using REFUSED or NXDOMAIN, log-spam (& probable increased AG CPU-use/possible resource exhaustion), but sites load.

YMMV; pick your poison?

Maybe it's possible for AG to detect this automatically, & adjust on-the-fly globally or even per site or request?

But reading that problem, it was really due to a bad designed rule, not the functionality itself. On Windows and Mac they have been blocking “adblock” type rules with IP 0.0.0.0.0 for a long time and there are not too many problems.

On Android, on the other hand, more and more apps start to flood a blocked request if it is answered with a REFUSED (Spotify, Reddit, TuneIn, Bluesky, Microsoft apps) and it ends up affecting battery life as Adguard has to work a lot harder.

When I had TuneIn, perfectly in 1-2 hours of playing a radio station, Adguard could block between 20,000-40,000 requests, which is quite severe.

So it is implied that it is much more likely to have an app that repeats intensively a request to Adguard, making it consume more battery than isolated problems due to incorrect rules.

[TPS]

Indeed, I'm retesting this solution since https://github.com/AdguardTeam/AdguardFilters/issues/199402 was closed & 🤞🏾 solved. So far, so good, but I'll need a good week or so before I'm comfortable enough to forget I've switched to this. 😅

[Versty]

@fdezsergio02 We have discussed your suggestion with the development team and decided to change the default state of the Blocking mode for adblock-style rules option.

[TPS]

Indeed, I'm retesting this solution since https://github.com/AdguardTeam/AdguardFilters/issues/199402 was closed & 🤞🏾 solved. So far, so good, but I'll need a good week or so before I'm comfortable enough to forget I've switched to this. 😅

Shockingly, I've remembered to come back to feedback:

Everything's been going great! Only problems I'm encountering are from other unrelated reported issues.

We have discussed your suggestion with the development team and decided to change the default state of the Blocking mode for adblock-style rules option.

@Versty, @maxikuzmin: Why has this issue been put back on Hold since this?

[muchqs]

I guess it depends on the app. some apps will keep spamming the log even with 0000

[TPS]

@muchqs This is just for DNS-blocking. Some apps will spam higher-level requests b/c they (are stupid, but also) have some code to work around "temporary" 😏 outages.

[sfionov]

Default mode has been changed in DnsLibs 2.6, which will be integrated in the next release.