Fiddler for Debugging HTTP Traffic in Windows Applications and UWP: Complete Guide to Proxy Setup

Installation and initial setup

Installing Fiddler Classic takes about two minutes. Download the installer from the official website telerik.com/fiddler and run it. After installation, Fiddler automatically sets itself as the system proxy for Windows on port 127.0.0.1:8888.

Immediately after launching, you will see the main window with three areas:

• Left panel (Sessions) — a list of all intercepted requests in real time
• Upper right panel — details of the selected request (headers, body, parameters)
• Lower right panel — server response

The first thing to do is to set up filtering; otherwise, the list will include all system traffic from Windows (updates, telemetry, OneDrive, etc.), making it difficult to find the necessary requests. Go to the Filters tab on the right and enable Use Filters. In the Show only the following Hosts field, specify the domains you are interested in.

It is also recommended to set up auto-saving of sessions right away: File → Capture Traffic and File → Save → All Sessions. This will allow you to return to the recorded traffic later and analyze it offline.

Intercepting HTTPS traffic: certificate setup

By default, Fiddler only intercepts HTTP traffic. To work with HTTPS (which accounts for 95%+ of modern traffic), you need to set up SSL decryption. Fiddler acts as a Man-in-the-Middle: it generates its own root certificate and signs all HTTPS connections with it.

Step-by-step setup for HTTPS interception:

1. Open Tools → Options → HTTPS
2. Check Capture HTTPS CONNECTs
3. Check Decrypt HTTPS traffic
4. From the dropdown, select ...from all processes
5. Click the Actions → Trust Root Certificate button
6. Confirm the installation of the certificate in the Windows system store
7. Restart Fiddler

After this, in the Protocol column, you will see HTTPS instead of CONNECT, and you will be able to view the decrypted content of requests and responses.

Some applications use Certificate Pinning — they check for a specific server certificate and will refuse to work through Fiddler. In this case, you will see a connection error in the application. Bypassing pinning is a separate topic beyond the scope of this article.

How to intercept traffic of UWP applications

UWP (Universal Windows Platform) applications are those from the Microsoft Store: Mail, Maps, Movies & TV, Spotify, Netflix, and many others. Their peculiarity is that for security reasons, they operate in an isolated container (App Container) and do not use the system proxy. This is why the standard Fiddler setup does not intercept their traffic.

To solve this problem, Fiddler provides a special tool — AppContainer Loopback Exemption Utility. It adds the UWP application to the exceptions list, allowing it to access the local Fiddler proxy.

Method 1 — through the Fiddler interface:

1. Select WinConfig from the menu (button on the toolbar or Tools → Win8 Loopback Exemptions)
2. A list of all installed UWP applications will open
3. Find the desired application and check the box next to it
4. Click Save Changes
5. Restart the UWP application

Method 2 — through the command line (for automation):

CheckNetIsolation LoopbackExempt -a -n="Microsoft.WindowsMaps_8wekyb3d8bbwe"

Replace Microsoft.WindowsMaps_8wekyb3d8bbwe with the Package Family Name of the desired application. You can find it in PowerShell with the command:

Get-AppxPackage | Select-Object Name, PackageFamilyName | Sort-Object Name

After adding the exemption, the UWP application will start sending traffic through Fiddler. You will see its requests in the session list — they are usually easily identifiable by User-Agent or destination host.

Filters, breakpoints, and modifying requests

The three most powerful features of Fiddler for debugging are session filtering, breakpoints, and AutoResponder. Let's break down each of them.

Session Filtering

The Filters tab allows you to show only the necessary requests. Key options include:

• Show only the following Hosts — filter by domain (e.g., api.example.com)
• Show only if URL contains — filter by part of the URL
• Show only if response Content-Type — only JSON, XML, images, etc.
• Hide if URL contains — exclude noise requests (e.g., telemetry, analytics)

You can also use the QuickExec line at the bottom of the window for quick commands. For example, select status 404 will highlight all requests with a 404 error, while bold api will bold all sessions containing "api" in the URL.

Breakpoints

Breakpoints allow you to stop a request or response before it is sent/received and manually modify the content. This is analogous to a breakpoint in a code debugger, but for HTTP.

• Rules → Automatic Breakpoints → Before Requests — stops each request before sending
• Rules → Automatic Breakpoints → After Responses — stops each response before passing it to the application
• Right-click on a session → Breakpoint → Break on Request — a point breakpoint on a specific URL

When a request is stopped, you can modify any header, request body, URL, and click Run to Completion to continue. This is especially useful for testing application behavior with modified data.

AutoResponder

AutoResponder is a tool for substituting server responses. You create a rule: "if the URL matches the pattern — return this file/response." Applications include:

• Testing an application with API stubs without a real backend
• Simulating server errors (500, 503, timeouts)
• Substituting resources — loading a local version of JS/CSS instead of the server version
• Speeding up development — caching slow requests to external APIs

Connecting an external proxy through Fiddler

One of Fiddler's important capabilities is operating in "proxy through proxy" mode (upstream proxy). Fiddler intercepts traffic locally and then routes it through an external proxy server. This allows you to debug requests while changing your IP address or geo-location simultaneously.

When this is needed:

• Testing application behavior when working through a corporate proxy
• Checking geo-dependent content — how the application works from another country
• Debugging an application that itself uses a proxy
• Testing APIs with IP restrictions (whitelist by IP)

Setting up an upstream proxy in Fiddler Classic:

1. Open Tools → Options → Gateway
2. Select Manual Proxy Configuration
3. In the Proxy field, enter the proxy address in the format host:port
4. If the proxy requires authentication — specify the username and password
5. Click OK and restart traffic capture

