How to View Your Mobile App's Traffic: A Step-by-Step Guide to mitmproxy and Charles

Are you developing or testing a mobile app and want to know exactly what requests it sends to the server and what it gets back? This step-by-step guide takes you from a blank slate to full control over your own app's network traffic. We'll cover the most popular tools of 2026, learn how to install a trusted certificate on your phone, emulator, and simulator, and carefully bypass SSL pinning in debug builds using standard features.

Important from the start: Everything described below applies only to your own app or to an app you have written permission from the owner to investigate. This is material for QA engineers and developers, not instructions for tampering with other people's programs. We'll discuss this in detail in the rules and ethics section.

Introduction: Why Developers and Testers Need to See Their App's Traffic

A mobile app constantly communicates with the server: logging in, fetching product catalogs, sending analytics, syncing data. While everything works, these requests remain invisible. But as soon as something breaks, the question is always the same: what exactly went to the server and what came back?

Being able to read your own app's traffic solves several problems at once:

• Integration testing. You see the exact format of requests to your API, headers, body, response codes. It's easy to figure out who caused the bug: the client or the backend.
• Bug reproduction. When a tester reports an issue, you can view the real sequence of requests and repeat the scenario.
• Audit for leaks. You check if anything unnecessary is leaking out: tokens in logs, personal data in analytics, extra fields.
• Testing error scenarios. You can fake a server response to see how the app behaves with a 500 error or a timeout.

What You'll Get in the End

After completing this guide, you'll be able to set up a local proxy on your computer, route your phone's traffic through it, decrypt HTTPS requests, read them in a convenient interface, replay them, and spoof responses. All for your own app.

Who This Guide Is For

This material is written for QA engineers, mobile developers, and technical specialists who want to understand the network layer of their app. Level: beginner-friendly, but with some advanced elements.

What You Need to Know in Advance

A basic understanding of what an HTTP request, server, and client are. Command-line knowledge is a plus, but we'll also cover graphical tools. No deep cryptography knowledge required.

How Long It Will Take

The initial setup takes 1–2 hours, including installing tools and certificates. Subsequent runs take just a couple of minutes.

Prerequisites: Tools, Requirements, and What to Install

Before diving into traffic, let's set up your environment. We'll compare four popular tools and choose the one that fits you best.

Tool Comparison: mitmproxy, Charles, Proxyman, and Burp

All these tools work as MITM proxies, meaning they sit between your app and the server. Differences are in the interface, price, and convenience.

• mitmproxy. Free and open source. Runs in the terminal but also has a web interface called mitmweb. Ideal for those who love scripts and Python automation. Cross-platform.
• Charles. Paid, with a trial period. Classic GUI on Java, works on Windows, macOS, and Linux. Very popular among mobile QA for its simplicity.
• Proxyman. A modern tool with a clean interface, originally for macOS, now also available for Windows and Linux. Convenient automatic certificate setup.
• Burp Suite. A security-focused tool. Powerful, with a free Community version. A bit overkill for simple traffic inspection, but useful for advanced analysis.

Tip: If you're a beginner and want to see results quickly, start with Charles or Proxyman. If you love the terminal and automation, go with mitmproxy. For this guide, we'll use mitmproxy and Charles as the most versatile options.

System Requirements

• A computer running Windows, macOS, or Linux with administrator privileges.
• A mobile device or an Android emulator / iOS simulator.
• A shared Wi-Fi network for the phone and computer, or a configured emulator.
• Access to your app's source code to build a debug version.

What to Download and Install

1. Download your chosen proxy tool from its official website. For mitmproxy, use the installer for your OS or a package manager.
2. Install the tool following the standard setup wizard for your system.
3. For Android emulator: install Android Studio with an emulator and a system image without Google services if you want easy access to the system certificate store.
4. For iOS simulator on macOS: install Xcode from the App Store.

⚠️ Warning: Only download tools from the official developer websites. Proxy programs have deep access to your traffic, so fake versions could be dangerous. Verify installer signatures where possible.

Backups and Device Preparation

