An Open TCP Port Does Not Prove a Proxy Works
A successful port check only establishes a connection. Check the proxy handshake and expected destination response as well.
An open TCP port establishes that a listener accepted a connection. It could be a proxy, a normal web server or another service; port 8080 does not identify the protocol.
For an endpoint documented as an HTTP proxy, use its real address in a bounded HTTPS request:
curl --proxy http://203.0.113.10:8080 --noproxy '' --connect-timeout 5 --max-time 15 --verbose https://example.com/The documentation address must be replaced with your HTTP endpoint or a candidate from the HTTP proxy list. For SOCKS, use the corresponding SOCKS client mode and complete that negotiation. A wrong handshake can fail immediately after TCP acceptance.
| Observed stage | What it establishes |
|---|---|
| TCP accepted | The listener is reachable. |
| Proxy handshake accepted | The listener accepted this proxy operation. |
| Destination TLS verified | The client completed the intended secure connection under its trust settings. |
| Expected status and content received | The application request produced its expected result. |
For HTTPS through an HTTP proxy, CONNECT must be permitted to the destination port. Even CONNECT 200 is intermediate: the tunnel can close before TLS or the final request succeeds. A plain HTTP success does not establish that tunnel capability.
Use a destination with predictable content, preferably one you control, and inspect its request record when available. A plain HTTP listener can return a fixed page with status 200 without contacting the target at all. Receiving some successful status is weaker evidence than matching the expected response; HTTPS identity verification provides an additional protection.
Record the last successful stage. “Port open, SOCKS negotiation rejected” gives the next investigation a useful starting point.