Proxy Formats: ip:port:user:pass, URL and SOCKS5 Syntax

A proxy format is the order in which a proxy’s host, port, username, password and protocol are written on a single line. The three most common forms are host:port:user:pass (the dashboard and list format), user:pass@host:port and http://user:pass@host:port (the URL format). A SOCKS5 proxy uses the same URL with the socks5:// or socks5h:// scheme.

The information is the same in every form; only the order and the separator change. Trouble starts because most programs expect just one of these forms: cURL and Python want a URL, antidetect browsers accept the four-part line, and Windows and Android only show a host field and a port field. The examples below use the WeProxy gateway address gw.weproxy.com.tr:8989; USER and PASSWORD are the credentials from your dashboard.

What is a proxy format and what parts does it have?

A proxy connection is described by at most five pieces of information. The host is the proxy server’s domain name or IP address (gw.weproxy.com.tr, 203.0.113.10). The port is the number the server listens on (8989). A username and password are needed if the proxy authenticates that way. The protocol tells the client how to talk to the proxy (http, socks5).

Host and port are required in every format. Without credentials, the line stays as host:port, and the proxy authorizes you by the IP address the connection comes from (IP whitelist). Most formats leave the protocol out, so the client falls back to its own default. Many tools read a line without a scheme as an HTTP proxy. If you pass a SOCKS5 proxy without a scheme, the connection opens, but the first request fails with a protocol mismatch error.

The HTTP vs SOCKS5 article explains how the two protocols differ and which one fits which job. Whichever you pick, you have to tell the program about it, either through the scheme or through a separate dropdown.

How do you read the ip:port:user:pass format?

ip:port:user:pass (or host:port:user:pass) is the form you’ll see most often in proxy lists. The four fields are separated by colons:

gw.weproxy.com.tr:8989:USER:PASSWORD
203.0.113.10:8989:USER:PASSWORD

This form pastes easily into spreadsheets, text files and the bulk import boxes of antidetect browsers. Its weak spot is that the separator can also appear inside the data. If the password contains a :, the line splits into five parts, and which part means what is left to the program’s assumptions. IPv6 addresses are already written with :, so in this form they can only be read inside square brackets ([2001:db8::10]:8989:USER:PASSWORD).

Some providers give the same four fields in a different order: user:pass:host:port or host:port@user:pass. The program won’t guess the order from your list. It checks whether the second field is a number and treats it as the port; if the password is all digits, the misread goes through without an error and you end up with a 407. Confirm the order of your list by looking at the host and port in the first line.

URL format: how do you write http://user:pass@host:port?

The URL form follows the generic address syntax defined in RFC 3986:

scheme://username:password@host:port
http://USER:[email protected]:8989

The scheme describes the protocol of the proxy server, and the target site’s protocol has nothing to do with it. If you’re reaching an HTTPS site through an HTTP proxy, the proxy address still starts with http://. The client sends a CONNECT request to the proxy, and the TLS connection is set up inside that tunnel. The https:// scheme means the client will speak TLS with the proxy server itself; if the proxy doesn’t offer that, the connection drops during the handshake.

The scheme-less user:pass@host:port form is also common. Most programs read it as an HTTP proxy, but not every tool accepts it. Python libraries such as requests and httpx expect a full URL with a scheme. Library-specific examples are in the Python proxy guide.

In cURL, you pass the URL to the -x option. To keep the credentials out of the address, use -U:

curl -x "http://USER:[email protected]:8989" https://api.ipify.org
curl -x "http://gw.weproxy.com.tr:8989" -U "USER:PASSWORD" https://api.ipify.org

According to the cURL documentation, a -x value without a scheme is treated as an HTTP proxy, and if the port is missing, 1080 is assumed. Always write the port explicitly; otherwise the request goes to the wrong port and you get Connection refused.

How do you write a SOCKS5 proxy? socks5 vs socks5h

A SOCKS5 proxy URL looks the same as an HTTP one; only the scheme changes:

socks5://USER:[email protected]:8989
socks5h://USER:[email protected]:8989

The two schemes differ in where the domain name gets resolved. socks5:// resolves the target domain on your machine and sends the IP address to the proxy. socks5h:// passes the domain to the proxy as is, and DNS resolution happens on the proxy side. With the second form, your DNS queries don’t leave your local network, and the target is resolved according to the proxy’s country. Details are in the DNS leak guide.

curl -x "socks5h://USER:[email protected]:8989" https://api.ipify.org

In SOCKS5, the username and password are sent through a separate subnegotiation (RFC 1929), while an HTTP proxy carries the same information in the Proxy-Authorization header. The way you write the format stays the same for both protocols. SOCKS4 has no password field and only carries a user ID, so writing a proxy that has a username and password as socks4:// throws the authentication away.

