Why Fiddler Is Not Capturing All Traffic and How to Fix It

When Fiddler appears to miss traffic, first determine whether the client is sending requests through Fiddler at all. If a session appears but its HTTPS contents are unreadable, that is a separate decryption or certificate-trust problem. Check the specific application’s proxy configuration, clear filters as a diagnostic, then investigate localhost, VPN, remote-device, and product-version differences.

Fiddler is a proxy-based capture workflow: a browser, app, or device must route its requests through the Fiddler listener. System proxy settings do not necessarily control every client. The right fix depends on the Fiddler product, operating system, application, and network path.

1. Identify what “not capturing” means

What you see	Likely area to investigate
No sessions appear at all	Listener, client proxy configuration, filters, or network route.
Some apps or destinations appear, others do not	App-specific proxy behavior, filters, localhost bypass, VPN, or another connection path.
HTTPS sessions appear but content is encrypted or unavailable	HTTPS decryption setting or certificate trust. The connection may have reached Fiddler even though its contents are not inspectable.
Desktop browser works but phone or another app does not	That device or app needs its own proxy configuration and network reachability; HTTPS inspection also requires appropriate certificate setup.

Write down the Fiddler product and version, operating system, client app, destination, and whether the Session List is empty or merely lacks decrypted HTTPS details. This narrows the diagnostic path.

2. Confirm the client is using Fiddler

