Master Fiddler AutoResponder Rules for Precise HTTP Debugging

Fiddler’s AutoResponder is the most powerful request-modification tool for developers who need deterministic, repeatable HTTP debugging — especially when backend services are unstable, slow, or unavailable.

Whether you’re mocking API responses during frontend development, testing error-handling logic, or validating client-side retry behavior, AutoResponder lets you intercept and replace any HTTP(S) request with a local file, static response, or dynamic script — all without touching your application code. This capability is indispensable in modern fiddler debugging workflows and complements core features like https decryption and request composition.

In this guide, we walk through every aspect of AutoResponder rules: setup, matching syntax, response injection, conditional logic, and real-world troubleshooting — all grounded in production-ready practices.

Enabling and Accessing AutoResponder

AutoResponder is disabled by default. To activate it:

Launch Fiddler (v5.0.20234.59236 or later — ensure you’re on a supported version).
Go to Rules > Automatically Respond to Requests (or press Ctrl+R).
Check the Enable rules checkbox at the top-right corner of the AutoResponder tab.

Once enabled, Fiddler begins evaluating each incoming request against your rule list from top to bottom. The first match wins — order matters. You’ll see a green indicator in the status bar when AutoResponder is active.

💡 Pro Tip: AutoResponder works only for requests that reach Fiddler — meaning it respects Fiddler’s filters (e.g., if you’ve excluded *.jpg in Filters tab, those won’t trigger rules). Always verify your Filters settings before assuming a rule isn’t firing.

Understanding Rule Matching Syntax

AutoResponder supports three primary matching modes:

Exact URL Match

