HTTP, HTTPS and TLS Proxy Modes Explained

IPPool classifies every endpoint into three independent modes. A single ip:port may support more than one of them, and each mode is validated, scored, and delivered separately.

HTTP mode — plain forwarding

The client connects to the proxy over http://ip:port and sends a request with an absolute URI. The proxy reads that request in plaintext and retrieves the target page on the client's behalf. This is the most basic behaviour of an HTTP proxy and the precondition for anonymity testing, because the proxy exposes its own request headers when forwarding.

How we validate it: an azenv-style environment page is requested through the proxy. The response must contain REMOTE_ADDR, and its value must be a valid IPv4 or IPv6 address other than our own server IP. This confirms both that the proxy forwarded the request and that the traffic genuinely left through it.

Suitable for: http:// targets, header and anonymity inspection, and existing tooling that supports plaintext proxies only.

HTTPS mode — CONNECT tunnel

The connection to the proxy remains plain http://ip:port, but instead of having the proxy forward the request, the client sends CONNECT host:443 and the proxy establishes a transparent tunnel. TLS is then negotiated end to end between the client and the destination, and the proxy only relays data it cannot decrypt. Plain forwarding and tunnelling are two independent capabilities, and a considerable number of proxies support only one of them, which is why each is tested separately.

How we validate it: https://icanhazip.com/ is requested through the proxy. The response must be a valid IPv4 or IPv6 address other than our own server IP. This result confirms both that the tunnel works and that the traffic genuinely left through the proxy.

Suitable for: any https:// target, which today covers the vast majority of sites. A tunnel places no restriction on the destination scheme, so these endpoints reach http:// sites as well.

TLS mode — encrypted entry

In this mode the first hop is encrypted as well: the client negotiates TLS directly with the proxy at https://ip:port, and the tunnelled request travels inside that outer TLS session. Intermediate devices on the link observe only a TLS connection to the proxy and cannot determine the actual destination.

How we validate it: the same https://icanhazip.com/ check as HTTPS mode is used, but the proxy itself is reached over https://. The response must likewise be a valid IPv4 or IPv6 address other than our own server IP.

Suitable for: environments where the link between the client and the proxy is untrusted, or where a plaintext proxy connection is easily identified.

Selecting a mode from the API

Pass the protocol parameter when extracting proxies to specify a mode. Omitting the parameter returns all enabled modes.

curl "https://ippool.cc/api/proxy?key=$IPPOOL_API_KEY&protocol=http&num=10"
curl "https://ippool.cc/api/proxy?key=$IPPOOL_API_KEY&protocol=https&num=10"
curl "https://ippool.cc/api/proxy?key=$IPPOOL_API_KEY&protocol=tls&num=10"

Client configuration differs slightly: endpoints in http and https mode are both configured as http://ip:port, whereas endpoints in tls mode must be configured as https://ip:port so that the client negotiates TLS with the proxy.

Scoring is per mode

Each of the three modes is scored independently. A proxy that tunnels reliably but does not support plain forwarding, for example, retains a full score in the HTTPS pool while gradually leaving the HTTP pool; requesting a given mode therefore returns endpoints that genuinely provide that capability. To verify an endpoint independently, see the proxy anonymity testing guide.