Please answer the following questions for yourself before submitting an issue
AdGuard version
AdGuard 7.22.6 (5267) (CL 1.20.92, DL 2.7.6
Browser version
Chrome Stable 146.0.7680.154
OS version
Windows 11 25H2
Issue Details
Setup: * 1. AdGuard for Windows (v7.22.6) or Android with Default/Standard filtering mode.
Enable HTTP/3 (QUIC) filtering in AdGuard settings.
In Chrome, ensure #enable-quic and #enable-tls13-kyber are active.
Connection: High-speed GPON (to eliminate ISP-induced jitter).
Baseline (AdGuard OFF): * Open Chrome DevTools -> Network tab (with "Protocol" column).
Visit youtube.com or google.com.
Result: Protocol is h3, average TTFB is ~170ms.
Testing (AdGuard ON):
Enable AdGuard protection and refresh the page.
Observation: TTFB spikes to ~550ms (+400ms overhead).
Result: Chrome's "Happy Eyeballs" detects the high UDP latency and forces a fallback to h2 (TCP) for the majority of resources.
Expected Behavior
-
Minimal Latency Overhead: The filtering engine should process HTTP/3 (QUIC) streams with minimal delay (less than 50ms overhead), ensuring that the total TTFB remains within the "Happy Eyeballs" threshold.
-
Stable h3 Connection: AdGuard should filter QUIC traffic without causing the browser to fall back to HTTP/2 (TCP) for the majority of web resources on high-speed connections (GPON).
-
Optimized WFP/Network Engine: Performance on Windows and Android should be consistent, allowing for the benefits of QUIC (0-RTT, reduced head-of-line blocking) to be preserved even when HTTPS filtering is active.
-
No Forced Downgrade: Enabling the "Filter HTTP/3" feature should result in active filtering of the UDP/443 stream rather than effectively disabling the protocol and forcing a 100% fallback to h2.
Actual Behavior
-
Significant Latency Overhead: The filtering engine introduces a ~400ms delay in processing HTTP/3 (QUIC) streams. Average TTFB (Time to First Byte) spikes from 170ms (AdGuard OFF) to ~550ms (AdGuard ON) on a high-speed GPON connection.
-
Protocol Downgrade: This overhead exceeds the threshold for Chrome's "Happy Eyeballs" algorithm, triggering an automatic fallback from h3 to h2 (TCP) for the majority of heavy web resources.
-
"Filter HTTP/3" Toggle Inefficiency: Enabling the "Filter HTTP/3" feature in settings effectively results in a 100% protocol fallback to h2, nullifying the performance benefits of QUIC (0-RTT, reduced head-of-line blocking).
-
Platform-Wide Issue: The behavior is consistent across Windows (WFP driver) and Android, suggesting a performance bottleneck within the shared CoreLibs filtering logic.
Screenshots
https://linksharing.samsungcloud.com/8BvRV19sBcSx - screenshots+video
Additional Information
Additional Context:
Moving from: This issue is being moved from AdguardForWindows #5922 as requested by @ameshkov.
ISP & Network: Tested on a high-speed GPON connection (Baku, Azerbaijan) using a Huawei HG8145V5 ONT.
DNS Performance: This is not an ISP-level UDP throttling issue. DNS queries via DoH3 (UDP/443) using NextDNS work instantly with no packet loss or unusual latency. The 400ms overhead only appears during HTTPS filtering of heavy HTTP/3 web streams.
Encryption/Security: Tested with and without TLS 1.3 Kyber; the behavior is identical. The protocol fallback occurs regardless of specific Chrome flags, as long as AdGuard HTTPS filtering is active.
Logs & Media: Detailed Trace logs and video evidence (showing the protocol shift in DevTools) have been sent to devteam@adguard.com.
Cross-platform: Similar latency spikes and protocol downgrades are observed on Android (Samsung G986U1), indicating a shared bottleneck in the CoreLibs filtering logic.
Please answer the following questions for yourself before submitting an issue
AdGuard version
AdGuard 7.22.6 (5267) (CL 1.20.92, DL 2.7.6
Browser version
Chrome Stable 146.0.7680.154
OS version
Windows 11 25H2
Issue Details
Setup: * 1. AdGuard for Windows (v7.22.6) or Android with Default/Standard filtering mode.
Enable HTTP/3 (QUIC) filtering in AdGuard settings.
In Chrome, ensure #enable-quic and #enable-tls13-kyber are active.
Connection: High-speed GPON (to eliminate ISP-induced jitter).
Baseline (AdGuard OFF): * Open Chrome DevTools -> Network tab (with "Protocol" column).
Visit youtube.com or google.com.
Result: Protocol is h3, average TTFB is ~170ms.
Testing (AdGuard ON):
Enable AdGuard protection and refresh the page.
Observation: TTFB spikes to ~550ms (+400ms overhead).
Result: Chrome's "Happy Eyeballs" detects the high UDP latency and forces a fallback to h2 (TCP) for the majority of resources.
Expected Behavior
Minimal Latency Overhead: The filtering engine should process HTTP/3 (QUIC) streams with minimal delay (less than 50ms overhead), ensuring that the total TTFB remains within the "Happy Eyeballs" threshold.
Stable h3 Connection: AdGuard should filter QUIC traffic without causing the browser to fall back to HTTP/2 (TCP) for the majority of web resources on high-speed connections (GPON).
Optimized WFP/Network Engine: Performance on Windows and Android should be consistent, allowing for the benefits of QUIC (0-RTT, reduced head-of-line blocking) to be preserved even when HTTPS filtering is active.
No Forced Downgrade: Enabling the "Filter HTTP/3" feature should result in active filtering of the UDP/443 stream rather than effectively disabling the protocol and forcing a 100% fallback to h2.
Actual Behavior
Significant Latency Overhead: The filtering engine introduces a ~400ms delay in processing HTTP/3 (QUIC) streams. Average TTFB (Time to First Byte) spikes from 170ms (AdGuard OFF) to ~550ms (AdGuard ON) on a high-speed GPON connection.
Protocol Downgrade: This overhead exceeds the threshold for Chrome's "Happy Eyeballs" algorithm, triggering an automatic fallback from h3 to h2 (TCP) for the majority of heavy web resources.
"Filter HTTP/3" Toggle Inefficiency: Enabling the "Filter HTTP/3" feature in settings effectively results in a 100% protocol fallback to h2, nullifying the performance benefits of QUIC (0-RTT, reduced head-of-line blocking).
Platform-Wide Issue: The behavior is consistent across Windows (WFP driver) and Android, suggesting a performance bottleneck within the shared CoreLibs filtering logic.
Screenshots
https://linksharing.samsungcloud.com/8BvRV19sBcSx - screenshots+video
Additional Information
Additional Context:
Moving from: This issue is being moved from AdguardForWindows #5922 as requested by @ameshkov.
ISP & Network: Tested on a high-speed GPON connection (Baku, Azerbaijan) using a Huawei HG8145V5 ONT.
DNS Performance: This is not an ISP-level UDP throttling issue. DNS queries via DoH3 (UDP/443) using NextDNS work instantly with no packet loss or unusual latency. The 400ms overhead only appears during HTTPS filtering of heavy HTTP/3 web streams.
Encryption/Security: Tested with and without TLS 1.3 Kyber; the behavior is identical. The protocol fallback occurs regardless of specific Chrome flags, as long as AdGuard HTTPS filtering is active.
Logs & Media: Detailed Trace logs and video evidence (showing the protocol shift in DevTools) have been sent to devteam@adguard.com.
Cross-platform: Similar latency spikes and protocol downgrades are observed on Android (Samsung G986U1), indicating a shared bottleneck in the CoreLibs filtering logic.