-
Notifications
You must be signed in to change notification settings - Fork 2.2k
Description
Prerequisites
-
I have checked the Wiki and Discussions and found no answer
-
I have searched other issues and found no duplicates
-
I want to request a feature or enhancement and not ask a question
The problem
Description
Enabling the bootstrap_prefer_ipv6 flag instructs AdGuard Home to prefer IPv6 for upstream queries. When IPv6 is available at startup, this works as expected.
However, if IPv6 routing is temporarily unavailable during startup (e.g., after a gateway reboot), AdGuard Home correctly falls back to IPv4. Once IPv6 connectivity is restored, AdGuard Home does not automatically switch back to IPv6 and continues using IPv4 until a manual restart.
With the bootstrap_prefer_ipv6 flag enabled, AdGuard Home should retry and automatically switch back to IPv6 once connectivity is restored.
Actual behavior
- IPv6 unavailable at startup → fallback to IPv4
- IPv6 connectivity restored later
- AdGuard Home continues using IPv4
- Manual restart required to resume IPv6 upstream queries
Why this matters
-
CGNAT port limitations
IPv4 traffic is constrained by CGNAT (e.g., ~1000 available ports per customer, even with 1:32 splits). Continuing to use IPv4 unnecessarily increases pressure on these limited resources. -
Incorrect ECS / CDN selection
When upstream DNS queries are sent over CGNAT IPv4 (e.g., AdGuard Premium DNS), CDN selection may use IPv4 ECS instead of IPv6. This can result in higher latency for YouTube specifically—for example, 10 ms optimal vs. 16–20 ms in my case—and may impact adaptive streaming, causing YouTube to fallback from 4K to 1080p.I am aware that latencies under ~40 ms are generally acceptable, but in this case the relative increase is nearly 2×, which has visible real-world effects.
Environment
- AdGuard Home: v0.107.71 (behavior persistent across versions, for more than a year)
- Primary Platform: Dedicated Raspberry Pi 5, 8 GB RAM, 256 GB NVMe SSD
- Network: IPv6-enabled fiber connection, IPv4 via CGNAT
- Ad Block Lists: 10M+ entries, including 28 days NDR
Proposed solution
AdGuard Home should periodically retry IPv6 when the bootstrap_prefer_ipv6 flag is enabled. Once IPv6 connectivity becomes available, AdGuard Home should automatically switch upstream queries back to IPv6 without requiring a manual restart.
Alternatives considered and additional information
Even if a method is implemented to detect the currently used upstream IP via the REST API and use an automation (e.g., with n8n) to restart AdGuard Home when IPv6 becomes available, this still constitutes a very ugly workaround. A built-in retry mechanism in AdGuard Home would be far cleaner and more reliable.