5 things that novices are advised to do after getting a VPS

I have a strict rule: no matter whether I buy a VPS for hosting websites, running projects, or anything else, I never jump straight into deploying my real workload the moment I get access. The reason is simple — quite a few providers ship images that are far from clean. Some even come with monitoring agents or backdoors. If you don’t test properly and later run into performance issues or weird network behavior, you’ll never know whether it’s overselling, bad hardware, or just some shady pre-installed crap eating resources.

Spending 1–2 hours upfront on a proper checklist saves you dozens of hours of painful debugging later.

Step 1: Benchmark & Fingerprint the Real Hardware

Once you’re in via SSH, don’t install anything yet. Run a testing script first. The goals are:

• Verify actual specs — Does the CPU model, RAM amount and disk performance match what was advertised? If Geekbench 5 single-core is suspiciously low → almost certainly oversold. Disk sequential read/write < 100 MB/s? Trash disk — forget about databases or any I/O-heavy workload.
• Network reality check — What’s the real return path to China? True CN2 GIA, or just bog-standard 163? Late-night packet loss tells you way more about daily experience than the bandwidth number on the sales page. Some providers hide asymmetric routing or different treatment for small/large packets — good test scripts will expose it.
• Streaming unblock check — If you bought an “unlocked” / residential / streaming-optimized IP, you want to confirm whether Netflix, Disney+, HBO, etc. are actually working.

I usually pick one of these two (lately I prefer the second):

Option A — NQ (clean & quick hardware + basic network overview)

bash <(curl -sL https://run.NodeQuality.com)

Option B — “Y融合怪” script (most comprehensive — CPU bench, disk speed, streaming detection, IPv4/IPv6 ASN info, etc.)

bash <(wget -qO- --no-check-certificate https://gitlab.com/spiritysdx/za/-/raw/main/ecs.sh)

Remember: benchmarks ≠ real-world performance, but they’re excellent at revealing blatant overselling or garbage hardware.

Step 2: Wipe & Reinstall a Truly Clean OS

Even when the provider offers a “Debian 12” image, I still reinstall it myself. Why? I want the stock official kernel and zero chance of hidden monitoring processes, extra cron jobs, or telemetry agents.

My go-to is still the Kejilion (科技Lion) reinstall script — very polished, supports most popular distros, and I’m just too lazy to switch now:

bash <(curl -sL kejilion.sh)

Choose reinstall → pick Debian 12 (or your preferred distro).

Critical reminder: After reinstall, SSH will drop. Wait 5–10 minutes, then reconnect. First thing you do after getting back in is change the root password. The default one is usually something trivial and widely known (e.g. LeitboGi0). Change it immediately:

passwd

Step 3: Basic but Non-negotiable Security Hardening

The public internet is brutal. I’ve seen un-hardened fresh servers get dozens of brute-force attempts within minutes. These three things are non-optional on every machine I touch:

1. Move SSH off port 22 (pick anything 20000–65535)

nano /etc/ssh/sshd_config
# Change #Port 22  →  Port 你的端口
systemctl restart sshd

2. Switch to key-only authentication & disable password login

Generate keypair locally (if you haven’t already):

ssh-keygen -t ed25519 -C "[email protected]"

Copy it to the server (use the new port):

ssh-copy-id -p 你的新端口 root@服务器IP

Once key login works, disable password auth:

nano /etc/ssh/sshd_config
# Change PasswordAuthentication yes  →  PasswordAuthentication no
systemctl restart sshd

3. Set up UFW + Fail2Ban

# Firewall — allow your new SSH port + web ports
ufw allow 你的SSH端口/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

# Install & enable Fail2Ban
apt install fail2ban -y
systemctl enable fail2ban
systemctl start fail2ban

Step 4: Basic System Housekeeping

Update everything & set correct timezone

apt update && apt upgrade -y
timedatectl set-timezone Asia/Shanghai

Add swap (especially important on low-memory instances — I usually do 1.5–2× RAM)

fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile
swapon /swapfile
echo '/swapfile none swap sw 0 0' >> /etc/fstab

Swap is slow — it’s only a safety net against OOM kills, not a replacement for real RAM.

Replace DNS (optional / situational)

Some overseas providers have painfully slow default DNS resolvers for Chinese domains. I usually switch to Google + Cloudflare:

sudo tee /etc/resolv.conf <<EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
nameserver 2001:4860:4860::8844
nameserver 2606:4700:4700::1111
EOF

Important exception: If you bought a streaming-unlock / residential IP VPS, the provider almost certainly gave you custom DNS servers. Changing them will break unblocking instantly. Know what you bought.

Step 5: Kernel & TCP Tuning (optional but often worth it)

Debian 12 already ships with BBR enabled, but on high-latency / high-loss international links you can usually squeeze out noticeably better throughput with extra TCP tuning.

Quick & easy: Neko’s TCP script — just choose the recommended preset

bash <(curl -L https://raw.githubusercontent.com/chiakge/Linux-NetSpeed/master/tcp.sh)

More advanced / tailored: tcp.xteko.com optimizer — generates settings based on your memory and measured latency, backs up the original config, easy to revert if it doesn’t help.

Only after these five steps do I consider the machine truly “mine”

Verification gives you confidence in what you bought.
Reinstall gives you a clean foundation.
Hardening lets you sleep at night.
Housekeeping + tuning lets the machine actually perform.

After this checklist, whether I’m running a website, bots, game servers, proxies or anything else — I feel calm and in control.