Take a typical HTTP v1.1 GET request, without using an HTTP proxy.
The browser first determines the IP address associated with www.google.com with a DNS lookup (or possibly a cache hit). It then connects to the server at that IP address on port 80 and sends something like the following:
GET http://www.google.com/search?q=lolphin HTTP/1.1
Host: www.google.com
Connection: close
The fully qualified path is included in the request to allow for server virtualisation; these days one IP address may host many different sites with different domains, so the domain name must be sent in the request to make clear to the server which domain name was entered by the user.
When an HTTP proxy is used the request is the same, but instead of connecting to the IP address obtained by resolving www.google.com a client connects to the IP address of the desired proxy server. It may need to resolve a domain like myproxy.mynetwork.com to get that IP address, but it never resolves the IP address of www.google.com in this scenario. It doesn't need to.
The HTTP proxy receives the request, performs the DNS lookup itself and performs the steps required to retrieve the webpage just as if it were a normal web client sending a typical request.
But that lookup performed by the proxy server is the clincher. Because the University proxy here is so overwhelmed by traffic and presumably runs on inadequate hardware, it takes longer than usual for the DNS lookup to be performed.
This might manifest simply as an added delay in connection times when retrieving webpages through the proxy, but apparently Firefox 3.0.6 hangs whilst waiting for a response from a proxy. The result is several seconds of wait time, during which Firefox becomes unresponsive.
(I have no actual evidence for this other than my own experience; if anyone fancies poring through Bugzilla and finding any relevant extant bug report please leave a comment on this article.)
