Some proxies fail on the browser's first request, while Chromium does not support SOCKS5 username-and-password authentication directly. This article explains both cases and the built-in relay that handles them.
A browser opens an HTTP proxy tunnel with a CONNECT request and normally includes the Host. Some proxy servers hang when they receive this header: they neither complete nor close the connection, leaving the tab loading indefinitely. It looks as if the proxy is down, even though curl can reach the same endpoint.
The built-in relay sits between Chromium and the proxy and rewrites the request into a form the server accepts. Chromium talks to the relay over plain local HTTP; the relay sends the external request without the problematic header.
Chromium supports SOCKS5 only without a username and password because its proxy authentication path is not implemented. A proxy written as socks5://user:pass@host:1080 will not work directly in any browser built on this engine.
The relay opens a local endpoint without credentials, authenticates to the external proxy itself and keeps the username and password outside Chromium. The browser receives 127.0.0.1, while the relay establishes a fully authenticated session with the external proxy:
NimbusX checks the proxy country, city and time zone before starting a profile. If the proxy location conflicts with the profile, launch stops and explains the values that do not match.
America/New_York with a European IP address, so iphey correctly returned Unreliable. Location is now resolved before the test run, so each generated profile starts with coherent settings.Bring your own HTTP, HTTPS or authenticated SOCKS5 proxy. The relay starts automatically and handles both failure modes described above without a separate utility or manual setup.
What open checks show · Profiles from code and AI tools