Fiddler supports HTTP, HTTPS, and SOCKS5 proxies as upstream. For SOCKS5, the format is slightly different:

socks=proxy.example.com:1080

For testing geo-dependent application behavior, residential proxies are well-suited — they use real IPs from home users in the desired country, and the application receives responses just as a real user from that region would. This is important if the API returns different content based on geo-location.

If you need high speed for downloading large amounts of data during debugging, data center proxies are suitable — they provide stable connections and minimal latency, which is convenient when working with heavy APIs.

static function OnBeforeRequest(oSession: Session) {
  if (oSession.HostnameIs("api.us-service.com")) {
    oSession["x-OverrideGateway"] = "us-proxy.example.com:8080";
  }
}

Practical scenarios: parsing, API testing, geo-bypassing

Let's discuss specific tasks that can be conveniently solved with Fiddler.

Scenario 1: Reverse engineering the API of a mobile application

You want to automate actions in an application, but it lacks a public API. Solution: run the application on an Android emulator or through the Windows client, configure it to use Fiddler as a proxy, and record all requests while performing the necessary actions.

After recording, you will have a complete picture: endpoints, request formats, authentication headers, tokens. This data can be used to write your own client or automate through scripts.

Scenario 2: Debugging a marketplace parser

When developing a parser for Wildberries, Ozon, or other marketplaces, it is often unclear why requests are blocked. Fiddler allows you to compare requests from the browser (which go through) with requests from the parser (which are blocked) and find differences in headers, their order, cookie values, or TLS fingerprints.

A typical finding: the parser sends headers in a different order, the Accept-Language is missing, or the User-Agent contains the version of Python. By correcting these details in the parser's code, you reduce the likelihood of being blocked.

Scenario 3: Testing geo-dependent content

If your application displays different content to users from different countries, you need to test it with real IPs from those countries. Set up Fiddler with an upstream proxy from the desired region, launch the application — and you will see exactly what a user from that country sees, plus a complete log of all requests.

Scenario 4: Monitoring background activity of applications

Want to know where an installed program "calls"? Launch Fiddler, run the program, and wait 5-10 minutes. The session list will show all hosts that the program has contacted. This is useful for auditing the security of third-party software, checking for telemetry, or unwanted connections.

Scenario 5: Exporting requests for reproduction

Fiddler allows you to export intercepted requests in cURL format, which can be immediately run in the terminal or pasted into Postman. Right-click on a session → Copy → cURL Request. This is convenient for passing a request to a colleague or for documenting the API.

Fiddler Classic vs Fiddler Everywhere: which one to choose

Telerik supports two versions of the product, and choosing between them is not always obvious. Let's break down the key differences.

When to choose Fiddler Classic: you are working only on Windows, you need to work with UWP applications, you use FiddlerScript for automation, or you want a completely free version without limitations.

When to choose Fiddler Everywhere: you are working on macOS or Linux, you need a modern interface, collaboration with shared request collections is important, or you want integration with CI/CD pipelines.

It is also worth mentioning alternatives: Charles Proxy (paid, popular on macOS), mitmproxy (free, console-based, very flexible), Wireshark (works at the packet level, not HTTP). Each tool has its strengths, but for most debugging tasks of Windows applications, Fiddler Classic remains the optimal choice.

Common issues and their solutions

When working with Fiddler, typical issues occasionally arise. Here are the most common ones and how to solve them.

Issue: The application does not work with Fiddler enabled

Causes: Certificate Pinning, hardcoded proxy in the application, or the application does not trust the Fiddler certificate. Solutions:

• Install the Fiddler certificate in the Local Machine → Trusted Root store
• Check if the application uses certificate pinning
• Add the host to SSL exceptions: Tools → Options → HTTPS → Skip Decryption for following hosts

Issue: Internet does not work after closing Fiddler

Fiddler did not manage to remove the system proxy during an abrupt shutdown. Solution: open Windows Settings → Network → Proxy and disable manual proxy. Or restart Fiddler and close it properly.

Issue: Only CONNECT tunnels are visible, but not HTTPS content

HTTPS interception is not set up. Go back to the section on certificate setup and ensure that the Decrypt HTTPS traffic checkbox is checked and the certificate is installed in the system store.

Issue: UWP application traffic does not appear in Fiddler

A loopback exemption has not been added for this application. Use WinConfig (described in the UWP section) and restart the application after adding the exemption.

Issue: Upstream proxy does not work (connection error)

Check: the correctness of the proxy address and port, the correctness of the username/password, the availability of the proxy server (try connecting directly without Fiddler). Also, ensure that the proxy supports the required protocol — not all HTTP proxies support HTTPS tunneling.

Conclusion

Fiddler is an indispensable tool for anyone working with HTTP traffic of Windows applications. It allows you to see all requests in real time, modify them on the fly, test application behavior under different conditions, and solve tasks that cannot be accomplished with browser DevTools. The support for UWP applications through the loopback exemption mechanism is especially valuable — this is a unique opportunity that most alternatives do not offer.

For tasks involving testing geo-dependent application behavior or checking functionality through external proxies — set up an upstream proxy in Fiddler. If you need real IPs from specific countries for accurate testing, consider residential proxies — they provide the most realistic geo and minimal risk of blocks from the services being tested.

Start with Fiddler Classic — it is free, well-documented, and covers 90% of debugging tasks on Windows. As your needs grow, you can switch to Fiddler Everywhere or complement your workflow with specialized tools like mitmproxy for more flexible automation.