When browsers are experiencing network problems, generally the first thing to test is your network proxy settings.
Misconfigured settings, or misbehaving settings, can have a profound impact on your network traffic (possibly resulting in pages not loading at all).
Main take aways:
Note: this document talks about some features which are not present in versions of chrome prior to 4.
By default, Chrome will use your "system proxy settings".
Exactly what this means varies across platforms.
On Windows, Chrome uses the WinInet proxy configuration.
These are the same settings that Internet Explorer uses.
On Mac, Chrome uses the proxy settings listed under the Network Control Panel.
These are the same settings that Safari uses.
On Linux, Chrome uses either GNOME / KDE proxy settings, or will use certain environment variables.
For more information, see http://code.google.com/p/chromium/wiki/LinuxProxyConfig.
It is important to note that certain browsers like Firefox use a different set of proxy settings.
So when something fails to load in Firefox but works in Chrome, it could well be that they are using different configurations, and that for Chrome is wrong.
To test this theory, it is easiest to load a webpage in another browser that we know to be using the same proxy settings as Chrome.
If it fails in the same way for that other browser, it is a good bet that the "system proxy settings" are wrong and need to be changed.
On Windows we can try loading a webpage in Internet Explorer and see if it fails in the same way.
The best way to see what proxy settings chrome is really using, is to navigate to this special page in Chrome:
This will dump out something resembling:
Which enumerates the precise settings that Chrome is using.
By default, chrome will have fetched these settings from the "system proxy settings".
When investigating misconfiguration problems, the first thing to check is whether these settings are intended (the values could have been overrided by flags),
and whether Chrome actually fetched the correct settings from the system.
NOTE: The proxy settings are fetched lazily on a 10 second poll delay, during HTTP requests.
It is possible to specify multiple competing proxy settings (for example, on Windows you could enable the auto-detect option, AND specify a manual proxy server).
In such cases, chrome will use the following proxy settings fallback sequence, which matches Internet Explorer.
This fallback sequence is used on other platforms too, but since there generally isn't a way to specify such configurations it doesn't come up.
Specifically, you can check the sequence of steps that Chrome ran through to apply the proxy settings by navigating to this URL:
Any errors or log messages generated by PAC script evaluation, are sent to the chrome_debug.log file.
To see them, you must enable logging.
You will have to use command-line flags to override.
These are the ones available:
--no-proxy-serverSee the source code for documentation.
Send all traffic through the SOCKS 5 server "foobar:1080"
Send all traffic through the HTTP proxy server "foo:6233"
Use the custom PAC script to resolve proxy servers:
As an experiment you can try running Chrome with the command-line flag
This will select an alternate implementation of proxy resolving that uses the WinHTTP library (only available on Windows).
Make note of whether this works.
We aim to be fully compatible with Internet Explorer's proxy settings, so if you run into an incompatibility please file a bug (and cc email@example.com)
The only known caveat right now is we don't support all of the Microsoft PAC extensions. The unimplemented functions are:
You can monitor the status in bug 25407.
One common cause of this is PAC scripts which make use of DNS resolves within the PAC script (DNS resolving can be arbitrarily slow, especially for host names that don't exist).
The first step to debugging this, is to load up:
And search for the URL you were trying to load.
You will find the "LoadLog" for the request, that shows the breakdown of where time was spent.
In particular, you will get to see a finer-granularity breakdown of where the time was spent in the proxy resolving stage.
This stage can be quite complex, and might involve any or all of the following: