Proxy Tools: Charles, Fiddler, mitmproxy

Why Proxy Tools for QA #

HTTP proxy tools sit between the client and server, giving you complete visibility and control over network traffic. For QA engineers, they are indispensable for debugging mobile apps (where you cannot see network requests directly), testing edge cases (by modifying server responses), and simulating network conditions (throttling, latency).

Unlike browser DevTools that only show traffic from the browser, proxy tools capture traffic from any application — mobile apps, desktop software, CLI tools, and background services. This makes them essential for testing applications beyond web browsers.

Common QA Use Cases #

• Debugging mobile apps: See every API call the app makes
• Testing error handling: Modify responses to return errors, empty data, or malformed JSON
• Simulating slow networks: Throttle bandwidth to test under 3G/4G conditions
• Verifying API contracts: Inspect exact request/response payloads
• Testing without backend changes: Replace server responses with local files

Charles Proxy and Fiddler #

Charles Proxy (macOS/Windows/Linux) #

Charles is the most popular GUI proxy for QA engineers. Key features:

Setup:

1. Install Charles Proxy
2. Configure browser/device to use Charles as HTTP proxy (usually localhost:8888)
3. For HTTPS: Install Charles root certificate and enable SSL proxying for target domains

Essential Features:

Breakpoints Example:

1. Enable breakpoints on api.example.com/users
2. Make the request from the app
3. Charles pauses the response before forwarding
4. Modify the response body (e.g., change user count to 0)
5. Forward the modified response to test empty state handling

Fiddler (Windows, .NET-based) #

Fiddler provides similar functionality to Charles with stronger Windows integration. Its key advantages include FiddlerScript (JavaScript-based rules engine) and better .NET application debugging.

mitmproxy for Automation #

mitmproxy is a command-line proxy tool that can be scripted with Python — making it perfect for CI/CD integration and automated testing.

Installation and Basic Usage #

# Install
pip install mitmproxy

# Start interactive console mode
mitmproxy

# Start web interface mode
mitmweb

# Start dump mode (non-interactive, for scripting)
mitmdump

Python Addon Script #

# modify_response.py — Inject error conditions for testing
from mitmproxy import http

def response(flow: http.HTTPFlow):
    # Simulate server error on specific endpoint
    if "/api/v1/checkout" in flow.request.pretty_url:
        flow.response.status_code = 500
        flow.response.text = '{"error": "Internal Server Error"}'

    # Add latency header for performance monitoring
    if flow.response:
        flow.response.headers["X-Proxy-Latency"] = str(
            flow.response.timestamp_end - flow.request.timestamp_start
        )

# Run with addon script
mitmdump -s modify_response.py

Charles Proxy Rewrite Rule Example #

Replace production API URL with staging in a mobile app without code changes:

1. Open Rewrite Settings (Tools > Rewrite)
2. Add new rule: Match api.production.com in Host
3. Replace with api.staging.com
4. The mobile app now hits staging while thinking it is production

Advanced Proxy Techniques #

Mobile App Proxy Setup #

iOS:

1. Connect to the same WiFi as your proxy machine
2. Settings > WiFi > HTTP Proxy > Manual: set proxy IP and port
3. Visit chls.pro/ssl to install Charles root certificate
4. Settings > General > About > Certificate Trust Settings > Enable Charles root

Android:

1. For Android 7+, apps ignore user-installed certificates by default
2. Add network security config to allow proxy certificates:

<!-- res/xml/network_security_config.xml -->
<network-security-config>
  <debug-overrides>
    <trust-anchors>
      <certificates src="user" />
    </trust-anchors>
  </debug-overrides>
</network-security-config>

3. This requires a debug build of the app — coordinate with developers

WebSocket and gRPC Inspection #

• Charles Proxy can inspect WebSocket frames (visible in the session view)
• mitmproxy supports WebSocket inspection with dedicated event hooks
• gRPC traffic (HTTP/2 + protobuf) requires proto definition files for readable inspection

Automated Response Recording for Mock Servers #

Record proxy sessions and export them as mock data:

# Record all responses to a file
mitmdump -w recorded_session.flow

# Replay recorded responses (acts as mock server)
mitmdump --server-replay recorded_session.flow

This creates instant mock servers from real traffic — invaluable for offline testing and CI environments.

Performance Profiling with Proxy Timing #

Proxy tools capture precise timing data for every request. Use this to:

• Identify the slowest API calls in a user flow
• Compare response times before/after code changes
• Detect unexpected API calls (apps making more requests than expected)
• Verify request batching and caching behavior

Hands-On Exercise #

Set up Charles Proxy and perform these tasks:

1. Configure SSL proxying for api.example.com
2. Capture traffic from a mobile app or web browser
3. Use breakpoints to modify an API response (change a status code to 500)
4. Use Map Local to return mock data from a local JSON file
5. Throttle connection to simulate 3G conditions and observe app behavior

Pro Tips #

• Always remember to disable proxy settings after testing — leftover proxy configs cause mysterious failures
• Use Map Local to test frontend against mock API responses without a backend
• Record proxy sessions for bug reports — they capture exact request/response data
• For mobile testing, use Android network security config to allow proxy certificates
• mitmproxy scripts can be integrated into CI for automated traffic manipulation tests

Key Takeaways #

1. Proxy tools provide unmatched visibility into client-server communication for debugging
2. Request/response modification enables testing edge cases impossible to create through the UI
3. mitmproxy’s scriptability bridges the gap between manual investigation and CI automation
4. Mobile app testing almost always requires proxy configuration for network-level inspection