Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to work out if my broadband provider is using a transparent proxy. Mostly I don't mind if they do, but today I'm trying to preview a site I have moved from one server to another, before DNS has propagated. So I put the new IP address into /etc/hosts and expect to be able to connect to the new server, but alas I'm still getting the old one.

To prove that I'm talking to the "new" server, I'm telnetting into the new IP address and doing this:


And this is still hitting the old server.

I tried the same operation from another host elsewhere on the internet that definitely doesn't have a transparent proxy cache on it, and this time it hit the correct server.

So I'm fairly sure that there's a cache on my broadband line... and the cache is doing its own DNS lookup which of course overrides my /etc/hosts file.

However, is there any way that I can find out more about it, and confirm that it's there?

  • the "source IP address" of my web requests seems to be my home IP address, so that doesn't show up a proxy cache

  • I'm not having any success with Wireshark examining the packets to see if there's any difference when communicating direct with a site (e.g. on localhost) vs. communicating via the proxy.

Can anyone offer any words of wisdom? Is there any sure-fire way of detecting or identifying an inline/transparent proxy cache?


share|improve this question
DNS doesn't propogate records are cached. – Zoredache Aug 15 '10 at 8:41
Ok, sorry, my bad terminology. But the core issue still stands - it looks like something, probably a transparent proxy, has cached the old IP address. When I telnet directly into the new IP address, port 80, I expect to actually reach that server, and not somehow find my request still ending up at the old server! – buzzki Aug 15 '10 at 9:14
up vote 1 down vote accepted

If you're using an IP address to connect to the remote server, then the contents of your /etc/hosts and/or DNS records don't matter.

You could try running nmap against the IP address in question from your local machine and a remote machine and see what it identifies as the remote TCP/IP stack in use, and see if it matches (or doesn't match) what you'd expect given what you know about the server's OS.

You could try using SSL, or an arbitrary non-standard port, if you want to try to avoid the proxy.

You could probably learn something by looking at the time it takes your machine to connect to port 80 on a remote machine, or many remote machines. If your ISP is running a local transparent proxy, then the time it takes to open a connection should be pretty similar whether you're trying to connect to a machine that's close or far away, because in either case you're actually connecting to a nearby machine. httperf might be helpful in this regard.

You might also learn something by shutting down the remote server, and then trying to connect via the proxy - if you can successfully connect to a machine that's not accepting connections, that's not a good sign.

share|improve this answer
Thanks for the info. httperf is showing some interesting results but I think it'll take some time before I'm confident in drawing conclusions from it. Most telling is the fact that even when I telnet into NEW:80, I am getting a page that only exists on OLD:80. I can get around the whole kaboodle by using a VPN to tunnel through, but that's kind of a long way around. Thanks for the reply though - good information. – buzzki Aug 15 '10 at 10:00
httperf shows the most useful info when I request tiny images from each site, rather than the front page. These now have a very consistent "Connection time" (within 10ms) no matter where in the world the servers are. – buzzki Aug 15 '10 at 10:15
10 ms * speed of light = approx 1860 miles, so if you're apparently getting a response from a server located on the other side of the earth in 10 ms, your ISP has some explaining to do. – gbroiles Aug 15 '10 at 14:54
^your maths teacher has some explaining to do.. – verbumSapienti Oct 8 '14 at 15:42

I did a quick search and stumbled across this:

Maybe give that a shot?

share|improve this answer

Try the "what is my ip" services; most will report the proxy's ip

share|improve this answer

This article has a perl script and techniques to detect the presence of a transparent proxy

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.