Test VPS Network Speed Across Route, Direction, and Time

A VPS speed test becomes useful only when you can answer which endpoint, route, direction, stream count, protocol, duration, and time window produced it. One attractive Mbps number cannot tell you whether a backup upload, customer download, database sync, or interactive session will meet its requirement tomorrow.

Here, mtr and iperf3 build a bounded network receipt. The tested path records route behavior, one-stream upload, one-stream download, aggregate throughput, UDP quality at a declared offered rate, and repeated samples. The goal is not to manufacture the largest result. It is to preserve enough context for a buyer or operator to make the next decision without guessing.

Requirements: SSH access to a Debian or Ubuntu VPS, permission to generate short traffic bursts, and an authorized second endpoint. A public iperf3 server is acceptable for screening; formal provider acceptance deserves a controlled endpoint whose location, port, load, and ownership you can keep constant. The UDP receiver check below also requires iperf3 3.21+; older clients can report false zero loss against older servers.

Freeze the Test Contract Before Moving Traffic

Two results are comparable only when their material conditions match. Before opening iperf3, write down the application direction and the minimum result that matters. A nightly backup might care about sustained VPS-to-storage upload. Software distribution usually cares about download from the VPS. Voice or game traffic may care more about latency variation and loss at a modest rate than maximum TCP throughput.

Use one row per test window:

One more baseline matters: ensure the VPS itself is not already CPU-bound. If application work is slow while raw network tests are healthy, check VPS CPU steal evidence before assigning the symptom to the path.

Create a guarded receipt directory

Preparation begins by installing maintained distribution packages, freezing the endpoint variables, resolving the target once, and placing every JSON artifact inside one guarded temporary directory. Replace the example endpoint with your controlled server when possible. Public servers can be busy, and their operators may publish a range of ports rather than one permanent process.

set -euo pipefail

sudo apt-get update
sudo apt-get install -y iperf3 mtr-tiny jq

export TEST_HOST="ping.online.net"
export TEST_PORT="5201"
export TEST_SECONDS="10"
export UDP_RATE="50M"
export LAB_ROOT="$(mktemp -d /tmp/vps-network-receipt.XXXXXX)"
export TEST_IP="$(getent ahostsv4 "$TEST_HOST" | awk 'NR==1 {print $1}')"
test -n "$TEST_IP"

date -u +'%Y-%m-%dT%H:%M:%SZ'
iperf3 --version | head -n 1
mtr --version
ip -brief link
printf 'target=%s ip=%s port=%s\n' "$TEST_HOST" "$TEST_IP" "$TEST_PORT"
ip route get "$TEST_IP"

Keep the version in the receipt. ESnet documents current iperf3 client/server, reverse, JSON, duration, and parallel options, but old third-party pages still contain stale ports and versions. The executable installed on the tested host is the immediate option authority for that run.

Record the Route Separately from Throughput

mtr combines traceroute-style TTL discovery with repeated response timing. It does not push an application-sized bulk stream. Its job here is to show which route answered and whether loss or latency continues to the destination during the same window.

TCP probes target the iperf3 control port, which is closer to the later test path than an unrelated ICMP-only check:

set -euo pipefail
: "${TEST_HOST:?Run the context block first}"
: "${TEST_PORT:?Run the context block first}"

mtr --tcp --port "$TEST_PORT" \
  --report-wide --report-cycles 20 \
  "$TEST_HOST" | tee "$LAB_ROOT/mtr-tcp.txt"

Debian’s mtr manual defines report cycles, TCP probes, target ports, response loss, and round-trip fields. Interpret them end to end. An intermediate router can forward packets normally while limiting its own probe replies. Do not blame hop 6 merely because hop 6 answers 40% of probes if later hops and the destination answer without corresponding loss.

Route evidence also prevents a location mistake. A test from one European VPS to one nearby endpoint says nothing about latency from Sydney customers, and a test from an office connection includes that access network. Use client regions that represent the real workload.

Measure One Flow in Both Directions

