Proxy IP and Port: Which Format Does Your App Need?

Some apps want IP:port. Others need a URL beginning with http:// or socks5://. Browser settings often put the address and port in different fields. The same endpoint can therefore appear in several formats without its address changing.

An IPv4 entry

Suppose an HTTP proxy list gives you the example HTTP proxy 203.0.113.10:8080.

Do not include the port twice. If the app already has a port box, putting 203.0.113.10:8080 into the host box can make it try to resolve the whole string as a hostname. Similarly, do not add a scheme to a field that explicitly expects only an IP address.

The scheme must match the service. Choose HTTP or SOCKS5 according to client support before converting the address. Writing socks5:// in front of an HTTP endpoint changes what the client sends; it does not enable SOCKS5 on that server.

IPv6 needs brackets in a URL

An IPv6 address already contains colons, so a URL encloses the address in square brackets before adding the port:

http://[2001:db8::10]:8080
socks5://[2001:db8::10]:1080

Without the brackets, the boundary between address and port is ambiguous. An app with separate fields usually wants 2001:db8::10 as its host and 8080 as its port; follow that app's input format. Both addresses used here are documentation examples, not live proxies.

Parse URLs rather than splitting every colon

A small Python script can handle IPv4 and bracketed IPv6 URLs with the standard URL parser:

from urllib.parse import urlsplit

proxy = urlsplit("http://[2001:db8::10]:8080")
print(proxy.scheme)
print(proxy.hostname)
print(proxy.port)

The hostname property returns the address without the brackets. Splitting the original string on every colon would break this example. In a real importer, also reject missing hosts, unsupported schemes, and ports outside 1–65535. Parsing a URL gives you its components; it does not prove that the service exists.

When the list includes a username and password

A common URL layout is http://username:password@host:port. Characters such as @, #, and / inside credentials need proper URL encoding. If the client offers separate credential fields, using those fields is usually easier than hand-building a URL.

Check the provider's original format before converting a colon-separated credential string. There is no universal meaning for four fields separated by colons, and a password can itself contain a colon. A parser designed for plain IP:port lines should not quietly guess its way through a different format.