Support authenticated SOCKS5/SOCKS4 proxies in Chrome/Edge (via a small built-in relay)

[SAKMZ]

Problem

SeleniumBase already handles authenticated HTTP/HTTPS proxies really well (the runtime chrome-proxy extension built in proxy_helper.create_proxy_ext). But authenticated SOCKS5/SOCKS4 proxies can't work in Chrome/Edge at all:

• Chromium silently ignores SOCKS credentials passed via --proxy-server, and
• webRequest.onAuthRequired never fires for SOCKS, so the extension approach doesn't help either.

So today Driver(proxy="socks5://user:pass@host:1080") fails with ERR_NO_SUPPORTED_PROXIES / ERR_EMPTY_RESPONSE. This comes up fairly often (e.g. #3832 and various discussions), because a lot of residential/mobile providers only hand out authenticated SOCKS5 endpoints.

Proposal

When the configured proxy is an authenticated SOCKS proxy, SeleniumBase could transparently start a tiny local, no-auth HTTP relay that forwards through the upstream SOCKS proxy, and point the browser at 127.0.0.1:<port> (cleaning it up on driver.quit()). Everything else — including the existing HTTP-auth extension path and IP-authenticated SOCKS — stays exactly the same.

The relay is ~150 lines of standard-library asyncio (no new dependencies). I've already built and battle-tested this as a small standalone MIT library, and I'd be happy to contribute a trimmed, SOCKS-only version:
https://github.com/SAKMZ/selenium-proxy-tools

Rough wire-in:

# browser_launcher, where the proxy string is normalized:
if proxy_is_socks_with_auth(proxy_string):
    relay = start_socks_relay(proxy_string)   # stdlib asyncio, daemon thread
    proxy_string = relay.local_addr           # "127.0.0.1:<port>"
    register_cleanup(relay.stop)              # on driver.quit()/atexit

On Windows the relay uses SelectorEventLoop so shutdown stays clean, and it does remote DNS (no DNS leaks).

A few questions before I open a PR

1. Would you welcome this in-tree, or would you rather point users to an external helper?
2. Preferred home — extend proxy_helper.py, or add a new proxy_relay.py?
3. Any constraints I should keep in mind (the relay is happy on Python 3.7+)?

Happy to open a PR along these lines (with a local SOCKS5-auth test, no network needed) if it's of interest. Thanks for SeleniumBase! 🙌

[mdmintz]

Hello! It's already possible: SeleniumBase lets you spin up a local proxy server with SOCKS5 & auth in one console/terminal window, and then you can connect to it without auth in a separate console/terminal window. Instructions for that:

Open two windows.

1. In one window, run sbase proxy --plugins proxy.plugin.ProxyPoolPlugin --proxy-pool=USER:PASS@IP:PORT --log-level=WARNING with your proxy settings.
2. In the other window, run your script, which should set proxy="127.0.0.1:8899".
   Then you no longer need to do auth through your web browser, and that should avoid issues with SOCKS5 proxies.

[zzzz0902zzzz-rgb]

One constraint worth baking in, from our own experience with an intermediary proxy layer (not from SeleniumBase): a local relay sitting between browser and upstream must be timeout- and buffering-transparent.

We ran long-polling behind a gateway and it broke exactly this way — proxy_read_timeout had to be strictly larger than the app's wait timeout, and proxy_buffering had to be off. Otherwise the client's wait returned empty immediately and looked like "nobody is talking"; with buffering on, the relay holds the response until a buffer fills, which turns one held response into a stalled connection.

For your SOCKS relay that means:

1. keep it a transparent byte pump — don't parse or normalize HTTP bodies;
2. no per-connection read/idle timeout shorter than the upstream's longest hold (SSE, long polls, websockets) — and make that timeout a parameter, not a constant;
3. flush streaming/chunked bodies as they arrive, no response-side buffering threshold;
4. expose max-conns / idle-limit through the helper rather than hardcoding them, so the host can align them.

A ~5 min test that catches all of it: point the relay at an endpoint that holds the connection open N seconds, and confirm the client receives the body once, at ~N s — not instantly, not never. Then kill the upstream mid-hold: you want an error, not an empty 200.

On Q3, I'd state the constraint as "the relay must be timeout-transparent" rather than a Python floor.