Proxy Chaining: Multiple Proxy Servers in a Row

In a chain, your app connects to the first proxy and asks it to reach the second, and so on, until the last proxy opens the connection to the site:

your app → proxy 1 → proxy 2 → … → proxy N → website

Each hop is an ordinary proxy connection:

• HTTP proxies chain with CONNECT: the app asks proxy 1 to open a tunnel to proxy 2, then sends a second CONNECT through that tunnel asking proxy 2 to open a tunnel to the site. TLS to the site runs inside the innermost tunnel, end to end.
• SOCKS proxies chain the same way: a SOCKS connection to proxy 2 is opened through proxy 1.
• Upstream proxies chain on the server side: proxy 1 is configured to forward everything it receives to proxy 2. Your app only knows proxy 1.

What each hop sees: the first proxy sees your IP and the address of the next hop; the last proxy sees the previous hop's IP and the site you visit; the site sees only the last proxy's IP. With HTTPS sites, no hop can read the pages, because they travel inside your own TLS session.

A super proxy is the entry server of a proxy network: the one host you connect to, which forwards your traffic to an exit IP in the provider's pool. The term is common in residential proxy networks. Seen this way, every rotating proxy service is a short chain run by the provider: your app, the entry server, then the exit IP that the site sees.

ProxyField's gateway, gate.proxyfield.io:7000, plays this role: you configure one address, and each request leaves from a residential or mobile IP in the pool, a new one per request or the same one for a sticky session up to 36 h. How the gateway picks IPs is covered in what a proxy pool is.

Most real chains have two hops and a practical reason:

• A company network that requires its own proxy. Traffic must leave through the office proxy first, so a proxy service can only be reached as the second hop.
• A local proxy in front of a proxy service. A local proxy handles authentication, routing rules or logging for apps that cannot send proxy credentials, and forwards everything upstream.
• Debugging. A local inspection tool shows the requests your scraper sends, then forwards them to the proxy service.
• Layering. Each hop sees only its neighbors, so no single proxy sees both your IP and the site. This only helps if the operators are independent and none of them logs; every extra hop is one more operator you trust.

For web scraping, a chain is rarely needed: one rotating residential proxy already gives each request a new IP. See proxies for web scraping.

On Linux, with proxychains-ng. It forces a program's TCP connections through a list of proxies in order. In /etc/proxychains.conf (or proxychains4.conf):

strict_chain
proxy_dns
tcp_connect_time_out 8000
tcp_read_time_out 15000

[ProxyList]
# hop 1: the office proxy; hop 2: ProxyField
http  10.0.0.5 3128
http  gate.proxyfield.io 7000 <login> <password>

Then run proxychains4 curl https://api.ipify.org: the output is the ProxyField IP. More in Linux proxy settings.

With a local upstream proxy (Squid). Your apps point at Squid; Squid forwards everything to the proxy service:

cache_peer gate.proxyfield.io parent 7000 0 no-query default login=<login>:<password>
never_direct allow all

For debugging (mitmproxy). Run it in upstream mode and point your scraper at it; it shows each request and forwards it to the proxy service:

mitmproxy --mode upstream:http://gate.proxyfield.io:7000 --set upstream_auth=<login>:<password>

mitmproxy decrypts HTTPS to show it, so your client must trust mitmproxy's certificate. Use this only on your own machine, for your own traffic, and never in production; the difference between tunneling and inspecting proxies is in what an SSL proxy is.

On Windows and macOS. Proxifier can chain proxies and apply the chain to chosen apps: Proxifier.

Every hop adds a round trip, a handshake and a point of failure:

• Speed. Latency adds up hop by hop. Two hops on the same continent are usually fine; hops spread across continents slow every request. Place hop 1 close to you and the last hop close to the target.
• Reliability. If any hop fails, the request fails. A chain of three proxies with 99% availability each works about 97% of the time.
• Debugging. Errors such as 407 or 502 can come from any hop; test each hop on its own first. See why a proxy is not working.
• Trust. Each operator can see what reaches its hop. Chaining a free public proxy adds risk, not protection.

A VPN encrypts all of a device's traffic to one server; a proxy chain relays one app's traffic through several servers, without encryption between hops unless the app's own traffic is encrypted. If you want privacy on an untrusted network, a VPN is simpler. You can also combine them: a VPN on the device, then a proxy as the hop the site sees, as described in proxy vs VPN.

Need a reliable last hop? ProxyField residential proxies work as the exit of a chain over HTTP, HTTPS or SOCKS5, with 412M+ IPs in 195+ countries, from $1.95/GB with no subscription. Start with the Easy Trial: 1 GB for $2.95. Traffic never expires, and all purchases are final.