Charles and mitmproxy reveal a mobile application's network communication: requests, responses, headers, delays, and call sequences. They help QA understand what lies behind a screen symptom and reproduce server responses that are difficult to trigger through ordinary actions.
These tools are particularly useful for errors, empty data, and slow responses. However, a proxy shows only traffic that actually passes through it. A missing request in the list does not prove the app did not communicate over the network.
How an intercepting proxy works
In a typical setup, the device routes supported traffic through a computer running the proxy. For HTTPS, the tool establishes separate TLS connections and uses its own certificate authority. The client must trust that CA to allow content inspection.
This distinction is essential: setting an IP address and port alone does not decrypt HTTPS. Some metadata or a CONNECT tunnel may remain visible even when request contents are inaccessible.
Preparing a safe environment
Use a test device, test accounts, and an agreed environment. Establish which build supports network diagnostics and which domains may be modified. Record the original network settings before starting.
The device and computer usually need network access to each other; then configure the HTTP proxy and check tool reachability. In Charles, SSL Proxying settings select HTTPS hosts. In mitmproxy, use the appropriate operating mode and trusted certificate for the selected installation.
Why a certificate may not be enough
On Android, trust in a user-installed CA depends on app configuration and its target platform. A modern app need not accept a user-installed certificate simply because the browser does. The team can provide a debug-only trust configuration for diagnostics.
On iOS, manually installing a CA profile does not automatically enable SSL/TLS trust. On versions with the relevant settings section, enable full trust for the required test certificate in Certificate Trust Settings; consult your OS documentation for its location. Certificates installed through MDM or Apple Configurator follow different trust rules.
Certificate pinning further restricts acceptable certificates or keys. Pinning is not a proxy defect. Use the team's intended test configuration; modifying production app protection should not become a routine QA instruction.
What to inspect in a session
Start with a specific action and a short time window. Map the request to the UI event, then inspect the method, URL, body, response code, and actual content.
- →Whether a request was sent after the tap, and how many times.
- →Whether it targets the correct environment under the correct account.
- →Whether parameters match entered data.
- →Whether the app handles the successful response body correctly.
- →Whether there is a retry, redirect, cancellation, or stalled request.
A 200 code does not establish a correct business result. For example, the response may contain an empty list while the app incorrectly displays old cached data.
Practical example: handling a cart error
Suppose you need to test temporary cart unavailability. Modify responses only for the test endpoint and according to the agreed scenario.
- 1.Retrieve the cart without modifications and save the original request and normal response.
- 2.Configure a narrowly targeted rule for the required URL and method. Return the agreed 503 response instead of the normal response.
- 3.Open the cart. Expect a clear error state, preservation of safe local context, and an available retry action.
- 4.Tap retry several times. Check that this does not trigger an uncontrolled stream of identical requests.
- 5.Disable the rule and reload. The app should restore the current cart without restarting or duplicating products.
- 6.Clear active rules and check the normal scenario again so the next tester does not inherit an artificial fault.
Substitution verifies the client's reaction to the selected response. It does not establish that the real backend generates that response correctly during an incident.
Data substitution and experiment boundaries
Breakpoints, rewrites, and local responses let you test a missing field, empty array, unusual value, or delayed response. Change one condition at a time and preserve the exact rule alongside the result.
Distinguish client resilience testing from server validation testing. If a response is changed after leaving the server, you cannot conclude that the backend stored the substituted data. That requires a separate request and verification of server state.
Slow networks and disconnections
Charles can limit bandwidth and add delay. This helps test screen loading, timeouts, and repeated taps. Record profile parameters and their scope.
However, HTTP throttling is not a complete mobile network model. It does not automatically reproduce radio interference, network handovers, every TCP characteristic, or app traffic using protocols that bypass the proxy. Supplement critical network scenarios with real devices and suitable network tools.
When traffic is not visible
Check computer reachability, address and port, proxy connection permission, the device's active network, HTTPS settings, and CA trust in that order. Then establish whether the app uses the system proxy and which protocol it uses.
Avoid blindly disabling TLS checks. If the app still works but the session is empty, possible causes include a different route, cache, VPN, or network stack behavior. If the app stops working only with the proxy, examine the TLS error and test build configuration.
Common mistakes and takeaways
Common mistakes are leaving substitution active, forgetting to restore network settings, and attaching a session containing valid tokens. Before sharing exports, remove secrets, cookies, and personal data; afterward, remove unnecessary trust in the test CA.
A good network experiment connects an action, request, controlled change, and expected UI behavior. Charles and mitmproxy make those relationships visible when QA understands interception limits and keeps client conclusions within their proper scope.