Most WeProxy products offer HTTP and SOCKS5 together. Mobile proxy endpoints support HTTP only, so if you write that product with socks5://, the connection won’t open. Protocol support is listed in the technical specifications table on each product page.

Proxy formats compared

If you’re writing code, stick with the URL form: it carries the protocol, it has a standard parsing rule, and percent-encoding solves the special character problem. When you’re sharing a list or adding proxies in bulk to an antidetect browser, host:port:user:pass is more practical.

Which tool expects which proxy format?

Browser automation tools ask for credentials separately from the URL by design. Chrome’s --proxy-server flag doesn’t accept a user:pass@ part. Playwright takes the proxy as an object:

const browser = await chromium.launch({
  proxy: {
    server: 'http://gw.weproxy.com.tr:8989',
    username: 'USER',
    password: 'PASSWORD',
  },
})

The Playwright documentation treats a scheme-less host:port value as an HTTP proxy. Chrome on its own doesn’t support SOCKS5 proxies with a username and password, so for authenticated proxies in Chrome automation, use the HTTP scheme. The full setup with page.authenticate() in Puppeteer is on the Puppeteer integration page.

The system-wide proxy screens in Windows and Android only take a host and a port. If you enter a proxy that requires authentication there, some apps prompt for the password and others reject the connection without asking. Step-by-step setup is in the Windows and Android guides on the integrations page.

How do you write a password with special characters or an IPv6 address?

In the URL form, @, :, /, #, ? and % have special meanings. If your password contains any of them, write it with percent-encoding:

For example, if your password is p@ss:9, the URL becomes http://USER:p%40ss%[email protected]:8989. An unencoded @ makes the client treat the rest of the password as the host name, and you get either an unresolvable address error or 407 Proxy Authentication Required. Rather than encoding by hand, use your programming language’s built-in function:

from urllib.parse import quote

password = quote("p@ss:9", safe="")  # p%40ss%3A9
proxy = f"http://USER:{password}@gw.weproxy.com.tr:8989"

Percent-encoding only applies to the URL form. If you put %40 in a host:port:user:pass line, most programs send it as the literal characters of the password. In tools with separate username and password fields (Playwright, Proxifier, antidetect browsers), always enter the password as is, without encoding.

IPv6 addresses go inside square brackets in a URL, because the address’s own : characters get mixed up with the port separator:

http://USER:PASSWORD@[2001:db8::10]:8989

Without brackets, the client takes the last colon in the address as the port separator. The IPv4 vs IPv6 article covers which sites work with IPv6 proxies.

How do you convert a proxy list from one format to another?

When you need to turn a host:port:user:pass list from the dashboard into URLs for a script, the proxy format converter converts the lines in bulk. It recognizes four input forms (scheme://user:pass@host:port, user:pass@host:port, host:port:user:pass, host:port) and writes them out in the format you choose. The conversion runs in your browser, and the list isn’t sent to a server.

The tool follows these rules:

• Lines without a scheme are converted to URLs with http://. If you’ll use SOCKS5, change the scheme in the output.
• In URL output, the username and password are percent-encoded; in host:port:user:pass output, they stay as they are.
• In a four-part line, the second field is read as the port. Put a list that comes in user:pass:host:port order into the right order first.
• The tool doesn’t recognize lines with the socks5h:// scheme and adds them to the “skipped” count. You can convert those lines as socks5:// and change the scheme back in the output.

To do the same in a script, keep in mind that the password may contain : and split the line at most three times:

from urllib.parse import quote

def to_url(line: str, scheme: str = "http") -> str:
    host, port, user, password = line.strip().split(":", 3)
    return f"{scheme}://{quote(user, safe='')}:{quote(password, safe='')}@{host}:{port}"

print(to_url("gw.weproxy.com.tr:8989:USER:PASSWORD"))
# http://USER:[email protected]:8989

split(":", 3) splits at the first three separators, so any : characters inside the password stay in the last part. This approach doesn’t work with IPv6 hosts; handle those lines separately.

Proxy format errors and how to fix them

A badly written proxy line rarely produces a clear “format error”. The problem shows up at a different stage of the connection, under a different name:

To check whether a line is correct independently of your code, paste it into the proxy checker. A line that works in the checker but fails in your program means the problem is in the format or in the program’s proxy settings. You can check the exit IP’s country and network with the My IP tool. The proxy error codes guide goes into which layer each HTTP status code comes from and how to retry temporary errors.

Proxy lines with credentials are passwords. Don’t share them in screenshots, support tickets or public repositories; read them from environment variables in code, and remove the password from the URL before sharing logs. Whatever you use a proxy for, the target site’s terms of use, its robots.txt file, and KVKK and GDPR obligations still apply. Permitted uses of WeProxy services are listed on the acceptable use page. To compare rotating and static IP options, see the rotating residential proxy and static datacenter IPv4 pages.