Localhost HTTP debugging with Fiddler

I've had great success using ethernet sniffers (such as Etherdetect, or Ethereal) to troubleshoot communication problems. Installing a sniffer, even after installing the required WinPcap packet capture library, doesn't require a reboot. I frequently use sniffers to troubleshoot servers and desktops alike. Ethernet sniffers should be a standard tool in your development troubleshooting toolkit, too.

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2006/05/localhost-http-debugging-with-fiddler.html

And since many Ethernet sniffers only record packets that pass through the NIC or NIC driver layer, localhost packets are not recorded.

Thanks, but are there any sniffers that record packets “below” the NIC or NIC driver level, then?

Check HTTP Analyzer: http://www.ieinspector.com/httpanalyzer/

It can capture any process’s HTTP/HTTPS traffic (even to localhost) in current user session without the need to configure a proxy.

I suppose you could always try mapping localhost to an external interface in hosts, or just using an external proxy (and using the external interface IP), but if the app explicitly binds to only the localhost, you’ll find that most anything you try is going to be a problem.

Pop over the sysinternals, and try TCPView and TDIMon (in the networking section). They MIGHT (heavy grain of salt here) do what you need, but you’ll definitely have to write an app to translate their logs into something more useful for parsing.

Best opensource proxy / reverse proxy I have used is webscarab, just so feature rich:


A sniffer can capture traffic, but it’s a little harder to actually change it (inbound or outbound). It’s also not as useful when the content is compressed or encrypted :slight_smile: But if you’re looking at packet-level stuff it can’t beat.

A proxy isn’t the only option…there’s several for localhost. The easiest is tcptrace (http://www.pocketsoap.com) that’s a port forwarder…like localhost:81-localhost:80

Another is a tool like TamperIE that lets you modify the POSTs and GETs just before they hit WinInet.

Of course, there are similar “sniffer-like” apps available as plugins for specific browsers:




Personally, I prefer to do sniffing at the ethernet level because it’s the most flexible, and it’s not tied to any particular protocol (HTTP), or application (web browser).

Live HTTP Headers is a really good firefox plugin that does the same sort of thing:


Localhost packets don’t pass through the
regular network stack, so they’re invisible
to an ethernet sniffer.
– Jeff Atwood

This isn’t exactly true.

Localhost packets do “pass through [much of] the regular network stack”. Localhost packets just don’t pass through any physical NIC or NIC driver layer ( possibly the network interface layer).

And since many Ethernet sniffers only record packets that pass through the NIC or NIC driver layer, localhost packets are not recorded.

Actually, there are several solutions to sniff a local (as in the same machine) connection:
1.You could run either server/service or client/consumer in a VM with virtual NATed or switched network (not bridged). I use VMware so my experience is with this one. Then you sniff packets.
2.You install two more NICs in you machine (PCI or USB), give them valid IPs and connect them with a crossover cable (one to the other). Then bind the server/service to one of those IPs and the client/cosumer to the other. Then you sniff packets.
3.You do number 2 but additionaly, if you just have to involve localhost (, you route packets that have localhost as destination through one of these NICs. You’ll have to fiddle with the routing table and I’m not sure about the exact command sequence (I have done this, but only with Linux). Then you sniff packets addressed or coming from localhost because they will pas through the complete IP stack (redirected to a physical NIC as they are).

I forgot to mention that I use a similar techniques to test serial communication.

I use TamperData for FireFox, very nice too.

I haven’t found a reliable way to sniff PPP traffic on WinXP systems.

For example, my connection is PPPoA, and as such, appears to Windows as a PPP connection. Ethereal (mostly Winpcap’s fault) refuses to see the traffic passing through it

I found tcptrace very useful in my case. Thanks to Scott Hanselman for mentioning it.

I have a proprietary web application that I administer my web applications with. I can stop and start them using this admin application. The admin application talks (HTTP post to localhost:1085) to a deamon running on the same box and tells it to stop/start a particular application.

So I launched the admin application, stopped the daemon (to free up port 1085), launched tcptrace and told it to listen on 1085, clicked in the admin to stop my app and tcptrace grabbed me the HTTP post request that stops my app :slight_smile:

Now I run a job that updates a db and then restarts my app to pickup the changes.

Just to reinforce what Stefan Schultze said about HTTP Analyzer.
It’s a good HTTP sniffer for development.

Check HTTP Analyzer: http://www.ieinspector.com/httpanalyzer/

HTTP Analyzer captures HTTP/HTTPS traffic (localhost) from the various processes.

I had a local proxy running ( WebCleaner ) to do some testing, and had no luck capturing anything with Wireshark, since it was all localhost traffic. Tried IEinspector and it worked great – its a phenomenal tool! Thanks Stefan!

Yes but ieinspector http analyzer is not free … :slight_smile: Can anybody tell me how to sniff localhost with microsoft loop back or other solution?

Have you tried sniffing localhost by adding a route to localhost to your gateway? I think the Windows command would be:
route add mask gateway IP metric 1
All of your packets would appear twice though, once on the way out and again coming back in. I think you would also have to turn off the Automatic metric check box in your advanced TCP/IP settings tab.

On 2nd thought, your gateway doesn’t know what to do with an IP packet destined for, so this probably won’t work. It will if you replace the localhost IP with your NIC’s IP address though. Then you would need some internal configuration though that maps localhost to your NIC’s IP address - not too sure how to do that.