By the way if you enter proxy ip and port to directly in the proxy settings everhtying working fine. Problem happening when proxy pac file using.

Unable to reproduce on 69.0.3486.0. I configured a proxy server on localhost port 80, and then create a proxy.pac file containing:


function FindProxyForURL(url, host) {
  return "PROXY 127.0.0.1:80; PROXY 127.0.0.2:80";
}


and configured Chrome to use it. I was able to connect to the whatsapp.com WebSocket:

t=4199 [st=  0] +HTTP_STREAM_JOB_CONTROLLER  [dt=571]
                 --> is_preconnect = false
                 --> url = "wss://w2.web.whatsapp.com/ws"
t=4199 [st=  0]    HTTP_STREAM_JOB_CONTROLLER_BOUND
                   --> source_dependency = 10164 (URL_REQUEST)
t=4199 [st=  0]   +PROXY_RESOLUTION_SERVICE  [dt=1]
t=4200 [st=  1]      PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST
                     --> pac_string = "PROXY 127.0.0.1:80;PROXY 127.0.0.2:80"
t=4200 [st=  1]   -PROXY_RESOLUTION_SERVICE
t=4200 [st=  1]    HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
                   --> proxy_server = "PROXY 127.0.0.1:80"
t=4200 [st=  1]    HTTP_STREAM_REQUEST_STARTED_JOB
                   --> source_dependency = 10166 (HTTP_STREAM_JOB)
t=4770 [st=571] -HTTP_STREAM_JOB_CONTROLLER

Is your proxy.pac matching against the URL scheme?

As you know your version 69.0.3486.0 is not released for end-user. We can use known latest 67.0.3396.99 stable version. Could you please reproduce with 67.0.3396.99? By the way yes, proxy.pac matching URL scheme. But chrome can't read for wss:// URL's.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Another test result. We try to test with 69.0.3492.0 (Chrome Canary)

and proxy pac file only including these rows;

function FindProxyForURL(url, host) {
  return "PROXY ip-address1:8080; PROXY ip-address2:8080";
}

Test result is: 

t=3711 [st=  0] +HTTP_STREAM_JOB_CONTROLLER  [dt=431]
                 --> is_preconnect = false
                 --> url = "wss://w3.web.whatsapp.com/ws"
t=3711 [st=  0]    HTTP_STREAM_JOB_CONTROLLER_BOUND
                   --> source_dependency = 588 (URL_REQUEST)
t=3711 [st=  0]   +PROXY_RESOLUTION_SERVICE  [dt=0]
t=3711 [st=  0]      SUBMITTED_TO_RESOLVER_THREAD
                     --> thread_number = 0
t=3711 [st=  0]      PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST
                     --> net_error = -326 (ERR_PAC_STATUS_NOT_OK)
t=3711 [st=  0]   -PROXY_RESOLUTION_SERVICE
t=3711 [st=  0]    HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
                   --> proxy_server = "DIRECT"
t=3711 [st=  0]    HTTP_STREAM_REQUEST_STARTED_JOB
                   --> source_dependency = 590 (HTTP_STREAM_JOB)
t=4142 [st=431] -HTTP_STREAM_JOB_CONTROLLER

The steps in #4 also work for me in 67.0.3396.99.

What about steps #5 and #6?

I've been testing on Linux, but it turns out that Chrome uses the system proxy.pac resolver on Windows and so my tests have been invalid.

I'm trying to retest on Windows but have run into technical difficulties.

I will need to determine whether this issue is due to a change in Chrome or a change in Windows.

I checked again with version 67.0.3396.99 on Windows. I still don't have any problems connecting:

t=10389 [st=  0] +HTTP_STREAM_JOB_CONTROLLER  [dt=588]
                  --> is_preconnect = false
                  --> url = "wss://w3.web.whatsapp.com/ws"
t=10389 [st=  0]    HTTP_STREAM_JOB_CONTROLLER_BOUND
                    --> source_dependency = 2296 (URL_REQUEST)
t=10389 [st=  0]   +PROXY_RESOLUTION_SERVICE  [dt=0]
t=10389 [st=  0]      PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST
                      --> pac_string = "PROXY 127.0.0.1:8000;PROXY 127.0.0.2:8000"
t=10389 [st=  0]   -PROXY_RESOLUTION_SERVICE
t=10389 [st=  0]    HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
                    --> proxy_server = "PROXY 127.0.0.1:8000"
t=10389 [st=  0]    HTTP_STREAM_REQUEST_STARTED_JOB
                    --> source_dependency = 2298 (HTTP_STREAM_JOB)
t=10977 [st=588] -HTTP_STREAM_JOB_CONTROLLER

Okay, I managed to reproduce. The trick is to supply the --winhttp-proxy-resolver command-line flag to Chrome. I've confirmed it also applies to ws: URLs:

t=  0 [st=  0] +HTTP_STREAM_JOB_CONTROLLER  [dt=208]
                --> is_preconnect = false
                --> url = "ws://echo.websocket.org/?encoding=text"
