Understanding VPS Bandwidth and Traffic Limits: What You’re Actually Paying For

Overview

VPS bandwidth refers to the total amount of data transferred in and out of your server over a billing period — usually one calendar month. Every HTTP request, file download, database query response, email sent, and backup transferred counts toward that number. If your plan includes 2 TB of bandwidth, that’s your monthly ceiling across all traffic your server handles.

Most users run into bandwidth questions for one of three reasons: they’ve received an overage warning, their server is performing unexpectedly slowly near the end of the month, or they’re trying to size a new plan correctly before launching a project. Whichever situation brought you here, this article covers how bandwidth is calculated, how to monitor it, and what your options are when things go sideways.

One thing worth clarifying upfront: bandwidth and speed are different. Bandwidth is a volume measurement (gigabytes transferred). Speed is your port rate (e.g., 1 Gbps). You can have a fast port and still burn through a limited bandwidth allowance very quickly — especially if you’re serving large files or running a busy application.

Prerequisites

• SSH access to your VPS, or access to your hosting control panel (cPanel, Plesk, or the Host & Tech client area)
• Basic familiarity with reading server statistics or control panel graphs
• Your VPS plan details — specifically your monthly bandwidth allowance and what happens on overage (check your welcome email or the VPS SSD Hosting plan page)
• Root or sudo access if you plan to run monitoring commands directly on the server

How VPS Bandwidth Is Actually Measured

This is where most of the confusion lives, so let’s be precise.

Bandwidth is typically measured at the network interface level, not at the application level. That means your hosting provider counts bytes flowing through your VPS’s virtual NIC — before any application-layer compression or filtering. A 500 MB compressed file transfer still counts as 500 MB of bandwidth. SSL/TLS overhead is included. Internal traffic between your VPS and a managed database on the same private network usually isn’t counted, but that depends on the provider and plan.

Most providers, including Host & Tech, measure outbound traffic only on standard VPS plans. Inbound (uploads to your server) typically isn’t counted. Some providers count both directions and bill on the higher of the two, or on the total. Read your plan terms — this matters a lot if you’re running a backup-heavy workload where large amounts of data are being pushed to your server regularly.

📝 Note: On Linux, your server sees the same traffic your provider counts — but the numbers won’t always match perfectly. Tools like vnstat count at the OS level and can miss traffic that occurred before the agent started, or traffic handled at the hypervisor layer. Always treat provider-side statistics as the authoritative number for billing purposes.

Step-by-Step: Monitoring Your Bandwidth Usage

Step 1 — Check Usage in Your Control Panel

The fastest way to see where you stand is in the Host & Tech client area or your cPanel/Plesk dashboard.

• cPanel: Log in, scroll to the right-hand sidebar, and look for the Bandwidth stat. Click it to see a breakdown by month and protocol (HTTP, FTP, SMTP, POP3).
• Plesk: Go to Websites & Domains > Statistics. Bandwidth is shown per domain and in aggregate.
• Host & Tech Client Area: Log in, navigate to Services > My Services, click your VPS, then select the Statistics or Bandwidth tab depending on the plan type.

Step 2 — Install vnstat for Ongoing CLI Monitoring

vnstat is a lightweight, passive bandwidth monitor that reads data from your kernel’s network counters. It’s accurate enough for day-to-day awareness and runs with no performance overhead.

On Debian/Ubuntu:

apt update && apt install vnstat -y
systemctl enable vnstat && systemctl start vnstat

On AlmaLinux / Rocky Linux / CentOS:

dnf install vnstat -y
systemctl enable vnstat && systemctl start vnstat

After a few minutes of collection, run:

vnstat -m

This gives you monthly totals per interface. Your primary interface is usually eth0 or ens3 — run ip a to confirm the name if you’re not sure.

Step 3 — Identify What’s Consuming Bandwidth

If your usage looks higher than expected, you need to find the source. nethogs shows real-time bandwidth consumption broken down by process — it’s the tool I reach for first when something looks off.

apt install nethogs -y   # Debian/Ubuntu
nethogs eth0

