It sounds like the proxy bypass is failing. Please follow the instructions at https://www.chromium.org/for-testers/providing-network-details to capture a netlog. I will be able to tell from it what is going on with your proxy. If it contains confidential or private information, you can email it to me rather than attach it to the issue.

I'm surprised that the connection to https://127.0.0.1/ is working. +rsleevi, isn't this supposed to be failing now?

First, Thank you for your help!

I made two network traces, with "strip private information".
One is with localhost the other with 127.0.0.1

The local web/websocket server is named: "websocket-sharp/1.0" listening on port 34714.

I am loading a test html page from the local web/websocket server: 
https://localhost:34714/alfa/abs/test/v4.0/client  (html)
referencing
https://localhost:34714/alfa/abs/test/v4.0/alfa.css
https://127.0.0.1:34714/alfa/abs/alfa-4.0-client.min.js
(typically these files would be part of a webapp hosted in our intranet; not on localhost)

The js makes the websocket connection:
wss://localhost:34714/Alfa/CurrentUser/Auth?Protocol=1&AppCode=AXX  (succeeding)
-or-
wss://127.0.0.1:34714/Alfa/CurrentUser/Auth?Protocol=1&AppCode=AXX  (failing)

Our proxy is "proxy-sd.s-mxs.net" but the internet settings are configured to bypass local addresses.
(In the 127.0.0.1 log I can see something different regarding the proxy usage. But my knowledge about that is limited.)

If you need other logs, I will provide them.

Btw.: Are there any plans with Chrome to limit access (other than CORS) to localhost or 127.0.0.1 from external origins?

Thank you! 
Gerhard

Deleted: chrome-logs.zip 120 KB

chrome-logs.zip 120 KB Download

Note: The JavaScript has a retry logic, so you can may see more than one wss connection attemp, when the connection fails.

I can see the wss://127.0.0.1:34714 connection going to the proxy and failing.

It looks to me like you have two possible proxy configurations, and Chrome isn't using the one you expect. It says that it's getting your proxy configuration from a PAC script at http://pac.s-mxs.net/. I don't know what's in that PAC script, but I expect if you search in it for the string 127.0.0.1 you'll be able to track down what's going on.

It can be difficult to determine what proxy settings are actually in use. The way I do it is to go to about:net-internals and click on "Proxy". If you can stop the browser using any proxy at all that would be the best way to determine whether your wss: connection to 127.0.0.1 is able to succeed at all.

Thank you for hint with the PAC file!
You are right. When the PAC file is used, "https://127.0.0.1" will succeede and "wss://127.0.0.1" will fail.


But strangly on another workstation the "wss://127.0.0.1" succeeds.
Maybe it's not a Chrome regression bug, but a configuration error at my side.


I investigated the Proxy-Settings and compared them to another workstation.

My settings (with Chrome v67) are:
---------------------------------
Effective proxy settings
PAC script: http://pac.s-mxs.net/
Original proxy settings
(1) PAC script: http://pac.s-mxs.net/
(2) Proxy server: proxy-sd.s-mxs.net:8080
    Bypass list: 
      *:5985
      *:5986
      sip.s-mxs.net
      sipweb.s-mxs.net
      *.scall.at
      anywhere.s-mxs.net
      10.18.*
      172.18.*
      iwb*
      192.168.1.1
      svatdss302.at.dc.eb-grp.net
      *.sd.spardat.at
      sslvpn.smxs.net
      *.mainframe.lan.at
      45.0.222.*
      45.0.223.*
      *.nwm.lan.at*
      server.wan.at
      10.0.222.*
      10.0.223.*
      45.14.1.*
      45.0.42.*
      archer.erste-group.net
      <local>

The settings (with Chrome v66) are:
----------------------------------
Effective proxy settings
PAC script: http://pac.s-mxs.net/
Source: SYSTEM                                <--- HERE
Original proxy settings
(1) PAC script: http://pac.s-mxs.net/
(2) Proxy server: proxy-sd.s-mxs.net:8080
    Bypass list: 
      *:5985
      *:5986
      sip.s-mxs.net
      sipweb.s-mxs.net
      *.scall.at
      anywhere.s-mxs.net
      10.18.*
      172.18.*
      iwb*
      192.168.1.1
      svatdss302.at.dc.eb-grp.net
      <local>
      *.sd.spardat.at
      sslvpn.smxs.net
      *.mainframe.lan.at
      45.0.222.*
      45.0.223.*
      *.nwm.lan.at*
     server.wan.at
      10.0.222.*
      10.0.223.*
      45.14.1.*
      45.0.42.*
      archer.erste-group.net
