Add a global bypass quic filtering option for apps along with the ability to only filter selected apps with quic such as brave

[jo2dan94]

Issue Details

I have vibe coded in some code to allow bypassing of all apps with just a toggle and an ability to keep certain apps like Brave that need to be filtered by quick.

Proposed solution

We should add it

Alternative solution

No response

[maxikuzmin]

@jo2dan94 could you clarify why you need to disable QUIC for all apps?

[jo2dan94]

@maxikuzmin

I think there is a strong case for adding an optional global QUIC bypass mode to AdGuard for Android.

This would not replace or change the current default behavior. Instead, it would give advanced users the ability to invert the existing QUIC policy when application compatibility is more important than filtering QUIC traffic.

The reason I think this is warranted is that the compatibility problem is already well established by AdGuard's own issue history, developer-recommended workarounds, and built-in package exceptions.

The underlying problem

AdGuard's current approach effectively relies on applications falling back when QUIC cannot be filtered:

App attempts QUIC/HTTP3 → AdGuard blocks it → app is expected to fall back to TCP/HTTP2 → filtering continues normally.

That works when the application handles fallback correctly.

However, there are documented cases where applications do not fall back reliably, take too long to fall back, fail the initial request, or lose functionality completely.

This has resulted in user-visible failures such as failed connections, missing images/files, uploads hanging indefinitely, search and voice requests failing on the first attempt, and other broken functionality.

More importantly, AdGuard already has to maintain application-specific QUIC exceptions because of these compatibility problems.

WeChat / AliExpress

AdGuard issue #5497 provides a particularly clean reproduction.

With QUIC filtering active, WeChat could not receive pictures/files. The reporter observed the blocked QUIC connections, added WeChat to QUIC bypass packages, and functionality was restored.

AdGuard subsequently shipped a compatibility exception. The AdGuard 4.10 changelog explicitly states:

“QUIC filtering is disabled for WeChat and AliExpress.”

#5497

This demonstrates that package-specific QUIC bypass isn't merely a theoretical workaround — AdGuard itself has determined that it is necessary for application compatibility.

YouTube

YouTube provides another strong example.

When QUIC/gQUIC was blocked, uploads from the official Android application could remain indefinitely on “Preparing.” Disabling AdGuard allowed the upload to proceed.

The corresponding CoreLibs discussion is especially relevant because an AdGuard developer recommended adding:

com.google.android.youtube

to:

pref.quic.bypass.packages

as the workaround.

#4106

AdguardTeam/CoreLibs#1596

This illustrates the problem with relying entirely on protocol fallback: some applications simply don't recover correctly when their preferred QUIC transport is blocked.

Google apps

Issue #5617 provides another useful reproduction involving Google Search, Gboard, Chrome, Circle to Search and other Google functionality.

The observed behavior was essentially:

QUIC/HTTP3 request → blocked by AdGuard → application reports a connection/server error → retry → application eventually falls back to HTTP2 → request succeeds.

Adding affected Google applications to the QUIC whitelist eliminated the problem.

AdGuard classified the report as a bug, and it was ultimately marked Done for AdGuard 4.13.

#5617

This case is particularly important because QUIC blocking didn't necessarily cause permanent failure. Instead, it caused intermittent first-request failures followed by successful fallback.

That type of failure is extremely difficult for an ordinary user to diagnose. If Google Search fails once and succeeds when tried again, few users will realize that the initial HTTP/3 connection was blocked and the subsequent request succeeded because the application fell back to HTTP/2.

Instagram

Instagram provides another important precedent.

com.instagram.android has historically been included in AdGuard's own QUIC bypass packages.

When removal of that exception was proposed because it was believed to no longer be necessary, the request was rejected.

#5031

Again, this demonstrates that maintaining QUIC exceptions is already an accepted compatibility mechanism within AdGuard.

Additional reports

There are also reports involving Weibo and other applications where blocking QUIC/gQUIC resulted in missing images or broken functionality:

#5631

There are reports from users maintaining government/banking applications in the QUIC bypass list because some reportedly crash during startup without it:

#5861

The important point isn't any single application. It is the recurring compatibility pattern.

The existing exceptions prove the compatibility problem exists

I think this is the strongest argument for exposing the proposed option.

