Although the system network settings have been sufficient for our network stack, eventually there will be some configuration settings specific to our network stack, so we need to have our own preference service for those settings. See also issue 266, in which some Firefox users demand that we not use the WinInet proxy settings (the de facto system proxy settings on Windows).
Chrome supports the following proxy-related command line arguments:
This tells Chrome not to use a Proxy. It overrides any other proxy settings provided.
This tells Chrome to try and automatically detect your proxy configuration. This flag is ignored if --proxy-server is also provided.
--proxy-server=<scheme>=<uri>[:<port>][;...] | <uri>[:<port>] | "direct://"
This tells Chrome to use a custom proxy configuration. You can specify a custom proxy configuration in three ways:
1) By providing a semi-colon-separated mapping of list scheme to url/port pairs.
For example, you can specify:
to use HTTP proxy "foopy:80" for http URLs and HTTP proxy "foopy2:80" for ftp URLs.
2) By providing a single uri with optional port to use for all URLs.
will use the proxy at foopy:8080 for all traffic.
3) By using the special "direct://" value.
--proxy-server="direct://" will cause all connections to not use a proxy.
This tells chrome to bypass any specified proxy for the given semi-colon-separated list of hosts. This flag must be used (or rather, only has an effect) in tandem with --proxy-server.
Note that trailing-domain matching doesn't require "." separators so "*google.com
" will match "igoogle.com
" for example.
will use the proxy server "foopy" on port 8080 for all hosts except those pointing to *.google.com
, those pointing to *foo.com
and those pointing to localhost on port 8080.
requests would still be proxied. ifoo.com
requests would not be proxied since *foo, not *.foo was specified.
This tells Chrome to use the PAC file at the specified URL.
will tell Chrome to resolve proxy information for URL requests using the windows.pac file.