How to Intercept Android App Traffic with mitmproxy (and Read What It Sends)

TL;DR: Install mitmproxy on your computer, install its CA certificate on your Android device, point the device’s Wi-Fi proxy setting at your computer on port 8080, and you can read every HTTP and HTTPS request an app makes. Apps targeting Android 7 or later ignore user-installed certificates by default, and SSL-pinned apps need a separate bypass, both covered below.

Reading an app’s network traffic is one of the fastest ways to understand what it actually does: which servers it talks to, what it sends on launch, where your data goes. mitmproxy is the standard free tool for the job. It sits between your phone and the internet, decrypts the traffic with a certificate you install, and shows you each request in a searchable interface. This guide covers the full setup on a real device, the two common reasons it fails, and how to get past each one.

One note before starting: only intercept traffic from apps you own or have explicit permission to test. The same steps that reveal a tracking SDK can also expose other people’s session tokens on a shared network, so keep the proxy on your own machine and your own device.

What you need

Step 1: Install mitmproxy

The simplest route is pip:

pip install mitmproxy

On macOS, brew install mitmproxy works too. The install gives you three tools: mitmproxy (terminal UI), mitmweb (browser UI), and mitmdump (scriptable, no UI). For reading traffic by eye, mitmweb is the pleasant choice. Start it:

mitmweb

It starts the proxy on port 8080 and prints the address of its web interface. Leave it running.

Step 2: Install mitmproxy’s CA certificate on the phone

To decrypt HTTPS, your phone must trust mitmproxy’s certificate authority. The proxy hosts its own installer page:

1. On the phone, set the Wi-Fi proxy to manual, pointing at your computer’s IP and port 8080 (see step 3 for the exact taps).
2. Open the browser on the phone and go to mitm.it.
3. Choose Android, download the certificate, and install it when prompted.

This is where Android 7.0 (API 24) changed the rules. Since 7.0, apps that target API 24 or higher do not trust user-installed CA certificates by default, only certificates in the system store. The certificate you just installed lands in the user store, so most modern apps will still refuse the connection with a TLS error. That is expected, not a misconfiguration. The fixes are in the troubleshooting section below.

Step 3: Point the phone at the proxy

On the phone: Settings → Wi-Fi, long-press your network, Modify network → Advanced options, set Proxy to Manual. Enter your computer’s local IP address as the proxy hostname and 8080 as the port. Save.

To find your computer’s IP: on Linux or macOS run ip addr or check System Settings → Network; on Windows run ipconfig. It will look like 192.168.1.42.

Test it: open a browser on the phone and visit any HTTP site. Requests should appear in mitmweb immediately. If they do, the plumbing works and you can move on to the app.

Step 4: Capture and read the traffic

Open the target app and use it normally while mitmweb records. Each row is one request. Click a row to see the request and response headers, bodies, and timing. A few things that make reading easier:

• Filter: type ~m POST to show only POST requests, or ~d example.com to show one domain. Combine them: ~m POST & ~d api.example.com.
• Save everything: run mitmdump -w capture.mitm instead of mitmweb to write all flows to a file, then open it later with mitmweb -r capture.mitm.
• Replay: select a request and press r to replay it, useful for seeing what changes between runs.

What to look for

• Endpoints: the hostnames and paths the app contacts. Analytics and ad SDKs usually show up as third-party domains within seconds of launch.
• Authentication: how the app proves who you are: bearer tokens, API keys, cookies. Note whether tokens are sent over every request and whether they expire.
• Cleartext HTTP: any http:// request carrying personal data is a finding, not a footnote.
• Certificate and TLS details: weak cipher suites or missing certificate validation show up when connections succeed where they should not.

When it does not work

The first row is the one that confuses everyone. It is worth repeating: on a modern app, a correctly installed user certificate and a correctly configured proxy will still fail, because the app was built to distrust user CAs. That behavior is the Android platform working as designed since 7.0.

Key takeaways

• mitmproxy plus its CA certificate plus a manual Wi-Fi proxy on port 8080 is the whole setup; mitmweb gives you the readable interface.
• Android 7.0+ apps ignore user-installed CAs by default, so plan for the system-store or repackaging step from the start.
• Certificate pinning is a separate problem from certificates, and it has a separate fix (Frida/Objection).
• Apps that bypass the proxy setting can still be captured with mitmproxy’s WireGuard mode.
• Only intercept apps you own or have permission to test.

References

• mitmproxy documentation, proxy modes: docs.mitmproxy.org/stable/concepts/modes
• mitmproxy 12.2.3 on PyPI: pypi.org/project/mitmproxy/12.2.3
• Android network security configuration: developer.android.com/privacy-and-security/security-config
• Our SSL pinning bypass guide: How to Bypass SSL Pinning on Android with Frida and Objection
• Our Apktool guide: How to Decode, Edit, and Rebuild an APK with Apktool