Troubleshooting misbehaving Web applications is a part of my job at work. Most of the time it's some buggy code that I or someone in our team had written. But sometimes I get approached about system problems too, like when a browser is having connection issues and can't access Web sites. If you are in the help desk business you know how the question is posed, "Is the Internet down?". I've always been tempted to reply: "Why yes, it is down. All that redundancy worked into it back in the DARPA era was a pile of lies. The whole Internet is toast."
Most of the time browser problems are not browser problems at all, they are network issues. The browser just gets the blame because it's front and center. A bad cable kicked once too many, an unplugged Wi-Fi access point, or a beleaguered DHCP server are the usual suspects. But the one that trips me most of the time is the proxy server setting. I've gotten better at it but I still occasionally miss this little item from my checklist.
As you may know proxy servers are protocol-level servers (appliances) that work as brokers between clients and servers. The most commonly used is the Web (HTTP) proxy server. Traffic passing back and forth between browsers and servers is funneled through them. Why use them? A detailed discussion is too boring, but in a nutshell, they make network admins' lives easier (more granular control, central management, etc), and they can cache and compress data saving on bandwidth and thus speeding things along.
Proxy servers are helpful, as long as one remembers that they're being used, especially when troubleshooting. Case in point, the other day I was working on a laptop connected to the Internet over Verizon Wireless broadband EVDO. No matter what I did I couldn't browse to the laptop's local Web server. Everything was fine when wireless was off, but as soon as I started it up, the local Web server would become inaccessible. What was happening? I could successfully ping my own server (duh), the Web service was running fine and listening on the local address, and there was no proxy server setting hidden in my browser (obvious place to look, but easily missed, specially when frantic).
After hours of investigating, including recruiting assistance from a colleague, the issue was revealed, quite by accident. Verizon Wireless comes with an add-on product called Venturi (enabled by default), used for optimization and compression. Turns out Venturi was the cause of this issue. When disabled, everything began working as expected. Venturi inserts itself in the TCP/IP stack and reroutes Web requests to a proxy server. No wonder I couldn't browse to the local server, the external Venturi proxy server had no idea how to access it, nor anything else on the private LAN.
The trouble with proxy servers is that it's hard to detect that your applications are using one, unless you pay attention to the telltale signs. First, with most applications, including browsers, you can check the network options and see if a proxy server address is configured. Next you can visit an IP address and header lookup page like whoami/My IP Address on this site, and check out the results. This page and the likes will display whatever information they can glean from your connection. Sometimes, but not always, proxy servers add headers such as "X-Forwarded-For" or "Via" to reveal the actual source of the request. You can also compare the shown source IP address to the IP address of your own machine. From the command line enter the "ipconfig" command (in Windows) which will display your actual IP address. If the lookup page is displaying the same IP address, chances are there is no proxy server in between, otherwise your traffic may be going through a proxy server and that would explain the irregularities of the sorts I was experiencing.
proxy servers,verizon wireless,evdo,ip address,ipconfig,tcp/ip,networks,browsers,http