How to Read VDS Network Metrics and What They Really Mean

Main Network Metrics

Before moving on to practical applications, I will discuss what network metrics exist and how they differ. If you already have this knowledge, then feeling confident in it, you can immediately proceed to the second section.

Interface Metrics

These are low-level indicators of the virtual network card — the number of transmitted and received bytes/packets, bandwidth, current transmission speed, as well as error and anomaly counters (CRC errors, dropped/overruns, collisions, etc.). This also includes the maximum frame size (MTU) and duplex/link speed parameters.

All these metrics show how loaded the interface is and whether there are problems at the link layer. In each subsection, I will tell you where to find them in Linux and WS, but, as you understand, the sources are different for everyone.

Where to look in Linux: the command ip -s link (or the outdated ifconfig). You can also check /proc/net/dev.

Where to look in Windows Server: the command netstat -e. In PowerShell, there is Get-NetAdapterStatistics, which outputs similar data for each adapter. You can also use the PerfMon snap-in (Network Interface counters).

TCP/IP Protocol Metrics

Here are all the performance indicators of the protocol stack. For example, the number of active connections and their state, the number of retransmissions of segments indicating packet loss (TCP Retransmits), the level of packet loss, latency, and jitter. This group can also include statistics on UDP, ICMP, and others — they can be viewed through utilities.

Where to look in Linux: ss (outputs a list of connections), ss -s (shows aggregate statistics) or netstat -s.

Where to look in Windows Server: netstat -s in CMD outputs. In PowerShell, you can use Get-NetTCPConnection for a list of TCP connections and Get-NetUDPEndpoint for UDP.

ARP and Related Metrics

ARP is the most important protocol designed to determine the MAC address of another computer based on a known IP. It is not measured in numbers by itself, but the state of the ARP table and the number of ARP requests affect the network.

I will separately highlight the dropped metric — the number of packets dropped by the interface. If drop packets are increasing and overruns are zero, then it's likely not due to channel overload, but rather protocol-related reasons (for example, "extra" VLAN frames).

Where to check in Linux: The RX dropped (when receiving) and TX dropped (when sending) fields in ip -s link or ifconfig.

Where to check in Windows Server: There is no direct command, but Get-NetAdapterStatistics will show discarded packets. Also, PerfMon has counters for "Packets Received Discarded"/"Packets Outbound Discarded".

Packet Loss

Packet loss is a clear symptom of problems along the data path. It can be caused by buffer overflow (then packets are dropped at routers), interference in wireless networks, channel overload, or bugs in the network.

A small packet loss (for example, 0.1%) is acceptable. But anything above a few percent noticeably disrupts operation (especially UDP traffic, streaming, VoIP).

Where to check in Linux: The ping utility (with the -c option) outputs the percentage of lost replies. For tracing and statistics, use mtr (if installed) or traceroute.

Where to check in Windows Server: The percentage of lost packets will be shown by ping (with -n). And tracert — the route tracing command — can only reveal breaks in the route.

Latency and Jitter

The most important metric here is the round-trip time (RTT) of a packet to the target and back. In local networks, latency can be less than 1 ms, while within a single data center, it can reach several milliseconds. In turn, an increase in latency often signals channel congestion or the distance of the node, while jitter — the variation in delays — is critical for voice and video traffic.

Where to check in Linux: Ping measures the RTT (round-trip time) to the target. To measure jitter, you can look at the variation in ping values, while traceroute or tracepath shows the time at each step of the route.

Where to check in Windows Server: Ping also shows latency, while tracert (analogous to traceroute) shows the time to each intermediate node. For analyzing jitter, there is pathping -n, but it is usually assessed by analyzing multiple ping results over a period of time.

As you can see, there are many network metrics, so for a complete picture, it is worth looking at them comprehensively. There is also one important point— both in Linux and in Windows on VDS, you deal with vNIC. Some low-level things (like real collisions) are absent there, as below the hypervisor, all packets are multiplexed into one physical one. CRC errors on a virtual machine are unlikely (there are no “real” electrical signals), so one should primarily trust dynamic metrics—volumes, errors, and losses.

How to read metrics

Knowing the names of counters is one thing, understanding whether it's normal or problematic is another. Therefore, I will explain how to interpret metrics using examples.

There is high load on the interface...

If graphs or ifconfig show that your VDS consistently pushes hundreds of Mbit/s from the available gigabit—the channel is close to saturation. At such times, latencies increase, and new connections are established more slowly.

In turn, high outgoing load (Tx) may be the result of backups, content distribution, or, God forbid, server compromise (spam, DDoS botnet). High incoming load (Rx) indicates that your server is either heavily downloading data or is subjected to heavy incoming traffic (attacker or just a peak in popularity).

