When Your Proxy Needs a Password and Your Software Can't Send One

You bought a proxy. It came with four values, all of them correct, and half your software has nowhere to put two of them. That is not your fault or your provider's: a lot of software was built for proxies that a company runs on its own network, where nobody needs a login.

This page shows where a proxy login cannot go, then four fixes, each from documentation rather than guesswork: an address allowlist, the program's own setting, our Chrome extension, and a local relay.

Where the login cannot go

Two rows come straight from the makers. Microsoft's own steps for Windows ask for "the proxy server name or IP address and port" plus optional exceptions, and nothing else. Chrome's documentation says that most systems' proxy settings can hold a username and password, and that "Chrome does not implement this, and will not use any credentials embedded in the proxy settings." The last row is old but telling: Google once described its Drive app as supporting "all unauthenticated proxies that are configured by the operating system", and the accepted answer for its users was a relay on their own machine.

Fix one: an address allowlist

Most providers, including us, let you swap the password for your own IP address. You add the address you connect from in the dashboard, and the proxy then accepts you with no login at all. On HProxy, the Premium plan takes up to 150 addresses. Your proxy line drops to two parts:

Every program on this page then works, because there is nothing to authenticate: Windows stops asking, Chrome's flag works, apps without login fields work.

The catch is real. Home connections change address, after a router restart or whenever the provider decides. When yours changes, everything stops at once, and it looks like a dead proxy rather than a login problem. An allowlist is right for a server or an office line with a fixed address, and a chore on a laptop that moves between networks.

Fix two: the program's own proxy setting

Many programs handle a proxy login perfectly well on their own; use their setting rather than the system's:

• Firefox follows the system proxy by default, as its source code shows, and asks for the proxy login in its own window. It also has its own proxy settings. See the Firefox guide.
• curl, package managers and your own code take the login in the proxy URL, http://user:pass@host:port, with special characters such as @ or # percent-encoded: curl, Python, Node.js, Go, PHP. The proxy format guide shows the encoding.
• Tools built around proxies, such as scrapers and multi-profile browsers, usually have their own proxy fields; our integrations pages show where each one takes the line.

If everything you use is in this list, you don't have a problem.

Fix three: Chrome with our extension

For Chrome, our free Chrome extension takes your proxy line in almost any shape, host:port:user:pass, user:pass@host:port or socks5://..., and connects Chrome through it; when the proxy asks Chrome for a login, the extension answers. As its store listing puts it, the password never leaves your browser: "the login goes only to the proxy it belongs to." The listing names HTTP, HTTPS, SOCKS4 and SOCKS5 proxies.

When code drives Chrome, Puppeteer's page.authenticate() hands Chrome the login, since --proxy-server will not take it.

One limit no extension can lift: Chrome's own documentation says "No authentication methods are supported for SOCKSv5 in Chrome". A SOCKS5 proxy that needs a login cannot work in Chrome at all; use the provider's HTTP port for the same proxy, an address allowlist, or a relay (below) that logs in for Chrome.

Fix four: a local relay

This is the one that works when nothing else does. You run a small proxy on your own computer that needs no password. It listens on 127.0.0.1, which only your own computer can reach, and forwards everything to your real proxy with the login attached. Your programs talk to 127.0.0.1:8080 and never learn that a login exists.

With gost, one command does it. Its manual shows forwarding to a proxy with a login as -F=http://user:pass@host:port; keep the listening side on 127.0.0.1:

gost -L=127.0.0.1:8080 -F=http://hp_ir4k2:9fa2c1@203.0.113.10:8080

gost forwards to SOCKS5 proxies too (-F=socks5://...), so it can bridge a SOCKS5 proxy into programs that only speak HTTP, which Windows' own proxy layers cannot: Microsoft lists SOCKS5 support as no for both of them. gost's original repository says it has been superseded by go-gost/gost, so check the newer one's syntax before relying on it.

With Squid, the proxy you may already run, a parent proxy takes the login in cache_peer:

http_port 127.0.0.1:3128
cache_peer 203.0.113.10 parent 8080 0 no-query default login=hp_ir4k2:9fa2c1
never_direct allow all
http_access allow localhost
http_access deny all

never_direct allow all sends everything through the parent, and the two http_access lines answer only your own computer. Squid's manual adds one trap: the login string can carry URL escapes, "this also means % must be written as %%".

Then point Windows, Chrome's flag or any program with only an address box at 127.0.0.1 and the relay's port.

Our free proxy setup generator writes both relays for your own line, the gost command and the Squid configuration, with the login escaped the way each one reads it.

Which fix to pick

Before you blame authentication

These produce the same symptoms and are more common:

The wrong login. Your dashboard login and your proxy login are different. The wrong one, or none, gets 407 Proxy Authentication Required, HTTP's code for "authenticate yourself to this proxy first".

A special character in the password. In a proxy URL, a raw @ or # breaks the line before any login is sent; the proxy format guide shows curl's exact errors and the fix.

A space copied with the password. Copying out of an email or a chat can pick up a trailing space; the string looks perfect and the login fails. Retype it once by hand.

A dead proxy. A dead proxy and a rejected login look the same from inside a stalled browser. Paste the line into our proxy checker first: it opens a real connection and reports whether the proxy answers, which separates the two problems before you change anything.

Mistakes other guides make

• "HTTP proxies do not support authentication." HTTP's standard, RFC 9110, defines the Proxy-Authorization header and the 407 code for exactly that.
• "SOCKS5 makes your data unreadable in transit." Its username and password method sends the password in clear text, as its own standard, RFC 1929, warns.
• "Firefox ignores the Windows proxy." Its default is to use the system proxy.

How we wrote this

We read Microsoft's own Windows proxy steps and its WinINet and WinHTTP comparison, Chromium's proxy documentation, HTTP's standard (RFC 9110) and the SOCKS5 login standard (RFC 1929), the Squid and gost manuals, Firefox's source and Puppeteer's documentation on 3 October 2026, plus our own extension's store listing and our plans page. The real cases come from Super User, where people describe programs that could not log in. The open-proxy count is our own free list's capture of 2 October 2026.

Limits: we did not install or run the relays; their settings come from their manuals. Which sync clients or games take a proxy login today was not tested one by one, and Google's statement on Drive is the one quoted on Super User in 2012.

Sources

All read on 3 October 2026.

• Microsoft Support: Use a proxy server in Windows; Microsoft Learn: WinINet vs. WinHTTP.
• Chromium: Proxy support in Chrome, net/docs/proxy.md (chromium.googlesource.com).
• RFC 9110, HTTP Semantics: sections 11.7.2 and 15.5.8; RFC 1929, Username/Password Authentication for SOCKS V5 (rfc-editor.org).
• Squid manual: cache_peer, never_direct, http_access (squid-cache.org); gost README (github.com/ginuerzh/gost).
• Firefox: StaticPrefList.yaml (github.com/mozilla-firefox/firefox); Puppeteer: Page.authenticate() (pptr.dev).
• HProxy: the Chrome Web Store listing of our extension; hproxy.com/rotating-residential-proxies.
• Super User questions 416845, 469200, 663093, 225784, 510586 and 448184.