How to Configure Fiddler to Capture All Traffic

Short answer: Fiddler can capture traffic from applications that send requests through its proxy. To get broader coverage, enable system or network capture, configure HTTPS decryption and trust the Fiddler root certificate, then set up remote clients, VPN connections or localhost separately. “All traffic” is conditional: applications that bypass the proxy, reject interception certificates or use pinned certificates can still be missing.

Fiddler Everywhere and Fiddler Classic have different menus and default ports. Use the section for your product, and verify the listening port in the application before configuring another device.

1. Identify your Fiddler version and capture target

Question	Why it matters
Everywhere or Classic?	Settings, capture modes and remote-device defaults differ.
Same computer or another device?	Remote clients must reach the Fiddler host and use its proxy address.
Browser, desktop app, localhost or VPN?	Some clients honor the system proxy; others need explicit settings or network capture.
HTTP only or decrypted HTTPS?	HTTPS payloads require a trusted Fiddler root CA on the device making the request.

Fiddler Everywhere documents port 8866 for remote devices by default. Fiddler Classic documents port 8888 for remote machines. These values can change, so check the active listener rather than copying a port blindly.

2. Capture local applications through the system proxy

1. Open Fiddler and enable its system capturing or proxy mode.
2. Start a new browser request or restart the desktop application you want to inspect.
3. Confirm that a new session appears in the Web Sessions list.
4. Use the session host, URL, method and status fields to confirm that you are seeing the intended request.

This mode works for browsers and applications that honor the operating system proxy. An application with its own proxy configuration, a proxy bypass rule or no proxy support will not necessarily appear. Configure that application explicitly or use Fiddler Everywhere network-capturing mode where appropriate.

Test the proxy with a command-line request

curl -x http://127.0.0.1:8888 https://example.com -I

Replace 8888 with the listener port shown by your Fiddler installation. If the request appears in Fiddler, the listener is reachable and the command is using it. A HTTPS request may still show only tunnel metadata until HTTPS decryption is enabled.

3. Enable HTTPS decryption safely

HTTP sessions are visible without certificate installation. HTTPS decryption is a separate opt-in operation because Fiddler must present a locally trusted certificate while it proxies the connection.

Fiddler Everywhere

1. Open Settings > HTTPS.
2. Install the Fiddler root CA using the application.
3. Trust the certificate in the certificate store used by the client.
4. Enable HTTPS traffic capture.
5. Generate a fresh request and inspect the session again.

Windows and macOS support the user certificate store. Fiddler Everywhere also documents a machine-store option on Windows, which requires administrative privileges. On Linux, export the CA and manually add it to the trust store used by the browser or application.

Fiddler Classic

1. Open Tools > Options > HTTPS.
2. Enable Capture HTTPS CONNECTs.
3. Enable Decrypt HTTPS traffic.
4. Accept the prompts to create and trust the Fiddler root certificate.
5. Save the options, then repeat the request.

Trusting the Fiddler CA permits interception of TLS connections routed through that proxy. Remove the certificate when it is no longer needed, and do not treat broad certificate-error bypasses as a normal fix. Certificate pinning, a separate trust store or an application that bypasses the proxy can still prevent decryption.

4. Capture remote computers and mobile devices

Fiddler Everywhere

1. Open Settings > Connections.
2. Enable Allow remote devices to connect.
3. Note the host computer’s reachable IP address and the actual listener port, 8866 by default.
4. On the remote device, set a manual HTTP/HTTPS proxy to that IP address and port.
5. Install and trust the Fiddler CA on the remote device if HTTPS decryption is required.
6. Make a new request and verify that the session appears on the host.

The devices must have network connectivity to the host. Firewalls, managed Wi-Fi and inbound access rules can block the connection or prevent device discovery.

Fiddler Classic

1. Open Tools > Options.
2. Enable Allow remote clients to connect.
3. Find the host name or IP address and confirm the listener port, 8888 by default.
4. Configure the other machine or device to use that address as its proxy.
5. Trust the FiddlerRoot certificate on the client for HTTPS decryption.

5. Include VPN, RAS and dial-up traffic

In Fiddler Classic, open Tools > Options and enable Monitor all connections. Then reconnect the VPN or dial-up connection and create a fresh request. The active VPN can change proxy selection, so check which interface and proxy the client is actually using.

FiddlerCore exposes the corresponding MonitorAllConnections startup setting for applications embedding FiddlerCore. Confirm the setting before starting capture; changing a VPN route alone does not guarantee that a client will use the proxy.

6. Handle localhost and applications that bypass the proxy

