---
title: "Backconnect proxy"
url: https://proxy.wiki/glossary/backconnect-proxy/
type: Glossary Term
author: "proxy.wiki editorial"
published: 2026-08-19
updated: 2026-08-29
site: proxy.wiki
topics: ["Proxy fundamentals"]
license: CC BY 4.0 — quote freely with attribution to https://proxy.wiki/
---

# Backconnect proxy

> A single gateway address that transparently routes each request through a different address in the provider's pool.

**A backconnect proxy gives you one endpoint that resolves to many addresses behind it.** You configure one host and port; the provider maps each connection onto a different member of the [pool](/glossary/proxy-pool/).

## Why it is built this way

Managing thousands of individual addresses in client code is impractical: they change, they fail, and they need health checks. A backconnect gateway moves all of that to the provider. Your configuration stays a single line even as the pool underneath changes continuously.

## Practical consequences

- Your firewall rules and connection settings reference one host, not thousands.

- You cannot choose a specific exit address directly — you express intent through parameters such as country or [session](/glossary/sticky-session/) identifier.

- The gateway’s own location is not the [exit](/glossary/exit-node/) location.

Nearly all modern [residential](/glossary/residential-proxy/) and [mobile](/glossary/mobile-proxy/) services are backconnect. Per-address lists are now mostly a [datacenter](/glossary/datacenter-proxy/) and [ISP](/glossary/isp-proxy/) arrangement.

## What the single endpoint hides

You configure one hostname and port. Behind it the provider selects an [exit node](/glossary/exit-node/), applies your [geo-targeting](/glossary/geo-targeting/), enforces your plan limits and records the traffic. Several consequences follow that are easy to miss.

| You observe | What is actually happening |
| --- | --- |
| One address in your configuration | Many addresses in use, chosen per request or per session |
| A connection failure | Could be the gateway, the selected exit, or the destination |
| Consistent latency to the gateway | Says nothing about latency from the exit to the target |
| An unchanged endpoint | The pool behind it changes continuously |

## Why it is built this way

Consumer devices cannot accept inbound connections reliably. They sit behind NAT, they move between networks and they disappear without notice. So the devices connect outward to the provider and hold the connection open, and the provider routes your request down an existing one. The name describes that reversal: the node connects back, rather than being connected to.

This is also why an exit can vanish mid-request. The node’s owner closed a laptop, and no protocol exists to warn you first.

## Frequently asked questions

### Why do I only get one hostname when the provider advertises millions of addresses?

Because selection happens at the gateway. You address the gateway, and it chooses which exit node carries the request. The alternative, publishing a list of consumer addresses, would be unusable because those addresses appear and disappear constantly.

### How do I control which exit is used?

Through the credentials or the endpoint, not through the address. Providers encode country, city, session identity and similar options into the username or the port number. The format is provider-specific.

### Why did my request fail halfway through?

On a backconnect network an exit can leave without notice, because it is a real consumer device. Treat a mid-transfer failure as a routine event and retry it rather than as evidence of a broken configuration.

## Sources

1. [RFC 9110: HTTP Semantics, proxies and message forwarding](https://www.rfc-editor.org/rfc/rfc9110.html)