Fixing net::ERR_NO_SUPPORTED_PROXIES

Chrome takes a proxy as scheme, host and port, nothing else. A login in the flag or socks5h:// fails at once, and SOCKS5 with a login doesn't work at all.

5 min readTested on Chrome 156 · Puppeteer 25.16 · Playwright 1.64
Chrome refuses a proxy login inside --proxy-server and the socks5h scheme with ERR_NO_SUPPORTED_PROXIES; SOCKS5 without a login fails to connect; HTTP with page.authenticate works.--proxy-server=… and what Chrome 156 answerssocks5://USER:PASS@…:11000ERR_NO_SUPPORTED_PROXIEShttp://USER:PASS@…:9000ERR_NO_SUPPORTED_PROXIESsocks5h://…:11000ERR_NO_SUPPORTED_PROXIESsocks5://…:11000ERR_SOCKS_CONNECTION_FAILEDhttp://…:9000 + page.authenticate()200Puppeteer 25.16 · Chrome 156 · Playwright 1.64 · October 22, 2026

In short

Remove the username and password from --proxy-server and write socks5://, not socks5h://. For a proxy that needs a login, use its HTTP port with page.authenticate(): Chrome can’t send a SOCKS5 login at all. If it has to be SOCKS5, put a local forwarder in between.

--proxy-server=http://host:portpage.authenticate()

--proxy-server takes a scheme, a host and a port. Anything Chrome can’t turn into a proxy it knows makes every request fail before a connection is even tried, with this error in Puppeteer:

txt
Error: net::ERR_NO_SUPPORTED_PROXIES at https://ipinfo.io/json

We launched Chrome 156 through Puppeteer with each value against our gateway (SOCKS5 on port 11000, HTTP on 9000):

--proxy-serverLoginResult
socks5://USER:PASS@…:11000in the flagnet::ERR_NO_SUPPORTED_PROXIES
http://USER:PASS@…:9000in the flagnet::ERR_NO_SUPPORTED_PROXIES
socks5h://…:11000page.authenticate()net::ERR_NO_SUPPORTED_PROXIES
socks5://…:11000page.authenticate()net::ERR_SOCKS_CONNECTION_FAILED
socks5://…:11000nonenet::ERR_SOCKS_CONNECTION_FAILED
http://…:9000nonenet::ERR_INVALID_AUTH_CREDENTIALS
http://…:9000page.authenticate()200
Fig. 1 — Puppeteer 25.16, Chrome 156.0.8078.47, October 22, 2026.

A login in the flag

Chrome doesn’t read credentials out of --proxy-server, for HTTP or SOCKS. It rejects the whole value instead of ignoring the login. Keep the flag to http://host:port and hand the login over separately.

socks5h is a curl word

socks5h:// tells curl and Python to let the proxy resolve hostnames. Chrome doesn’t know the scheme and refuses it. Write socks5://: Chromium’s proxy documentation says it hands hostnames to a SOCKS5 proxy to resolve anyway.

No login over SOCKS5

With a clean socks5://host:port Chrome connects, the proxy asks for a username and password, and Chrome has none to give: ERR_SOCKS_CONNECTION_FAILED. page.authenticate() doesn’t help, it only answers HTTP proxies. Over HTTP the same login works, which is why the last row is the only one that loads. More Puppeteer proxy errors.

Playwright doesn’t get as far as a navigation. Given a SOCKS5 proxy with a username, it refuses to launch the browser, and not only Chromium:

launch failschromium, firefox, webkit · { server: 'socks5://…:11000', username, password }Browser does not support socks5 proxy authentication
goto failschromium · { server: 'socks5://USER:PASS@…:11000' }net::ERR_SOCKS_CONNECTION_FAILED
200chromium · { server: 'http://…:9000', username, password }HTTP takes the login

Selenium drives the same Chrome and hits the same wall; what works there.

Two setups that work

Both ran unchanged with Node 24 against our gateway. PROXY_USER and PROXY_PASS come from the environment.

1. Use the HTTP port

The simplest fix when the provider has one. The login goes through page.authenticate(), never into the flag.

http_login.mjs
import puppeteer from "puppeteer"; // npm i puppeteer

