{"id":1203,"date":"2026-09-22T22:42:03","date_gmt":"2026-09-22T22:42:03","guid":{"rendered":"https:\/\/virtualserversvps.com\/blog\/?p=1203"},"modified":"2026-09-22T22:42:03","modified_gmt":"2026-09-22T22:42:03","slug":"ebpf-tcpdump-find-packet-loss-vps-uplink","status":"publish","type":"post","link":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/","title":{"rendered":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing"},"content":{"rendered":"\n<p class=\"wp-block-paragraph\">Packet loss on a VPS uplink is reported by three different layers, and they disagree. Increase <code>netstat -s<\/code> counters point at the kernel stack, <code>ifconfig<\/code> drop counters point at the virtual interface, and the provider&#8217;s SLA refers to a physical link you cannot see. This article walks the tooling that isolates where the loss actually happens: tcpdump for capture, <code>nstat<\/code> for kernel counters, and a small eBPF program to attribute drops to a specific point in the receive path.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Start with counters &mdash; three of them, not one<\/h2>\n\n\n\n<pre class=\"wp-block-code\"><code># kernel stack errors\nnstat -az | grep -Ei 'drop|error|retrans|overflow|prune|collaps'\n# virtual interface drops\nip -s link show eth0\n# per-socket retransmit rate\nss -ti | grep -oE 'retrans:[0-9\/]+' | head\n# tcpdump-level: is it loss or latency? watch SYN\/ACK on a probe\ntcpdump -ni eth0 -c 200 'tcp[tcpflags] &amp; tcp-syn != 0'<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">Each counter means something specific. <code>TcpExtListenOverflows<\/code> and <code>TcpExtListenDrops<\/code> are application-side: the accept queue filled. <code>TcpExtTCPBacklogDrop<\/code> is the same queue at a different stage. <code>TcpRetransSegs<\/code> is loss as TCP saw it, whether the loss was upstream, downstream, or self-inflicted by a buffer overflow. <code>ifconfig<\/code>&#8216;s RX dropped is the NIC or virtual switch discarding before the kernel ever counts it. Map the symptom to the layer with the table below.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table><thead><tr><th>Counter<\/th><th>Layer<\/th><th>Meaning<\/th><th>Typical fix<\/th><\/tr><\/thead><tbody><tr><td><code>TcpExtListenOverflows<\/code><\/td><td>Application<\/td><td>Accept queue full, app not calling accept()<\/td><td>Raise <code>net.core.somaxconn<\/code>, fix slow app<\/td><\/tr><tr><td><code>TcpExtListenDrops<\/code><\/td><td>Application<\/td><td>SYN dropped because queue full<\/td><td>Same, plus increase backlog in app<\/td><\/tr><tr><td><code>TcpRetransSegs<\/code><\/td><td>TCP<\/td><td>Segment lost or ACK lost<\/td><td>Investigate path, not the server<\/td><\/tr><tr><td><code>TcpExtTCPRcvCollapsed<\/code><\/td><td>Kernel memory<\/td><td>Receive buffer too small<\/td><td>Raise <code>tcp_rmem<\/code> max<\/td><\/tr><tr><td><code>ifconfig RX dropped<\/code><\/td><td>NIC \/ virtual switch<\/td><td>Hardware or hypervisor discard<\/td><td>Provider-side, raise queue<\/td><\/tr><tr><td><code>UdpRcvbufErrors<\/code><\/td><td>Socket<\/td><td>UDP buffer overflow<\/td><td>Raise <code>net.core.rmem_max<\/code><\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n<p class=\"wp-block-paragraph\">The distinction that saves the most time: server-side counters explain loss the <em>server<\/em> caused. A steady <code>TcpRetransSegs<\/code> climb with clean listen counters and zero receive-buffer collapses means the loss is on the path, and no amount of server tuning will remove it. Choosing a provider whose network is actually sized for the workload is the real fix, which is why <a href=\"https:\/\/virtualserversvps.com\/\">network tier and peering quality<\/a> belong in the buying decision rather than being an afterthought.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">tcpdump correctly &mdash; and its limits<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\"><code>tcpdump<\/code> sees packets that reached the socket layer, so it cannot prove loss on the wire. It can prove the opposite: if a SYN arrives and no SYN-ACK leaves within a few milliseconds, the drop is server-side. If retransmissions appear in the capture without corresponding duplicates, the loss is upstream of the capture point.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># watch retransmits and duplicate ACKs for one flow, ring-buffer to limit disk use\ntcpdump -ni eth0 -s 96 -W 10 -C 50 \\\n  'host 203.0.113.10 and (tcp[tcpflags] &amp; (tcp-syn|tcp-fin|tcp-rst) != 0)' -w \/tmp\/probe.pcap\n\n# after capture, count retransmissions and duplicates\ntcpdump -nr \/tmp\/probe.pcap 'tcp[tcpflags] &amp; tcp-ack != 0' | wc -l\ntshark -r \/tmp\/probe.pcap -Y 'tcp.analysis.retransmission || tcp.analysis.duplicate_ack' -T fields -e tcp.seq 2&gt;\/dev\/null | wc -l<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The critical caveat: drop counters you see in tcpdump output (&#8220;packets dropped by kernel&#8221;) mean tcpdump itself could not keep up, not that the network lost packets. On a busy VPS, always filter before capturing rather than capturing everything, and note the drop count printed at the end of a run. A capture with self-reported drops is not evidence of network loss.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">eBPF for attribution when counters are ambiguous<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">When <code>nstat<\/code> shows drops but nothing points to a cause, a tracepoint on the kernel&#8217;s drop function gives the exact reason and call site. <code>skb:kfree_skb<\/code> fires for every dropped packet and carries the reason code, which is the missing link between &#8220;we dropped 4,000 packets&#8221; and &#8220;we dropped them because the socket receive queue was full.&#8221;<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Option 1: bpftrace &mdash; count drops by reason code (kernel \/dev\/null || sudo \/usr\/sbin\/tcpdrop-bpfcc<\/code><\/pre>\n\n\n\n<p class=\"wp-block-paragraph\">The reason codes that matter in practice: <code>NO_SOCKET<\/code> means no matching listener or connection (port scanning, or a service that died); <code>TCP_ABORT_ON_CLOSE<\/code> and <code>TCP_RESET<\/code> are reset-driven; <code>SOCKET_FILTER<\/code> means your own iptables\/nftables or eBPF filter discarded it; <code>QDST_COALESCE<\/code> and <code>MEMORY<\/code> mean kernel memory pressure on queues. If you see <code>SOCKET_FILTER<\/code>, the &#8220;network loss&#8221; is your own firewall and the investigation ends at <code>nft list ruleset<\/code>.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">One practical note on VPS kernels: <code>bpftrace<\/code> and bcc need matching kernel headers (<code>linux-headers-$(uname -r)<\/code>) and a kernel with BTF or a full debuginfo set. On providers that ship custom kernels without headers, install the headers first &mdash; if they are unavailable, use <code>tcpdrop<\/code> from the kernel&#8217;s own <code>tools\/bpf<\/code> only after verifying <code>\/sys\/kernel\/btf\/vmlinux<\/code> exists. Container-based VPS plans often restrict <code>bpf()<\/code> with seccomp, so run these on the host, not inside a Docker container.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Putting it together<\/h2>\n\n\n\n<p class=\"wp-block-paragraph\">The decision order is: <code>nstat<\/code> first to classify the layer, <code>tcpdump<\/code> second to confirm which direction a flow fails in, and eBPF third only when counters show a drop with no identifiable cause. In most incidents involving a self-managed VPS, the answer is in the first command &mdash; either a listen overflow from an application that stopped accepting, or a steady retransmit rate that turns out to be a congested path outside the server entirely.<\/p>\n\n\n\n<p class=\"wp-block-paragraph\">When everything above comes back clean and loss persists, the constraint is provider-side: an oversubscribed uplink, a saturated virtual switch, or a peering path with insufficient capacity at peak hours. At that point no sysctl will help, and the decision becomes a procurement one. The <a href=\"https:\/\/virtualserversvps.com\/\">VPS performance and network tier comparison<\/a> is the place to check before migrating, because a host on a congested shared uplink will reproduce the same loss pattern on any configuration you apply.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Map packet-loss symptoms to the layer that caused them using kernel counters, targeted tcpdump captures, and eBPF kfree_skb reason codes. Includes a counter-to-cause reference table.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":0,"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1203","post","type-post","status-publish","format-standard","hentry","category-performance-optimization"],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v26.1 (Yoast SEO v26.1) - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing - Virtual Servers VPS Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing\" \/>\n<meta property=\"og:description\" content=\"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing\" \/>\n<meta property=\"og:url\" content=\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/\" \/>\n<meta property=\"og:site_name\" content=\"Virtual Servers VPS Blog\" \/>\n<meta property=\"article:published_time\" content=\"2026-09-22T22:42:03+00:00\" \/>\n<meta name=\"author\" content=\"Virtual-Servers-Vps-Editor\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Virtual-Servers-Vps-Editor\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/\",\"name\":\"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing - Virtual Servers VPS Blog\",\"isPartOf\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\"},\"datePublished\":\"2026-09-22T22:42:03+00:00\",\"author\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\"},\"breadcrumb\":{\"@id\":\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\/\/virtualserversvps.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#website\",\"url\":\"https:\/\/virtualserversvps.com\/blog\/\",\"name\":\"Virtual Servers VPS Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0\",\"name\":\"Virtual-Servers-Vps-Editor\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g\",\"caption\":\"Virtual-Servers-Vps-Editor\"},\"sameAs\":[\"https:\/\/virtualserversvps.com\/blog\"],\"url\":\"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing - Virtual Servers VPS Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/","og_locale":"en_US","og_type":"article","og_title":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing","og_description":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing","og_url":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/","og_site_name":"Virtual Servers VPS Blog","article_published_time":"2026-09-22T22:42:03+00:00","author":"Virtual-Servers-Vps-Editor","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Virtual-Servers-Vps-Editor","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/","url":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/","name":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing - Virtual Servers VPS Blog","isPartOf":{"@id":"https:\/\/virtualserversvps.com\/blog\/#website"},"datePublished":"2026-09-22T22:42:03+00:00","author":{"@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0"},"breadcrumb":{"@id":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/virtualserversvps.com\/blog\/ebpf-tcpdump-find-packet-loss-vps-uplink\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/virtualserversvps.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Finding Packet Loss on a VPS Uplink with tcpdump, nstat, and eBPF Drop Tracing"}]},{"@type":"WebSite","@id":"https:\/\/virtualserversvps.com\/blog\/#website","url":"https:\/\/virtualserversvps.com\/blog\/","name":"Virtual Servers VPS Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/virtualserversvps.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/82a299a8284a66ff49f97c74684724a0","name":"Virtual-Servers-Vps-Editor","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/virtualserversvps.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d820b15f1cd028e97610d9adf536df7be5cb6423869967037d468d5355fa003f?s=96&d=mm&r=g","caption":"Virtual-Servers-Vps-Editor"},"sameAs":["https:\/\/virtualserversvps.com\/blog"],"url":"https:\/\/virtualserversvps.com\/blog\/author\/virtualserversvps\/"}]}},"_links":{"self":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1203","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/comments?post=1203"}],"version-history":[{"count":1,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1203\/revisions"}],"predecessor-version":[{"id":1205,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/posts\/1203\/revisions\/1205"}],"wp:attachment":[{"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/media?parent=1203"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/categories?post=1203"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/virtualserversvps.com\/blog\/wp-json\/wp\/v2\/tags?post=1203"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}