The fact that AdGuard has had to create and maintain application-specific QUIC exceptions is itself evidence that blocking QUIC and relying on fallback is not universally compatible with Android applications.

WeChat required an exception.
AliExpress received an exception.
Instagram has had an exception.
YouTube has required pref.quic.bypass.packages as a developer-recommended workaround.
Google applications have exhibited first-request failures directly correlated with blocked QUIC traffic.

These aren't hypothetical edge cases.

The existing package-bypass mechanism exists precisely because this compatibility problem is real.

The limitation of maintaining package exceptions

pref.quic.bypass.packages is useful and should remain available, but a package-based compatibility list is necessarily reactive.

The lifecycle is effectively:

App uses QUIC → AdGuard blocks QUIC → functionality breaks → user notices → user identifies AdGuard as the cause → QUIC is identified as the specific cause → package is manually exempted or eventually added to AdGuard's defaults.

No package-based compatibility list can cover newly released, updated, regional, enterprise, banking, government, or otherwise unreported applications before those incompatibilities are discovered.

This becomes increasingly relevant as HTTP/3/QUIC adoption grows.

It also places a substantial diagnostic burden on users. A user experiencing an intermittent connection failure generally isn't going to know that the application attempted QUIC, AdGuard blocked it, and a later attempt succeeded because the application switched transports.

Proposed solution: an optional inverse QUIC policy

I'm not proposing that AdGuard change the current behavior for everyone.

The current behavior should remain the default.

Instead, expose an advanced option that allows users to invert the existing policy.

Current/default:

Filter/block QUIC globally → bypass selected packages

Optional compatibility mode:

Bypass QUIC globally → filter/block QUIC only for selected packages

For example:

QUIC mode

Filter QUIC whenever possible — Default

Current AdGuard behavior. QUIC is filtered/blocked as necessary and applications requiring compatibility exceptions use the bypass package list.

Bypass QUIC globally — Maximum compatibility

Allow QUIC without forcing applications to fall back, except for applications explicitly selected for QUIC filtering/blocking.

The UI could clearly warn that enabling global bypass may reduce AdGuard's ability to filter traffic carried over QUIC.

This preserves the existing privacy/filtering-oriented default while providing an explicit compatibility-oriented alternative.

Why this is better than disabling AdGuard for affected apps

When an application breaks because of QUIC handling, completely disabling AdGuard protection for that application is unnecessarily broad.

Users shouldn't have to choose between:

breaking the application

or

excluding the entire application from AdGuard protection.

If QUIC is the only incompatibility, bypassing that transport still allows AdGuard to protect/filter the application's DNS, TCP and other supported traffic where applicable.

That is significantly more granular than excluding the application entirely.

This extends an existing AdGuard mechanism rather than replacing it

AdGuard already has:

pref.quic.bypass.packages

AdGuard already ships package-specific QUIC exceptions.

AdGuard developers already recommend this preference as a workaround for applications that don't behave correctly when QUIC is blocked.

So the requested feature is essentially the inverse policy.

Instead of only:

block/filter QUIC except these packages

allow advanced users to choose:

bypass QUIC except these packages

The existing behavior remains unchanged by default.

Why I think this is worth exposing

The question isn't really whether blocking QUIC can cause application compatibility problems — AdGuard's own exceptions and issue history already demonstrate that it can.

The question is whether users should have access to the inverse policy when they prioritize application compatibility and reliable connectivity over filtering QUIC traffic.

Making this an optional advanced setting would provide that choice without weakening AdGuard's defaults:

Existing maximum-filtering behavior remains unchanged by default.
Users who prioritize compatibility don't have to discover and maintain an ever-growing list of individual package exceptions.
Affected applications can retain AdGuard protection for other supported traffic instead of being excluded from protection entirely.
New or unknown applications that don't gracefully fall back from QUIC work without waiting for an application-specific compatibility exception to be discovered and added.

Given the increasing adoption of HTTP/3/QUIC, the existing pref.quic.bypass.packages mechanism, AdGuard's own built-in application exceptions, and multiple documented cases where blocking QUIC causes real application failures, I think an optional global/inverse QUIC bypass policy would be a useful and technically justified advanced compatibility feature.