Keep-alive

Every HTTP request needs a connection to the server. Without keep-alive, the client would open a new TCP connection for each request, and for HTTPS it would also repeat the TLS handshake. Keep-alive, or a persistent connection, lets you send many requests over one connection. In HTTP/1.1 this is the default behavior.

The benefit is easy to see. Fewer handshakes mean lower latency, especially when the server is far away. Fewer service packets mean slightly less traffic. The server also spends fewer resources on opening and closing connections.

A persistent connection does not live forever. The server or the client closes it after some idle time or after a certain number of requests, and then the next request opens a new connection. HTTP/2 goes further: one connection can carry several requests in parallel. For proxies this means that the number of connections and the number of requests are different numbers, and it is the connections you should count, especially when it matters which address each request leaves from.

With proxies there is a catch. Port 823 (HTTP) and port 824 (SOCKS5) on gw.prokso.com give you a new IP on every request. In practice, though, the address is chosen when the client opens a new connection to the gateway. If a library keeps the connection open and sends several requests through it, those requests may leave from the same address.

This happens most often with sessions in libraries. For example, the Session object in Python requests keeps a pool of connections and reuses them. For HTTPS over CONNECT, all requests inside one tunnel take the same route, which means the same address.

If you need a new address for every request, open a new connection: close the session, turn off connection reuse or send the Connection: close header. If, on the contrary, the IP must stay the same, do not rely on keep-alive and use a sticky IP port from the 10000-20000 range instead. Setup examples are in the Python requests guide.

Either way, check the result. Send several requests to the My IP page the same way your script does and see whether the address changes. This shows you the real behavior of your library, not the expected one. Read more about changing addresses in the rotating proxy article.