IP, Port, Username, Password: What Your Proxy Line Actually Means

Somebody handed you a line that looks like this:

198.51.100.7:8080:hp_ir4k2:9fa2c1

No labels, no instructions, and four boxes on screen waiting for something. That line already contains everything you need. It is confusing because it was written to be stored, not to be read: four values on one line so a thousand of them fit in a text file. This page splits it up, shows the shapes different tools want, and covers the password characters that quietly break it.

The four parts

Reading left to right:

The host is where the proxy lives: an IP address like 198.51.100.7 or a name like res.hproxy.com. Both work the same way.

The port is a number between 1 and 65535 that says which service on that machine you want. 8080, 3128 and 1080 are common, but the number is whatever your provider runs, and only they know it.

The username and password are the login for the proxy itself, almost never your account login on the provider's website.

The colons are not part of any value. They are separators.

The same proxy, written three ways

The four values never change, but tools insist on different orders, which is why a proxy that works in one place seems broken in another. Our dashboard hands out the first two shapes, the Premium console adds the URL shape and a CSV export, and our free proxy formatter converts a whole list between them in your browser:

The http:// at the start of the third shape describes how your software talks to the proxy, not what you browse. curl's manual spells out the prefixes: none or http:// means an ordinary HTTP proxy, which also carries https:// sites; https:// means a TLS connection to the proxy itself, which an ordinary proxy does not speak, so that line fails; socks5:// and socks5h:// pick SOCKS5, and with socks5h the proxy looks up the site's name instead of your computer.

Which screen or tool wants which shape

Chrome's row surprises people most. Its own documentation says that most systems' proxy settings can store a user name and password, and that "Chrome does not implement this, and will not use any credentials embedded in the proxy settings." It asks for the login instead. When Chrome is driven by code, Puppeteer's page.authenticate hands it over. For SOCKS5 there is no login in Chrome at all: the same documentation says "No authentication methods are supported for SOCKSv5 in Chrome", so a SOCKS5 line with a user name and password needs the provider's HTTP port, or an address allowlist, before Chrome can use it.

Special characters in the password

This is the failure that looks most like a dead proxy. In the URL forms, @ separates the login from the address and # starts a part of the URL that gets cut off, so a password containing either one breaks the line before any connection is made. The URL standard, RFC 3986, allows only letters, digits, a few symbols and : in the login part; everything else has to be percent-encoded. curl's manual: user and password in the proxy string "are URL decoded by curl. This allows you to pass in special characters such as @ by using %40 or pass in a colon with %3a."

We tested it with the curl that comes with Git for Windows, pointing at an address where nothing listens, so no request left the computer:

To encode a whole password at once, JavaScript's encodeURIComponent('p@ss#w:rd') gives p%40ss%23w%3Ard, and Python's urllib.parse.quote('p@ss#w:rd', safe='') gives the same. Encode only the user name and password, never the whole line. The errors you see without it are specific: curl says Unsupported proxy syntax ... Bad hostname, git says Couldn't resolve proxy '123@ipaddress' (the end of the password, taken for the address), and Python's requests says Please check proxy URL. It is malformed and could be missing the host.

Our free proxy setup generator does this for every place at once: paste the line in either form and each setting gets the password the way it reads it, encoded in curl and the shell variables, as typed in a Mac command or a settings screen.

The colon form needs no encoding for @ or #, because nothing in it is a URL. It has its own edge: a careful reader splits at the first three colons and treats everything after the third as the password, which is what our dashboard does. A tool that splits at every colon breaks on a password containing one; for that tool, use the URL form with %3A.

One more edge: if the proxy's address is itself an IPv6 address, the colon form cannot work, because the address is full of colons. The URL form puts it in square brackets, as RFC 3986 requires: http://hp_ir4k2:9fa2c1@[2001:db8::10]:8080.

Quoting the line in a terminal

Shells change some characters before a program ever sees them. In Bash and zsh, double quotes keep every character literally "with the exception of $, `, \" and, interactively, !; so a password like P@$$1234 inside double quotes reaches curl as something else. Single quotes keep every character as typed. PowerShell works the same way: a single-quoted string "is passed to the command exactly as you type it. No substitution is performed."

curl -x 'http://hp_ir4k2:P%40%24%241234@198.51.100.7:8080' https://www.cloudflare.com/cdn-cgi/trace

Single quotes plus percent-encoding cover both layers. Keep logins out of what other people can read, too: curl's manual warns that a password in a command line can be seen by other users of the same machine and recommends reading it from a file, and the requests documentation calls storing it in an environment variable or a file under version control "a security risk".

When there's no username and password

A two-part line is not a broken four-part line:

Open proxies, the kind on free lists, have no login, so there is nobody to log in as. If a screen offers a password option, leave it off. Paid proxies without a password usually mean address authorisation: you give the provider your own IP address, they allow it, and the proxy accepts you without a login. That is convenient until your home address changes, at which point everything stops at once and looks like an outage.

