Version of Google Chrome (Wrench-> About Google Chrome): 55.0.2883.87 m (64-bit)
Version of MSI (if applicable):
Using group policy settings? Yes


Issue:
When running chrome with "chrome --winhttp-proxy-resolver" the described issue is not happening.

Chrome in our enterprise is configured with a .PAC file. The instructions provide a FALLBACK proxy of "DIRECT".

I used chrome://net-internals/#proxy to see why the primary proxy is invalidated and when and I saw the below:

This is the point where our proxy is deemed bad because of source dependency
18115 which can be found below:

t=219521 [st=488] SOCKET_POOL_BOUND_TO_CONNECT_JOB
--> source_dependency = 18115 (CONNECT_JOB)
t=219521 [st=488] -SOCKET_POOL
--> net_error = -111 (ERR_TUNNEL_CONNECTION_FAILED)
t=219521 [st=488] PROXY_LIST_FALLBACK
--> bad_proxy = "192.168.51.8:3128"
t=219521 [st=488] +HOST_RESOLVER_IMPL_REQUEST [dt=0]
--> address_family = 0
--> allow_cached_response = true
--> host = "www.facebook.com:443"
--> is_speculative = false
t=219521 [st=488] HOST_RESOLVER_IMPL_IPV6_REACHABILITY_CHECK
--> cached = true
--> ipv6_available = false
t=219521 [st=488] -HOST_RESOLVER_IMPL_REQUEST
--> net_error = -804 (ERR_DNS_CACHE_MISS)

So, when Chrome can't use this proxy to access Facebook (or any other site
for that matter), then the whole proxy is considered BAD and the Fallback
option in the PAC is enabled (which Is DIRECT).


18115: CONNECT_JOB
ssl/www.facebook.com:443
Start Time: 2017-01-10 16:01:06.294

t=219039 [st= 0] +SOCKET_POOL_CONNECT_JOB [dt=482]
--> group_name = "ssl/www.facebook.com:443"
t=219039 [st= 0] +SOCKET_POOL_CONNECT_JOB_CONNECT [dt=482]
t=219039 [st= 0] +SOCKET_POOL [dt=482]
t=219521 [st=482] SOCKET_POOL_BOUND_TO_CONNECT_JOB
--> source_dependency = 18116 (CONNECT_JOB)
t=219521 [st=482] -SOCKET_POOL
--> net_error = -111 (ERR_TUNNEL_CONNECTION_FAILED)
t=219521 [st=482] -SOCKET_POOL_CONNECT_JOB_CONNECT
--> net_error = -111 (ERR_TUNNEL_CONNECTION_FAILED)
t=219521 [st=482] -SOCKET_POOL_CONNECT_JOB

Our proxy shouldn't get invalidated when access to one site is not working. We intentionally block a big number of URLs for security and compliance reasons.


Expected Behavior:
We need this facility to work exactly like it does on Internet Explorer 11 and Firefox. Stick to the primary proxy "unless" the proxy is completely unresponsive/unavailable. Testing of the availability of the proxy would be to check a number of URLs in the background (like well known sites like google.com, bing.com, godaddy.com) in a way to make sure that the proxy has failed completely.

Actual Behavior:
Whenever a site is not accessible, the proxy is invalidated.

Workaround proposal:
Add a Group Policy option to always run Chrome with --winhttp-proxy-resolver

Solution proposal:
Add a Group Policy option to make this work like --winhttp-proxy-resolver but continue to use Chrome's facility and WinInet API.