A web proxy looks like a single click from the outside — paste a URL, get a page. Underneath, there are three separate network conversations happening in sequence, and understanding them explains almost every question people ask about proxies: what the network sees, whether the destination site knows, why the loading spinner takes an extra beat, and how much of your privacy actually changes.
Here is exactly what happens when you open a page through a web proxy, hop by hop.
The three hops
The whole flow is short:
- Browser → Proxy. Your device makes a TLS-encrypted request to the proxy’s own domain (for AnyProxy, that is
anyproxy.site). The request body carries the URL you want to open. - Proxy → Destination. The proxy server opens a fresh TLS connection to the destination site (say,
youtube.com) and fetches the page as if it were an ordinary visitor. - Proxy → Browser. The proxy rewrites the page’s internal links and asset URLs so that everything on it continues to route through the proxy, then sends the result back to your tab over the same TLS connection from hop 1.
The browser stays where it started. Nothing changes about your operating system, your DNS settings, or your extensions. Only the traffic pattern shifts.
Hop 1 — Browser to proxy
Your browser opens a standard HTTPS connection to the proxy. This looks — from the network’s point of view — identical to visiting any other website. The TLS handshake reveals only the proxy’s hostname, not what you plan to do next.
The URL you want to open travels inside the encrypted body of that request. It could be youtube.com, chatgpt.com, or a specific github.com/user/repo deep link. Local network filters, ISP loggers, and hotel Wi-Fi captive portals can see that you talked to the proxy — they cannot see what came next.
This is the hop that a DNS-level filter loses at. If the filter blocks youtube.com, changing DNS servers routes around it — but if the filter is deeper (IP-level or DPI on YouTube specifically), you need a proxy or VPN to move the request path off the filtered network. Both work here.
Hop 2 — Proxy to destination
Now the proxy makes a fresh TLS connection outward to the real site. The proxy server has its own IP address — one from its region’s block — and the destination site sees that IP as the visitor.
Two consequences follow:
- Geographic reach. If the destination site was geo-restricted to a country where the proxy has a server, this hop is where the restriction dissolves. YouTube’s “not available in your country” message keys off the request IP; the proxy’s IP looks local to wherever it is hosted.
- Cookies and sessions. Sessions the destination uses to identify you (login cookies, browsing history, algorithmic personalization) are keyed by the request’s cookies and IP. Through a proxy, the site cannot correlate you with your prior visits unless you sign in. If you do sign in on the real destination URL after it loads, the site sees a normal logged-in session from a new IP.
The proxy is deliberately not sending your original IP, your user-agent tricks, or any custom headers you added. It is a plain fetcher.
Hop 3 — Proxy back to browser (with a rewrite)
Once the destination sends the page back, the proxy does the work most people never notice: it rewrites the page so that every internal link, script src, image URL, form action, and asynchronous fetch continues to route through the proxy.
The math is quiet but exhaustive. A link like <a href="/watch?v=xyz"> becomes something like <a href="/browse?url=https%3A%2F%2Fyoutube.com%2Fwatch%3Fv%3Dxyz">. A <script src="https://s.ytimg.com/vi/xyz/hqdefault.jpg"> becomes a proxy-relative URL that fetches the same file through the same tunnel. Every asset the destination page requested — thumbnails, JavaScript bundles, WebSocket URLs — passes through the same rewrite.
This is why a modern web proxy can handle single-page applications like YouTube, Instagram, and Reddit: the rewrite covers not just the initial HTML but every follow-up request the JavaScript on the page makes. When it works well, the user cannot tell the page is proxied.
When it does not work well, you see the tell: an image missing, a video that will not play, a “sign in with Google” popup that never resolves. Those are the pages where the rewrite missed a URL or the destination site pushes back with DRM checks or captchas.
What each layer sees, in one table
| Layer | Can see |
|---|---|
| Your local network | An encrypted connection to anyproxy.site — nothing more |
| Your ISP | Same as the local network — encrypted, hostname only |
| The proxy server | Both sides — your original request and the destination page |
| The destination site | A request from the proxy’s IP address, with the proxy’s region and headers |
| Whoever you sign in as | A logged-in session from a new IP (if you choose to sign in on the real destination) |
The proxy is the trust hinge. This is why a serious web proxy publishes a logging policy and why the “we do not log the URLs you visit” line matters — the proxy is the only party in the chain that can see both ends.
Latency — where the extra time actually goes
A proxy adds one hop. That hop has a real cost, and it lives in one place: the leg between the proxy server and the destination site.
- Hop 1 (browser → proxy) is usually the shortest — you and the nearest proxy region are often on the same continent.
- Hop 2 (proxy → destination) is where the total latency stretches. If the destination has a CDN edge near the proxy, this hop is quick; if not, you pay the transit.
- Hop 3 (proxy → browser) is the same round-trip as hop 1, in reverse.
In practice, a well-placed proxy region adds 30–100 ms to page loads for most users. That is a real cost but rarely one people notice on a browse-a-page workflow. Video streams and single-page apps that make many small requests pay this cost more visibly than static pages.
Latency is the reason serious proxies show a region picker with live numbers — picking the closest region to you sets the total round-trip. Picking a region closer to the destination site sometimes wins on fast video streams.
The bottom line
A web proxy is three network conversations chained together, with one rewrite pass in the middle to keep the destination page’s follow-up requests routing through the proxy. Your browser stays where it is, your operating system is untouched, and the destination site sees a visit from the proxy’s region.
If you want to see this happen live, open AnyProxy with a link. The tab that opens is the destination page, delivered through the flow above — same three hops, every time.