Fiddler Not Capturing Traffic? 6 Proven Fixes

Fiddler isn’t capturing traffic — it’s one of the most frustrating roadblocks in HTTP debugging. You launch Fiddler, configure your browser or app, and watch the session list stay stubbornly empty. No requests. No errors. Just silence. This isn’t a software failure — it’s almost always a configuration mismatch, proxy misalignment, or HTTPS decryption gap.

Whether you're using Fiddler for API testing, mobile app analysis, or legacy system integration, missing traffic breaks your workflow. And since Fiddler operates as a local proxy (the core of any fiddler proxy setup), its visibility depends entirely on whether traffic actually flows through it. In this guide, we’ll walk through six actionable, developer-tested fixes — from basic connectivity checks to advanced HTTPS decryption troubleshooting — so you regain full visibility over your HTTP and HTTPS traffic.

1. Verify Fiddler Is Actually Running as a Proxy

Fiddler must be running and configured to act as a system proxy. It’s easy to assume it’s active when it’s silently paused or disabled.

Check the Status Bar & Capture Toggle

At the bottom-left corner of Fiddler’s UI, look for:

✅ "Capturing" — means traffic capture is active.
⚪ "Paused" — means Fiddler is running but not recording.
❌ "Not Capturing" — indicates proxy interception is off.

Click the Capture Traffic button (F12) or go to File > Capture Traffic to toggle. Also confirm Rules > Customize Rules hasn’t injected a oSession.Ignore = true line — that silently drops all sessions.

Confirm System Proxy Settings

Fiddler sets itself as the system proxy on startup — but only if Allow remote computers to connect is unchecked (unless you’re debugging remote devices). To verify:

Go to Tools > Options > Connections
Ensure Act as system proxy on startup is checked ✅
Note the port (default: 8888) — this must match your client’s proxy config
Uncheck Allow remote computers to connect, unless explicitly needed (enabling it disables automatic system proxy registration)

💡 Pro Tip: Run netstat -ano | findstr :8888 in Command Prompt. If no output appears, Fiddler isn’t listening — restart it with admin privileges.

2. Browser & App Proxy Configuration Mismatch

Modern browsers (Chrome, Edge, Firefox) and many apps ignore system proxy settings by default — especially when launched via shortcuts or CLI tools.

Browsers

Chrome / Edge: Launch with explicit proxy flags:
```
chrome.exe --proxy-server="127.0.0.1:8888" --proxy-bypass-list="<-loopback>"
```
This bypasses localhost/127.0.0.1 — critical for avoiding infinite loops when Fiddler intercepts its own traffic.
Firefox: Go to Settings > Network Settings > Settings…, select Manual proxy configuration, enter 127.0.0.1 and port 8888. Ensure Also use this proxy for FTP and HTTPS is checked.
Safari (macOS): Requires manual network proxy setup in System Settings > Network > Advanced > Proxies, then enable Web Proxy (HTTP) and Secure Web Proxy (HTTPS) with 127.0.0.1:8888.

Desktop & Mobile Apps

.NET apps: Set WebProxy programmatically or via app.config:

<system.net>
  <defaultProxy enabled="true">
    <proxy proxyaddress="http://127.0.0.1:8888" />
  </defaultProxy>
</system.net>

Mobile (Android/iOS): Configure Wi-Fi proxy manually to point to your PC’s LAN IP (e.g., 192.168.1.10:8888) — not 127.0.0.1. Then install Fiddler’s root certificate on the device (more tutorials).

3. HTTPS Decryption Isn’t Enabled or Trusted

If Fiddler captures HTTP but not HTTPS, the issue is almost certainly HTTPS decryption — a cornerstone of modern fiddler debugging.

Enable HTTPS Decryption

In Fiddler, go to Tools > Options > HTTPS
Check Decrypt HTTPS traffic ✅
Click Actions > Trust Root Certificate — this opens Windows Certificate Manager
Install the DO_NOT_TRUST_FiddlerRoot cert into Trusted Root Certification Authorities (not Intermediate CA)

⚠️ Warning: On Windows 10/11, you may need to manually import the cert using certmgr.msc, especially if Group Policy blocks auto-install.

Handle Certificate Pinning & Modern TLS Constraints

Some apps (especially banking, React Native, or Flutter apps) implement certificate pinning — they reject Fiddler’s generated certificates outright.

For Android: Use adb shell settings put global http_proxy <PC_IP>:8888, then install FiddlerRoot.cer via Settings > Security > Install from storage.
For iOS: Open http://ipv4.fiddler:8888 in Safari → download & install profile → enable full trust in Settings > General > About > Certificate Trust Settings.
For pinned apps: You’ll need runtime patching (e.g., Frida scripts) — browse Troubleshooting tutorials for advanced mitigation patterns.

4. Firewall, Antivirus, or Corporate Policies Are Blocking Fiddler

