Capture Traffic from Specific Domains in Fiddler

Fiddler is the de facto standard HTTP/HTTPS debugging proxy for developers and QA engineers — but capturing only the traffic you care about saves time, reduces noise, and sharpens your fiddler debugging workflow. When testing APIs, auditing third-party integrations, or diagnosing domain-specific latency, indiscriminate traffic capture becomes counterproductive. This tutorial shows you exactly how to configure Fiddler to capture requests only from specific domains — whether HTTP or HTTPS — using built-in filters, custom rules, and HTTPS decryption best practices.

Why Domain-Specific Capture Matters

In modern web applications, a single page load often triggers dozens of requests across multiple origins: your own API (api.example.com), analytics (analytics.google.com), CDNs (cdn.jsdelivr.net), ad networks, and authentication providers. Capturing all of them clutters your session list, slows down Fiddler’s UI, and obscures the signals you need. Targeted domain capture improves:

• Performance: Less data = faster rendering and lower memory use.
• Security compliance: Avoid accidental logging of sensitive third-party tokens or PII.
• Debugging precision: Isolate issues to your backend or a specific integration point.
• HTTPS decryption efficiency: Decrypt only domains you control or trust — critical for fiddler proxy security hygiene.

Step 1: Enable HTTPS Decryption (Prerequisite for Secure Domains)

Before filtering HTTPS traffic, ensure Fiddler can decrypt it. Without this, https://api.example.com appears as encrypted tunnel traffic (CONNECT) with no readable request/response bodies.

Configure Trust & Certificates

1. Launch Fiddler → Tools > Options > HTTPS.
2. Check Decrypt HTTPS traffic.
3. Click Actions > Trust Root Certificate and follow the OS prompts (Windows/macOS require admin/root privileges).
4. Under Certificates generated by Fiddler, select Use Windows certificate store (recommended on Windows) or Use separate certificate store (macOS/Linux).
5. Click OK, then restart Fiddler.

⚠️ Troubleshooting Tip: If HTTPS requests show Tunnel to <domain>:443 with no decrypted content, verify:

• The target domain isn’t in Tools > Options > HTTPS > Ignore Hosts (e.g., localhost, 127.0.0.1 are excluded by default).
• Your browser or app trusts Fiddler’s root cert (check browser certificate manager; import manually if needed).
• You’re not using a corporate MITM proxy that conflicts with Fiddler.

This step is essential for reliable https decryption — especially when debugging OAuth flows or GraphQL endpoints over HTTPS.

Step 2: Use the Built-in Host Filter

Fiddler’s fastest way to restrict capture to specific domains is its real-time host filter.

Apply a Basic Host Filter

1. In the main Fiddler window, locate the Filters tab (bottom-left panel, or press Ctrl+R).
2. Check Use Filters.
3. Scroll to Hosts section → select Show only the following hosts.
4. Enter domains comma-separated (no protocol, no path):

   api.example.com, auth.example.io, cdn.example-static.net
   

5. Click Actions > Run Filters Now (or press F5).

✅ Result: Only requests whose Host header matches one of those domains appear in the Web Sessions list.

💡 Pro tip: Use wildcards sparingly — *.example.com works only if enabled under Tools > Options > General > Enable wildcard matching in filters. Without it, *.example.com treats the asterisk literally.

Step 3: Write Custom Rules with FiddlerScript