Working with certificates and network settings is usually safe and reversible. But it's good to be cautious.

1. Write down your phone's current Wi-Fi settings so you can restore them later.
2. Use a separate test device or profile for experiments, not your main work phone.
3. If using a work device, remember which certificates you install so you can remove them after debugging.

✅ Check: At this point, you should have a proxy tool installed, a test device or emulator ready, and access to a build of your app.

Basic Concepts: How an MITM Proxy Works and Why You Need Your Own Certificate

To move forward confidently, let's go over key terms in simple language. This is the foundation; without it, the steps will feel like magic.

What Is an MITM Proxy

MITM stands for man-in-the-middle. The proxy sits between your app and the server. The app thinks it's talking to the server, and the server thinks it's talking to the app. In reality, both are talking to the proxy, which sees and can show you all the traffic.

For regular HTTP, this works immediately: data is sent in plain text. But modern apps use HTTPS, where traffic is encrypted. That's where the fun begins.

What Happens During a TLS Handshake

HTTPS is built on top of the TLS protocol. When an app connects to a server, they perform a handshake. The server presents its certificate to prove it is who it claims to be. The app checks this certificate against a list of trusted certificate authorities.

A certificate authority (CA) is an organization that devices trust. Its signature on the server's certificate convinces the app the connection is secure.

Why You Need Your Own CA Certificate

For the proxy to show encrypted traffic, it must act as the server for the app. To do that, the proxy generates a certificate for each requested domain on the fly and signs it with its own root CA certificate.

But by default, the app doesn't trust this homemade CA. So we manually install the proxy's root certificate into the device's trusted certificate store. After that, the app sees the proxy's signature as trustworthy and establishes the connection.

Tip: Think of the proxy's root certificate as a pass. Until you give the device this pass, it won't let the proxy read encrypted traffic.

Why Without Trust You Only See the Hostname in SNI

If the proxy's certificate isn't installed, the app will refuse to establish a secure connection through it. But you'll still see something. At the start of the TLS handshake, the SNI field is sent — the server name being requested. It's needed so the server knows which site you're asking for.

So even without trusting the certificate, you'll see the list of domains the app connects to, but not the content of requests and responses. To read the content, you need a trusted certificate installed.

What Is SSL Pinning

SSL pinning (or certificate pinning) is an extra layer of security. The app stores the fingerprint of the expected server certificate or key and checks that the server presents exactly that. Even if the system has a trusted proxy certificate, the app with pinning will reject it because the fingerprint doesn't match. We'll talk about working with pinning in your own debug builds separately.

✅ Check: You understand that the proxy shows traffic by being the middleman, and that reading HTTPS requires a trusted root certificate from the proxy on the device.

Step 1: Configuring the Proxy in the Network on Android and iOS

Goal of this stage: Route all web traffic from your phone through your computer, where the proxy tool is running.

Prepare Your Computer and Get Its Address

1. Make sure your computer and phone are on the same Wi-Fi network.
2. Start the proxy tool. For mitmweb, type the command to launch the web interface in the terminal; for Charles, simply open the app.
3. Check which port the proxy is listening on. By default, mitmproxy uses port 8080; Charles uses 8888 or 8080 depending on the version.
4. Find your computer's local IP address on the network. On Windows, use the network settings command; on macOS and Linux, a similar command in the terminal. The address looks like 192.168.1.15.

Tip: Write down your computer's IP address and the proxy port on a piece of paper. You'll enter these two values into your phone's settings.

Setting Up the Proxy on Android

1. Open the Settings app on your phone.
2. Go to Network & Internet, then Wi-Fi.
3. Tap the name of your current network to open its settings.
4. Look for the Advanced section or a pencil icon to edit the network.
5. In the Proxy field, select Manual.
6. In the Proxy hostname field, enter your computer's IP address, e.g., 192.168.1.15.
7. In the Port field, enter the proxy port, e.g., 8080.
8. Save the settings by tapping Save.

Setting Up the Proxy on iOS

