Two questions, not six products
Where the address comes from, and how the connection behaves. You answer both on the same username. Every page below says what its answer is good at and, more usefully, where it fails.
Where the address comes from
Pick exactly one.
Residential, datacenter and mobile are alternatives to each other. All three bill at the same rate against the same balance, so this is a technical choice rather than a budget one — you escalate because a target rejected you, not because you can afford to.
- IP classResidential proxiesThe target rejects hosting ranges but does not need a carrier address.
- IP classDatacenter proxiesNothing is blocking you yet, or a predictable round trip matters more than provenance.
- IP classMobile proxiesResidential was rejected too, or the platform expects a carrier address.
Side by side
Five rows that differ, and one that does not. The last row is the reason the first five are a technical argument rather than a budget one.
| Compare | Residential proxies | Datacenter proxies | Mobile proxies |
|---|---|---|---|
| Address belongs to | A consumer ISP subscriber line | A hosting provider | A cellular carrier |
| Published as a hosting range | No | Yes — catalogued and easy to match | No |
| Latency | Varies with the household line | Lowest and most consistent | Highest — carrier NAT is in the path |
| Blocking one address also blocks | One household | One hosting range | Many real subscribers behind that carrier IP |
| UDP over SOCKS5 | Available | Not available | Available |
| Rate | $2/GB | $2/GB | $2/GB |
How the connection behaves
Set alongside the IP class, not instead of it.
Protocol and rotation are separate dials on the same connection. A single username can say residential, SOCKS5 and sticky at once — these pages exist because each dial has its own failure mode.
Still not sure?
Start from the job instead. The use-case pages give the exact type, rotation and targeting we would configure for a specific workload — and the mistakes that waste gigabytes on it.