Welcome to the world of fun that is Proxy Auto-Configuration files (and indeed Google Chrome)!
You haven't seen anything, yet. Include more than just Chrome and Firefox in the mixture of WWW browsers, and one is in for a world of difficulty. (I recently tried to diagnose why a PAC file was causing RealPlayer to lose the ability to resolve any domain names at all.)
Useful diagnosis tools, where "useful" incorporates "I've used them myself to diagnose problems.", include Chrome's JavaScript console and debug logging function. I diagnosed a syntax error in a fairly large PAC file with that, once. The Chromium "Net Internals" proxy configuration reporting page (whose URL SuperUser doesn't allow as a hyperlink), and its initialization reporting counterpart (likewise), are also useful:
chrome://net-internals/proxyservice.config
chrome://net-internals/proxyservice.init_log
Yes, it is quite difficult to persuade Chrome to re-load a PAC file afresh. Chrome has had a fairly troubled history when it comes to proxy settings. One way to do it that is fairly reliable is to completely turn off all proxy settings in the system settings dialogue (and save that change, of course), wait for a minute, then turn them back on again. But in the past (with earlier versions) I have had to completely exit and restart Chrome. In part this is because Chrome works by polling for changes to the system settings every 10 or so seconds in the background when it is otherwise idle.
In Chrome's bug database you'll find that the request to allow run-time switchable Chrome-specific proxy settings like other WWW browsers have, which relates to your problem, languished for three years and was closed as "We won't fix this.", although there's now supposedly an extension (and a set of command-line options that are, of course, not run-time switchable).
As you've observed, Firefox has a simple "Reload" button. As you can see by reading the three years of bug discussion, this is an area where people are quite unhappy about how feature-poor and quirky Chrome is compared to Firefox.
Note that this might not be the root cause of your underlying problem, but since you haven't asked about that, let alone provided anywhere near enough details of it, I'm not going to address it. ☺
Given that the problem is gone now, it is pure speculation to what the cause could be.
Often malware changes the proxy server of your internet connection to an internal component of the malware so all traffic is monitored. You can find this setting here:
1. Open your Control Panel
2. Go to Internet Options
3. Access the tab Connections
4. Click the button LAN settings
5. at the bottom, you see the Proxy Server settings. This should be unchecked and blank.
Given the comments that you tested this and with the feedback supplied, another thing that comes to mind is an edited hosts file. But given that the hosts file does not have wildcard ability, it would've been full with sites you visit often.
The hosts file is a textfile located at:
c:\windows\system32\drivers\etc
Best Answer
This is pretty much impossible as ping works at a much lower level than the proxy.
I am guessing you use a HTTP proxy – it works at a high level; the browser (or yum) only sends it HTTP requests for specific URLs (e.g.
GET http://www.google.com/
), and the proxy handles everything else – it might open a TCP connection to the server and forward the request; or it might do something entirely different. HTTP requests are the only thing you can send to them.Some HTTP proxies are configured to allow the client to open TCP connections (lower level), by making a special request (e.g.
CONNECT www.google.com:443
). In this mode, the client and server can exchange data over the TCP connection, but they still do not have any control over actual TCP or IP packets being sent. (Also, usually only specific TCP ports like 443 for HTTPS are allowed.)The protocol has no mechanism for altering TCP options or using any other protocol than TCP – the client cannot send UDP datagrams, and most importantly in your case, it cannot send/receive ICMP packets, which the ping tool requires.
Note that the word "ping" by itself is more general than the
ping
command. It's more likely that yum "pings" the server by making dummy HTTP requests (which makes sense as its task is to determine which server responds to HTTP the fastest, while ICMP pings are quite irrelevant).