• Localhost: Some clients bypass proxies for localhost and 127.0.0.1. Use the client’s proxy exception settings or Fiddler Everywhere network-capturing rules for localhost.
• Own proxy settings: Configure the application’s HTTP and HTTPS proxy explicitly with the Fiddler host and port.
• Proxy bypass: Remove the target domain from bypass lists only when that is acceptable for your test.
• No proxy support: Use Fiddler Everywhere network-capturing mode, which captures outgoing TCP traffic, or use a dedicated capture setup for the device.
• Certificate pinning: The application may reject Fiddler’s certificate even when the operating system trusts it. Use a test build or the vendor’s documented debugging switch instead of disabling validation globally.

7. Understand what “all traffic” can and cannot mean

Traffic source	Normal system-proxy capture	Additional setup
Proxy-aware browser	Usually visible	Trust CA for HTTPS content
Desktop app with its own networking stack	May be absent	Explicit proxy or network capture
Localhost service	Often bypassed	Exception changes or localhost rules
VPN/RAS connection	Depends on route and proxy selection	Monitor all connections and verify active interface
Remote phone or computer	Not visible automatically	Remote access, manual proxy and client CA trust
Pinned HTTPS endpoint	Session may appear but remain undecrypted	Use a compatible test build or vendor-supported debugging

8. Troubleshooting missing sessions

No sessions appear in the Web Sessions List

• Cause: Capture is disabled or the client is not using Fiddler.
• Fix: Enable system capture, check the client’s proxy settings and generate a new request.

HTTP appears but HTTPS content is blank

• Cause: HTTPS decryption is disabled, or the client does not trust the Fiddler CA.
• Fix: Enable HTTPS decryption and install the CA in the trust store used by that browser or application.

The remote device cannot connect

• Cause: Wrong IP, wrong port, disabled remote access or blocked inbound traffic.
• Fix: Enable remote connections, verify the actual listener port, use a host IP reachable from the device and permit the connection through the host firewall.

Only some requests are captured

• Cause: The application bypasses the proxy, uses a separate proxy, excludes localhost or uses certificate pinning.
• Fix: Inspect bypass rules, configure the application directly, add localhost handling or switch to network capture for that client.

VPN requests are missing

• Cause: The VPN route or RAS connection is not being monitored, or the client selects a different proxy path.
• Fix: Enable Monitor all connections in Classic, reconnect the VPN and verify the active route and proxy.

Sessions appear but filters hide them

• Cause: Fiddler filters or workspace views exclude the host or process.
• Fix: Clear filters, switch to the unfiltered session list and repeat the request.

Certificate warnings continue after installing the CA

• Cause: The CA was installed in a different user or machine store, the application has its own trust store or pinning is enabled.
• Fix: Install the CA where the client reads trust anchors, then check for pinning or a separate application certificate bundle.

9. A repeatable capture checklist

1. Record the Fiddler product and version.
2. Record the listener host and port.
3. Enable system or network capture.
4. Confirm the client points to that proxy and has no conflicting bypass rule.
5. Enable HTTPS decryption only when needed.
6. Trust the CA on every device that makes the request.
7. For remote capture, enable inbound connections and test host reachability.
8. For VPN or localhost, enable the matching special handling.
9. Clear filters and generate a fresh request.
10. Remove temporary CA trust and remote-access settings after debugging.

10. Performance, reliability and privacy considerations

• Overhead: Proxying and decrypting traffic adds a hop and certificate work. Capture only the hosts and processes needed for the investigation.
• Reliability: A restart, VPN reconnect or network change can alter the selected proxy. Recheck capture state after each change.
• Storage: Request and response bodies may contain credentials, cookies or personal data. Save sessions only where access is controlled and delete exports when finished.
• Scope: A successful Fiddler session proves that one client used the proxy; it does not prove that every process or packet on the machine was captured.

11. Or skip the browser setup

If your goal is a clean screenshot rather than debugging network sessions, ScreenshotNeo returns an image or PDF with one API request. Cookie and consent banners, newsletter popups and chat widgets are removed before the shot; bot checks, blank pages and failed loads are never billed. Its MCP server lets AI agents take screenshots, and 1,000 screenshots a month are free with no card; paid plans start at $5 for 3,000. See the ScreenshotNeo API documentation for all options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

Create a free ScreenshotNeo account with 1,000 screenshots per month and no card.

FAQ

Does Fiddler capture every packet?

No. Proxy capture depends on application behavior and routing. Bypasses, non-proxy clients and pinned certificates create gaps.

Can I inspect HTTPS without installing a certificate?

You can usually see tunnel metadata, but decrypted request and response content requires the Fiddler CA to be trusted by the client.

Which remote port should I use?

Everywhere documents 8866 by default; Classic documents 8888. Always confirm the current listener in the application.

Why does a phone show no traffic while my browser works?

The phone needs a manual proxy pointing to the host, network reachability to that host and CA trust for HTTPS.

Is network capture a replacement for system-proxy capture?

It is a lower-level option for some proxy-bypassing applications, but VPN endpoints and remote devices still need their documented configuration.