During prolonged peaks >80% of the channel, it is advisable to either optimize the software or consider a plan with a larger channel.

There are interface errors...

Ideally, there should be no errors on interfaces, and their appearance indicates there is an issue with transmission. For example, RX errors with an increasing number of frame or CRC errors usually indicate reception problems—either the physical line is suffering, or there are failures at the level of the virtual switch.

Drops and overconsumption have appeared...

RX drops indicate overflow of the incoming queue—the server cannot process network interrupts quickly enough. Often (but not always), the growth of this metric is accompanied by an increase in RX overruns, which definitely confirms packet drops due to backlog overflow in the network stack.

There are retransmissions and packet losses...

Retransmissions at the TCP level are one of the main indicators of network problems. TCP automatically retransmits segments if it does not receive an acknowledgment (ACK) within a certain time.

A small number of retransmits is normal (the network is not perfect), but their increase brings nothing good. The causes include channel overload (yours or along the way), packet loss on the route, or, for example, "remote" network issues (some throttling by the provider). The picture can be supplemented by packet loss measured by the same ping metric.

Determining where exactly packets are lost is helped by traceroute/mtr. By seeing at which node the losses occur, one can understand whose segment it is (your server, the provider's switch, a backbone node, etc.). In general, if the metrics indicate that losses are not local, then the issue lies in the provider's infrastructure.

Response time has increased…

An increase in the average response time to important nodes (databases, APIs, users) indicates either network overload or a "detour" route (for example, traffic is taking a longer path).

If the CPU is not at 100%, the channel is not congested, and latency is still fluctuating — there is a high likelihood that the problem lies with the provider. Only a request can help here, but first, make sure that aggressive QoS has not been enabled on the server, limiting outgoing traffic, for example.

MTU and fragmentation

Incorrectly configured MTU can also lead to hidden problems. For example, if a tunnel sets an MTU smaller than the standard 1500, but the nodes "do not know" about it, fragmentation or packet drops may occur.

For instance, if a ping does not pass at a size of 1472 (which gives 1500 considering headers), but passes at 1464, then somewhere the MTU = 1492 (typical for PPPoE connections). This situation often occurs on VDS when a tunnel is raised inside (you know which one).

My top utilities for network monitoring

In general, the correct interpretation of metrics comes with experience. But one command alone does not make a warrior, so I will share some proven tools:

• iftop — a console utility (Linux) for monitoring network bandwidth in real-time. It is somewhat analogous to top for the network, showing active network connections and how much traffic they generate. It is convenient that the output is divided by pairs of hosts, allowing you to quickly check who is communicating with whom and at what speed.

• NetHogs — another console monitor (Linux), but it groups traffic by processes. Very handy for debugging when it's unclear who is consuming all the internet.

• vnStat — a daemon for collecting traffic statistics by interfaces. It does not show who exactly generated the traffic but keeps aggregate data by days/weeks/months. It is great for finding out how much traffic was used in a month or looking at daily load patterns.

• tcpdump — a console sniffer that allows you to record traffic to a file or quickly filter it. With its help, you can see which packets are being lost and at what stage of the session the failures occur.

• Wireshark — a GUI application for detailed analysis of captured traffic, with protocol decoding. It can highlight TCP Retransmissions (it even marks them in a separate color in the packet list) and indicate the RTT, window, and flags of the segments.

• Netdata — an agent that is installed on the server and immediately starts collecting hundreds of metrics. It has a built-in web interface where you can view colorful graphs of all indicators in real time.

• Prometheus + Grafana — a powerful combination for continuous monitoring of multiple servers. Prometheus collects metrics through special agents, while Grafana displays this data on dashboards.

• ntopng — an advanced network monitor with a web interface, focusing specifically on traffic analysis. It can "dissect" traffic down to the application protocols, shows which IPs and ports are most active, and builds graphs for hosts.

• MTR (My Traceroute) — a console hybrid designed for continuously measuring loss and delays at each node of the route.

• iperf3 — a console utility for testing network bandwidth between two nodes. Unlike wget or speedtest-cli (where speed may be limited by a slow disk or CPU), it generates traffic directly in memory. Roughly speaking, it allows for a "clean" network test between two nodes.

And although this is not a separate tool, I still want to mention a fairly old technique "netstat/ss + grouping". It is needed to sort connections by the number of connects or state. For example, the command ss -tp | grep ESTAB | awk '{print $7}' | sort | uniq -c | sort -nr will show the distribution of TCP connections by processes.

Of course, there are dozens of utilities for visualizing traffic in the console, measuring speed, and monitoring latency... But the ones listed are my personal top for working with VPS.

In the comments, share your life hacks and utilities for analyzing network metrics and let us know what other guides and collections would be useful for you.

© 2026 LLC "MT FINANCE"