// No SOCKS needed: the HTTP port takes the login through page.authenticate().
const browser = await puppeteer.launch({ args: ["--proxy-server=http://via.proxies.vision:9000"] });
try {
  const page = await browser.newPage();
  await page.authenticate({ username: `${process.env.PROXY_USER}-country-de`, password: process.env.PROXY_PASS });
  await page.goto("https://ipinfo.io/json");
  console.log(await page.evaluate(() => document.body.innerText));
} finally {
  await browser.close();
}

2. Keep SOCKS5, add a local forwarder

proxy-chain opens a proxy on 127.0.0.1 without a login and forwards everything to the SOCKS5 proxy with it. Chrome only ever sees the local address.

socks_forwarder.mjs
import puppeteer from "puppeteer";
import { anonymizeProxy, closeAnonymizedProxy } from "proxy-chain"; // npm i puppeteer proxy-chain

const user = encodeURIComponent(`${process.env.PROXY_USER}-country-de`);
const pass = encodeURIComponent(process.env.PROXY_PASS);

// Chrome takes no login in --proxy-server and none at all for SOCKS5.
// proxy-chain opens a local proxy without a login that forwards to ours with it.
const local = await anonymizeProxy(`socks5://${user}:${pass}@via.proxies.vision:11000`);

const browser = await puppeteer.launch({ args: [`--proxy-server=${local}`] });
try {
  const page = await browser.newPage();
  await page.goto("https://ipinfo.io/json");
  console.log(await page.evaluate(() => document.body.innerText));
} finally {
  await browser.close();
  await closeAnonymizedProxy(local, true);
}
playwright_forwarder.mjs
import { chromium } from "playwright";
import { anonymizeProxy, closeAnonymizedProxy } from "proxy-chain"; // npm i playwright proxy-chain

const user = encodeURIComponent(`${process.env.PROXY_USER}-country-de`);
const pass = encodeURIComponent(process.env.PROXY_PASS);

// Playwright refuses SOCKS5 with a username in every browser; hand it a local proxy instead.
const local = await anonymizeProxy(`socks5://${user}:${pass}@via.proxies.vision:11000`);
const browser = await chromium.launch({ proxy: { server: local } });
try {
  const page = await browser.newPage();
  await page.goto("https://ipinfo.io/json");
  console.log(await page.innerText("body"));
} finally {
  await browser.close();
  await closeAnonymizedProxy(local, true);
}
txt
{
  "city": "Köln",
  "country": "DE",
  …

Targeting stays in the username, as anywhere else. For the same exit IP across pages, add a session and use the sticky port: USER-country-de-session-job1-lifetime-10 on 12000 for SOCKS5, 10000 for HTTP.

What does net::ERR_NO_SUPPORTED_PROXIES mean?
Chrome couldn't use the proxy you gave it at all. In our tests that happened for three values of ‑‑proxy-server: a username and password inside it (socks5://user:pass@host:port or http://user:pass@host:port) and the scheme socks5h://. Chrome accepts only scheme, host and port there.
Does Chrome support SOCKS5 with a username and password?
No. Without the login in the flag, Chrome 156 connected to the SOCKS5 port, the proxy asked for credentials Chrome doesn't send, and the page failed with net::ERR_SOCKS_CONNECTION_FAILED. page.authenticate() only answers HTTP proxies. Use the proxy's HTTP port, or a local forwarder.
Why does Playwright say 'Browser does not support socks5 proxy authentication'?
Playwright checks before launching: a socks5 proxy with a username is refused for Chromium, Firefox and WebKit alike (Playwright 1.64). Use the HTTP port with username and password, or point Playwright at a local forwarder that adds the login.
What is the easiest fix?
If your provider has an HTTP port, use it: ‑‑proxy-server=http://host:port plus page.authenticate() in Puppeteer, or proxy: { server, username, password } in Playwright. If it must be SOCKS5, run proxy-chain's anonymizeProxy(), which opens a local proxy without a login and forwards to yours with it.

Residential proxies, pay per GB

HTTP and SOCKS5. Country, city and sticky sessions in the username. No subscription.