Direct TCP download throughput drops by 50–80% with AdGuard WFP + Mihomo TUN on Windows; upload is unaffected

### Please answer the following questions for yourself before submitting an issue

- [x] Filters were updated before reproducing an issue
- [x] I checked the [knowledge base](https://adguard.com/kb/) and found no answer
- [x] I checked to make sure that this issue has not already been filed

### AdGuard version

7.22.9 (5282)

### Browser version

Vivaldi (8.1.4087.46), Zen (1.21.6b)

### OS version

Windows 11, 25H2 (26200.8655)

### Traffic filtering

- [x] yes, I do

### Ad Blocking

AdGuard Base filter

### Privacy

_No response_

### Social

_No response_

### Annoyances

AdGuard Popups filter

### Security

uBlock Origin – Badware risks

### Other

_No response_

### Language-specific

List-KR

### Which DNS server do you use?

DNS protection disabled

### DNS protocol

None

### Custom DNS

https://adguard-dns.io/

AdGuard Personal DNS is configured as the encrypted DNS upstream in Mihomo.
AdGuard Desktop DNS protection is disabled.
The private Personal DNS endpoint contains an account-specific identifier, so I have not included it in this public issue. I can provide it privately if required.

### What Stealth Mode options do you have enabled?

Block WebRTC

### Support ticket ID

_No response_

### Issue Details

1. Start AdGuard for Windows 7.22.9 (5282).
2. Go to **Settings -> Network -> Traffic filtering** and select the **WFP** driver.
3. Enable AdGuard protection and HTTPS filtering. Keep AdGuard Desktop DNS protection disabled.
4. Confirm that the following Clash components are already excluded from AdGuard application filtering:
- `C:\Program Files\Clash Verge\clash-verge.exe`
- `C:\Program Files\Clash Verge\verge-mihomo.exe`
- `C:\Program Files\Clash Verge\resources\clash-verge-service.exe`
5. Start Clash Verge Rev 2.5.1 with Mihomo v1.19.28.
6. Enable TUN mode with the following relevant settings:

```yaml
mode: rule
interface-name: "이더넷 5"
tun:
enable: true
stack: system
mtu: 1400
auto-route: true
auto-detect-interface: true
strict-route: false
```

7. Ensure that the final routing rule is `MATCH,DIRECT`. The Speedtest connections must not use a remote proxy.
8. Open `https://www.speedtest.net/` in Zen Browser and use the MOACK Data Center / KT multi-connection test.
9. Run the test with both AdGuard WFP protection and Mihomo TUN enabled.
10. Without changing the browser, server, Mihomo configuration, or TUN stack, disable only AdGuard protection and repeat the test.
11. Re-enable AdGuard protection, disable only Mihomo TUN, and repeat the test.
12. Repeat the TUN-enabled test with `gvisor`, `mixed`, and `system` stacks.

The issue is consistently reproducible. Download throughput recovers immediately when either AdGuard protection or Mihomo TUN is disabled. Upload throughput is not affected.

### Expected Behavior

AdGuard WFP filtering and a third-party Mihomo TUN adapter should be able to operate together without reducing direct TCP download throughput by approximately 50-80 percent.

Applications that are explicitly excluded from AdGuard application filtering, including the active Mihomo core, should not cause the browser-to-fake-IP flow and the Mihomo-to-real-IP egress flow to be processed in a way that severely limits receive throughput.

Download and upload throughput should remain close to the results measured when either AdGuard or TUN is used independently.

### Actual Behavior

When AdGuard WFP and Mihomo TUN are enabled together, download throughput is severely limited while upload throughput remains normal.

| AdGuard | Mihomo TUN | TUN stack | Download | Upload |
|---|---|---|---:|---:|
| Enabled | Enabled | gVisor | 80-100 Mbps | about 490 Mbps |
| Enabled | Enabled | mixed | 154.95 Mbps | 489.85 Mbps |
| Enabled | Enabled | system | 159.67 Mbps | 493.04 Mbps |
| Disabled | Enabled | gVisor | 300-400 Mbps | about 490 Mbps |
| Disabled | Enabled | system | 400-480 Mbps | about 490 Mbps |
| Enabled | Disabled | N/A | about 310 Mbps | about 490 Mbps |

Changing the TUN stack from gVisor to mixed/system improves download throughput but does not remove the limitation. Updating Mihomo to v1.19.28 also does not resolve it.

### Screenshots

Speedtest results

### AdGuard WFP enabled + Mihomo Mixed TUN

### AdGuard WFP enabled + Mihomo system TUN

### AdGuard disabled + Mihomo gVisor TUN

### Additional Information

### Environment

- Windows 11 25H2, build 26200.8655, x64
- AdGuard for Windows 7.22.9 (5282)
- AdGuard traffic filtering driver: WFP
- AdGuard HTTPS filtering: enabled
- AdGuard Desktop DNS protection: disabled
- Clash Verge Rev 2.5.1
- Mihomo v1.19.28
- Browser: Vivaldi (Chrome-based), Zen Browser (Firefox-based)
- Active network adapter: Realtek Gaming USB 2.5GbE Family Controller
- Link speed: 1 Gbps
- NIC driver version: 11.19.602.2025
- ESET Security 19.2.7 is installed

### Network observations

- The Speedtest bulk-transfer connections use TCP port 8080.
- The same target IPs are used with TUN enabled and disabled:
- `203.227.185.3:8080`
- `202.165.66.5:8080`
- `210.117.237.60:8080`
- `210.22.155.34:8080`
- Mihomo logs show the Speedtest connections matching `MATCH` and using `DIRECT`.
- No Mihomo DNS, dial, timeout, warning, or error messages occur during the tests.
- The physical NIC reports zero packet errors and zero discarded packets.
- No Windows TCP/IP port-exhaustion event occurs during the reproduction.
- `TIME_WAIT` remains below 80 entries.
- Zen handle counts remain stable at approximately 1,800-1,900.
- Mixed-stack snapshot at peak download: approximately 517 total socket rows, 70 Zen rows, 143 Mihomo rows, and 27 AdGuard service rows.
- System-stack snapshot during the test: approximately 530 total socket rows, 66 Zen rows, 150 Mihomo rows, and 27 AdGuard service rows.
- The large transfer uses TCP port 8080, so adding `speedtest.net` to HTTPS filtering exclusions does not address the measured data path.

### Troubleshooting already performed

- Added the full paths of Clash Verge, Mihomo, the Clash service, backup/alpha cores, and ESET executables to AdGuard application filtering exclusions.
- Excluded loopback, private LAN, link-local, multicast, broadcast, and IPv6 local ranges from AdGuard filtering.
- Tested gVisor, mixed, and system TUN stacks.
- Kept the same browser and Speedtest servers across comparisons.
- Updated Mihomo to v1.19.28.
- Disabled only AdGuard protection: throughput recovered immediately.
- Disabled only Mihomo TUN: throughput recovered immediately.

SockFilter is not a practical workaround in this environment. It causes severe game latency spikes even when the affected game executables are excluded from application filtering, as reported in:

https://github.com/AdguardTeam/AdguardForWindows/issues/6045

SockFilter also increases Twitch and CHZZK live-stream latency from approximately 0.5-1 second to 3-4 seconds and causes more frequent buffering.

Could the AdGuard WFP driver be processing both the browser-to-Mihomo fake-IP flow and the Mihomo egress flow, or otherwise interacting with the TUN receive path despite the Mihomo executable exclusions? Please let me know which AdGuard debug log level or network trace would be most useful for further diagnosis.