← Back to Blog
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

Proxy with Username and Password in Unauthenticated Software: Local Gateway on gost, 3proxy, Squid, and proxychains

The program only asks for the address and port, but the proxy has a username and password? Set up a local gateway: gost with one command, 3proxy with a port for each profile, Squid with logging, or proxychains-ng for software without proxy support. Commands, configs, and errors that cause the real IP to leak.

📅October 11, 2026
Proxy with Username and Password in Unauthenticated Software: Local Gateway on gost, 3proxy, Squid, and proxychains

You bought a proxy, received a string like login:password@host:port, but the program only asks for "address and port." A familiar situation: Chrome with the flag --proxy-server, system settings in Windows and Android, an old parser, Selenium grid, a utility without a password field. The solution has been the same for many years — local gateway: a small proxy on your own machine that accepts connections without a password and automatically inserts the login when connecting to the actual proxy. We will examine four proven tools, commands for each, and the common mistakes that usually waste time and money.

Why programs "don't understand" proxies with passwords

There are two ways to authenticate with a proxy provider: by username and password (Basic Auth) or by IP whitelist. The second option eliminates the problem but only works if you have a static external IP — home internet and mobile networks often lack this, and cloud functions change with each launch. We compared both methods in detail in the proxy authentication guide.

With a username and password, we run into the limitations of the programs themselves:

  • Chrome and Chromium. The flag --proxy-server according to Chromium documentation accepts a scheme, host, and port (for example, --proxy-server="foopy:8080") — there are no fields for credentials in this syntax. In a regular browser window, it will show a password dialog, but in headless mode and in automated tests, there is no one to fill it out.
  • System settings. In the manual proxy settings of Windows and in the Wi-Fi settings on most Android firmware, there are only host and port. A password may be requested by a specific application, but there is nowhere to enter it.
  • Old and custom software. Many utilities and libraries support proxies, but without authentication, or they break on special characters in the password.
  • Programs without proxy support at all. Console utilities that do not read environment variables or settings.

The local gateway covers all four cases: the program sees the proxy 127.0.0.1:8080 without a password, and the gateway forwards the traffic to the provider with the login.

How the scheme works

  1. A lightweight proxy server is launched on your machine (or VPS where the parser runs) and listens on a local port, for example, 127.0.0.1:8080.
  2. The gateway's configuration specifies the "parent" (upstream) proxy — the provider's address, username, and password.
  3. The program connects to the local port without authentication.
  4. The gateway opens a connection to the provider, authenticates, and forwards the traffic. To the website, you appear with the provider's IP address, not your own.

HTTPS is not decrypted: through the HTTP proxy, the browser establishes a tunnel using the CONNECT method, and the gateway simply forwards the encrypted bytes.

Option 1: gost — one command, no configs

gost (GO Simple Tunnel) is a single executable file written in Go for Windows, macOS, and Linux. This is the fastest way to set up a gateway. In gost, the flag -L specifies the local service, and -F specifies the node through which to forward traffic. Credentials are specified directly in the node address:

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