As for the many searches for a free proxy with a username and password: a login exists because someone controls who may use that proxy. A free line that comes with one is either a provider's trial, handed to you on purpose, or someone else's paid access that was never meant to be shared. Our free proxy list has no logins for exactly that reason: every entry is an open proxy, re-tested by opening a real connection to it.

When the username carries your settings

On a rotating residential gateway, the username often grows words:

user-country-de-city-frankfurt

That is not corruption. The targeting rides in the username: every request goes to one host and port, res.hproxy.com:8080 on HProxy, and the words after your login say which country, and on Premium which state, city or network, the exit should come from. So you never change the host or port to change country; only the username changes.

Without a session, a rotating gateway gives you a different exit on every request, which is what you want for spreading requests out and what breaks a login, because the site sees you jump between addresses mid-session. A sticky line adds one more part to the username that holds the same exit for the length you chose. You don't type these by hand: pick a country and a session length in the dashboard and it writes the finished line. Knowing what the words mean helps when you read a line back and wonder why it behaved as it did.

HTTP or SOCKS5, and why the port changes

HTTP proxies carry web traffic: a browser or library asks the proxy for a page, or for a tunnel to an https:// site. This is what browsers and most setup guides assume.

SOCKS5 is lower level and moves any TCP connection, so it also works for things that are not web pages: mail, SSH, game clients. Some SOCKS5 proxies carry UDP too, where the provider supports it.

The same proxy usually runs each on a different port, and there is no way to work out one from the other; your provider tells you both. Pointing SOCKS5 software at the HTTP port gives a connection that hangs or is refused, which looks exactly like a dead proxy. If you leave the port out altogether, curl assumes 1080, as the picture above shows.

If you don't know which you need, use HTTP. Reach for SOCKS5 when a tool asks for it by name, or for traffic that is not web pages.

Where to actually type it

Test the line before you trust it

A dead proxy and a mistyped one produce the same symptom: a page that spins and loads nothing. Paste the line into our proxy checker first. It opens a real connection and reports whether the proxy answers, its protocols, anonymity, country and latency, which separates "this proxy is dead" from "I put the port in the wrong box" before you change anything.

Mistakes that look exactly like a dead proxy

A special character in the password

An @, #, / or ? in the URL forms, unencoded. The fix and the exact errors are above.

The port in the address box

The most common one. The address box takes the host alone.

No port at all

The tool picks one for you. curl picks 1080.

https:// or http:// in an address box

A field labelled "address" or "server" wants the bare host. Scheme prefixes belong only in the one-box URL form.

The wrong protocol for the port

SOCKS5 selected, HTTP port entered. The connection hangs, and nothing in the error mentions protocols.

A space or line break copied with the password

Copying a password out of an email or a chat can pick up a trailing space or line break; the proxy rejects the login while the string looks perfect on screen. Retype the password once by hand.

Account login instead of proxy login

Your dashboard login and your proxy login are different. The wrong one gives 407 Proxy Authentication Required, which at least names the problem.

Mistakes other guides make

• "Escape a colon in the password with --user-special." curl has no such option; it is not in curl's manual.
• "Put the proxy URL in double quotes to handle special characters." Quotes do not stop an @ from ending the login, and double quotes let the shell expand $. Percent-encoding and single quotes do the job.
• "Firefox ignores the system proxy." Firefox's default is to use it.
• https:// in front of an ordinary proxy. That prefix means a TLS connection to the proxy itself.

The short version

A proxy line is four values with colons between them. The order changes between tools; the values don't. In the URL forms, encode @, # and friends in the password, and quote the line with single quotes in a terminal. Extra words in the username are settings, not damage. And when a proxy fails, check that it is alive before you check your typing, because the two look the same from the outside.

How we wrote this

We read curl's manual, RFC 3986, the documentation of Python's requests, Puppeteer and Chromium's proxy notes, and the Bash and PowerShell quoting rules on 3 October 2026, and our own dashboard code for the shapes HProxy hands out. The real errors come from Stack Overflow and Super User, where people paste them word for word. The terminal picture is our own test with curl 8.16.0 against an address where nothing listens, so no request left the computer.

Limits: we measured curl only; git's, Python's and apt's behaviour comes from their documentation and the questions' error lines. Other tools may split the colon form their own way.

Sources

All read on 3 October 2026.

• curl manual: --proxy, --proxy-user and the proxy prefixes (curl.se).
• RFC 3986, Uniform Resource Identifier: sections 3.2.1 and 3.2.2 (rfc-editor.org).
• Requests documentation, Advanced Usage: Proxies and SOCKS (requests.readthedocs.io).
• Chromium: Proxy support in Chrome, net/docs/proxy.md (chromium.googlesource.com).
• Puppeteer: Page.authenticate() (pptr.dev).
• GNU Bash manual: Single Quotes, Double Quotes (gnu.org); PowerShell: about_Quoting_Rules (learn.microsoft.com).
• HProxy: the rotating residential page (hproxy.com/rotating-residential-proxies) and our dashboard's line formats.
• Stack Overflow questions 6172719, 9282186, 76800250, 61937317 and 72016277; Super User question 106467.
• Our test with curl 8.16.0, 3 October 2026.