Chrome proxy errors: what each code means, and how −111 differs from −130

The main pair: −130 versus −111

The names look alike, the stages do not, and neither do the fixes. ERR_PROXY_CONNECTION_FAILED means the proxy was never reached: the source comment describes it as an error resolving its name or connecting a socket to it — and explicitly says this does not include failures during the CONNECT method itself.

ERR_TUNNEL_CONNECTION_FAILED is the opposite case: the proxy is reachable, the connection to it is up, but the CONNECT tunnel did not come up. In the source, every place this code is returned sits downstream of a successful proxy connection: a malformed status line, extraneous data after the headers, any CONNECT response other than 200 or 407.

The table

Values are checked against net_error_list.h on Chromium's main branch. Tying them to a browser version is neither needed nor wise: the file changes over time, with codes added and removed, so what is given here is the date of the check rather than a version number.

# Checked against net_error_list.h in main, 17 August 2026.
# Every value is negative — there is no "error 130".
#
# VISIBLE ON THE ERROR PAGE
  ERR_PROXY_CONNECTION_FAILED        -130   never reached the proxy: the name did
                                            not resolve or the socket did not open
  ERR_TUNNEL_CONNECTION_FAILED       -111   the proxy answered, the tunnel did not
  ERR_PROXY_CERTIFICATE_INVALID      -136   the HTTPS proxy's certificate is invalid
  ERR_PROXY_AUTH_UNSUPPORTED         -115   the proxy offered an auth scheme Chrome
                                            does not implement
  ERR_UNEXPECTED_PROXY_AUTH          -323   a 407 arrived although the request did
                                            not go through a proxy
  ERR_MANDATORY_PROXY_CONFIGURATION_FAILED
                                     -131   a mandatory PAC could not be fetched,
                                            parsed or executed
  ERR_EMPTY_RESPONSE                 -324   the connection closed without any data
  ERR_CONNECTION_REFUSED             -102
  ERR_CONNECTION_RESET               -101
  ERR_CONNECTION_TIMED_OUT           -118
  ERR_NAME_NOT_RESOLVED              -105
#
# NEVER REACHES THE PAGE
  ERR_PROXY_AUTH_REQUESTED           -127   intercepted and turned into the
                                            credential prompt
  ERR_NO_SUPPORTED_PROXIES           -336   internal; the source comments say
                                            outright it should not be user visible

The page shows the name, not the number

Chrome prints the symbolic name in the ERR_SOMETHING form on the error page and never the number. So searching by number is useless and the name is what to paste — which is what people do. The numbers are useful elsewhere: they do not move when wording changes, which makes them a stable anchor when reading logs.

One more detail: ERR_PROXY_CONNECTION_FAILED has its own page, headed as a lack of internet, with the line that something is wrong with the proxy server or the address is incorrect. ERR_TUNNEL_CONNECTION_FAILED has no page of its own and lands on the generic “This site can't be reached” screen. The absence of a specific message does not make the error any less specific.

Two codes you will not see

ERR_PROXY_AUTH_REQUESTED never reaches a page: it is intercepted and replaced by a credential request, so the user sees a login prompt instead. A curious detail — dismiss that prompt and the request finishes as ERR_TUNNEL_CONNECTION_FAILED. Which means some share of −111 complaints are simply a cancelled password dialog.

ERR_NO_SUPPORTED_PROXIES is marked in the source itself as a code that should not be user visible. If it does surface somewhere, it is about internal protocol-selection logic rather than about your configuration.

What Chrome does when a proxy fails

A popular misconception is worth dispelling here. Chrome does not silently go direct when a proxy fails: with a single configured proxy, every request simply fails with ERR_PROXY_CONNECTION_FAILED. Going direct happens only when DIRECT is itself listed in the proxy list — and then it is the next entry in that list, not an invented fallback.

Only connection-level failures move Chrome to the next proxy: the proxy's name failing to resolve, or a TCP socket failing to connect. A failed tunnel is not among them — it used to be, and the behaviour was changed because it broke deployments where a proxy intentionally refuses some requests.

The one case of a silent direct connection

It exists, just not where people look for it. If a PAC script is in use and could not be fetched, proxy resolution silently falls back to direct. The exception is a PAC marked mandatory: then requests fail with ERR_MANDATORY_PROXY_CONFIGURATION_FAILED. So if traffic unexpectedly bypassed the proxy, look at the PAC rather than at the proxy.