Test the exact application whose traffic is missing. A browser working on the same machine does not prove that a command-line tool, desktop app, runtime, or mobile device uses the same proxy. Fiddler’s [client configuration guide](https://docs.telerik.com/fiddler/configure-fiddler/tasks/configureclients) covers different client types because each may need separate setup.

Confirm Fiddler is running and its listener is online. Check the listening port in the product’s connection settings.
Inspect the proxy setting used by the affected client. It may use the operating system proxy, an app-specific proxy, environment variables, or no proxy at all.
Generate a known request from that same client while watching the Session List.
If the client supports proxy configuration, point it at the Fiddler host and port. For a local client, use the documented local listener address and port for your setup.
Temporarily remove proxy bypass rules for the test destination, then restore the intended configuration.

Fiddler’s [traffic-missing troubleshooting guide](https://docs.telerik.com/fiddler/observe-traffic/troubleshooting/alltrafficmissing) specifically recommends reviewing client configuration, localhost monitoring, filters, and VPN or dial-up monitoring.

Command-line client checks

For a client that honors standard proxy environment variables, test with the actual listener address and port. Substitute the values shown by your Fiddler configuration:

export HTTP_PROXY=http://127.0.0.1:8888
export HTTPS_PROXY=http://127.0.0.1:8888
curl -v https://example.com/

On Windows Command Prompt, set the variables for the current shell and run the request:

set HTTP_PROXY=http://127.0.0.1:8888
set HTTPS_PROXY=http://127.0.0.1:8888
curl.exe -v https://example.com/

These commands only help if the client honors those variables and the listener is reachable at that address and port. Some tools have their own proxy flags or ignore environment variables. The initial HTTPS CONNECT may be visible even when its payload is not decrypted.

3. Distinguish HTTPS capture from HTTPS decryption

Fiddler Classic’s documentation says: “By default, Fiddler Classic does not capture and decrypt secure HTTPS traffic.” Enable HTTPS decryption in Tools > Options > HTTPS when you need to inspect HTTPS content, and follow the product’s prompts to trust its certificate. See the [official HTTPS configuration instructions](https://docs.telerik.com/fiddler/configure-fiddler/tasks/decryptinghttps).

Look for a CONNECT or HTTPS session before concluding that the request never reached Fiddler.
Enable HTTPS decryption in the product’s HTTPS settings if inspection is required.
Install and trust the Fiddler root certificate only on test clients where inspection is intended.
Repeat the request and check whether the session now exposes request and response details.

Certificate trust is client- and platform-specific. A device can successfully route HTTP through a proxy while rejecting intercepted HTTPS because it does not trust the proxy certificate. Follow the current instructions for that platform and remove test trust configuration when it is no longer needed.

4. Check filters and hidden sessions

A filter can hide traffic that is present in the capture. Temporarily disable or clear active filters, reproduce the request, and see whether the session appears. If it does, restore filters one at a time to find the condition excluding it. The official [missing-session checklist](https://docs.telerik.com/fiddler/observe-traffic/troubleshooting/alltrafficmissing) calls out filters as a possible cause.

Check host, process, status-code, and session-type filters that your product exposes.
Check whether the Session List is paused, limited, or displaying only selected traffic.
After diagnosis, reapply the filters needed for normal work.

5. Troubleshoot localhost and loopback traffic

Local requests can bypass a proxy through loopback handling or proxy bypass rules. Fiddler Classic’s localhost instructions are specifically scoped to Internet Explorer 8 and earlier or .NET Framework scenarios; they are not a universal recipe for every browser or runtime. For those documented cases, Telerik describes using the machine name or special hostnames such as ipv4.fiddler, ipv6.fiddler, or localhost.fiddler. Consult [Monitoring traffic to localhost](https://docs.telerik.com/fiddler/observe-traffic/troubleshooting/monitoringlocalhosttraffic) for the applicable setup.

For other clients, inspect their proxy bypass list and loopback behavior. Do not assume that changing the destination hostname is appropriate unless the client and Fiddler documentation support it.

6. Check VPN, dial-up, and alternate network routes

A VPN or dial-up connection can have proxy settings distinct from the ordinary LAN connection. Confirm which network the affected client is using and which proxy settings apply to it. Fiddler Classic documents Tools > Options > Connections > Monitor all connections for relevant scenarios. It also describes browser automatic configuration scripts and, for an always-active connection, a HookConnectionNamed registry value. The registry setting is for that specific connection scenario; do not apply it generically. See [Monitor RAS, VPN, or dial-up connections](https://docs.telerik.com/fiddler/configure-fiddler/tasks/monitordialupandvpn).

One documented edge case is that Internet Explorer uses proxy settings from an active VPN connection whether or not that VPN provides internet access. Compare the client’s behavior with the VPN disconnected only when doing so is safe for your environment.

7. Configure remote and mobile devices

A remote device must be able to reach the Fiddler machine’s listener. In Fiddler Classic, enable Allow remote computers to connect under Tools > Fiddler Options > Connections, then restart Fiddler if prompted. Configure the device’s Wi-Fi proxy with the Fiddler computer’s reachable IP address and listening port. The Classic Android guide describes port 8888 as the usual default, but use the port actually configured on your machine.

Put the device and Fiddler computer on a network where they can reach each other.
Enable remote connections in Fiddler Classic and restart if required.
Set the device’s manual proxy host to the Fiddler machine’s reachable IP and its listener port.
Open http://ipv4.fiddler:8888/ on Android when using the documented default setup. A successful Echo Service page confirms basic connectivity; adjust the address or port for your configuration.
Only after reachability works, configure HTTPS decryption and certificate trust if needed. Use current platform-specific instructions.
Remove the device proxy and test certificate when finished if they are no longer needed.

If the Echo Service does not load, troubleshoot the host address, port, firewall, Wi-Fi isolation, and network reachability before investigating HTTPS certificates. See Telerik’s [Android capture instructions](https://docs.telerik.com/fiddler/configure-fiddler/tasks/configureforandroid). The guide notes that newer Android versions reject certificates with validity greater than two years and recommends its BouncyCastle certificate generator; treat that as the documented Android setup, not a rule for every Android release or proxy.

8. If your application embeds FiddlerCore

With FiddlerCore, inspect startup configuration as well as the embedding application’s proxy registration. The official [startup settings API reference](https://docs.telerik.com/fiddlercore/api/fiddler.fiddlercorestartupsettings) exposes separate controls for HTTPS decryption, HTTP/2, remote clients, system-proxy registration, monitoring all connections, upstream proxy settings, and listener port.

Check the settings relevant to the symptom:

DecryptSSL controls HTTPS decryption.
EnableHTTP2 controls HTTP/2 session support.
RegisterAsSystemProxy controls system proxy registration.
MonitorAllConnections affects which connections are pointed to FiddlerCore.
AllowRemoteClients permits remote devices and has security implications.
ListenPort determines the listener port.
UpstreamProxySettings matters when requests must pass through another proxy.

The API reference marks CaptureLocalhostTraffic obsolete and points toward registering the proxy for required connections and configuring bypass hosts. Follow the current reference for your version rather than copying obsolete startup patterns. If enabling remote clients, restrict exposure to the network and clients that need it.

9. Fiddler product and version considerations

Fiddler Classic is Windows-focused. Progress/Telerik describes Fiddler Everywhere as its supported commercial, cross-platform offering. The supplied vendor documentation, updated August 3, 2026, says Classic is no longer in active development and describes licensing changes effective September 17, 2026. These terms can change, so check the [current product and licensing documentation](https://www.telerik.com/fiddler) before choosing a product for commercial or cross-platform use.

A product change will not fix a client that is simply bypassing the proxy. First establish whether the affected application routes through the listener. If selecting a product, compare operating systems, desktop versus mobile capture workflow, license terms, protocol needs such as HTTP/2, TLS handling, and support status.

10. Troubleshooting by symptom

Symptom	Cause to check	Fix
Session List is completely empty	Client is not configured for the listener, Fiddler is offline, or the network route bypasses it.	Verify listener state and port; configure the affected client explicitly; make a test request from that client.
Browser appears, command-line tool does not	The tool ignores system proxy settings or has its own proxy configuration.	Use the tool’s proxy options or supported proxy environment variables and confirm the listener address.
HTTP works, HTTPS content does not	Decryption is disabled or the client does not trust the Fiddler certificate.	Check whether CONNECT is present; enable decryption and follow platform-specific certificate setup.
Only one destination is missing	A filter or bypass rule may exclude it.	Clear filters temporarily and inspect proxy bypass settings.
Localhost requests are missing	Loopback bypass or client-specific localhost behavior.	Check the client’s bypass rules; use only the localhost approach documented for that client and Fiddler version.
Traffic disappears while VPN is active	The VPN connection has separate proxy or routing settings.	Confirm the active connection and proxy settings; review Fiddler’s monitor-all-connections guidance.
Phone cannot open the Echo Service	Wrong IP or port, remote connections disabled, firewall, or network isolation.	Fix basic reachability before troubleshooting HTTPS or certificates.
Phone HTTP appears but HTTPS fails	Certificate installation, certificate validity, or trust policy issue.	Follow the current platform-specific Fiddler certificate instructions and verify trust on that device.
FiddlerCore captures some protocols but not HTTP/2	HTTP/2 support may not be enabled in startup settings.	Review the version’s `EnableHTTP2` setting and protocol requirements.

11. Reliability, performance, and cost considerations

Proxy capture adds a routing and inspection layer, so each client must keep using the configured proxy and remain able to reach it. Certificate trust can differ across apps on the same device. For repeatable investigations, record the client, proxy address, port, active network, filters, and HTTPS setting alongside the capture.

Capture only the traffic needed for diagnosis and avoid leaving remote access or test certificate trust enabled beyond the task. Large or busy captures can be harder to inspect; narrow the reproduction and use filters after confirming they are not hiding the session. Fiddler licensing and support terms depend on product and use, so verify current terms with Telerik before adopting it in a commercial workflow.

Or skip the browser setup

If the goal is a clean visual screenshot of a page rather than inspecting its network requests, ScreenshotNeo takes a URL and returns an image or PDF in one API request. It does not replace Fiddler’s proxy capture or expose request timelines and payloads; it is an alternative for the separate job of capturing page visuals.

For this example, replace the target URL and API key. See the ScreenshotNeo API documentation for options.

cURL

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

Python

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)

Node.js

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
const bytes = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', bytes));

Cookie or consent banners are accepted and removed before capture; newsletter popups and chat widgets are removed too.
Bot checks, blank pages, failed loads, timeouts, and cache hits are never billed; response headers say which page verdict occurred and whether it was billed.
An MCP server provides take_screenshot, get_page_info, and capture_pdf tools for AI agents.
1,000 screenshots per month are free with no card; paid plans start at $5 for 3,000.

FAQ

Does seeing a CONNECT session mean HTTPS decryption is working?

No. It shows the proxy connection is visible; decrypting the HTTPS contents requires the relevant decryption setting and client trust setup.

Why does one browser work while another application does not?

Each client can use a different proxy configuration or bypass behavior. Configure and test the affected app directly.

Should I switch from Fiddler Classic immediately?

Not solely because a session is missing. First check routing and filters. Consider product support, platform, protocol needs, and current license terms when choosing a longer-term setup.

Can a screenshot API diagnose a missing Fiddler session?

No. A screenshot captures page appearance; it does not show whether a specific app routed requests through Fiddler or expose its network session details.