1. Open the Settings app.
2. Go to Wi-Fi.
3. Tap the blue information icon next to your network name.
4. Scroll down to the HTTP Proxy section.
5. Select Manual mode.
6. In the Server field, enter your computer's IP address.
7. In the Port field, enter the proxy port.
8. Go back; the settings are saved automatically.

⚠️ Warning: After setting up the proxy, all web traffic from your phone goes through the computer. If the proxy tool is off, the phone's internet will stop working. That's normal: just turn on the proxy or remove the settings.

Expected Result

Open a browser on your phone and visit a simple HTTP site. In the proxy interface, you should see requests appear. For now, HTTPS will show only the hostname because the certificate isn't installed yet.

Possible Issues: If nothing appears, check that the phone and computer are on the same network, that you entered the correct IP and port, and that the computer's firewall isn't blocking connections.

✅ Check: The proxy window shows incoming requests from the phone, at least as a list of domains.

Step 2: Installing and Trusting the Root Certificate

Goal of this stage: Make the device trust the proxy's root certificate so you can read HTTPS request content.

Download the Proxy Certificate

With the proxy set up and the phone going through it, there's a convenient way to get the certificate directly on the device.

1. Open a browser on your phone.
2. For mitmproxy, go to the special service address mitm.it. This page only appears when traffic is going through mitmproxy.
3. You'll see buttons for different platforms. Choose the one you need, e.g., Android or Apple.
4. A certificate file will download.
5. For Charles, the certificate is also available via a service address shown in the program's help menu.

Installing on Android 7 and Newer

Starting from Android 7, the system separates two certificate stores: user and system. This is very important.

• User store. You can install a certificate here without root. But by default, apps don't trust user certificates unless the developer explicitly allows it in the app's configuration.
• System store. All apps trust it, but you can only add a certificate here on a rooted device or on an emulator with a non-Google-services image.

To install into the user store:

1. Open Settings, then Security.
2. Find Encryption & credentials or Additional security settings.
3. Select Install a certificate, then CA certificate.
4. The system will warn you about risks; confirm the installation.
5. Point to the downloaded certificate file.
6. Give the certificate a recognizable name, like DebugProxy.

Important: Because of the separate stores on Android 7+, your app may not see traffic even if the certificate is installed in the user store. We'll cover the solution via the app's configuration in the pinning step.

Installing and Trusting on iOS

On iOS, the process has two steps: installing the profile and enabling trust.

1. After downloading the certificate, iOS will tell you a profile has been downloaded.
2. Open Settings; at the top you'll see Profile Downloaded.
3. Tap on it and select Install in the top right corner.
4. Enter your device passcode if you have one.
5. Confirm the profile installation.

Now the crucial step that many forget: enabling full trust:

1. Open Settings, then General.
2. Go to About.
3. Scroll down to Certificate Trust Settings.
4. Find your proxy certificate in the list.
5. Toggle the switch next to it to enable full trust for that root certificate.

⚠️ Warning: Without enabling the switch in Certificate Trust Settings, iOS will consider the certificate installed but not trusted. HTTPS traffic will not be readable. This is the most common mistake beginners make on iOS.

Expected Result

Open your browser and go to any HTTPS site. Now in the proxy interface, you should see the full content of requests and responses, not just domain names.

✅ Check: The proxy tool shows decrypted HTTPS request content from the phone's browser.

Step 3: Doing the Same on Android Emulator and iOS Simulator

Goal of this stage: Set up traffic interception without a physical device, directly on the developer's computer.

Android Emulator

The emulator is convenient because you can use a non-Google-services image and gain access to the system certificate store.

1. In Android Studio, open Device Manager and create a virtual device.
2. When choosing a system image, prefer one without Google Play, so you have system partition access.
3. Start the emulator.
4. In the emulator's extended settings, you can set the proxy directly, or you can configure it via Wi-Fi settings inside the emulator just like on a real phone.
5. For system store access, use command-line tools that let you restart the emulator with write access to the system partition and add the certificate there.

Tip: An emulator without Google services and with system store access saves you many headaches with certificate trust. It's the best choice for regular debugging.

