A Port Is a Door Number, Not a Protocol#
When a provider hands you gateway.example:7000, the 7000 is a TCP port: a 16-bit number, 1 to 65535, that tells the operating system which listening program on that host should receive the connection. That is all a port is. It does not declare what language the program behind it speaks, whether it wants HTTP proxy requests or a SOCKS5 handshake, or whether anything is listening at all. Two facts have to line up for a proxy to work, and the port is only one of them: the right program must be listening on that port, and your client must speak the protocol that program expects.
This is the single most common source of proxy configuration pain. A setting labelled "port" sits next to a setting labelled "type" or "protocol," and it is easy to get the number right and the protocol wrong, or to assume a well-known number implies a particular protocol. It does not. The conventions exist and they are useful, but they are habits, not rules the network enforces. The rest of this guide separates the conventions worth knowing from the mismatches worth recognizing, and then reproduces both with a local proxy you can run.
The Numbers You Will Actually See#
A handful of port numbers recur across proxy documentation because tools and providers copied each other for decades. Knowing them saves time, as long as you remember they predict a likely protocol, never a guaranteed one. The IANA service-name registry assigns some of these formally and leaves others as pure convention.
| Port | Usual association | What it actually guarantees |
|---|---|---|
| 8080 | HTTP proxy (and HTTP servers generally) | Nothing; it is the most overloaded port in the list |
| 3128 | HTTP proxy (Squid's default) | Nothing; a habit inherited from Squid |
| 1080 | SOCKS proxy | Nothing; the historical SOCKS convention |
| 8888 | HTTP proxy (many gateways, debuggers) | Nothing; popular alternate |
| 80 / 443 | Plain HTTP / HTTPS | The web ports; some providers front proxies here to survive restrictive firewalls |
| Provider-specific (7000, 10000, ...) | Whatever the provider documents | Only what the provider's own documentation says |
The practical takeaway: read the provider's documentation for the pairing of port and protocol, and treat the conventional numbers as a memory aid rather than a contract. A gateway can serve HTTP proxying on 1080 or SOCKS5 on 8080 if its operator chose to, and some deliberately use 80 or 443 so the traffic looks like ordinary web browsing to a firewall. The HTTP versus SOCKS5 guide covers how the two protocols differ once you are speaking the right one to the right port.
Run the Lab: One Port, Two Protocols, Two Failures#
The clearest way to internalize "port is not protocol" is to watch one live port accept the right protocol and reject the wrong one, with a third case where the conventional port has nothing behind it. This harness starts a small HTTP forward proxy on the conventional HTTP-proxy port 3128 and drives it with the system curl; it was verified with Node v24.14.0 and curl 8.17.0. The three commands change only the -x proxy argument:
# 1. HTTP protocol to the live HTTP-proxy port: works.
curl -s -x http://127.0.0.1:3128 http://127.0.0.1:8091/inventory
# -> origin saw GET /inventory (curl exit 0)
# 2. SOCKS5 protocol to the SAME live port: wrong protocol.
curl -s -x socks5://127.0.0.1:3128 http://127.0.0.1:8091/inventory
# -> curl: (97) Received invalid version in initial SOCKS5 response
# 3. SOCKS5 to the conventional SOCKS port 1080, nothing listening.
curl -s -x socks5://127.0.0.1:1080 http://127.0.0.1:8091/inventory
# -> curl: (7) Failed to connect to 127.0.0.1 port 1080Trial 2 is the instructive one. The port is alive and a proxy is genuinely listening, but curl spoke the SOCKS5 opening handshake and the HTTP proxy answered with an HTTP response. curl reports invalid version in initial SOCKS5 response because it expected a SOCKS version byte and got the letter H from HTTP/1.1. Trial 3 never gets that far: nothing is on 1080, so the connection itself fails. Same family of symptom ("my proxy does not work"), two entirely different causes, distinguishable by the error alone.
Read the Error: Wrong Port or Wrong Protocol#
Once you have seen the two failures side by side, the error message becomes a diagnosis rather than a dead end. When the browser is the client, those same two failures surface as Chrome's proxy and firewall suggestion. The distinction is always the same: did the connection fail to open, or did it open and then break during the protocol conversation?
| Symptom | Most likely cause | First thing to check |
|---|---|---|
| Connection refused / failed to connect / timeout | Nothing is listening on that host and port, or a firewall dropped it | The host and port themselves: is the service up, is the number right, is egress allowed |
| "invalid version in initial SOCKS5 response," or a proxy that returns HTML/errors when you expected a tunnel | The port is live but you are speaking the wrong protocol to it | The protocol setting: HTTP vs SOCKS5, and http vs https vs socks5 vs socks5h in the client |
| 407 Proxy Authentication Required | Right port, right protocol, missing or wrong proxy credentials | Proxy username and password, and that they went to the proxy not the origin |
| Works with curl, fails in one app | That application ignores the proxy, uses its own setting, or does not support the scheme | The application's own proxy configuration and NO_PROXY |
The curl exit codes make this concrete: exit 7 is a connection failure (check the port), exit 97 in the lab is a SOCKS protocol failure (check the protocol). Other clients use different numbers for the same two conditions, so read the words, not only the code. When a single exit is up but you want to confirm its liveness, protocol result, and headers at a point in time, the proxy checker runs exactly that probe; it inspects one connection rather than proving a whole configuration, so it complements this port-versus-protocol reasoning.
Configure It Right the First Time#
Every mismatch above is avoidable by treating the provider's documentation as the source of truth for the port-and-protocol pair, and by making the protocol explicit in the client rather than trusting a default. In curl the scheme in the -x value is the protocol: http://, https:// (TLS to the proxy itself), socks5:// (local DNS), or socks5h:// (proxy-side DNS). Most libraries have the same distinction under a different surface.
# Be explicit about protocol and port; keep the password out of the URL.
curl -x http://GATEWAY:PORT --proxy-user 'USER:PASS' https://example.com/
curl -x socks5h://GATEWAY:PORT --proxy-user 'USER:PASS' https://example.com/Before blaming the network, confirm four things in order: something is listening on that host and port; you are speaking the protocol that listener expects; your credentials reached the proxy; and the specific application you care about actually honors the setting. A proxy changes the route your traffic takes; it never changes what you are authorized to reach, and a port or protocol that finally connects is not permission to bypass a control the destination enforces. For the protocol decision itself, the HTTP versus SOCKS5 comparison goes deeper; for what a proxy is doing to the connection underneath the port, the proxy fundamentals guide traces the full path; and when you need a maintained gateway whose documented ports and protocols simply match what you configured, that is what managed networks are for.
