How to test a VPS or server network speed from the command line

Updated: 2026-10-08

A server has no browser, so the usual speed test sites are no help. You can still measure its real network performance from the terminal. This guide shows how, and how to interpret what you see.

Why test a VPS network

Providers advertise port speeds, but real throughput depends on routing, shared hosts and the time of day. Testing tells you whether you get what you pay for, and which location performs best for your users.

Run PulseTest from the terminal

PulseTest has a command-line tool that uses the same measurement engine as the website. Over SSH, run the one-line installer:

curl -fsSL https://pulsetest.net/ | sudo bash

It works on Linux, macOS and FreeBSD, installs a single command and needs no extra dependencies on most systems. As with any installer you pipe into a shell, you can read the script first by opening https://pulsetest.net/install.sh in your browser.

Then run the test:

pulsetest

The command speedtest also works as a shortcut.

Useful options

• pulsetest -s prints a short, simple result.
• pulsetest -j prints JSON, handy for scripts and monitoring.
• pulsetest -q prints only the essential figures.
• pulsetest --help lists every option.

How to read the results

• Download and upload in Mbps show throughput to the test server. Compare them with your plan’s port speed.
• Ping shows latency to the server, mostly set by distance.
• Jitter shows how stable that latency is. A server can be fast and still jittery.

Get results you can trust

• Test more than once, at different times of day. Shared hosts vary.
• Compare against more than one region, because the result is only as good as the path to the test server.
• Avoid running other heavy transfers during the test.
• Keep a log: run the command from cron and store the output to spot slowdowns that only happen at certain hours.

When results look low

A result far below the advertised speed, repeated at several times, is worth raising with the provider. Include the figures, the times and the test location. Often the answer is a congested host, a throttled plan or a poor route, and a different data centre solves it.