iOS Simulator

The iOS simulator on macOS uses the trusted certificates of the macOS system, which simplifies setup.

1. Install the proxy's root certificate into your Mac's system keychain.
2. Open the Keychain Access app, find the proxy certificate.
3. Double-click it, expand the Trust section, and set SSL/TLS to Always Trust.
4. Launch the simulator via Xcode. It will inherit the certificate trust from macOS.
5. The simulator's traffic will go through the Mac's system proxy if configured, or through the proxy set in network settings.

Expected Result. In both cases, you'll see decrypted traffic from the test app or browser running in the emulator or simulator.

Possible Issues. If the Android emulator doesn't pick up the proxy, check the Wi-Fi settings inside it and the emulator launch parameters. For the iOS simulator, make sure the certificate in the keychain is marked as trusted.

✅ Check: Traffic from the emulator or simulator is readable decrypted in the proxy tool.

Step 4: Handling SSL Pinning in Your Debug Build

Goal of this stage: Understand if the app has certificate pinning and safely disable it only in the debug build using platform-standard features.

This is the most critical section, so let's approach it thoughtfully.

How to Tell if Pinning Is Enabled

If the proxy certificate is installed and trusted, your browser shows traffic, but your app still doesn't work or complains about a network error, chances are it has pinning.

• In the proxy interface, you'll see the connection break during the TLS handshake for your app's domains.
• Your app's logs may contain messages about certificate validation errors or untrusted chains.
• Often, the developer knows pinning was added intentionally to protect the release build.

Disabling Pinning on Android via network_security_config

Android provides a standard network security configuration mechanism. You can allow user certificates to be trusted only in debug builds.

1. In your project, create a network security configuration file in the resources.
2. In it, describe trust rules for certificates specifically for the debug configuration, using a special block for debug overrides.
3. Specify that in debug mode the app trusts the user certificate store.
4. Link this file in the app's manifest via the appropriate attribute.
5. Ensure that the debug overrides only apply when the app is built in debug mode and never in release.

Important: The special debug override block only works when the app is marked as debuggable. In a release build, these rules are completely ignored by the system, ensuring security.

Disabling Checks on iOS via Info.plist Settings

On iOS, transport security is controlled by ATS. In a debug build, you can relax strict checks for specific domains of your test environment.

1. Open your debug configuration's Info.plist file.
2. Add App Transport Security settings for the needed test server domains.
3. Remember that ATS controls connection policy; custom pinning in the app code must be disabled separately.
4. If pinning is implemented in the code, add a condition so that the fingerprint check only runs in the release configuration.

⚠️ Warning: Never leave relaxed checks in a release build. That creates a real vulnerability for your app's users. All changes must strictly apply to the debug configuration and automatically disappear in release.

Why Only in Debug and Never in Release

SSL pinning protects your app's users from traffic interception. Disabling it in debug is something you do on your own controlled device, for diagnostic purposes, consciously and temporarily. In release, such protection is critical and should remain as strict as possible.

Tip: Separate the certificate validation logic by build flag. Configure it so that even by accident you can't build a release with relaxed checks. This protects you from human error.

Expected Result

After correctly configuring the debug build, your app will connect through the proxy, and you'll see its decrypted requests and responses.

✅ Check: Your app's requests to its API appear readable in the proxy, and the changes only affect the debug build.

Step 5: Reading and Analyzing Traffic

Goal of this stage: Learn to find the requests you need, filter out noise, export data, replay requests, and spoof responses.

Filters and Search

Even a small app generates dozens of requests. Filters help you find what you need.

1. Use a domain filter to show only requests to your API.
2. Filter by content type, e.g., only JSON responses.
3. Search by a string in the request or response body to quickly find a specific call.
4. Charles has a convenient host tree; mitmweb offers a flexible filter string.

Tip: Set a filter to show only your app's domains. This immediately removes background traffic from the system and third-party services.

Exporting to HAR

The HAR format is a standard way to save a traffic session into a single file. It's convenient for sending to the backend team or attaching to a bug report.