t=  1 [st=  1]    HTTP_STREAM_JOB_CONTROLLER_BOUND
                  --> source_dependency = 1257 (URL_REQUEST)
t=  1 [st=  1]   +PROXY_RESOLUTION_SERVICE  [dt=0]
t=  1 [st=  1]      SUBMITTED_TO_RESOLVER_THREAD
                    --> thread_number = 0
t=  1 [st=  1]      PROXY_RESOLUTION_SERVICE_RESOLVED_PROXY_LIST
                    --> net_error = -326 (ERR_PAC_STATUS_NOT_OK)
t=  1 [st=  1]   -PROXY_RESOLUTION_SERVICE
t=  1 [st=  1]    HTTP_STREAM_JOB_CONTROLLER_PROXY_SERVER_RESOLVED
                  --> proxy_server = "DIRECT"
t=  1 [st=  1]    HTTP_STREAM_REQUEST_STARTED_JOB
                  --> source_dependency = 1259 (HTTP_STREAM_JOB)
t=208 [st=208] -HTTP_STREAM_JOB_CONTROLLER

In my case it's falling back to "DIRECT", but that can be configured by another option.

A workaround is to not use the --winhttp-proxy-resolver flag if possible.

WinHttpGetProxyForUrl() is failing with code ERROR_WINHTTP_UNRECOGNIZED_SCHEME. https://docs.microsoft.com/en-us/windows/desktop/api/winhttp/nf-winhttp-winhttpgetproxyforurl says that this error means 'The URL of the PAC file specified a scheme other than "http:" or "https:".', which matches the symptoms we're seeing.

Thanks for your actions. But we don't use --winhttp-proxy-resolver flag anywhere. In the other hand I'm trying with basic Proxy PAC file and commands. Result is same.

#14 It shouldn't be possible for it to happen without the flag. Enter the URL chrome://version and look in the "Command Line" section. It may be coming from somewhere unexpected.

You right. When I check the version page it says used flag --winhttp-proxy-resolver . But I don't use this flag anywhere. No policy, no parameter. Where is it coming from?


Command Line	chrome.exe --winhttp-proxy-resolver --proxy-pac-url=http://ip-address/proxy.pac --flag-switches-begin --flag-switches-end

#16 If it's not an admin policy then my best guess would be that it comes from the shortcut that is used to start Chrome.

My investigation shows that Chrome and Firefox pass a wss: URL to FindProxyForURL(), while Safari and Edge change it to an https: URL.

I think when we are using the winhttp backend we will have to convert it to an https: URL.

The system resolver on Mac OS X has the same issue.

#17 I checked the admin policy. There is no any enforcement for this parameter. And I checked the all of shortcuts, registry entries. There is no any entry for the flag.

#20 I found this page which contains a bit more information: https://www.chromium.org/developers/design-documents/network-stack/debugging-net-proxy, but probably won't help you. I have heard of firewall or anti-virus software changing Chrome's command-line flags.

It could be added directly by security software when Chrome is launched, I suppose.

#21 Yes, I saw these article. It's not helping to me. I think added by security softwares. I'm checking right now.

Yes, I found the source for this parameter. We use Forcepoint Endpoint DLP extension for Chrome. When we remove the extension --winhttp-proxy-resolver parameter is clearing and Chrome working stable and expected for wss: connections. We are opening a case to Forcepoint. Thanks for your helps. You can close this issue.

#24 Thank you for the followup! I am glad you won't have to wait for a fix in Chrome.

I am still working to make this configuration work in Chrome, so if you don't mind I will leave this issue open for now.

#25 Yes, off course. You can leave the issue as open.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de

commit 5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de
Author: Adam Rice <ricea@chromium.org>
Date: Thu Aug 02 15:28:43 2018

[WebSocket] Fix proxy.pac --winhttp-proxy-resolver

Make proxy.pac resolution for WebSockets work for Windows and Mac when
the --winhttp-proxy-resolver flag is supplied. These platforms don't
support passing WebSocket URLs to the proxy.pac file. Convert ws and wss
URLs to http and https before passing them to proxy.pac. This matches
the behaviour of the vendor browsers on these platforms.

Add a WebSocket end-to-end test to verify that WebSockets can be
accessed via a proxy specified in proxy.pac.

Since preflighting proxy credentials makes the tests really complicated,
add an extra mode to testserver.py for a vanilla proxy that doesn't
require auth.

BUG= 862121 

Change-Id: I63b318b7f6d3083a6c21f5811bb27966d17cb02a
Reviewed-on: https://chromium-review.googlesource.com/1143093
Commit-Queue: Adam Rice <ricea@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Reviewed-by: Eric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#580196}
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/proxy_resolution/proxy_resolver_mac.cc
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/proxy_resolution/proxy_resolver_winhttp.cc
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/test/spawned_test_server/base_test_server.cc
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/test/spawned_test_server/base_test_server.h
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/test/spawned_test_server/local_test_server.cc
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/tools/testserver/testserver.py
[modify] https://crrev.com/5b4a3d893cfd6a42a2d1f685fa6a828d34c9c1de/net/websockets/websocket_end_to_end_test.cc