Improve handling of captive portals by temporarily disabling DNS protection

[agoodkind]

Issue Details

When AdGuard DNS protection is enabled on iOS, Wi-Fi networks that use captive portals (airlines, hotels, airports, cafés) often fail to show their login or payment page. Captive portals typically rely on redirecting web traffic or responses from specific probe URLs to trigger the captive portal login flow, and this depends on using the network’s own DNS resolver. With AdGuard DNS protection active, the system’s captive portal check does not complete correctly, so I either never see the captive portal, or I see a “No Internet” state and cannot authenticate. Right now I have to disable AdGuard DNS protection manually, connect to the Wi-Fi, complete the captive portal, and then remember to turn DNS protection back on afterward. It is easy to forget that last step, so I may end up using unprotected DNS for a long time after leaving the captive portal network.

Proposed solution

Add captive portal awareness to AdGuard for iOS and temporarily pause DNS protection whenever the device is behind a captive portal. The app can watch for the operating system’s captive portal detection to trigger (for example when a predefined connectivity check URL is redirected instead of returning the expected response) and then automatically switch DNS protection off or into a special “captive portal” mode that lets the network’s DNS resolver handle queries. While this state is active, AdGuard could show a small status message indicating that DNS protection is temporarily disabled due to a detected captive portal. As soon as the captive portal is no longer detected and the connectivity check succeeds with the expected response, AdGuard should automatically restore full DNS protection without requiring any manual toggle.

Alternative solution

One alternative is to keep doing everything manually: turn DNS protection off before joining a public Wi-Fi, complete the captive portal, and then turn DNS protection back on afterward, but this is easy to forget and does not scale well when moving between multiple networks. Another option would be to maintain a manual list of SSIDs that should bypass AdGuard DNS, but that still does not help with new or unknown captive portals and requires user configuration for every network. Automatic captive portal detection with temporary DNS protection suspension would address both known and unknown captive portals with no extra setup.

[Swen90]

Good day @agoodkind
Thank you for the interesting request! I will be back soon with the answer very soon.

[Swen90]

Hi @agoodkind
In order to troubleshoot this issue, we need to get your application logs.

Here's what we need you to do:

1. Enable debug logging:
   Settings -> General -> Advanced -> Logging level -> Debug.
2. Reproduce the problem, then remember the exact time when it happened.
3. Collect logs:
   Settings -> General -> Advanced -> Export logs and system info.
4. Send this file to qa@adguard.com:
   • include [android] keyword and 2505 as an issue number in the subject of your email
   • specify the exact time when the issue occurred

[agoodkind]

Hi @agoodkind
In order to troubleshoot this issue, we need to get your application logs.

Here's what we need you to do:

1. Enable debug logging:
   Settings -> General -> Advanced -> Logging level -> Debug.
2. Reproduce the problem, then remember the exact time when it happened.
3. Collect logs:
   Settings -> General -> Advanced -> Export logs and system info.
4. Send this file to qa@adguard.com:
   • include [android] keyword and 2505 as an issue number in the subject of your email
   • specify the exact time when the issue occurred

Hey it's not really an existing issue! It's a new feature request

[Swen90]

Hello @agoodkind
Perhaps, I should have given some clarification before asking for logs. So, we are thinking that this is very useful but also challenging to implement feature and it would be very helpful if you could send your debug logs 👍