appproxy: a Flutter Android proxy tool with per-app routing and an MCP interface

Why this project exists: the common Android proxy tools all age badly

The readme opens with the reason the project was written, and it is a specific and recognisable frustration.

When analysing an app you sometimes need to capture its traffic, and the author tried the common proxy tools, Drony, Postern and ProxyDroid, and found they all share the same problem: they are not friendly to newer Android systems. Either the app list does not display correctly, or the interface is too complicated, and often the setup stops working after a while.

A second thread runs through the story. The author found a newer proxy tool on Play with a good, clear interface, but it was not friendly to users in China, some features required a membership, and even paying did not help because of lack of maintenance or network reasons, so the full functionality could not be used. So the project was written in spare time.

The motivation is therefore not marketing, it is substitution. This is the author's own tool for a job the existing tools made painful, and the tone of the whole readme reflects that: the goals are stated in one line, the configuration instruction is repeated three times, and the licence and a disclaimer close the document.

The disclaimer says the program is for learning and exchange only and must not be used for illegal purposes. The audience is a developer analysing apps, and the tool is intended to run on your own handset, where you already have the authority to see the traffic.

What it does: HTTP and SOCKS5, with per-app routing

The feature description is short, and each line is worth reading because the scope is deliberately narrow.

It is built on flutter and tun2socks, and appproxy is a lightweight VPN proxy tool supporting HTTP and SOCKS5 protocols. Functionality is limited to proxying only, with per-app proxying available, and the readme is blunt about the design intent: the double-tap to change configuration is logically simple, and the goal is that it works and nothing more.

That last point is the design philosophy, stated as a feature. The author describes the project as built for the purpose of learning and getting familiar with flutter, shared with everyone, and helping test it along the way.

The tun2socks base is what makes the per-app part work. A local VPN interface on Android captures traffic at the system level, and tun2socks translates that tun device traffic into a userspace proxy connection, so the proxy server can speak HTTP or SOCKS5. Per-app routing comes from the VPN service's ability to exclude selected applications from the tunnel, so only the app under analysis is proxied and everything else on the phone keeps its normal route.

That combination is the reason the tool exists rather than being a plain proxy app. A plain proxy app on Android needs a manual VPN configuration in the system settings, which is fiddly and gets lost. A VPN-based tool needs none of that, and it can also select which apps to include, which a system-level manual proxy cannot do at all.

The repository root reflects the stack: an android/ directory, a lib/ directory for the Dart side, a tun2socks directory and a btun2socks.sh script for building the native proxy, a pubspec.yaml, a shorebird.yaml for hot updates, and an analysis_options.yaml.

Driving it over MCP, and the default credential to change first

The feature that makes this different from the tools it replaces is remote control, and the way it is exposed is the Model Context Protocol.

The readme states that MCP remote calls are supported, with the IP address being the phone's IP, the default port 12345 and the default auth value appproxy. The configuration for a client looks like this:

{
  "mcpServers": {
    "appproxy-mcp": {
      "type": "http",
      "url": "http://192.168.0.10:12345/mcp",
      "headers": {
        "Authorization": "Bearer appproxy"
      }
    }
  }
}

The tools exposed are listed in a table: start_proxy to start the proxy with a given host, port, type, authentication and per-app proxy package list, stop_proxy to stop the running proxy service, get_proxy_status to check whether the proxy is currently active, get_proxy_config to read the current configuration, and update_proxy_config to change the running parameters, which triggers a restart if needed.

This is a genuinely useful shape for the intended workflow. An assistant or a script can start the proxy, run a test on the device, read the configuration back, and stop it, without anyone touching the handset. The MCP reference in the readme points at the Kotlin SDK's simple streamable server sample.

The security consequence is the obvious one, and the readme does not draw attention to it. The default bearer token is the literal string appproxy, and the endpoint is an HTTP service on the phone's network address on port 12345. On a shared or untrusted network, anything that can reach that address and send that header can start and reconfigure a proxy on your device. Change the auth value before you connect it to anything, and treat the phone's address as a secret of the same order.

Android 9 and above, with a companion step for the certificate

Two platform constraints are stated plainly.

The first is the minimum version. The readme says it supports Android 9 and above, and for anything below Android 9 it recommends Postern. Given the whole premise of the project is that the common tools are unfriendly to newer Android systems, it is a bit ironic that the replacement has a floor too, but the reason is structural: the per-app proxying depends on the VPN service capabilities the platform provides, and the notification and permission behaviour below Android 9 is more constrained.

