# Rotating residential proxies are live
Source: https://proxuno.com/blog/rotating-residential-proxies-launch
Updated: 2023-09-19

> Our second product line — a Europe-wide residential pool billed per gigabyte, with country and city targeting and sticky sessions. How the pool is sourced, how targeting works, and how to connect.

Version 3.0 adds a second product line next to dedicated mobile proxies: **rotating residential proxies**. One gateway, a pool of household connections across Europe, billed per gigabyte, with targeting by country and city and the choice between a new IP per request or a sticky session.

This post covers how the pool is built, how to use it, and how it fits alongside mobile proxies.

## Why we added residential

Mobile proxies are the right tool for hard targets and account work, but they are a poor fit for some jobs customers kept asking about:

- **Broad geographic coverage** — checking prices or search results in dozens of cities, not just one per country.
- **High identity counts** — thousands of distinct addresses per hour for independent requests.
- **Variable volume** — projects that need a lot of traffic one week and none the next.

A per-GB residential pool covers these. Mobile proxies remain the better choice where each identity has to last and every block is expensive.

## How the pool is sourced

Residential proxies are only as good — and as defensible — as the way peers join the network. Ours are devices whose owners **explicitly opted in** to share idle bandwidth through partner applications that:

- explain in plain language, at the moment of consent, that the device will route third-party web traffic;
- offer a reward in exchange (typically a premium feature or a payment);
- make it possible to stop at any time from the app's settings.

Peers only route traffic when idle, on unmetered connections, and within bandwidth caps that protect their own use. Categories of domains — online banking, government services, payment checkouts — are blocked at the gateway and never reach a peer.

We do not buy traffic from SDKs embedded silently in free apps. That is a commercial choice as much as an ethical one: such pools tend to shrink suddenly when app stores or antivirus vendors react, taking customers' workflows down with them.

## Connecting

Every account gets one set of residential credentials. Everything else — country, city, session — is set in the username.

| Setting | Value |
|---|---|
| Host | `resi.{{gatewayDomain}}` |
| HTTP port | `7000` |
| SOCKS5 port | `7001` |
| Username | your residential login plus targeting parameters |
| Password | your residential password |

The username follows one pattern:

```text
LOGIN-country-CC[-city-CITY][-session-ID-ttl-MINUTES]
```

- `country-CC` — an ISO country code such as `de`, or `eu` for a random European exit.
- `city-CITY` — optional, a city slug from the list in the dashboard, such as `city-munich`.
- `session-ID-ttl-MINUTES` — optional; keeps the same exit IP for the given number of minutes. `ID` is any 8-character alphanumeric string you choose.

### Examples

A new German IP on every request:

```bash
curl -x http://LOGIN-country-de:PASSWORD@resi.{{gatewayDomain}}:7000 https://api.ipify.org
```

A sticky Milan session for ten minutes:

```bash
curl -x http://LOGIN-country-it-city-milan-session-a1b2c3d4-ttl-10:PASSWORD@resi.{{gatewayDomain}}:7000 \
  https://api.ipify.org
```

Repeat the second command with the same session ID and you will get the same IP until the TTL runs out or the peer goes offline. Change the ID to get a new one.

## Rotation or sessions?

- **Per-request rotation** suits independent requests: product pages, search queries, availability checks. Every request leaves from a different household, which spreads load naturally.
- **Sticky sessions** suit flows of several requests that must come from one address: paginated results, a multi-step form, anything with a cookie set on the first response. At launch, sessions last up to 10 minutes.

A residential peer is a real household device, so it can disconnect at any time. If a sticky session's peer goes away, the next request gets a new peer on the same targeting. Build your client to tolerate that — retry the failed request and re-establish state if needed.

## Billing

Traffic is bought in packages of gigabytes and is **valid for 90 days** from purchase. Only traffic actually transferred through the gateway counts — both directions, headers included. Failed connections to the gateway are not billed. You can follow consumption per day in the dashboard and over the API, and stack packages: the one expiring first is consumed first.

Current tiers and per-GB prices are on the [pricing page](/pricing).

## Using residential with mobile

The two products share one account, one order history and the same API key. Typical combinations we see:

- residential for broad price and search monitoring, plus a few dedicated mobile proxies for logged-in marketplace accounts;
- residential to discover and test targets cheaply, then mobile for the ones that block residential traffic;
- mobile proxies for social media management, residential for the public research that feeds it.

## What comes next

Residential is new, and we will keep extending it: more cities, longer sticky sessions and more detail in usage reporting are already on the list. The [residential targeting documentation](/docs/residential-targeting) has the full list of countries and cities and the details of every username parameter.