1. Select the requests you need or the whole session.
2. Choose the export to HAR option in the tool's menu.
3. Save the file and attach it to the issue in your tracker.

Replaying Requests

Sometimes you need to repeat the same request several times, for example to test idempotency or reproduce a bug.

1. Select the request in the list.
2. Use the replay function – in Charles it's Repeat, in mitmproxy it's a flow replay command.
3. If needed, edit the request before replaying, changing headers or the body.

Spoofing Responses for Testing Error Scenarios

This is a powerful feature. You can make the app receive a response you want instead of the real one.

1. Set up a spoofing rule – in Charles it's Map Local or Breakpoints, in mitmproxy it's Python scripts.
2. Specify that when a request to a certain address is made, a pre-prepared response is returned, e.g., a 500 error or an empty list.
3. Run the scenario in the app and see how it handles the error.

Tip: Using response spoofing, you can easily test the app's behavior with poor internet, server errors, or unexpected data, without touching the real backend.

✅ Check: You can filter traffic, export HAR, replay a request, and spoof a response for your app.

How Mobile Proxies Help Test Your App from a Different Network and Region

Let's talk separately about mobile proxies. These are proxy servers that run through real mobile carrier networks. They're useful for testing how your app behaves when a user connects from a mobile internet in a different region.

Why QA Needs This

• Regional content verification. Many apps show different data depending on the user's region. A mobile proxy allows you to see the app from the perspective of a user in a specific region.
• Testing on a mobile network. Behavior on mobile internet differs from Wi-Fi: different latencies, IP changes, carrier network quirks. A mobile proxy helps reproduce such conditions.
• Geo-dependent logic checks. If your backend determines the region by IP, you can verify that the logic works correctly for different locations.

Important: Use mobile proxies only for testing your own app and within legal boundaries. This is a QA tool for checking regional logic correctness, not a means to bypass anything. Services like MobileProxy.space provide legal access to mobile IPs for such tasks.

Tip: Combine a mobile proxy for changing the exit point with a local MITM proxy for reading traffic. This way you see the request contents while checking regional behavior.

Verifying Success: Checklist for a Successful Setup

Go through this list to make sure everything is working as intended.

• The proxy tool is running and listening on the correct port.
• The phone, emulator, or simulator directs traffic through the proxy.
• The proxy's root certificate is installed and trusted on the device.
• HTTPS traffic from the browser is readable in decrypted form.
• In the app's debug build, pinning is disabled using standard platform features.
• Your app's API requests appear fully in the proxy.
• You can filter, export, replay, and spoof requests.

How to Test

1. Launch the debug build of your app.
2. Perform a typical scenario, such as logging in and loading the main screen.
3. Verify that the proxy shows requests to your API with readable bodies.
4. Replay one request and spoof one response to check the app's reaction.

Success indicators. You see the full lifecycle of your app's network interactions and can influence them for testing.

Common Mistakes and Solutions

Let's go over frequent problems in the format: problem, cause, solution.

The App Ignores the System Proxy

Problem: Traffic doesn't appear in the proxy, but the browser works. Cause: The app uses its own network stack that doesn't read system proxy settings. Solution: In the debug build, configure the network client to respect the system proxy, or use transparent proxy mode at the network level.

QUIC Traffic Is Not Visible

Problem: Some requests are missing. Cause: The app uses the QUIC protocol over UDP, which regular HTTP proxies don't intercept. Solution: In the debug build, temporarily disable QUIC support in the network client so traffic goes over regular HTTPS and becomes visible to the proxy.

Android 14 Nuances

Problem: Certificate is installed, but the app doesn't see it. Cause: In newer Android versions, rules for user certificates have become stricter, and apps don't trust them by default. Solution: Use network security configuration with debug overrides, or the system store on an emulator.

iOS Doesn't Decrypt Traffic

Problem: The app's requests on iOS are not readable. Cause: The certificate is installed, but full trust is not enabled in Certificate Trust Settings. Solution: Go to Settings, General, About, Certificate Trust Settings, and enable the switch.

