Somebody handed you a line that looks like this:
198.51.100.7:8080:hp_ir4k2:9fa2c1
No labels, no instructions, and four different boxes on screen waiting for something. That line already contains everything you need. It's confusing because it was written to be stored, not to be read: four values crammed onto one line so a thousand of them fit in a text file.
The four parts
One proxy line, four separate values
198.51.100.7Host:8080Port:hp_ir4k2Username:9fa2c1Password198.51.100.7:8080:hp_ir4k2:9fa2c1hp_ir4k2:9fa2c1@198.51.100.7:8080http://hp_ir4k2:9fa2c1@198.51.100.7:8080
The colon-separated shape used by most proxy sellers, including HProxy's dedicated proxies. Values shown are examples.
Reading left to right:
The host is where the proxy lives. It's either an IP address like 198.51.100.7 or a hostname like gate.example.com. Both work the same way. Nothing else about the line changes depending on which one you got.
The port is a number between 1 and 65535 that says which door on that machine to knock on. One server can run many services, and the port is how it knows you want the proxy rather than something else. You'll see 8080, 3128, 1080 and 80 constantly, but the number is arbitrary and only your provider knows the right one.
The username and password are the login for the proxy itself. They're almost never your account login for the provider's website. Providers generate a separate pair, because the proxy is a different system from the dashboard.
The colons aren't part of any value. They're separators, so four things fit on one line and a thousand proxies fit in one text file.
The mistake that costs people the most time
An address box wants 198.51.100.7 and nothing else. Pasting 198.51.100.7:8080 into it fails on almost every platform, because the software takes the whole thing as a hostname and goes looking for a machine literally called that. The port has its own box. Every time.
The same proxy, written three ways
The four values never change, but the order does, and different tools insist on different orders. That's why a proxy that works in one place appears broken in another. All three lines below describe exactly the same proxy:
Pick the shape your tool asks for
198.51.100.7Host:8080Port:hp_ir4k2Username:9fa2c1Password198.51.100.7:8080:hp_ir4k2:9fa2c1hp_ir4k2:9fa2c1@198.51.100.7:8080http://hp_ir4k2:9fa2c1@198.51.100.7:8080
All three are the same proxy. Converting between them is pure rearranging, with nothing added or lost.
If your software gives you one text box and calls it a proxy URL, it wants the third shape, with http:// on the front. If it gives you four labelled fields, it wants them filled in individually and you can ignore the joined-up versions entirely.
One detail that trips people up: the http:// at the start of a proxy URL describes how you talk to the proxy, not what you're browsing. You use http:// proxy URLs to visit HTTPS websites all day long. Writing https:// there instead is almost always wrong and will usually fail to connect.
When there's no username and password
A two-part line is not a broken four-part line:
A public proxy, complete with two parts
203.0.113.42Host:3128PortThe shape every free proxy list uses. Open proxies have no login at all.
Free and public proxies have no authentication. There's nobody to log in as. If you're working from a free list and something demands a username, leave those fields empty and untick any "this proxy requires a password" option. A free proxy that asks you for credentials isn't offering you access, it's someone's private proxy that happens to be reachable.
Paid proxies without a password usually mean the provider uses IP authorisation instead: you tell them your own IP address, they add it to an allow list, and then the proxy accepts you with no login. That's convenient until your home IP changes, at which point everything stops working at once and looks like an outage.
We publish a free proxy list and we're blunt on every page of it: each entry is tested by opening a real connection, and the uptime you see is measured rather than promised. Free proxies still die constantly. That's fine for a quick look at a page from another country, and a bad foundation for anything you depend on.
When the username carries your settings
This is the part almost nobody explains, and it's the one that makes people think their proxy is malformed. On a rotating residential plan, your username often looks like this:
hp_ir4k2-country-us-city-chicago-session-a41f9c-time-1800
That's not corrupted. Those extra words are instructions, and the provider reads them out of the username at connection time. It's a neat trick: instead of publishing thousands of different addresses, one for each country and city, the provider gives you a single address and lets you steer it with text.
What the extra words in a rotating username mean
| Modifier | What it does |
|---|---|
-country-us | Send this connection out through an IP in the United States. Uses two-letter country codes. |
-state-california | Narrow it further to one state or region. |
-city-chicago | Narrow it to a single city, where the provider has coverage there. |
-session-a41f9c | Keep me on the same exit IP. Reuse the same session id and you keep the same IP; change it and you get a new one. |
-time-1800 | How long that session should last, in seconds. 1800 is thirty minutes. |
The modifier grammar HProxy residential plans use. Your dashboard writes these for you.
Two things follow from this, and both matter.
Without a session modifier, a rotating gateway gives you a different IP on every single request. That's exactly what you want for spreading requests around, and exactly what breaks a login, because the site sees you jumping between countries mid-session. Anything with a shopping basket or a signed-in account needs a session id.
And because the settings live in the username, you never change the host or the port to change country. The address stays identical. Only the username grows.
You don't normally type these by hand. Pick a country and a session length in the dashboard, and it builds the finished line for you. Knowing what the words mean matters when you're reading a line back and working out why it behaved the way it did.
HTTP or SOCKS5, and why the port changes
Most proxies speak two languages, on two different ports.
HTTP proxies understand web traffic. They read the request, see which site you want, and fetch it. This is what browsers use by default and what the great majority of setup guides assume.
SOCKS5 is lower level and doesn't care what you're sending. It moves raw connections, so it works for things that aren't web traffic at all: game clients, torrent traffic, mail, SSH. It also handles UDP, which HTTP proxies can't.
The practical consequence is short. The same proxy uses a different port for each, and there's no way to work out the SOCKS5 port from the HTTP one. Your provider tells you both. Setting your software to SOCKS5 while pointing it at the HTTP port produces a connection that hangs or refuses, and that looks identical to a proxy that's simply dead.
If you don't know which you need, use HTTP. Reach for SOCKS5 when a tool asks for it by name, or when you're proxying something that isn't a web page.
Where to actually type it
Once you know which four values you have, the rest is finding the right screen:
From a line of text to a working connection
- 1
Decide whether you want one app or the whole computer proxied
A system proxy covers everything that follows the system setting, which on Windows and macOS includes most browsers. Firefox, most games, torrent clients and command line tools ignore it and need configuring on their own.
- 2
- 3
Send one request and look at the IP that comes back
If the address you see is the proxy's rather than your own, it's working. If nothing loads at all, the proxy is almost certainly offline rather than misconfigured.
Test the line before you trust it
There's a reason to check a proxy before you put it into anything: a dead proxy and a mistyped proxy produce exactly the same symptom, which is a browser that spins forever and loads nothing. Once you're staring at that, you can't tell which mistake you made.
Our proxy checker opens a real connection to the address you paste, and reports whether it answered, which protocols it spoke, where it exited and how long it took. Thirty seconds there separates "this proxy is dead" from "I put the port in the wrong box", and those two problems have completely different fixes.
Five mistakes that look exactly like a dead proxy
A trailing space on the password. Copying a credential out of an email or a chat message picks up a space or a newline surprisingly often. The proxy rejects the login, your software reports a generic failure, and the string looks perfect on screen. If a proxy fails on first use, retype the password by hand once before assuming anything else.
The port in the address box. Covered above, and worth repeating because it's the most common one by a distance.
http:// typed into an address field. A field labelled "address" or "server" wants the bare host. Scheme prefixes belong only in the single-box URL form.
The wrong protocol for the port. SOCKS5 selected, HTTP port entered. Connection hangs. Nothing in the error message mentions protocols.
Account credentials instead of proxy credentials. Your provider dashboard login and your proxy login are different accounts. Using the wrong one gives you 407 Proxy Authentication Required, which at least names the problem clearly.
The short version
A proxy line is four values with colons between them, and the colons mean nothing. The order changes between tools, the values don't. Extra words in the username are settings rather than damage. And when a proxy fails, check that it's alive before you check that you typed it correctly, because those two failures look the same from the outside and only one of them is your fault.