Hrm...  In that log, event 2133 shows the proxy was already marked as bad 12 seconds into the log, with no attempts to use it before that.  Event 2243 successfully uses the log, 34 seconds in, to talk to https://www.gstatic.com/ to request "/chrome/config/plugins_2/plugins_mac.json", but looking at the code, this is an internal Chrome request, using the SystemRequestContext, which has its own ProxyConfigService, so all we learn is that the proxy works for at least some requests.

We need a log where the proxy transitions from good to bad.

[+eroman]:  Does clicking "Re-apply proxy settings" at chrome://net-internals/#proxy clear the list of bad proxies?

[francis.tam@ge.com]:  One frequent cause of this we've seen is that if a proxy is being used on all ports, but only works certain ports, we'll mark it as bad.  The log doesn't provide any evidence this is the issue, just thought I'd mention it as a potential cause.

> Does clicking "Re-apply proxy settings" at chrome://net-internals/#proxy clear the list of bad proxies?

Yes.

Try launching Chrome with the command line flag:
  --log-net-log=PATH_TO_LOG_FILE

This will allow capturing all events from startup.

Thanks so much guys.  We'll take a look.

Does the problem still happen? If yes, could you provide the net log starting with the browser launch (see comment #5)? 

Thanks for the follow-up.  Actually the issue was urgent so we implemented a work around by setting mtalk.google.com DIRECT in the pac file.  We don't reckon it a perm. fix but most problems seem to come from mtalk.google.com for us.  We haven't really collected the log since then.  I think the issue is still there, but we just got around it.

Hrm...Could be the aforementioned port issue.  Looks like we talk to mtalk.google.com on port 5228.  If your proxy blackholes that port, then that would explain the problem.

Or suppose it could be that domain is flaky, so the proxy has trouble connecting to it, and however the proxy fails the tunnel request in that case causes us to try with a direct connection, and that request often succeeds, since the domain is flaky?

No activity in a while.  If this is still an issue, please feel free to file a new bug.