Looks like an issue with the proxy to me.  We connect to the proxy, negotiate a SOCKS5 proxy connection to ebay, send the request, get what look like correct ebay response headers back, and then get a a couple hundred body bytes (When the site works, it should be closer to 50k, from a local test).  The proxy hangs up on use 30 seconds later, without sending any more data.

Since the proxy is showing permissions errors, that reinforces the theory that this is a server issue.  Without evidence this is a Chrome problem, I don't think this is worth investigating further.

Well there are no issues with non-chromium browsers. This was also working before on older versions of chromium, and no changes have been made to the proxy configuration. 2/3 working browsers suggests there's at least some chrome-specific issue.

I was looking at wireshark (I'm not sure how detailed the chrome net dumps are) and it looked like the browser sends a packet with the FIN/ACK flags mid stream, then stops responding to the proxy packets, which would explain why the proxy stops sending data... From what I've read, sshd throws that error around somewhat loosely so it's not very helpful.

I can provide the packet dump later today.

You note failures on random-looking hosts like gdfqrefvtwloa -- those are being generated by https://cs.chromium.org/chromium/src/chrome/browser/intranet_redirect_detector.cc?q=intranet+package:%5Echromium$&l=82. The log messages are probably benign, however maybe they are affecting your proxy state?

* Your log is from a Chromium build -- have you tried with Chrome builds (i.e. Stable/Beta/Dev/Canary) ?
https://www.google.com/chrome/browser/canary.html
https://www.google.com/chrome/browser/beta.html

* Are you using the proxy as SOCKSv5 in the other browsers? To my knowledge IE and Edge don't support v5 SOCKs, which implies your test using Edge is actually doing v4.

Some experiments you can try:

(1) Try using it as a SOCKSv4 proxy instead:  --proxy-server=socks4://67.231.30.151:1963    (Don't pass the --host-resolver-rules as you will be doing the DNS resolves locally). I realize this isn't what you want, but try it as an experiment to see if it works.

(2) Try using SOCKSv5 as before, but preventing the intranet redirect detector requests from going through the proxy. Unfortunately they can't be disabled, but you can use a PAC script to prevent them from hitting the proxy which should be sufficient to diagnose if they are the culprit:

Save this to a file, say pac.js:

function FindProxyForURL(url, host) {
  if (host.indexOf(".") == -1)
    return "PROXY 0.0.0.0";
  return "SOCKS5 67.231.30.151:1963";
}

Then launch Chrome with:

--proxy-pac-url=file:///C:/Users/foobar/Desktop/pac.js    (Update path to match where you saved it.

If that doesn't work, then try tweaking the PAC script to be even more restrictive so it only accepts the subset of traffic you want to test.

Got an email from my provider saying there were "connectivity issues" that are now resolved. The symptoms have gone away, so I suspect that was the underlying problem.

A few extra observations:
Safari exhibited the same behavior as chrome (making Firefox the odd one out; Edge is in fact socks4 only).
Socks4 worked on all chrome browsers despite the connectivity issue

I'm not sure why firefox handled the issue more gracefully.

One theory is that there was a problem affecting only udp traffic (hence socks4 having no issues), and firefox either falls back to tcp or doesn't support whatever udp based protocol (quic?) had issues. This would else explain a site to site dependence, since not all servers support it.

Its not unreasonable for the browser to fail under such conditions, so this issue could be closed. That being said, it is interesting that firefox survived, and someone may want to dig deeper to find out exactly why and make chrome more immune.

Thank you for providing more feedback. Adding requester "ajha@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

Sounds like your proxy endpoint had a DNS outage, which explains why doing the resolutions locally (and using SOCKS v4 in Chrome) worked whereas SOCKS v5 in Chrome didn't.

As far as why Firefox's behavior was different, probably your Firefox was doing local DNS resolutions (even though using a v5 proxy). This is configurable in Firefox through network.proxy.socks_remote_dns. Whereas in Chrome we operate as if socks_remote_dns were always True for v5, and off for v4 (v4a of the protocol does support remote resolutions)

Firefox can be configured to do local DNS resolutions when using a SOCKS v5 proxy, whereas Chrome will always just do remote resolutions when selecting SOCKS v5. (Vanilla v4 doesn't support remote resolution, however v4a does; that said, Chrome abandoned support for v4a in favor of v5 if you want remote DNS)