Guide 01 · Select
Spec sheets are marketing. This is how to see through them — pick a box that isn't secretly throttled, judge residential-IP quality, and prove it with a ten-minute benchmark before you pay.
Before any spec, answer one question: does your traffic need to look like a home user, or just be fast? That single fork decides everything else.
| Need | Pick | Why |
|---|---|---|
| Websites, APIs, apps, backups | Datacenter | Far more compute, memory, disk and bandwidth per dollar. The IP being flagged as "hosting" is irrelevant — nobody's checking. |
| Look like a real person (scraping, ad verification, social ops, region-locked access) | Residential exit | A genuine consumer-ISP address (Comcast, Spectrum, Verizon, Cox…) that anti-fraud systems trust. Weak hardware, but that's not the point. |
| Both — speed and a clean home IP | Both, chained | A fast datacenter relay in front of a residential exit. That's the whole second half of this guide. |
Providers list numbers that sound impressive and hide the ones that hurt. Here's what each line actually tells you.
| The spec says | What it really means |
|---|---|
| vCPU count | A share of cores, not cores. "4 vCPU" on an oversold host can be slower than "2 vCPU" elsewhere. Count means nothing without a per-core benchmark. |
| CPU model | Often masked (a generic "QEMU Virtual CPU" or bare "Skylake"). A masked CPU can be secretly great or a decade-old Xeon — you can't tell without running it. |
| "NVMe SSD" | The device is fast; your allowance may not be. Many budget tiers cap you to a few thousand IOPS regardless of the disk underneath. |
| Bandwidth ("1 Gbps port") | The port speed, not your sustained throughput. Real transfer is set by peering, contention, and sometimes a soft per-VM cap. |
| RAM | The one number that's usually honest. Still worth confirming the bandwidth if you do memory-heavy work. |
| Location / "Los Angeles" | Where the company is, not always where the IP geolocates. Registrant-address artifacts routinely put a box on the map a few states from where it physically sits. |
For an exit, the hardware barely matters — the IP's reputation is the product. Two boxes on the same "residential" plan can be night-and-day. Check four things:
Most providers offer an hourly or trial box. Spin one up, run the same four tests you'd run on every candidate, then destroy it. Identical commands each time is the whole trick — that's what makes numbers comparable.
# same params every time; "events per second" is your score sudo apt install -y sysbench sysbench cpu --cpu-max-prime=20000 --threads=1 --time=10 run # single-core sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=10 run # all-core
sysbench memory --memory-block-size=1M --memory-total-size=10G --memory-oper=read run sysbench memory --memory-block-size=1M --memory-total-size=10G --memory-oper=write run
sudo apt install -y fio
fio --name=r --filename=./t --size=256M --direct=1 --ioengine=libaio \
--iodepth=16 --bs=4k --rw=randread --runtime=10 --time_based --group_reporting
# repeat with --rw=randwrite, then: rm -f ./t
That's for KVM. On container-virtualized boxes (OpenVZ/LXC — common in the cheap-residential tier), libaio or O_DIRECT are often missing and fio will abort; swap --ioengine=psync and drop --direct=1 (page-cache will flatter the numbers, so read them as a ceiling).
# bytes/sec ×8 ÷ 1e6 = Mbps
curl -o /dev/null -w '%{speed_download}\n' --max-time 30 \
'https://speed.cloudflare.com/__down?bytes=524288000'
Use a big payload (500 MB+) and run it 2–3 times. On a gigabit box a small download finishes in a fraction of a second — too fast to escape TCP slow-start, so it under-reports exactly the fast links you're trying to rank.
Got your box? The next guide wires it into a real network.