The second is the certificate, and it is handled by a separate companion project. The readme mentions adding MoveCertificate, with the comment that the upstream and downstream are then both covered, linking to ys1231/MoveCertificate.

That is worth being careful about. Moving a user-installed CA certificate into the Android system certificate store is what lets an app's TLS traffic be decrypted by an interception proxy, and it is a procedure that normally requires a rooted device or a factory image, or that leaves the device in a state where a user CA is trusted by the whole system. On a handset you use every day, that is a meaningful change to the security posture of the device, and it needs to be undone afterwards.

So the sensible sequence is: use a test device or an emulator you can wipe, move the certificate there, do the traffic analysis there, and treat the phone's state afterwards as something to restore rather than something to leave.

The readme also states that when the app under analysis uses certificate pinning, the interception will fail, which is the other half of the same story and a reason the certificate work can look ineffective.

Building it: tun2socks first, then the Flutter APK

The build is a two-stage process, and the order matters because the native proxy binary has to exist before the app that drives it.

First, the tun2socks binary, built with a script at the repository root:

./btun2socks.sh

Then the Flutter application itself. The readme gives a specific toolchain recommendation, and the reasoning is worth passing on: it notes that if Android Studio debugging of Flutter jumps to a read-only file and you cannot modify code during debugging, you can restore the previous version, because that is a known pitfall. The recommendation is Android Studio Iguana 2023.2.1 Patch 2 or Android Studio Meerkat 2024.3.1 Patch 1, with the line length set to 100.

The build commands themselves are:

flutter --no-color pub global run intl_utils:generate
flutter build apk --release --split-per-abi --build-name=$VERSION --dart-define=BUILD_DATE=$(date +%Y-%m-%d) --obfuscate --split-debug-info ./build/

The intl_utils step is there because the app ships translations, and the release build splits per ABI, obfuscates the Dart code, and writes the split debug info into a build directory so a stack trace from a release crash can still be symbolised.

Hot updates go through Shorebird. The readme documents installing the Shorebird CLI with the platform-appropriate curl or PowerShell one-liner, registering at console.shorebird.dev, logging in with shorebird login, initialising the project with shorebird init, releasing with shorebird release -p android --artifact apk, and patching with shorebird patch --platforms=android. It also notes that appproxy is already bound to an app_id that can be force-updated, so patches reach installed copies.

The development guidance for contributors is that branches should be created from the iyue branch, which is also the default branch of the repository.

What it is not, and where a different tool fits

The comparison worth making is not with other proxy apps but with the alternative ways of getting the same information.

The first alternative is a conventional interception proxy on the desktop, a mitmproxy or a Burp or Charles setup, with the phone's traffic tunnelled to the desktop over a local network or a VPN. That gives you a much richer inspection environment, with a request log, breakpoints and rewriting, and it is the right answer when you are doing serious protocol work rather than checking what host an app talks to. The trade is that it needs a machine running and a configuration change on the phone, and the certificate has to be trusted on the device either way.

The second alternative is the system proxy that the tools in the readme already offer, configured by hand in Android's Wi-Fi settings. The readme's own criticism of those tools is that the configuration is easy to lose and the app list breaks on newer Android versions, and appproxy's answer is to make it a VPN and make it selectable in the app.

The third is not doing interception at all, and reading the app's logs and its own network configuration instead. For a question like which endpoints an app contacts, that is often enough and it involves no certificate at all.

What appproxy does not do is decrypt traffic. It is a proxy and a router, and for HTTPS it needs the companion MoveCertificate step to be in the picture at all. A reader who expects a full interception console will find the MCP tool list thin, and that is the correct expectation to set: the tool is a clean front end over a tunnel, not an analysis suite.

The project is GPL-3.0 licensed, the last push was on 2026-09-24 with v0.3.0 the same day, following v0.2.9 on 2026-09-22 and v0.2.8 on 2026-09-03, so the release cadence is frequent and the project is on an early version number.

Editorial conclusion

appproxy fits a developer who needs to inspect the traffic of an app on an Android device they control, who wants a simple interface rather than a full interception suite, and who wants to drive the proxy from an assistant or a script. It does not fit someone who needs a general purpose VPN, or a team that cannot accept a fixed default credential on a network-exposed endpoint. Before you rely on it, change the MCP auth value from the default, install the companion MoveCertificate step only on a test device you are willing to re-provision, and confirm your Android version is 9 or above, since the readme recommends Postern below that.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. ys1231/appproxy on GitHub