Debugging HTTP on Android is still terrible. Here's what we did about it.
If you've ever tried to inspect HTTP traffic from an Android app, you know the feeling. It's that specific mix of frustration and disbelief that software development in 2026 still involves Googling "how to set proxy on Android" and landing on a Stack Overflow answer from 2017 that no longer works.
On desktop, it's trivial. Fire up a debugging proxy, set it as system proxy, done. Every app on your machine routes through it. You see every request, every response, every header. Five minutes, tops.
On Android? It's a different universe.
The many ways Android says "no" to your proxy
Let's count the ways Android makes HTTP debugging painful, because there are more than you'd think.
Most apps ignore the system proxy. This is the big one. Android has a system-level proxy setting, and most apps couldn't care less about it. The system proxy only affects apps that explicitly use it through the default HTTP stack. Plenty of apps, especially those using custom HTTP clients or native networking libraries, bypass it entirely. You configure the proxy, you launch the app, and your debugging tool shows... nothing. It's not broken. The app just never asked the OS for proxy settings.
Flutter apps are proxy-unaware by default. If you're a Flutter developer, you've probably hit this wall. Dart's HttpClient doesn't respect Android's system proxy settings out of the box. Your Flutter app happily ignores whatever proxy you've configured on the device. The official workaround? Modify your app's source code to explicitly route through a proxy. Which means you need access to the source, you need to rebuild, and you need to remember to remove it before shipping. For your own app, annoying but doable. For someone else's Flutter app? Game over.
React Native and custom HTTP stacks have the same problem. It's not just Flutter. Any framework that brings its own networking layer, OkHttp with custom configurations, Cronet, BoringSSL, or anything that doesn't go through Android's default URLConnection, will likely ignore your proxy settings.
Android 7+ restricts user-installed certificates. Since Android Nougat, apps targeting API 24 and above no longer trust user-installed CA certificates by default. Even if you manage to route traffic through your proxy, HTTPS interception fails because the app refuses your debugging certificate. The workaround is adding a network_security_config.xml to the app. Which, again, requires access to the source code and a rebuild.
ADB proxy setup is fragile. You can set a global proxy via adb shell settings put global http_proxy, but it has the same fundamental problem: apps that don't check the system proxy ignore it. Plus, it doesn't survive reboots, it's easy to misconfigure, and forgetting to unset it later will leave you wondering why your phone can't connect to anything.
Wi-Fi proxy settings are per-network and manual. You can set a proxy on your Wi-Fi connection, but you have to do it every time you switch networks. And it still only affects apps that respect the system proxy. We're going in circles.
The core issue is architectural. Android doesn't have a mechanism to force all network traffic through a proxy at the OS level. The proxy setting is a suggestion, not an enforcement. Apps are free to ignore it, and many do.
Unless you use a VPN.
The VPN trick
Here's the one thing Android does enforce: VPN routing. When a VPN is active, all network traffic from the device (or from selected apps) goes through the VPN tunnel. Apps don't get a choice. They can't bypass it. It's handled at the network layer, below the application.
This is the key insight behind Fluxzy Connect. Instead of hoping apps will respect a proxy setting, we create a local VPN on the device that captures traffic and forwards it to your Fluxzy proxy. The apps never know they're being proxied. They just see a normal network connection. The VPN handles the redirect transparently.
It's not a new idea. But making it actually pleasant to use? That took some work.
Fluxzy Connect
Fluxzy Connect is a free Android app that routes your device's HTTP and HTTPS traffic through a remote Fluxzy proxy instance using a local VPN tunnel.
It's fully open source under Apache 2.0: github.com/FluxzySas/fluxzy.connect
Here's what it does and why each feature exists.
Automatic proxy discovery via mDNS
You start Fluxzy on your computer (CLI, Desktop, or using Fluxzy.Core in your own app). You open Fluxzy Connect on your phone. The app finds the proxy instance on your local network automatically. Tap to connect.
No IP addresses to type. No port numbers to remember. No "wait, is it 8888 or 44344?" moments. The app uses mDNS (the same protocol that makes AirPlay and Chromecast discoverable) to find Fluxzy instances on your LAN.
This sounds like a small thing. It's not. Every extra manual step in a debugging setup is a step where someone gives up and adds a print() statement instead.
Per-app VPN routing
You probably don't want all your phone's traffic going through the proxy. Your Spotify, your email, your messaging apps, they don't need to be inspected, and routing them through a proxy just adds latency.
Fluxzy Connect lets you select exactly which apps get routed through the VPN tunnel. Everything else uses the normal network path. Debug your Flutter app while your Slack notifications arrive normally.
This is also essential for avoiding noise. When you're debugging one specific app, the last thing you want is your proxy flooded with requests from thirty other apps checking for updates, sending analytics, and syncing in the background.
One-tap certificate installation
For HTTPS interception, your device needs to trust the proxy's root certificate. Fluxzy Connect can download the certificate directly from your Fluxzy proxy instance and walk you through installing it. One tap in the app instead of a multi-step manual process involving file transfers and Android's buried security settings.
SOCKS5 tunnel mode
Fluxzy Connect isn't locked to Fluxzy. It can act as a generic VPN-to-SOCKS5 tunnel. If you have any SOCKS5 proxy (with or without authentication), you can point the app at it and route your Android traffic through it. This makes it useful beyond just Fluxzy, whether you need to route through a corporate proxy, a remote server, or any other SOCKS5 endpoint.
Stable foreground service
Android aggressively kills background processes. A debugging tunnel that randomly disconnects is worse than no tunnel at all. Fluxzy Connect runs as a foreground service with a persistent notification, which tells Android "this is actively doing something, don't kill it." The tunnel stays up reliably, even during long debugging sessions.
HTTP/3 (QUIC) blocking
Some apps use HTTP/3 over QUIC (UDP-based) which can bypass traditional HTTP proxy inspection. Fluxzy Connect has an option to block QUIC connections, forcing apps to fall back to HTTP/2 or HTTP/1.1 over TCP, which the proxy can intercept normally. A small toggle that prevents a common "why can't I see this traffic?" headache.
Built for automation
This part is for the people who don't just debug manually but build automated testing pipelines.
Fluxzy Connect exposes an API surface that lets you control the proxy connection programmatically. Combined with per-app VPN routing, this means you can:
- Start and stop the VPN tunnel from your test scripts
- Select which apps are routed through the proxy
- Integrate Android traffic capture into your CI/CD pipeline
- Build automated testing scenarios that require inspecting or modifying HTTP traffic on a real device
If you're doing mobile test automation and need to verify that your app is making the right API calls, sending the right headers, or handling error responses correctly, having programmatic control over the proxy tunnel removes a lot of manual setup from your workflow.
The typical workflow
Here's what debugging a Flutter app looks like with Fluxzy Connect:
- Start Fluxzy on your computer:
fluxzy start -l 0.0.0.0:44344 -p --enable-discovery - Open Fluxzy Connect on your Android device
- Tap your computer's name in the auto-discovered list
- Select your Flutter app in the per-app filter
- Install the certificate (one tap, first time only)
- Use your app normally. Every HTTP and HTTPS request shows up in Fluxzy on your computer.
- --enable-discovery enables the mDNS discovery, so you don't have to enter IP addresses or ports. The app finds your proxy automatically.
No source code changes. No rebuild. No network_security_config.xml. No ADB commands. No manual IP entry.
The same workflow applies whether you're debugging a React Native app, a native Android app with a custom HTTP stack, or any third-party app you want to inspect.
Here's a video walkthrough showing the full setup in action:
Why open source, why Apache 2.0
The app is built with Flutter (yes, the irony of using Flutter to solve Flutter debugging problems is not lost on me) and Kotlin for the Android VPN layer. The full source is on GitHub under Apache 2.0.
Why Apache 2.0? Because this is a client-side tool that connects to Fluxzy. Making it easy for people to use, fork, and adapt serves everyone. If you want to customize the VPN behavior for your specific setup, build an internal version for your team, or just read the code to understand how the VPN tunnel works, go ahead.
Get it
- Google Play: Fluxzy Connect
- Source code: github.com/FluxzySas/fluxzy.connect
- Fluxzy CLI (the proxy you'll connect to): fluxzy.io/download
Android HTTP debugging has been unnecessarily painful for years. The OS doesn't help, the frameworks don't help, and the existing workarounds all require modifying the app you're trying to debug. A VPN-based approach is the only one that works transparently for every app, and Fluxzy Connect is our attempt to make that approach as frictionless as possible.
Try it. If something's broken or missing, open an issue. It's open source. We'll fix it together.