For dynamic, logic-based filtering — like capturing only POST requests to api.example.com/v2/* — FiddlerScript gives full control.

Edit CustomRules.js

1. Press Ctrl+R or go to Rules > Customize Rules.

2. Fiddler opens CustomRules.js in Notepad (or your default editor).

3. Locate the OnBeforeRequest function (around line 140–160).

4. Add this logic inside the function:

   if (oSession.host.toLowerCase() !== "api.example.com" && 
       oSession.host.toLowerCase() !== "auth.example.io") {
       oSession.Ignore();
       return;
   }
   // Optional: further refine by method or path
   if (oSession.hostname === "api.example.com" && oSession.RequestMethod === "POST" && 
       oSession.uriContains("/v2/users")) {
       // Keep only POST /v2/users
   } else if (oSession.hostname === "api.example.com") {
       oSession.Ignore(); // Drop all other api.example.com traffic
   }
   

5. Save (Ctrl+S) — Fiddler auto-compiles and reloads the script.

🔁 How It Works: oSession.Ignore() removes the session from the UI before it’s fully processed — lightweight and efficient. Unlike UI filters, this runs at the network layer and applies even to background requests (e.g., service workers, fetch calls).

🔧 Bonus: Combine with oSession.oRequest.headers.ExistsAndContains("Authorization", "Bearer") to isolate authenticated API calls — powerful for http debugging workflows.

Step 4: Leverage AutoResponder for Domain-Based Mocking

While not strictly “capture,” AutoResponder lets you simulate domain-specific responses — useful for isolating behavior without live traffic.

Set Up Domain-Scoped Mocks

1. Go to AutoResponder tab.
2. Check Enable rules and Unmatched requests passthrough.
3. Click Add Rule → enter pattern:

   https://api.example.com/v1/status
   

4. Set action: Find a file (e.g., C:\mocks\status-200.json) or Respond with text.
5. To scope to domain only: use regex REGEX:^https?://api\.example\.com/.*$

This complements domain capture by letting you test frontend logic against controlled backend responses — a key part of robust fiddler tutorial workflows.

Step 5: Export & Share Domain-Specific Sessions

Once filtered, export clean, actionable logs.

Save Filtered Sessions

• Select sessions → right-click → Export Sessions > Selected Sessions > JSON (Structured).
• Or use File > Export Sessions > All Sessions > SAZ Archive, then open in another Fiddler instance with filters re-applied.

📁 Pro tip: Name exports descriptively — e.g., api.example.com-v2-auth-flow-20240522.saz. This supports traceability during team handoffs or bug reporting.

Troubleshooting Common Pitfalls

Issue	Cause	Fix
CONNECT entries only, no decrypted bodies	HTTPS decryption disabled or misconfigured	Re-run Trust Root Certificate; verify domain not in Ignore Hosts list
Filter ignores subdomains (app.example.com vs api.example.com)	Exact match required unless wildcards enabled	Enable wildcard matching or add both explicitly
Mobile app traffic missing after filtering	App bypasses system proxy or uses certificate pinning	Use Fiddler’s Remote Connections feature + manual proxy config; disable pinning for dev builds
oSession.Ignore() doesn’t apply to WebSocket traffic	WebSockets use different lifecycle hooks	Use OnBeforeWebSocketConnect in CustomRules.js instead

Also remember: Fiddler captures traffic after DNS resolution — so host reflects the resolved hostname, not the original URL. For CNAMEs or CDN aliases, inspect oSession.hostname and oSession.host separately.

Best Practices for Production-Like Debugging

• Always disable filters before performance profiling: Full traffic visibility helps spot unexpected dependencies.
• Use color rules: Right-click column headers → Color Rules → assign colors per domain (e.g., red for payment.gateway.com, green for internal-api).
• Combine with breakpoints: Set Breakpoints on specific domains (bpu api.example.com) to inspect request/response headers mid-flight.
• Log to file selectively: Use FiddlerObject.Log.String() inside OnBeforeRequest to log domain-matched activity to FiddlerCore.log — ideal for CI or audit trails.

Domain-specific capture transforms Fiddler from a general-purpose sniffer into a surgical fiddler debugging instrument. Whether you're reverse-engineering an undocumented SaaS API, validating CSP headers on assets.example.com, or auditing cookie scope across login.example.com and app.example.com, precise filtering eliminates guesswork.

Key Takeaways

• Domain filtering starts with proper https decryption setup — never skip this for secure endpoints.
• Use UI filters (Filters tab) for quick, temporary domain scoping.
• Prefer oSession.Ignore() in CustomRules.js for persistent, logic-driven filtering — especially across environments.
• Always validate filters using Fiddler’s Statistics tab: compare total vs filtered session counts.
• Pair domain capture with AutoResponder and breakpoints for end-to-end API validation.

Mastering domain-specific capture makes your http debugging faster, safer, and more repeatable. Once you eliminate noise, patterns emerge — and bugs become obvious.

Ready to level up? more tutorials cover advanced topics like TLS version forcing, conditional breakpoints, and scripting Fiddler with .NET Core. For domain-focused scenarios, browse HTTP/HTTPS Capture tutorials. Questions? contact us — we help teams integrate Fiddler into CI pipelines and security review workflows.