Source: SYSTEM                                <--- HERE


The <local> entry is on a different position, which I suppose does not matter.

But there are also two lines with "Source: SYSTEM". 
This is maybe an important difference, but I dont know, what these two lines mean.
Maybe I accidentally altered the configuration somehow and therefore lost them.

My questions now:
1. What means the "Source: SYSTEM" entry?
2. How can this entry be configured?

Regards, Gerhard

#7 "Source" is just where Chrome found the setting. So "SYSTEM" means it found it in your system settings (it can also get it via DHCP and some other ways). I'm not sure why it's not displayed in Chrome v67. Assigning to lilyhoughton@ who touched this code recently to try to find out why.

Chrome normally uses the system proxy settings. So you can just open your proxy configuration in your system settings, or go to Chrome's settings and click on "Open proxy settings", which should do the same thing.

Can you attach your PAC script (http://pac.s-mxs.net/) ?

My expectation is your PAC script is incorrectly routing requests based on the URL rather than the host (and in doing so, is making a different decision for url="https://127.0.0.1" vs "wss://127.0.0.1").

Regarding the absence of "Source: SYSTEM" --> that information was removed in 67, and will not have a bearing on the outcome of the proxy decision. Don't worry about it being different.

Regarding the long list of bypass list --> that is not relevant here, as the PAC script is being used instead. The joy of proxy settings is such that the server + bypass list is merely a fallback for when the PAC file can't be fetched, and not an additive.

I expect what is happening is that the PAC script is wrong, and returning "PROXY proxy-sd.s-mxs.net:8080;DIRECT" for "wss://localhost/", when really you want it to be returning "DIRECT". The proxy server is then failing the CONNECT.

This problem would manifest itself to you as a regression between M66 and M67, since in M66 a failure in establishing a tunnel to the proxy server would result in a fallback to the next proxy option, which in your case is DIRECT.

Sadly, in Chrome 67 the policy was changed such that a failure in establishing a tunnel to the proxy server is no longer consider a retryable error ( Issue 815239 ), so if my suppositions in this analysis are correct this bug is a WontFix.

Hi eroman!

Thank you a lot for the insight you gave me about PAC scripts!
I was not aware of the fact that the local configured proxy bypass is only a fallback after the PAC script.

What you said, makes perfect sense and matches all of my observations!

I investigated the PAC script myself and - as you said - localhost is always DIRECT, 127.0.0.1 is prefixed with the https:// protocol, but wss:// is missing completely. So the proxy is returned for wss://127.0.0.1

Our PAC script was changed a few months ago at our side, so maybe half of the problem was introduced at that time.
Currently I'm out of office. I will double check this with our PROXY-department on Monday and arrange for a fix.

I can see that a policy change from v66 to v67 "not to automatically fall back to DIRECT" makes sense from a browser's point of view.
Too bad, I was not aware of such a change prior and there are lot of differences how different browser vendors try to resolve local loopback addresses. 

But regarding  issue 815239 :
I would have assumed (naive) that when the PAC script returns multiple options, all of these options are tried.
The PAC script would always be able to return no secondary option; preventing DIRECT. (Am I wrong?)


Thank you both (eroman + ricea) for helping and the time you spent to analyse this problem.

Kind Regards, Gerhard

Thanks for the follow-up!

> I would have assumed (naive) that when the PAC script returns multiple options,
> all of these options are tried.
> The PAC script would always be able to return no secondary option; preventing
> DIRECT. (Am I wrong?)

In a PAC script, one can differentiate whether a fallback to DIRECT is desired or not by including DIRECT in the proxy list, and this has not changed. For instance:

// Use a direct connection if connection to proxy fails.
return "PROXY foo:80; DIRECT";

Vs:

// Use the proxy. If it can't be reached, the entire request will fail with
// ERR_PROXY_CONNECTION_FAILED.
return "PROXY foo:80";


The full rules for PAC and proxy evaluation are complicated. There are some other fallbacks, but they aren't too relevant here. For instance if the PAC script doesn't return a proxy list (for instance it throws an exception) there is an implicit fallback to DIRECT. Or if the PAC script fails to be downloaded, there is an implicit fallback to the manually provided proxy server + bypass list.

In Chrome that is configurable by using what is called a "mandatory" PAC script, which will not silently tolerate failures. This is only accessible via Chrome extensions API, as there isn't anything equivalent in Windows's system proxy settings.

 Issue 815239  is a different beast, see the thread for more details. I can't say the use-case is sound, but it is the fallback policy that other browsers apply.