Cover image: VPS acceptance in the first hour
New VPS — like a used car: shiny on the outside, and what’s under the hood is revealed later. The host promised “dedicated NVMe-core disks 10 Gbit/s,” but the storefront doesn’t say that the neighbor on the node mines, emailed spam to you, and sits on three blacklists, and the NVMe offers the speed of a regular SATA because the node was resold twice.
Most hosts have a window when you can get your money back or change the tariff without losses: somewhere it’s an official money-back within 3–30 days, somewhere the first day or two while support is loyal to a new client. So you have about an hour of honest work to run the server through all items and decide: keep or return.
Do all checks below BEFORE you start living on the server. When you’ve already moved prod, the panel, and a dozen containers onto the VPS, it’s psychologically easier to accept a bad disk than to move again. A bare server is easy to return — a lived-in one almost never is.
Stage 1. Hardware: 0–15 minutes
Check 1. What virtualization is truly used
systemd-detect-virt
Answer kvm — good: you have your own kernel, WireGuard in the kernel, TUN, Docker without caveats. Answer openvz or lxc — you’re in a container on someone else’s kernel: some modules are inaccessible, memory can be counted oddly, and “guaranteed” resources often mean “guaranteed oversold.” For a proxy server or Docker stack, take KVM — container virtualization makes sense to endure only for fairly small money.
Check 2. CPU: model and stolen time
lscpu | grep -E "Model name|MHz"
vmstat 1 5
In vmstat look at the last column st (steal) — the percent of time the hypervisor took from your VM in favor of neighbors. On a healthy node, steal is about 0–1%. Stable 5–10% and above — the node is overloaded, and no tariff will fix that: during peak hours your proxy will be «biting» even if graphs show free resources.
Check 3. Memory without surprises
free -h
dmesg | grep -i -E "oom|killed process"
Compare the amount with the tariff, check if swap exists (in many templates there is none — for 1 GB RAM VPS it’s a future container drop). OOM-killer messages on a freshly issued server are a bad sign: either the template is faulty, or memory is already under pressure.
Check 4. Disk: fio, not dd
Classic dd if=/dev/zero of=test bs=1G count=1 measures not the disk but the write cache and the host’s ability to compress zeros. The figure “1.2 GB/s” from dd means nothing. The only honest quick-check tool is fio with direct access (--direct=1).
apt install -y fio
fio --name=t --filename=test.fio --size=1G --direct=1 \
--rw=randread --bs=4k --iodepth=64 --runtime=30 --time_based
fio --name=t --filename=test.fio --size=1G --direct=1 \
--rw=randwrite --bs=4k --iodepth=64 --runtime=30 --time_based
rm test.fio
Guidelines for random read 4k: real NVMe — tens of thousands of IOPS; SATA SSD — about 5–15 thousand; if you see hundreds of IOPS, you were sold HDD or a heavily throttled disk, whatever it’s called in the tariff. For databases, Nextcloud, or Immich, this is a death sentence.
Stage 2. Network: 15–30 minutes
Check 5. Bandwidth
apt install -y iperf3 speedtest-cli
speedtest-cli --simple
One measurement is not enough: run tests during day and evening in peak hours. “Up to 10 Gbps” in the tariff is port speed, not a guarantee; a fair question is how much the server holds stably. For iperf3, pick a couple of public servers from the network lists and test in both directions (-R for reverse).
Check 6. Routes and latency
apt install -y mtr-tiny
mtr -rwbzc 20 <your-home-ip>
Run mtr from the server to yourself and from your home machine to the server — routes can be asymmetric. Look at the final latency and losses on the last hops (losses in the middle of the path on transit nodes are normal; they just cut ICMP). For a VPS used as a proxy, latency to you matters more than megabits: 60 ms vs 120 ms is a difference between a smooth video call and “you’re stuck.”
Check 7. MTU and fragmentation
ping -M do -s 1472 8.8.8.8
If a packet of 1472 + 28 bytes of headers = 1500 does not pass, somewhere along the path there is a tunnel with a reduced MTU. Not fatal by itself, but it’s the source of the most mystic bugs like “sites open halfway,” especially over WireGuard — better to know in advance, reducing the size to the first passing value.
Check 8. IPv6
curl -6 -s ifconfig.co && ping -6 -c3 2001:4860:4860::8888
The advertised IPv6 is often not configured or routed halfway around the world. If you need it (and for bypassing blocks having a backup address family isn’t superfluous) — verify that it actually reaches the outside.
Stage 3. IP reputation: 30–45 minutes
The most undervalued stage. Hardware can be tolerated, host network can be fixed — but a dirty IP will silently spoil life daily.
Check 9. Blacklists
Find out your IP (curl -s ifconfig.me) and run it through check.spamhaus.org and the aggregator MXToolbox Blacklists, which queries dozens of DNSBLs at once. A listing in a couple of small lists is common for any hosting range; listing in Spamhaus SBL/XBL is a reason to immediately request an IP replacement or a refund.
Check 10. rDNS and port 25
dig -x $(curl -s ifconfig.me) +short
timeout 5 bash -c "cat < /dev/null > /dev/tcp/smtp.gmail.com/25" && echo "25 open" || echo "25 closed"
A PTR record like spam-relay.old-client.tld tells more about the past address than any scanner. Being able to set your own rDNS in the panel is a sign of an adult host. Outgoing port 25 closed for most tasks is not a problem (and even hygienic), but if you plan your own mail server — this is a hard factor, clarify the unblocking policy in advance.
Check 11. How do services see your IP
Look at ipinfo.io and equivalents: which country is determined, whether the address is marked as hosting/proxy/VPN — and, importantly, open from the server the services you bought it for. Cheap host ranges get banned as whole subnets and ASN for neighbor sins: today it works, tomorrow the entire /24 is banned. This is not something you can fully insure against, but starting from a banned range is definitely not a good idea. If the server is bought to bypass blocks — align with our analysis of block diagnostics to distinguish a service ban from a provider block.
Stage 4. Suitability for tasks: 45–60 minutes
Check 12. TUN, Docker and hoster limits
ls -l /dev/net/tun # should exist
grep -cE "vmx|svm" /proc/cpuinfo # >0 — nested virtualization flags present
Without TUN, WireGuard, OpenVPN, or sing-box in TUN mode won’t work — on KVM it’s always present; on container VPS you need to enable it in the panel, and not all have it at all. Then install Docker and ensure that docker run hello-world works and that required registries are accessible — if images don’t pull, our guide on Docker Hub mirrors helps.
The last item is not a technique, but documentation: reread the hoster’s ToS. Prohibitions on VPN/proxy, fair-use unlimited traffic with a real cap, and response rules to abuses — all of this is clarified in five minutes of reading and saves weeks of ticketing with support.
If you don’t want to assemble commands by hand — there’s a toolkit YABS: curl -sL https://yabs.sh | bash will run fio, iperf3 and Geekbench in one go. It’s convenient for comparing hosts: the output is standardized, and results are easy to place side by side. But stages 3 and 4 (reputation and suitability) aren’t covered by it — you still do them manually.
[security]While acceptance is underway, the server is already being scanned by bots — this happens with any fresh IP in the very first minutes. Do not deploy dashboards and services before basic hardening: login with keys instead of a password, disabled root login, firewall. For Docker stacks remember that Docker bypasses UFW — how to properly close container ports was discussed in the topic about ufw-docker.
[/security]
A one-page acceptance cheat sheet: systemd-detect-virt → vmstat 1 5 (steal ≤ 1–2 %) → free -h → fio randread/randwrite 4k (NVMe = tens of thousands of IOPS) → speedtest-cli twice at different times → mtr in both directions → ping -M do -s 1472 → curl -6 ifconfig.co → Spamhaus + MXToolbox → dig -x → ipinfo.io + the required services → /dev/net/tun → docker run hello-world → ToS. All green — the server is ready to be inhabited: further useful is the roadmap for a home server, much of it is applicable to VPS as well.
Sources
- fio — documentation
- iperf3 — official site
- Spamhaus IP check
- MXToolbox Blacklist Check
- YABS — Yet Another Bench Script
What checks are in your personal acceptance checklist? And name the hosting providers that failed your acceptance — with figures (steal, IOPS, blacklists): such community statistics are more useful than any ratings.