Corporate environments often restrict local proxy usage or flag Fiddler’s self-signed certs as malicious.

Quick Diagnostic Steps

Temporarily disable antivirus (especially Symantec, McAfee, or CrowdStrike) — some inject their own TLS inspection and conflict with Fiddler’s https decryption layer.
Add Fiddler.exe and FiddlerCap.exe to Windows Defender exclusions (Settings > Privacy & Security > Virus & threat protection > Manage settings > Exclusions).
Check corporate proxy group policies: Run gpresult /h report.html, then search for “Proxy Server” or “Turn off access to all Windows Update features”. If enterprise proxy rules are enforced, Fiddler may be overridden silently.

Test Local Loopback Capture

Run this PowerShell snippet to verify Fiddler sees any local traffic:

Invoke-WebRequest -Uri "http://localhost:8080/test" -Proxy "http://127.0.0.1:8888" -ProxyUseDefaultCredentials

If this shows up in Fiddler, your proxy stack works — the issue lies with your target app’s routing.

5. WinINET/WinHTTP Applications Bypass Fiddler by Default

Many Windows-native apps (PowerShell Invoke-WebRequest, .NET HttpClient, Outlook, Teams) use WinHTTP — which ignores system proxy settings unless explicitly configured.

Force WinHTTP to Use Fiddler

Run this command as Administrator to set WinHTTP proxy globally:

netsh winhttp set proxy 127.0.0.1:8888 "<local>"

To reset later:

netsh winhttp reset proxy

🔍 Confirm with: netsh winhttp show proxy

For .NET apps targeting HttpClientHandler, explicitly assign the proxy:

var handler = new HttpClientHandler {
    Proxy = new WebProxy("http://127.0.0.1:8888"),
    UseProxy = true
};
var client = new HttpClient(handler);

6. Fiddler Extensions or Custom Rules Are Filtering Traffic

Fiddler’s extensibility is powerful — but dangerous when misconfigured. A single faulty rule can drop all traffic before it hits the UI.

Diagnose Rule Interference

Go to Rules > Customize Rules (opens CustomRules.js)
Search for:
- oSession.Ignore = true
- oSession.utilCreateResponseAndBypassServer()
- if (oSession.hostname... blocks without else fallbacks
Temporarily comment out all custom logic and restart Fiddler

Disable All Extensions

Tools > Extensions
Uncheck every extension
Restart Fiddler

Common culprits: JSON Formatter (v5.0+ bugs), AutoResponder (misconfigured rules), or legacy SAZ importers.

You can also launch Fiddler in safe mode to rule out extensions entirely:

Fiddler.exe -safe

If traffic appears in safe mode, re-enable extensions one-by-one to isolate the offender.

Bonus: Quick Diagnostic Flowchart

When Fiddler isn’t capturing traffic, follow this sequence:

✅ Is Fiddler showing "Capturing" in status bar?
✅ Does netstat -ano | findstr :8888 return a LISTENING process?
✅ Is your client configured to use 127.0.0.1:8888 (or correct LAN IP)?
✅ Is HTTPS decryption enabled and the root cert trusted in OS/browser/device?
✅ Are WinHTTP apps forced via netsh, or .NET apps explicitly using WebProxy?
✅ Are extensions/rules disabled — and does -safe mode work?

If all six pass and traffic still doesn’t appear, check for upstream network restrictions (e.g., captive portals, transparent proxies, or ISP-level filtering). You can also export a Netmon trace alongside Fiddler logs (Help > Debug Logs) for deeper correlation.

Conclusion: Regain Control Over Your HTTP Debugging Workflow

Fiddler not capturing traffic is rarely a bug — it’s a signal that something in the request path isn’t aligned with Fiddler’s proxy model. Whether it’s a browser ignoring system settings, an untrusted certificate breaking https decryption, or WinHTTP bypassing your proxy entirely, each failure mode has a precise, repeatable fix.

Mastering these six areas transforms Fiddler from a mysterious black box into a predictable, reliable fiddler proxy for all your HTTP debugging needs. You’ll spend less time diagnosing silence and more time analyzing headers, rewriting requests, and validating API contracts.

Remember: Every successful fiddler tutorial starts with verified capture. Once traffic flows, everything else — breakpoints, auto-responses, performance analysis, or script injection — falls into place. If you hit a rare edge case not covered here, contact us — we’ll help you trace it down.

Key takeaways:

Always validate Fiddler’s listening state and system proxy registration first.
HTTPS requires both decryption enablement and OS/browser certificate trust — not just checkbox toggling.
WinINET/WinHTTP apps need explicit proxy configuration — don’t assume system-wide settings apply.
When in doubt, test with -safe mode and minimal clients (e.g., curl -x http://127.0.0.1:8888 https://httpbin.org/get).
Treat Fiddler as infrastructure: monitor it like a service — not just a UI tool.