gRPC and HTTP/2

Problem: Data is visible but in a binary, unreadable format. Cause: The app uses gRPC over HTTP/2 with binary serialization. Solution: Use tools that understand HTTP/2, and if needed, plugins to decode the message format so you can read the content.

No Internet After Proxy Setup

Problem: The phone no longer has internet access. Cause: The proxy tool is off, but the proxy settings remain. Solution: Turn on the proxy on your computer or remove the proxy settings from the phone's Wi-Fi configuration.

Firewall Blocking Connections

Problem: The phone cannot connect to the proxy. Cause: The computer's firewall blocks incoming connections on the proxy port. Solution: Add a rule to allow traffic on the proxy port in your system's built-in firewall.

Additional Features and Advanced Settings

Once you've mastered the basics, it's time to expand your toolkit.

Scripting and Automation

mitmproxy allows you to write Python scripts that automatically modify requests and responses. This is great for regression testing and complex spoofing scenarios.

Saving Sessions

Save recorded traffic sessions to files so you can revisit them later or share with the team. This speeds up bug analysis.

Mapping to Local Files

The feature to map a response to a local file lets you develop the app's UI independently of the backend's readiness. You simply serve pre-prepared JSON responses to the app.

Throttling

Many proxies can artificially slow down the connection. This helps test the app's behavior on a slow network and spot timeout issues.

Tip: Build a library of typical spoofing and throttling scenarios and reuse them with each release. This turns manual debugging into a repeatable testing process.

FAQ: Frequently Asked Questions

Do I need root on Android to read traffic?

For the user store and your own app with a debug configuration, root is not needed. For the system store on a real device, you need root, but it's easier to use an emulator without Google services.

Can I avoid installing a certificate?

Without a trusted certificate, you'll only see domain names in SNI, not the content. For reading requests, the certificate is mandatory.

Why does the browser see traffic but the app does not?

Most likely the app has SSL pinning or a custom network stack. Configure the debug build as described in the pinning step.

Is it safe to install a proxy root certificate?

On a test device and only for the duration of debugging, it's acceptable. After you're done, remove the certificate to avoid leaving extended trust on the device.

What if traffic goes over QUIC?

Disable QUIC in the debug build of your network client so connections go over regular HTTPS and become visible to the proxy.

Can I analyze someone else's app's traffic?

No. Only your own app or one you have explicit permission from the owner to inspect. This is a fundamental rule.

Charles or mitmproxy: which should a beginner choose?

Charles is easier to start with thanks to its graphical interface. mitmproxy is more powerful for automation. Start with whichever feels more comfortable.

How do I undo all changes after debugging?

Remove the proxy settings from Wi-Fi, delete the installed certificate in security settings, and rebuild the app in release configuration with full checks.

Why doesn't certificate trust work on iOS?

You installed the profile but didn't enable full trust in Certificate Trust Settings. That's a separate mandatory step.

Can I view traffic on a slow network?

Yes, many proxies can artificially throttle the connection to test app behavior on a poor internet connection.

Conclusion

Congratulations, you now have a complete set of skills to analyze the network traffic of your own mobile app. You've learned to choose between mitmproxy, Charles, Proxyman, and Burp, set up a local proxy, route phone, emulator, and simulator traffic through it.

You've understood how an MITM proxy works and why you need a trusted root certificate, mastered the nuances of certificate stores on Android 7+ and the mandatory trust step on iOS. You've learned how to carefully and only in the debug build disable SSL pinning using platform-standard features, never touching release.

Finally, you can read, filter, export, replay, and spoof requests, and use mobile proxies to test regional app behavior legally.

What's Next

Consolidate the skill on a real project: set up traffic interception for your own app and add typical response spoofing scenarios to your testing process. Gradually explore automation scripts and share traffic sessions with your team.

Where to go from here: dive deeper into HTTP/2 and gRPC analysis, learn to write mitmproxy scripts, integrate traffic interception into automated tests. And always remember the golden rule: work only with your own app or with explicit permission from the owner, comply with the law, and respect user privacy.