Now any program can use the HTTP proxy 127.0.0.1:8080 without a password. If the password contains special characters (@, :, #), the gost documentation suggests passing them through the auth parameter in base64:

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<base64_result>

Note: if auth is specified, the username and password written directly in the address are ignored by gost. Multiple -F flags in succession create a chain of multiple proxies.

When to use: when you need to quickly "connect" one browser or script to a proxy, without installing packages and editing configs.

Option 2: 3proxy — multiple ports on one machine

3proxy is a compact proxy server with a configuration in a single file. The key directive is parent; according to the documentation, its syntax is: parent <weight> <type> <ip> <port> <username> <password>, and it must be placed after the allow rule. The minimal configuration for the gateway:

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

What’s important here:

  • auth iponly — no password, but with ACL checking; the rule allow * 127.0.0.1 only allows local connections.
  • The weight 1000 means "always through this parent." Weights below 1000 are used by 3proxy to build random chains.
  • Parent type: http, connect, socks4, socks5, and others — choose the protocol provided by your provider.
  • -i127.0.0.1 binds the service to the local interface. By default, 3proxy accepts connections on all interfaces.

A convenient trick: repeat the block allow / parent / proxy several times with different ports and different provider accounts. This way, you get "port = separate proxy": 127.0.0.1:8081 — USA, :8082 — Germany, and so on. This format is understood by almost any software, including those where proxies are entered as a list of "host:port."

When to use: when you have dozens of profiles or streams, each needing its own exit.

Option 3: Squid — if you need caching and logging

Squid is heavier, but it provides caching, detailed logs, and flexible ACLs. The provider is specified as a parent node via cache_peer, and the directive never_direct allow all prevents Squid from accessing the internet directly, bypassing the parent:

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Details from Squid documentation:

  • The ICP port is set to 0 if the parent does not support it — commercial proxies do not have it.
  • In login=, URL-escape sequences are allowed (for example, %20 for space), so the character % in the password must be written as %%.
  • Without never_direct, Squid may decide that it’s more beneficial to go directly to the site — and the request will go out with your real IP. This is the worst scenario for scraping and multi-accounting.

When to use: in an office or team where logging who accessed what is needed, or for repeated requests to the same resources.

Option 4: proxychains-ng — for programs without proxy support

If a program does not support proxies at all, proxychains-ng (Linux and macOS) can help. It intercepts the network calls of the program and wraps its TCP connections in a proxy. SOCKS4a, SOCKS5, and HTTP are supported, with authentication — username and password for SOCKS and Basic for HTTP. The line in the [ProxyList] section has the format type ip port [username password]:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

To run: proxychains4 curl https://api.ipify.org — the response will show the provider's IP, not yours.

  • strict_chain — all proxies in the list are used in order, and if one is unavailable, there will be no connection. It’s safer than dynamic_chain, which skips dead nodes.
  • proxy_dns — DNS requests also go through the proxy. Without this, your internet provider can see which domains you are requesting, and the site may notice a mismatch between the DNS geolocation and the IP.
  • The config is searched in order: the file from -f or the variable PROXYCHAINS_CONF_FILE, then ./proxychains.conf, ~/.proxychains/proxychains.conf, and /etc/proxychains.conf.

Limitations noted by the authors themselves: only TCP (UDP and ICMP are not proxied), possible failures with programs that spawn many processes, and on macOS, SIP protection does not allow intercepting system programs.

Which tool to choose: a quick reference

  • One browser or script, need it "right now" — gost.
  • Many profiles, each with its own IP or country — 3proxy with a separate port for each account.
  • Team, request log, cache — Squid.
  • Program with no proxy settings at all — proxychains-ng.

Five mistakes that cost the most

  1. The gateway listens on all interfaces. If you run gost with -L http://:8080 on a VPS — you get an open proxy for the entire internet on your gigabytes. Open proxy scanners find them quickly. Always specify 127.0.0.1, and if other machines use the gateway — close the port with a firewall. We wrote about how quickly botnets find open ports on servers with parsers in our analysis of the CARBONATO worm.
  2. Leakage bypassing the gateway. Squid without never_direct, proxychains without proxy_dns, a browser that accesses via WebRTC/UDP directly — all of this reveals your real IP. Check the result on an IP detection service and a DNS leak test.
  3. One gateway for all accounts. If 30 anti-detect profiles are looking at one port with one sticky session, everyone will have the same IP — this is a direct path to account linking. Spread profiles across ports or use session parameters from the provider.
  4. Special characters in the password. @ and : break the parsing of addresses like login:pass@host. Use the base64 parameter in gost, escaping in Squid, or generate a password without special characters.
  5. The gateway is an extra hop and point of failure. On a local machine, the delay is almost zero, but if the gateway is in another data center, each request adds network latency. Keep the gateway close to the program and set it to auto-start (systemd, Windows service), otherwise, after a server reboot, the parser will quietly go nowhere.

Which proxies to use behind the gateway

The gateway does not care what type of proxy is behind it — the choice depends on the task:

  • Residential proxies — for scraping protected sites, marketplaces, and anti-detect profiles: IPs of home users raise fewer suspicions with anti-bots.
  • Mobile proxies — for social networks and applications where checks are the strictest: many real subscribers usually go online through one mobile operator's IP (via CGNAT), and blocking it is risky for the platform itself.
  • Datacenter proxies — for large tasks without strict protection: availability checks, APIs, tests. The cheapest per gigabyte.

If the proxy has rotation, the logic for changing IPs is usually set by the provider — through parameters in the login or settings in the dashboard. The gateway does not break this: it passes the login as is. Therefore, it is convenient to set up several ports with different session parameters — one with a new IP for each request, another with a fixed IP for 30 minutes.

Conclusion

A proxy with a username and password works with any program if you place a local gateway between them. gost solves the task with one command, 3proxy is convenient for "port = profile," Squid is for teams with logging, and proxychains-ng connects even software that knows nothing about proxies. The main rules: listen only on 127.0.0.1, prohibit direct connections bypassing the parent, and check that the site sees the provider's IP, not yours.