Localhost HTTP debugging with Fiddler
I have been a huge fan of Fiddler the HTTP Debugging Proxy for a couple years now. However one thing that always bugged me about any network debugging tool was the fact that it could not debug localhost or 127.0.0.1. However I just found a solution while racking my brain for a way to debug one of my local projects.
I don’t know if many of you are aware but the website http://www.somesite.com points to 127.0.0.1 as a standard for URL examples.
C:\Users\Nick>ping somesite.com
Pinging somesite.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
So if somesite.com points to the same local IP address as localhost, I figured that I could just use somesite.com instead of localhost in my projects. I used the following setup:
With the above setup I was able to get Fiddler to monitor my localhost traffic my tricking the network card to go external for the somesite.com reference.
So basically that is all that I needed to do and it make pretty quick work of getting around the localhost problem.
Tags: 127.0.0.1, Fiddler, How To, localhost, Ping, somesite.com
Social: 
| View blog reactions
Subscribe in a reader
Subscribe via Email
March 10th, 2008 at 12:24 pm
Localhost HTTP debugging with Fiddler
You’ve been kicked (a good thing) - Trackback from DotNetKicks.com
March 11th, 2008 at 6:41 am
Check out you lmhost file in c:\windows\system32\drivers\etc - here you can filter specific URL’s to point to another location.
Otherwise you can always use http://{machinename}/default.aspx (or whatever file you are asking for), i.e. http://kbe/default.aspx - this will cause Fiddler to catch up on the HTTP requests even though the files are located on your local IIS.
March 11th, 2008 at 6:42 am
I think there’s a typo: “one thing that always bugged me about any network debugging tool was the fact that it could debug localhost” should be “that it could NOT debug localhost”.
There are other ways of using Fiddler on a local site:
1) Use your PC’s hostname instead of “localhost”.
2) Edit your Windows hosts file to create additional localhost aliases. See http://blog.kowalczyk.info/kb/local-dns-modifications-on-windows—etc-hosts-equivalent-.html
March 11th, 2008 at 6:56 am
I understand and know about the hosts and lmhosts file in c:\windows\system32\drivers\etc. And I know about the using your local machine trick too. Also by using your hosts file that is what causes the issue, because the hosts file bypasses the process of sending the request through the normal route, when mapped to 127.0.0.1, which is why localhost doesn’t work. If you removed localhost from the hosts and added localhost to an external DNS you would see localhost to start working in Fiddler.
However my problem is when dealing with a team of developers the easiest solution is usually the best solution. And it is almost impossible to edit your hosts file in Windows Vista because of the protections placed on it, and as outlined above it wouldn’t work anyways. So working on a team where everybody has Vista and different machine names I choose to use http://www.somesite.com.
I probably should have spelled it out, but those are my reasons for choosing something universal such as http://www.somesite.com.
March 11th, 2008 at 7:45 am
You can also use “localhost.”
March 11th, 2008 at 7:46 am
“localhost.” has the nasty habit of not working with port numbers at least in my experience.
March 11th, 2008 at 12:54 pm
See any reason to not use your netbios name? eg: http://mycomputername/mysite
March 11th, 2008 at 4:48 pm
I don’t know how reliable it is - AFAIK, only example.* is reserved for examples, but it’s an interesting trick. I wonder who owns somesite.com and why they pointed it to 127.0.0.1…..
March 11th, 2008 at 6:06 pm
Don’t know how long it will be around, but basically it is just a DNS lookup there is no actual site for it. So stability is not an issue.
Created: 2003-07-02
Updated: 2007-06-17
Expires: 2008-07-02
Registrant
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
Administrative Contact
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
E-mail: KbYDlJHYrd5MNdcCS/
Technical Contact
SOMESITE.COM
c/o Whois IDentity Shield
142-757 W. Hastings St., Suite #777
Vancouver, BC
Canada V6C 1A1
E-mail: tInMTdMS88zN3zlv6vN8QAR1e/ZcjWr+jRymBAqH8MsEOT4fJTU=@2008.identityshield.com
Name servers for this domain:
NS1.HITFARM.COM 72.51.27.54
NS2.HITFARM.COM 217.68.70.72
NS3.HITFARM.COM 64.40.116.38
March 12th, 2008 at 6:03 am
Jeffro,
As stated above when working on teams, you need something that is common in your project configurations. Unfortunately the computer name is… well unique to the computer.
March 26th, 2008 at 5:33 am
As Nick Berardi Says:
“localhost.” (the dot at the end is important)
It works #1 even with port number “http://localhost.:2128/”
March 26th, 2008 at 3:24 pm
Localhost HTTP debugging with Fiddler - repost
Debugging with http traffic with Fiddler works great, until you try to intercept traffic on localhost.
June 25th, 2008 at 6:50 pm
Other workarounds are here: http://www.fiddler2.com/fiddler/help/hookup.asp#Q-LocalTraffic