net-internals log for when it fails attached.

Deleted: net-internals-log.json 4.8 MB

net-internals-log.json 4.8 MB View Download

And the net-internals log with the --winhttp-proxy-resolver flag

Deleted: net-internals-log --winhttp-proxy-resolver flag.json 5.6 MB

net-internals-log --winhttp-proxy-resolver flag.json 5.6 MB View Download

It looks like without the command line setting, the later request was unable to do session pooling. However, there was a HTTP2_SESSION created earlier but got deleted before the session pooling due to read error. It might be the connect job with proxy doing something different for the two cases. 

I don't see any obvious differences in resolved proxy in those logs. In Comment #1's log was it in a failure state when you finished logging?

- Are you able to attach your PAC script? (i.e. http://wpad/wpad.dat).
- What happens if you change the system settings to rather than using auto-detect checkbox, to explicitly use the PAC URL  http://wpad/wpad.dat

Yes, by the end of Comment #1's log I had no internet through Chrome.

.dat file attached, I'll try and test using the PAC URL explicitly later.

Deleted: wpad.dat 349 bytes

wpad.dat 349 bytes Download

Thanks for the data.

I don't see anything in the logs that confirms the description "Proxy server reverts to DIRECT connection" (comment #0).

What I am seeing from the logs is that in both the --winhttp-proxy-resolver and the default case, the proxy server "10.104.150.1:800" is being used for all requests [1]

This is consistent with the PAC script, and I believe the expected behavior.

At some point however, the proxy server stops working. Chrome is still sending requests to it, however in the log without command line flag it fails with ERR_PROXY_CONNECTION_FAILED. There is no fall-back to DIRECT connections specified by proxy settings so it just fails.

For whatever reason the --winhttp-proxy-resolver test case does not hit this case, however it appears to be calling out to the proxy server in the same way AFAICT.

Does this happen consistently? Is it possible to reproduce the same thing with  --winhttp-proxy-resolver ?

As for why the proxy server starts dropping stuff I don't know. It is relying on NTLM so maybe something goes wrong on the authentication. Or maybe there is a particular request that trips it up, or too many open connections.

Can you reproduce with other browsers?

[1] Technically there are a few exceptions for the single-component hostnames

iphonejs@: Could you respond to the questions in c#6?  We need more information to keep making forward progress on this bug.

Thank you for providing more feedback. Adding requester "eroman@chromium.org" for another review and adding "Needs-Review" label for tracking.

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

Thanks for all the comments. As I'm not experiencing this issue site wide, I'll close the case, and reopen should it occur elsewhere.

I may have also been a bit quick to end the logging, which is perhaps why the error doesn't appear.

Thanks again for your help.

Also, I can't seem to replicate the issue anymore, so it could be a chrome update, extension update or a change to our Smoothwall that's solved the issue completely.

If you are able to reproduce again, and gather the data again, let me know.

Until then I will consider this closed.