Android Download Manager traffic fails when routed through AdGuard outbound proxy in Local VPN mode

[libnode]

Please answer the following questions for yourself before submitting an issue

• Filters were updated before reproducing an issue
• I checked the knowledge base and found no answer
• I checked to make sure that this issue has not already been filed

AdGuard version

4.12.81

Environment

• OS version: Hyperos 3.0 with Android 15
• Device: POCO F5
• Outbound proxy: local proxy app on 127.0.0.1:2080/7890
  Tested with both NekoBox and a Clash-compatible proxy app
• Proxy app itself is excluded from AdGuard routing/filtering
• Firewall is disabled for testing
  HTTPS filtering/content filtering is disabled for the related apps for testing
• Tested apps/components:
  X/Twitter app modified with media download patch
  Android Download Manager / Downloads
  Downloads UI
  Media Storage
  Android Shell, for curl testing
• Direct access to X/Twitter service is blocked by local ISPs and DNS is hijacked

HTTPS filtering

• yes, I do

Root access

• yes, I have it

Integration with AdGuard VPN

• yes, I do

Routing mode

Local VPN

Ad Blocking

AdGuard Base filter

Privacy

AdGuard Tracking Protection filter

Social

No response

Annoyances

AdGuard Annoyances filter

Security

No response

Language-specific

No response

Other

AdGuard DNS filter

Which DNS server do you use?

Automatic DNS

DNS protocol

Regular

Custom DNS

• Local DNS Server udp://127.0.0.1:6450
• https://dns.cloudflare.com/dns-query

What Stealth Mode options do you have enabled?

Hide your IP address

Issue Details

Steps to reproduce:

1. Enable AdGuard protection in Local VPN mode.
2. Configure an outbound proxy in AdGuard pointing to a local proxy app, for example 127.0.0.1:2080
3. Exclude the proxy app itself from AdGuard.
4. In AdGuard app management, set X/Twitter, Download Manager/Downloads, Downloads UI, Media Storage, and related system components to route through AdGuard and through the configured outbound proxy. Disable HTTPS filtering and content filtering for these apps.
5. Open X/Twitter and call the download action for an image or video, which invokes Android DownloadManager.
6. Observe that the system download fails or keeps retrying.
7. As a control test, disable AdGuard and run the same local proxy app in VPN/per-app mode with only Download Manager routed through it. The download succeeds.
8. As another control test, keep the proxy app in proxy-only mode and configure Android Wi-Fi/system HTTP proxy to 127.0.0.1:2080/7890. DownloadManager also succeeds.
9. Replacing NekoBox with a Clash-compatible local proxy as AdGuard’s outbound proxy does not resolve the issue.

Expected Behavior

When Download Manager/Downloads is configured in AdGuard to route through the outbound proxy, Android DownloadManager should be able to download the same media successfully.

AdGuard should either:

• route DownloadManager traffic, including DNS-related handling, through the configured outbound proxy correctly; or
• clearly indicate that DownloadManager/system download traffic is not fully supported with outbound proxy routing in Local VPN mode.

The expected result is that system downloads behave the same as when:

• the same local proxy app is used directly in VPN/per-app mode, or
• Android system/Wi-Fi HTTP proxy is set to the same local proxy port.

Actual Behavior

The X/Twitter app itself can access the network normally through AdGuard and the outbound proxy, but media downloads handled by Android DownloadManager fail.

The same proxy server works correctly when used directly:

• curl -x http://127.0.0.1:2080 ... succeeds.
• SOCKS5 and HTTP CONNECT to the same local proxy port both succeed.
• The same media URL returns HTTP 200/206 through the local proxy.
• NekoBox VPN/per-app mode with only Download Manager routed through it succeeds.
• Android Wi-Fi/system HTTP proxy set to 127.0.0.1:2080 also allows DownloadManager to download successfully.

However, when AdGuard Local VPN is in front and the same local proxy is configured as AdGuard’s outbound proxy, DownloadManager fails with errors such as:

DMS_DownloadThread: uri=https://pbs.twimg.com/... statusInfo=HTTP_DATA_ERROR(495) errorMsg=java.net.SocketException: Connection reset

Sometimes it fails with a timeout:

java.net.SocketTimeoutException: failed to connect to pbs.twimg.com/<resolved IP>:443

The logs also show that the download is executed by Android DownloadManager/DownloadService, while the task is associated with the originating app:

pkg=com.twitter.android setThreadStatsPid com.twitter.android===>... com.android.providers.downloads/.service.DownloadService android.process.media

In some failed attempts, the network state reported by the download thread briefly appears as:

NetworkInfo: type: WIFI[], state: DISCONNECTED/BLOCKED

This suggests that DownloadManager traffic may not be handled by AdGuard outbound proxy routing in the same way as ordinary app traffic.

Additional Information

Control tests already performed:

• Direct local proxy test succeeds:
  • HTTP CONNECT via 127.0.0.1:2080 returns HTTP 200/206.
  • SOCKS5 via the same local port also succeeds.
• NekoBox VPN/per-app mode succeeds when only Download Manager is routed through it.
• Replacing NekoBox with a Clash-compatible proxy as AdGuard’s outbound proxy does not fix the issue.
• Setting Android Wi-Fi/system HTTP proxy to the same local proxy port works around the issue, but this is not ideal because it is network-specific or causes system-wide instability when set globally.

The issue appears specific to AdGuard Local VPN + outbound proxy handling of Android DownloadManager/system download traffic. Ordinary app traffic can still work through AdGuard and the same outbound proxy.

[maxikuzmin]

@libnode does the issue reproduce when downloading a regular file (e.g. 100 MB test file from a browser) through Android Download Manager, without Twitter involved?

also, can you confirm whether com.android.providers.downloads traffic appears in the AdGuard filtering log and whether it is marked as routed through the outbound proxy?

[libnode]

@libnode does the issue reproduce when downloading a regular file (e.g. 100 MB test file from a browser) through Android Download Manager, without Twitter involved?

also, can you confirm whether com.android.providers.downloads traffic appears in the AdGuard filtering log and whether it is marked as routed through the outbound proxy?

I checked AdGuard’s Recent activity while reproducing the issue.

I do not see com.android.providers.downloads / Download Manager entries during the failed X/Twitter DownloadManager download. The related entries appear either as the X app connecting to already-resolved IP addresses on port 443, or as DNS requests shown under Android OS.

For example, during the X/Twitter test, Recent activity shows entries like:

X → tcp://172.66.0.227:443
X → tcp://104.18.37.127:443
Android OS → x.com DNS
Android OS → api.twitter.com DNS

but no visible com.android.providers.downloads entry.

I also tested another app that triggers Android DownloadManager for plugin downloads from GitHub. The download appears in Android’s system download manager and succeeds, but AdGuard Recent activity still does not show it as com.android.providers.downloads. Instead, it shows entries like:

Android OS → raw.githubusercontent.com DNS
Android OS → tcp://185.199.109.133:443
Android OS → tcp://185.199.110.133:443

I do not see a clear indicator in the Recent activity list showing whether those entries are routed through the outbound proxy.

Additional controls:

• If the outbound proxy points to a failed proxy node, new DownloadManager downloads from GitHub become stuck.
• If I disable AdGuard outbound proxy routing, the GitHub DownloadManager queue continues successfully, likely because GitHub is reachable directly in my network.
• The X/Twitter DownloadManager download still fails with AdGuard Local VPN + outbound proxy, but succeeds when Android Wi-Fi/system HTTP proxy is set to the same local proxy port, and also succeeds when the local proxy app is used directly in VPN/per-app mode for Download Manager.

Based on this, it looks like DownloadManager traffic is not being exposed or attributed as com.android.providers.downloads in AdGuard Recent activity. DNS appears under Android OS, and TCP connections appear as already-resolved IP:443 connections. I cannot confirm from the UI whether these DownloadManager-related entries are actually routed through the outbound proxy.