You may need to take special configuration steps to capture traffic that is sent to a server running on the same computer as the client application and Fiddler are both running on. Such traffic is called “loopback” traffic because it never leaves the machine; loopback traffic typically includes traffic sent to the loopback addresses of 127.0.0.1, [::1], the hostname localhost, and sometimes to any of the current computer’s TCP/IP addresses.
There are three scenarios that can cause problems with loopback traffic:
1. Many client applications and frameworks are hardcoded to bypass the proxy server for loopback traffic.
2. On Windows Vista and later, HTTP authentication behaves different when the client and server are on the same computer.
3. On Windows 8, Metro-style applications are not able to connect to loopback listeners (like Fiddler) running outside of the app package.
Let’s explore each of these in turn.
Loopback Bypasses
Many clients automatically bypass the proxy for loopback traffic with the expectation that a remote proxy server wouldn’t know what to do with traffic bound for “127.0.0.1”, since the proxy’s definition of that address is different than the client’s. However, these clients failed to consider the case where the proxy server is running on the same computer as the client (like Fiddler), in which case both the client and the proxy have the same definition for such addresses.
82 | Configuring Fiddler and Clients
Prior to Internet Explorer 9, all traffic sent via the WinINET networking stack (used by IE, Office, etc.) would bypass the proxy server if it was sent to addresses of 127.0.0.1, [::1], or the hostname localhost. Current versions of Opera do the same, and Firefox’s No Proxy For setting is set to localhost, 127.0.0.1 by default. Microsoft .NET Framework versions 1 to 4 also bypass the proxy for loopback requests.
If you attempt to use one of these clients to connect to a server running on your local computer, the client ignores the proxy setting and sends traffic directly to the server.
The simplest way to capture such traffic in Fiddler is to change the hostname requested by the client so that the client doesn’t recognize it as bound for a loopback address. One option is to simply use the current computer’s DNS hostname (e.g. http://mymachinename) instead, but this requires that you know the current computer’s hostname and can make it complicated to build test cases that work across multiple machines.
To help mitigate that shortcoming, Fiddler supports several “virtual hostnames” that alias the loopback addresses:
Rather than: Instead use:
127.0.0.1 ipv4.fiddler [::1] ipv6.fiddler localhost localhost.fiddler
By using these virtual hostnames, the client will send the traffic to Fiddler, and Fiddler will automatically substitute the correct hostname in the request URL and Host header.
In Internet Explorer 9, WinINET was enhanced with a new feature that allows the client to configure WinINET to proxy loopback traffic. To opt-in to this behavior, the Proxy Bypass List is configured with the special token
<-loopback>; Fiddler sets this token automatically by default, ensuring that you can easily see traffic sent to the local computer. Starting in Windows 8, the WinHTTP stack also respects the <-loopback> token. Hopefully, Opera and the .NET Framework will permit loopback proxying in future versions.
Loopback Authentication
Windows Vista and later attempt to protect the user against “loopback authentication” attacks, in which a client thinks it is authenticating with a remote server but is actually authenticating back to the local computer. Such attacks are usually attempting to elevate privilege against the local computer. When Windows encounters an unexpected attempt to authenticate to the local machine, the authentication request will be blocked.
To disable loopback protection, set DisableLoopbackCheck=1 as described here: http://support.microsoft.com /kb/926642.
Loopback Blocked from Metro-style Windows 8 Apps
Windows 8 introduced a new application-isolation technology known as AppContainer. This technology is used by new “Metro-style apps” including the Metro-style mode of Internet Explorer, as well as all applications you down-load from the Windows Store. In order to prevent inter-process communication between the isolated AppContainer processes and other processes (most of which run at higher privilege) Metro-style applications are prevented (by the firewall) from making network connections to servers running on the local computer. This blockage occurs no matter
83 | Configuring Fiddler and Clients what hostname is used-- attempts to connect to http://localhost, http://127.0.0.1, and http://machinename will all fail. Using the CheckNetIsolation.exe tool, an end-user may exempt a single process from this restriction for debugging or development purposes only. Debugging an application with the upcoming version of Visual Studio will also temporarily allow it to connect to loopback.
By default, if you run Fiddler on Windows 8 and launch the Metro-style browser or any Metro-style application, you will find that the app is unable to connect to any site, including Internet sites. That’s because Fiddler is running on the local computer and the firewall will block the application from proxying its traffic to Fiddler. Because Fiddler is the configured proxy server, the app will conclude that the network is unavailable and abort the request.
To resolve this problem, I’ve created a graphical utility called EnableLoopback which allows you to exempt one or more AppContainers from Loopback restrictions. Users of the v4 builds of Fiddler will find the
EnableLoopback.exe utility installed by default; it can be launched using the Win8 Config toolbar button at the left edge of the Fiddler toolbar:
Users of the v2 builds of Fiddler can download the utility from http://fiddler2.com/r/?Win8EL. The tool requires Administrative privileges to adjust the Loopback Exemptions list, and will prompt for permission to run as an Administrator when launched.
As the utility starts, it will enumerate all of the AppContainers on the local computer and display them in a listview.
A checkbox before each entry indicates whether the AppContainer is exempted from loopback restrictions. You can individually change the setting on a per-AppContainer basis, or you may use the buttons at the top of the tool to adjust all AppContainers’ exemptions together. After making changes, click the Save Changes button to commit the list back to Windows.
84 | Configuring Fiddler and Clients
After exempting an app’s AppContainer from loopback restrictions, you will find that Fiddler can successfully debug its traffic, just like any other desktop application.