# Chromium proxy tunnel error lab

This download reproduces `net::ERR_TUNNEL_CONNECTION_FAILED`,
`net::ERR_PROXY_CONNECTION_FAILED` and the neighbouring Chromium proxy errors
on your own machine. Every "proxy" is a tiny Node.js server on `127.0.0.1`
with one deliberate behaviour (closed port, silent socket, CONNECT answered
403/407/429/502/503, tunnel dropped after 200, and so on). The destination is a
local self-signed HTTPS server plus one plain HTTP server. No proxy account,
credentials or outbound traffic beyond package installation is needed.

The same failures are driven through three clients so you can compare what each
one reports: Playwright (its own `proxy` option), Puppeteer (raw Chromium
`--proxy-server` flags and `page.authenticate`) and curl (`-x` with the
`%{http_connect}` write-out).

`results.json` is the recorded run behind the guide at
https://ipvolt.com/guides/fix-err-tunnel-connection-failed. It was produced on
17 September 2026 with Node.js 24.20.0, Playwright 1.63.0 (Chromium
153.0.8010.12), puppeteer-core 25.11.0 and curl 8.18.0 on Linux. Those are
dated observations for those versions, not a promise about future releases.

## Run the lab

Requirements: Node.js 20 or newer, `openssl` on the PATH (used once to create a
throwaway self-signed certificate for the local destination), and curl.

```sh
npm install
npx playwright install chromium
npm run lab
```

The script prints one JSON line per case and writes `results.json` in the
current directory. Puppeteer cases are skipped automatically if
`puppeteer-core` is not installed; they reuse the Chromium that Playwright
downloaded, so no second browser download is needed.

Each case launches a fresh browser with the proxy bypass list set to
`<-loopback>`, which makes Chromium send loopback destinations through the
proxy. Without that rule raw Chromium bypasses `127.0.0.1` and `localhost`
silently; one Puppeteer case demonstrates exactly that. The destination uses a
self-signed certificate, so the browser cases ignore destination certificate
errors. That setting only affects the destination TLS check inside the tunnel;
it has no effect on how Chromium talks to the proxy.

## What the fixtures are not

They are HTTP/1.1 forward proxies written for one purpose each. They do not
model a specific provider's gateway, rate limiting, IP allow-listing, TLS
proxies or SOCKS5. Use the recorded error strings to recognise the failure
stage in your own logs, then confirm the actual proxy status with curl against
your real gateway, as the guide describes.