Replace eth0 with your actual interface name. You’ll see a live view of which PIDs are pushing the most traffic. A rogue backup job, a misconfigured mail server, or an application sending excessive API calls will show up immediately.

⚠ Warning: If you see an unfamiliar process consuming large amounts of outbound traffic, treat it as a potential security incident. Isolate the process, check /var/log/auth.log for unauthorized access, and contact support. Don’t just kill the process and move on.

Step 4 — Set Up Bandwidth Alerts

Don’t wait until you get an overage warning. If your provider supports threshold alerts (Host & Tech sends email notifications at 80% and 95% usage on most VPS plans), make sure those are enabled in your client area under Account > Notifications.

For server-side alerting, you can pair vnstat with a simple cron job that emails you when monthly usage crosses a threshold:

#!/bin/bash
USAGE=$(vnstat --oneline | awk -F ';' '{print $11}' | sed 's/ GiB//')
LIMIT=1800  # Set this to ~90% of your plan's GB allowance
if (( $(echo "$USAGE > $LIMIT" | bc -l) )); then
  echo "Bandwidth warning: ${USAGE} GiB used" | mail -s "VPS Bandwidth Alert" you@yourdomain.com
fi

Add this to /etc/cron.daily/bw-check and make it executable with chmod +x /etc/cron.daily/bw-check.

What Happens When You Hit Your Limit

This varies by provider and plan, so know yours before you hit the wall. Common outcomes:

• Hard cutoff: Traffic stops. Your server becomes unreachable until the next billing cycle or you purchase additional bandwidth. Rare on managed plans, more common on budget unmanaged VPS.
• Speed throttling: Your port speed drops (e.g., from 1 Gbps to 10 Mbps). The server stays online but becomes very slow. This is the most common approach and is far less disruptive.
• Overage billing: You’re charged per GB over your limit. At Host & Tech, overage rates and throttling behaviour are listed in your plan terms — check the VPS SSD Hosting page or open a support ticket to confirm what applies to your specific plan.

If you’re consistently hitting your limit, upgrading your VPS plan is usually the right call. Trying to artificially suppress traffic through rate limiting can cause real problems for legitimate users.

Common Issues and Troubleshooting

Usage Is Much Higher Than Expected

The most common cause I see is a misconfigured outbound mail server acting as an open relay, or a backup job transferring data over the public interface instead of a private network. Run nethogs to identify the process, then check your mail queue with mailq and your backup configuration. If backups are the culprit, switch them to run over your private/internal network interface if your plan includes one.

Provider Usage Stats Don’t Match vnstat

This is normal and expected. vnstat starts counting from when it was installed, misses traffic at the hypervisor level, and can differ slightly due to how TCP overhead is counted. Always go by the provider’s dashboard for billing-relevant numbers. Use vnstat for trend monitoring, not for disputing invoices.

Server Is Throttled Before the Billing Cycle Ends

If your server has been throttled but you haven’t received a warning email, check your spam folder first — overage alerts often end up there. Log in to your client area to confirm your current usage and available options. Some plans allow you to purchase a bandwidth top-up without waiting for the next cycle. If throttling seems incorrect (e.g., the stat shows you’re only at 60% usage), open a support ticket immediately with a screenshot of your bandwidth graph.

High Bandwidth From a Single IP Address

If nethogs or your access logs show one IP consuming a disproportionate amount of traffic, you may be dealing with a scraper or a DDoS amplification issue. Block the IP temporarily:

iptables -A INPUT -s 203.0.113.45 -j DROP
iptables -A OUTPUT -d 203.0.113.45 -j DROP

Then investigate further. For persistent abuse, consider adding the IP to your firewall’s permanent ruleset via firewalld or ufw, and look at rate limiting in your web server or application layer.

Bandwidth Spike Overnight With No Obvious Cause

Scheduled jobs are almost always the explanation: automated backups, cron-triggered exports, CMS update tasks. Check /var/log/cron and cross-reference timestamps with your bandwidth graph. If the spike is truly unexplained, check for compromised user accounts or unauthorized cron entries with crontab -l for each system user.

FAQ