Residential Proxies: Real IPs in 170+ Countries

What actually happens when you send a request

Your client connects to gw-residential.node4.io and authenticates with your username and password. The gateway parses the targeting segments out of the username, checks each one against your plan's entitlements, and selects an exit in the partner network that matches: a household connection in the country, state or city you asked for. Your request then leaves from that consumer address and the response returns along the same path. For HTTPS, the gateway carries an opaque CONNECT tunnel, so the TLS session runs end to end between your client and the destination; we relay encrypted bytes, we do not terminate them. From the target's point of view the visitor is the household connection: its IP, its ISP, its geography.

Targeting down to the city

Targeting rides in the username, so you can change country per request without touching your dashboard or rotating credentials. Every segment is validated against your plan before the connection is made. An entitlement you do not have is refused with a clear reason rather than silently downgraded, because being served the wrong country without knowing is worse than an error.

• user-42-abc123-country-us: anywhere in the United States
• user-42-abc123-country-au-state-nsw-city-maitland: one city
• user-42-abc123-session-482913: hold one exit IP across requests

Sticky sessions, described honestly

A sticky session holds the same exit IP across repeated requests. The hold is best effort rather than a fixed window: exits are real consumer connections, so the partner network decides how long a pin survives, and a session's address can change when the peer behind it goes offline. Design multi-step flows to tolerate an address change rather than assuming one address forever. A session ID is any string of letters and digits, up to 32 characters, that you choose: send the same ID to stay on the same exit, change it to move to a fresh one. Session identifiers are hashed per customer before they reach the upstream network, so nobody can steer onto your exit by guessing your session ID. What hashing cannot do is reserve an address: the partner network's session space is finite, so under heavy concurrent use two sessions can land on the same exit. A sticky exit is yours for the session, not exclusive to you. The dashboard builder generates an ID for you.

Where the IPs come from

Residential is a partner network, not IPs node4 owns, and we would rather say so than imply otherwise. Before we put it on sale we spot-checked 30 exits on 27 July 2026: all 30 carried traffic, and none of them came from a hosting range. That is a sample of 30, not a survey of the pool. The per-country and per-city figures on this page are a different kind of number: they are read from the live coverage snapshot and refreshed daily. Datacenter, shared and rotating products run on IP blocks node4 does own.

What residential proxies are the wrong tool for

Per-gigabyte billing and consumer last-mile connections shape what this product is bad at, and it is worth knowing before you buy. Bulk transfer of large files is the clearest case: if the job is moving gigabytes rather than making many small requests, a per-GB price punishes exactly the thing you are doing, and an unlimited-bandwidth datacenter proxy does the same work for a flat monthly cost. Latency-sensitive work is another: a household connection is inherently more variable than a datacenter uplink, and no amount of targeting changes that. And if your target accepts hosting ranges (most APIs and a large share of ordinary websites do), you are paying the residential premium for a property you do not need. Try the rotating or datacenter product first and move here only when the target actually forces it.

When an exit stops working

Residential exits are real devices on real networks, so churn is normal: peers go offline, and destination sites sometimes decide they dislike a particular address. The handling differs by mode. In default rotation the problem solves itself: the next request is assigned a different exit, so a transient failure is worth one retry before it is worth an investigation. In a sticky session, a dropped peer means a new address, so the target may observe an IP change mid-flow; design multi-step flows to tolerate that rather than assuming one address forever. If a target has soured on your current sticky exit, do not fight it: switch to a fresh session ID and you get a fresh exit. What no residential product can honestly promise is an exit that never gets challenged. The value is that recovering from a challenge costs you one username change instead of an infrastructure change.

Keeping per-gigabyte costs under control

Bandwidth is metered on bytes transferred in both directions, which makes efficiency a line item rather than a virtue. The biggest single saving in scraping workloads is not fetching what you do not parse: a product page's HTML is often a small fraction of its images, fonts and scripts, so a client that requests only the document, or hits the underlying data endpoint directly, cuts consumption dramatically. Retries deserve attention too, because a failed request that transferred a response body still transferred bytes; back off rather than hammering, and abandon responses you can already tell are useless from the status line. The dashboard's usage page shows consumption as it accrues, so measure the cost of one unit of your workload early and multiply, rather than discovering the run rate at the end of the month.

Protocols and authentication

HTTP(S) and SOCKS5 both work with the same credential: the gateway identifies you by username, not by protocol, so there is no second credential to manage. Authenticate with username and password. Bandwidth is metered per gigabyte with no monthly commitment.

How to evaluate the pool before committing

Because there is no monthly commitment, the sensible evaluation is a small live one rather than a feature-list comparison. Buy the smallest bandwidth tier, point the code samples below at your real target (not just an IP-echo service) and check three things: that the geography you need actually resolves (the dashboard builder only offers locations with live exits, so build the username there), that your target accepts the traffic at the request rate you intend, and that the gigabytes consumed per unit of useful work support your economics. We audited the pool before selling against it, but your target is the judge that matters, and testing against it costs a few gigabytes at most.