How a Proxy Works: What Happens to Your Request on the Way

You can memorize "a proxy is a middleman" in a second, and it explains nothing. Follow one request all the way instead, from the line in your settings to the site's reply. After that, protocols and sessions stop being a mystery, and so does the reason a site sees one address when you configured another.

Step by step

1. Connection. Your software connects to the proxy address from its settings. For the site, you do not exist yet.
2. Handshake. The software and the server speak one of the protocols: HTTP with its CONNECT command, or SOCKS. Login and password travel at this stage if access uses them. We cover the protocols separately in the article on proxy types.
3. Exit. The proxy opens its own connection to the site from its exit address. The site logs this address along with its country and provider.
4. Relay. From here the server pumps bytes in both directions. On encrypted sites it sees only the domain and the volume, because TLS protects the content all the way from your software to the site.
5. Reply. The page comes back the same way. As far as the site can tell, it talked to the proxy, and your address never appeared.

Who sees what

This table answers the main practical question: a proxy moves your trust from your ISP to the proxy operator. That makes the choice of whose server you use more important than the choice of protocol. With public addresses from free lists, you have no idea who the operator is, as we explain in our review of public proxy risks.

Where rotation comes from

Modern services rarely sell "one server with one address". The line you enter leads to a gateway, and behind the gateway sits a pool of exit addresses. Two modes follow. Rotation sends each request from a new pool address, which suits scraping. A session pins one exit to you while you work, which accounts need. You pick the mode in the line itself or when you create a list, and your software knows nothing about any of this. The design is called backconnect, and it has its own article.

The difference between address types grows from the same root: pool exits can live in a data center, on home networks or with mobile carriers. To a site these are different worlds. A hosting range is recognized in a second, while a home address looks like an ordinary subscriber. Plans are built on this, from data center proxies to residential ones.

Common questions

Does a proxy slow things down? The extra node adds milliseconds to the trip, and with a fast nearby server you will not notice them. Real slowdowns come from an overloaded exit. On public addresses that is routine, and on commercial pools speed depends on the type of exit device.

What can my ISP still see? That you talk to the proxy's address, and how much data flows. The domains you open through the proxy leave its view, and the proxy operator sees them instead. This is why we describe it as moving trust: an observer is still there.

Is access without a login and password possible? Yes, through the second authorization method: a list of allowed IPs. You enter your server's address in the dashboard, and the lines work only from it. Our packages work this way: they have no login at all, and the list opens only to your machines.

Test it on a live line

You can verify all of this in a minute. Take a line and open the IP lookup page through it: you will see the exit address, its country and network. Refresh the page on a rotating line and the address changes; on a session line it stays. Then open the anonymity check: it shows whether the server adds headers with your real address, which is the difference between anonymity levels. From a console one command does the same: curl with a proxy parameter returns the exit address, and we give examples in the setup guide.

Knowing the request path saves hours of troubleshooting. Once you know who sees what and who connects to whom, an error comes down to two questions: did the software reach the proxy, and did the proxy reach the site. To answer the first, try to open any page through the line. To answer the second, switch the target to a site you know is up. Two minutes later you know the culprit. Our support team uses the same logic when it reviews lines you send, which is why it asks for the request time and the error text.