Enter the full URL (e.g., https://api.example.com/v1/users/123) to intercept only that exact request. Case-insensitive, but path and query string must match precisely.

Wildcard Matching

Use * as a placeholder:

https://api.example.com/v1/* matches any path under /v1/
*example.com/*/status matches /users/status, /payments/status, etc.
* alone matches all requests (use sparingly — great for global mocks or logging)

Wildcard matching is fast and intuitive — ideal for broad API versioning or domain-level overrides.

Regular Expression Matching

Click the regex:* checkbox next to any rule to enable .NET-style regex matching. Example patterns:

^https://api\.example\.com/v1/users/\d+$ → matches /users/42, /users/999, but not /users/me
(?i)^http://.*\.dev$ → case-insensitive match for any .dev domain over HTTP

Regex gives you surgical precision — essential for complex routing logic or multi-environment switching (e.g., redirecting staging traffic to local dev endpoints).

⚠️ Note: Regex mode disables wildcard expansion. You cannot mix * and regex in the same pattern — choose one strategy per rule.

Injecting Responses: Files, Text, and Scripts

After matching, you define what to return. AutoResponder supports three response sources:

Local File Response

Click Select File…, browse to a saved JSON/XML/HTML file (e.g., mock-user-42.json), and Fiddler serves it with original headers unless overridden. Ideal for realistic, version-controlled mocks.

✅ Best practice: Store mock files in a dedicated ./fiddler-mocks/ folder and use relative paths. Fiddler resolves them relative to its executable directory — but absolute paths (C:\mocks\error-500.json) work reliably across machines.

Text Response

Click Text Response, then paste raw content (e.g., {"id": 123, "name": "Mock User"}) and set the Content-Type header manually. Useful for quick one-offs or dynamic literals.

You can inject headers using the + button beside the text field:

Content-Type: application/json
X-Fiddler-Mock: true
Cache-Control: no-cache

Scripted Response (FiddlerScript)

For dynamic behavior (e.g., returning different status codes based on query params), click Run a Script Function and select a custom function from CustomRules.js. Example:

static function OnBeforeResponse(oSession: Session) {
  if (oSession.uriContains("/api/v1/users") && oSession.oRequest.headers.ExistsAndContains("User-Agent", "MobileApp")) {
    oSession.utilCreateResponseAndBypassServer();
    oSession.oResponse.headers.SetStatus(200, "OK");
    oSession.oResponse.headers.Add("Content-Type", "application/json");
    oSession.utilSetResponseBody('{"role":"premium"}');
  }
}

Then reference x-some-dynamic-rule as the script function name in AutoResponder. This bridges AutoResponder’s simplicity with FiddlerScript’s power — perfect for conditional mocking in CI or QA environments.

Advanced Rule Management

Chaining and Priority

Rules execute top-down. Drag-and-drop to reorder. Use Disable Rule (uncheck the box) instead of deleting — preserves intent and avoids accidental gaps.

To simulate fallback behavior (e.g., “try mock A, else serve live”), place high-priority mocks first, then a catch-all * rule pointing to https://[original-host]/[original-path] — but note: AutoResponder cannot proxy to upstream servers directly. For true fallback, combine with Fiddler’s x-overrideHost or use Composer + Breakpoints.

Conditional Activation with Flags

AutoResponder supports flags in the “Rule Editor” column (rightmost):

b → bypass cache (adds Cache-Control: no-cache)
i → ignore case (for non-regex matches)
r → require HTTPS (only matches https:// URLs)
s → suppress logging (removes matched sessions from Web Sessions list)

Example rule entry:

https://api.example.com/v1/*  →  ./mocks/v1-default.json  [bi]

This matches case-insensitively and bypasses cache — critical when testing stale-while-revalidate flows.

Importing and Exporting Rules

Click Import or Export (bottom-left) to share rule sets across teams. Exported .aurl files are plain-text JSON — easy to review in Git, diff, or automate via CI pipelines. You can even generate them programmatically using PowerShell or Python scripts that output valid AutoResponder JSON schema.

Troubleshooting Common AutoResponder Issues

Rule Not Firing?

Confirm Enable rules is checked.
Verify Filters aren’t excluding the request (e.g., uncheck “Hide if URL contains” → healthz).
Check the Log tab: AutoResponder logs hits as AutoResponder: Matched '...' → '...'.
Test with * — if that works, your pattern is too restrictive.

HTTPS Requests Not Intercepted

AutoResponder relies on Fiddler’s ability to decrypt HTTPS. If your rule targets https://api.example.com, but no match occurs:

Ensure https decryption is enabled (Tools > Options > HTTPS > Decrypt HTTPS traffic).
Confirm the target domain isn’t in the Ignore List (e.g., localhost, 127.0.0.1 are ignored by default — add +localhost to override).
Check certificate trust: Windows/macOS must trust Fiddler’s root cert. Run certmgr.msc and verify DO_NOT_TRUST_FiddlerRoot is under Trusted Root Certification Authorities.

Mock Returns 404 or Blank Response?

File path is incorrect or inaccessible (permissions, spaces, Unicode).
Text response lacks required headers (e.g., missing Content-Length when body is non-empty — Fiddler usually auto-calculates, but not always).
Script function throws an exception — check Fiddler Log for JavaScript errors.

Performance Lag with Many Rules?

AutoResponder evaluates every rule until a match. With 200+ rules, latency becomes noticeable. Optimize by:

Grouping similar domains into broader wildcards first (*.example.com/*).
Using regex only where necessary — wildcards are faster.
Disabling unused rules instead of deleting.

Real-World Use Cases

Frontend Development Without Backend

A React app calls GET https://api.dev/users?limit=10. While the backend is down:

Rule: https://api.dev/users* → ./mocks/users-list.json
Add flag b to prevent browser caching interference.

Developers iterate instantly — no waiting for PR merges or Docker restarts.

Testing Edge-Case HTTP Statuses

Simulate service outages or rate limiting:

Rule: https://api.payments/charge → Text Response: {"error":"rate_limited"}
Headers: Status: 429 Too Many Requests, Retry-After: 60

Validates UI error states, exponential backoff logic, and analytics instrumentation — all within Fiddler’s fiddler debugging environment.

Environment-Aware Mocking

Using regex + script:

Rule: regex:^https://(staging|prod)\.example\.com/api/.* → Run a Script Function: OverrideToDev
OverrideToDev() checks oSession.host and returns appropriate dev-domain response or redirects.

Eliminates manual config switching across dev/staging/prod test cycles.

Key Takeaways

AutoResponder is foundational for reliable, scalable HTTP debugging — especially when paired with https decryption and session filtering.
Matching order matters: design rules top-down, starting with specific, high-value endpoints.
Prefer wildcards over regex unless you need pattern complexity — they’re faster and more maintainable.
Always validate mocks in-browser and via Fiddler’s Inspectors tab (Headers, TextView, JSONView) to confirm headers, status, and body fidelity.
Export rule sets regularly — treat them as infrastructure-as-code for your fiddler proxy workflow.

AutoResponder transforms Fiddler from a passive observer into an active collaboration layer between frontend, backend, and QA teams. Once mastered, it reduces dependency on staging environments, accelerates bug reproduction, and hardens resilience testing — making it a cornerstone of professional fiddler tutorial resources.

For deeper automation, explore more tutorials on FiddlerScript extensibility or dive into browse Request Modification tutorials for related techniques like request rewriting and header injection.