Start with one ordinary TCP stream. This asks a useful application-like question: what throughput can one well-designed flow achieve between these two endpoints under current conditions? JSON output preserves exact sender and receiver summaries for later comparison.

set -euo pipefail
: "${TEST_HOST:?Run the context block first}"
: "${TEST_PORT:?Run the context block first}"

iperf3 -c "$TEST_HOST" -p "$TEST_PORT" \
  -t "$TEST_SECONDS" -O 1 --connect-timeout 5000 --json \
  | tee "$LAB_ROOT/single-upload.json"

jq '{receiver_mbps:(.end.sum_received.bits_per_second/1000000),
     retransmits:(.end.sum_sent.retransmits//0)}' \
  "$LAB_ROOT/single-upload.json"

Default client mode sends from this VPS toward the server. The receiver summary is normally the useful delivered-throughput value. Retransmits add context, but a nonzero count alone does not identify congestion, host pressure, path loss, or a receiver limit.

Reverse direction is a separate test, not a cosmetic label:

set -euo pipefail
: "${TEST_HOST:?Run the context block first}"
: "${TEST_PORT:?Run the context block first}"

iperf3 -c "$TEST_HOST" -p "$TEST_PORT" \
  -t "$TEST_SECONDS" -O 1 --reverse \
  --connect-timeout 5000 --json \
  | tee "$LAB_ROOT/single-download.json"

jq '{reverse:(.start.test_start.reverse==1),
     receiver_mbps:(.end.sum_received.bits_per_second/1000000),
     retransmits:(.end.sum_sent.retransmits//0)}' \
  "$LAB_ROOT/single-download.json"

In the final reproduced lab, one-stream forward delivery was about 892 Mbps, while reverse delivery was about 998 Mbps. That difference is an observation for one route and window, not a product guarantee and not proof that the VPS port itself is asymmetric. Endpoint load, TCP behavior, peering, traffic shaping, and each host can contribute.

Ask a Different Question with Parallel TCP and Capped UDP

Several simultaneous TCP streams may reach aggregate headroom that one flow does not. Current iperf3 threading guidance notes that version 3.16 and later use one thread per test stream. That matters on very fast paths, but parallelism still changes the workload shape.

set -euo pipefail
: "${TEST_HOST:?Run the context block first}"
: "${TEST_PORT:?Run the context block first}"

iperf3 -c "$TEST_HOST" -p "$TEST_PORT" \
  -t "$TEST_SECONDS" -O 1 --parallel 4 \
  --connect-timeout 5000 --json \
  | tee "$LAB_ROOT/parallel-upload.json"

jq '{streams:.start.test_start.num_streams,
     receiver_mbps:(.end.sum_received.bits_per_second/1000000),
     retransmits:(.end.sum_sent.retransmits//0)}' \
  "$LAB_ROOT/parallel-upload.json"

Four streams reached about 976 Mbps versus 892 Mbps with one, while the parallel sender summary recorded 444 retransmits versus 45. That does not make four streams “more accurate.” It proves that single-flow and aggregate capacity are different reader decisions. Preserve both when the application includes each shape.

UDP removes TCP’s retransmission behavior and reports jitter and loss, but only at the rate you offer. Begin below the expected limit and increase deliberately. An uncapped flood can disrupt production and teaches little about the workload’s actual requirement.

Use iperf3 3.21+ for this receiver check. The iperf3 3.21 release fixes a false zero-loss result that could appear when a client queried an older server. The command fails closed on an older client, requests the server’s text receipt, and reads the receiver-marked JSON object rather than the sender summary.

set -euo pipefail
: "${TEST_HOST:?Run the context block first}"
: "${TEST_PORT:?Run the context block first}"
: "${UDP_RATE:=50M}"

IPERF_VERSION="$(iperf3 --version | awk 'NR==1 {print $2}')"
dpkg --compare-versions "$IPERF_VERSION" ge 3.21 || {
  printf 'iperf3 3.21+ is required for receiver-accurate UDP loss\n' >&2
  exit 1
}

iperf3 -c "$TEST_HOST" -p "$TEST_PORT" \
  -t "$TEST_SECONDS" -O 1 --udp --bitrate "$UDP_RATE" \
  --connect-timeout 5000 --get-server-output --json \
  | tee "$LAB_ROOT/udp-quality.json"

jq '{offered_bps:.start.test_start.target_bitrate,
     receiver_mbps:(.end.sum_received.bits_per_second/1000000),
     loss_percent:.end.sum_received.lost_percent,
     jitter_ms:.end.sum_received.jitter_ms,
     receiver_summary:(.end.sum_received.sender==false)}' \
  "$LAB_ROOT/udp-quality.json"

At an offered 50 Mbit/s, the iperf3 3.21 rerun received 49.99 Mbps with 0% receiver-reported loss and about 0.021 ms jitter. The server text also recorded 0/17481 lost datagrams. The valid statement ends there: this short sample passed at 50M. It does not prove zero loss at 500M, during peak traffic, or from another region.

Repeat the Same Shape Instead of Saving the Best Run

One run can land in a favorable or unfavorable interval. Repeat the same endpoint, port, direction, object, duration, and client region. Public iperf3 servers are useful for screening, but a busy process can force a port change and invalidate a strict comparison. For the repeatability receipt, stage one non-sensitive fixed-size object on an HTTPS origin you control, record its byte size and checksum, and keep host, resolved origin, port, path, object, and client unchanged.

set -euo pipefail
: "${LAB_ROOT:?Run the context block first}"
: "${CONTROLLED_HOST:?Set the HTTPS hostname you control}"
: "${CONTROLLED_ORIGIN_IP:?Set its fixed origin IP privately}"
: "${CONTROLLED_PATH:?Set the stable test-object path}"

CONTROLLED_PORT="443"
for attempt in 1 2 3; do
  started_at="$(date -u +'%Y-%m-%dT%H:%M:%SZ')"
  raw="$LAB_ROOT/curl-$attempt.json"
  output="$LAB_ROOT/repeat-$attempt.json"

  curl --fail --silent --show-error --location \
    --resolve "${CONTROLLED_HOST}:${CONTROLLED_PORT}:${CONTROLLED_ORIGIN_IP}" \
    --output /dev/null \
    --write-out '{"http_code":%{http_code},"remote_ip":"%{remote_ip}","remote_port":%{remote_port},"size_download":%{size_download},"speed_download":%{speed_download},"time_total":%{time_total}}' \
    "https://${CONTROLLED_HOST}${CONTROLLED_PATH}" > "$raw"

  jq -e --arg started "$started_at" --arg host "$CONTROLLED_HOST" \
    --arg path "$CONTROLLED_PATH" '
      . + {started_at_utc:$started,host:$host,path:$path}
      | select(.http_code==200 and .remote_port==443 and
               .size_download>0 and .speed_download>0 and .time_total>0)
    ' "$raw" | tee "$output"
  sleep 10
done

jq -s '
  [.[].speed_download*8/1000000] as $mbps
  | {samples:length, timestamps:[.[].started_at_utc],
     host:.[0].host, port:.[0].remote_port, path:.[0].path,
     remote_ip_consistent:([.[].remote_ip]|unique|length==1),
     object_bytes:([.[].size_download]|unique),
     receiver_mbps:($mbps|map(. * 100 | round / 100)),
     spread_percent_of_max:(((($mbps|max)-($mbps|min))/($mbps|max)*100)
                            *100|round/100)}
  ' "$LAB_ROOT"/repeat-*.json | tee "$LAB_ROOT/repeat-summary.json"

The controlled rehearsal downloaded the same 67,108,864-byte object from the same origin IP on HTTPS port 443 at 14:33:23, 14:33:34, and 14:33:44 UTC. Delivered rates were 846.66, 827.19, and 581.78 Mbps, a 31.28% max-to-min spread. The result proves short-window variability on that fixed path; it does not establish a daily percentile or another region. The public endpoint directory still matters for the earlier iperf3 screening tests because public processes can be busy and available ports can change.

Read the Receipt Without Overclaiming

Below, the representative observed block condenses the successful Debian lab. Local addressing is redacted; remote identity, port changes, direction, stream count, rates, retransmits, UDP cap, and repeat spread remain visible.

{
  "public_tested_at_utc": "2026-08-09T14:48:38Z",
  "client": "Debian 13, Linux 6.12.96, iperf3 3.18 TCP / 3.21 UDP, mtr 0.95",
  "region_scope": "European client to Paris public iperf3; fixed repeat to controlled German origin",
  "public_iperf": {"host": "ping.online.net", "ip": "51.158.1.21", "test_seconds": 4, "omit_seconds": 1},
  "mtr_final_hop": {"protocol": "TCP", "port": 5201, "cycles": 10, "loss_percent": 0, "avg_ms": 12.5},
  "single_upload": {"protocol": "TCP", "direction": "client_to_server", "port": 5201, "receiver_mbps": 892.36, "retransmits": 45},
  "single_download": {"protocol": "TCP", "direction": "server_to_client", "port": 5204, "receiver_mbps": 997.69, "retransmits": 0},
  "parallel_upload": {"protocol": "TCP", "direction": "client_to_server", "port": 5204, "streams": 4, "receiver_mbps": 976.20, "retransmits": 444},
  "udp_50M": {"protocol": "UDP", "client_version": "3.21", "direction": "client_to_server", "port": 5204, "offered_mbps": 50, "receiver_mbps": 49.99, "loss_percent": 0, "jitter_ms": 0.021, "receiver_summary": true},
  "fixed_repeat_download": {
    "protocol": "HTTPS over TCP",
    "direction": "controlled_origin_to_client",
    "host": "www.voxfor.com",
    "origin_ip": "redacted from public receipt; retained in private lab log",
    "port": 443,
    "path": "/voxfor-network-repeat-112-20260809T142800Z.bin",
    "object_bytes": 67108864,
    "timestamps_utc": ["14:33:23", "14:33:34", "14:33:44"],
    "receiver_mbps": [846.66, 827.19, 581.78],
    "spread_percent_of_max": 31.28
  },
  "receipt_verification": "pass",
  "capacity_verdict": "not set: no reader workload threshold supplied"
}

Hop 6 answered only 40% of MTR probes while the destination answered all ten in that sample. Later-hop recovery prevents an intermediate response policy from becoming a false loss diagnosis. When destination loss does persist, correlate it with Linux softnet receive-path counters before deciding whether the guest, virtual NIC, host, or upstream path owns the drop.

Another mismatch has a different owner: small probes may succeed while larger encrypted traffic stalls. That pattern belongs to WireGuard MTU and PMTU verification, not to a generic demand for more bandwidth.

Verify completeness before judging capacity

Evidence completeness is machine-checkable. Capacity acceptance is workload-specific. This verification requires the expected files, rejects iperf3 errors, checks positive delivered rates, confirms reverse mode, checks four-stream identity, and requires the UDP offered rate to be recorded. Replace MIN_REQUIRED_MBPS with a real workload threshold only after choosing the relevant direction and sample window.

set -euo pipefail
: "${LAB_ROOT:?Run the context block first}"

for file in single-upload single-download parallel-upload udp-quality; do
  test -s "$LAB_ROOT/$file.json"
  jq -e '.error == null' "$LAB_ROOT/$file.json" >/dev/null
done

jq -e '.end.sum_received.bits_per_second > 0' \
  "$LAB_ROOT/single-upload.json" >/dev/null
jq -e '.start.test_start.reverse == 1 and .end.sum_received.bits_per_second > 0' \
  "$LAB_ROOT/single-download.json" >/dev/null
jq -e '.start.test_start.num_streams == 4 and .end.sum_received.bits_per_second > 0' \
  "$LAB_ROOT/parallel-upload.json" >/dev/null
jq -e '.start.test_start.protocol == "UDP" and .start.test_start.target_bitrate > 0' \
  "$LAB_ROOT/udp-quality.json" >/dev/null
UDP_VERSION="$(jq -r '.start.version | capture("iperf (?<v>[0-9.]+)").v' \
  "$LAB_ROOT/udp-quality.json")"
dpkg --compare-versions "$UDP_VERSION" ge 3.21
jq -e '.end.sum_received.sender == false and
       .end.sum_received.bits_per_second > 0 and
       .end.sum_received.lost_percent >= 0 and
       .end.sum_received.jitter_ms >= 0 and
       (.server_output_text | contains("receiver"))' \
  "$LAB_ROOT/udp-quality.json" >/dev/null

test -s "$LAB_ROOT/mtr-tcp.txt"
grep -Eq "${TEST_HOST}|${TEST_IP}" "$LAB_ROOT/mtr-tcp.txt"

test "$(find "$LAB_ROOT" -maxdepth 1 -name 'repeat-[123].json' | wc -l)" -eq 3
jq -s -e '
  ([.[].http_code]|all(.==200)) and
  ([.[].remote_ip]|unique|length==1) and
  ([.[].remote_port]|unique==[443]) and
  ([.[].host]|unique|length==1) and
  ([.[].path]|unique|length==1) and
  ([.[].size_download]|unique|length==1) and
  ([.[].started_at_utc]|unique|length==3) and
  ([.[].speed_download]|length==3 and all(.>0))
' "$LAB_ROOT"/repeat-[123].json >/dev/null
jq -e '.samples==3 and .remote_ip_consistent==true and
       (.object_bytes|length)==1 and
       (.receiver_mbps|length)==3 and .spread_percent_of_max>=0' \
  "$LAB_ROOT/repeat-summary.json" >/dev/null

printf '%s\n' 'receipt_acceptance=pass'
printf '%s\n' 'capacity_acceptance=not_evaluated_without_declared_threshold'

Now translate the receipt into the decision it can actually support:

For purchase planning, compare the resulting threshold with Voxfor lifetime VPS plans; listed plan context cannot substitute for route-specific evidence. Sustained-versus-burst findings can then inform dedicated or cloud workload placement, while measured transfer requirements should enter a twelve-month VPS budget as explicit assumptions.

Raw network throughput still does not prove a website works for customers. Keep login, checkout, DNS, TLS, and recovery transactions inside customer-journey uptime monitoring after the infrastructure baseline passes.

Remove Only the Disposable Receipt

No service, firewall, kernel, or production configuration was changed by this measurement path. Cleanup removes only the guarded temporary JSON directory and unsets the test variables. Keep copies elsewhere first if the receipt belongs in an incident or procurement record.

set -euo pipefail
: "${LAB_ROOT:?LAB_ROOT is not set}"

case "$LAB_ROOT" in
  /tmp/vps-network-receipt.*)
    rm -rf -- "$LAB_ROOT"
    ;;
  *)
    printf 'Refusing unexpected cleanup path: %s\n' "$LAB_ROOT" >&2
    exit 1
    ;;
esac

unset TEST_HOST TEST_PORT TEST_SECONDS UDP_RATE TEST_IP
unset CONTROLLED_HOST CONTROLLED_ORIGIN_IP CONTROLLED_PATH CONTROLLED_PORT LAB_ROOT
printf '%s\n' 'cleanup=pass'

Remove the fixed test object from the controlled HTTPS endpoint only after checking its exact path and expected byte size; the reproduced lab required 67,108,864 bytes and verified absence after unlink. If you opened a firewall port on your own iperf3 server, remove only that temporary rule after confirming no other service uses it. Never leave a public unauthenticated throughput listener running merely because the client test finished.

Keep the Receipt, Not Just the Peak Mbps

A defensible VPS network result is a small chain of evidence. Route context prevents false hop attribution. Forward and reverse tests preserve direction. One and multiple streams keep application flow separate from aggregate headroom. Capped UDP states the quality question honestly. Repeated windows expose variation.

Pass the receipt before passing the plan. When every field is present, the evidence is complete. Only the reader’s declared workload threshold can decide whether that network path is suitable.