BestHub
Sign in
Operations 19 min read

How to Diagnose and Fix Network Packet Loss in Nginx on Linux

This guide walks through identifying severe packet loss affecting Nginx, using hping3, netstat, ethtool, iptables, and tcpdump, then resolves the issue by removing a faulty netem rule and correcting an MTU misconfiguration, ultimately restoring normal HTTP responses.

MaGe Linux Operations
MaGe Linux Operations
MaGe Linux Operations
How to Diagnose and Fix Network Packet Loss in Nginx on Linux

What is packet loss?

Packet loss occurs when data packets are discarded before reaching the application, and the loss rate (lost packets ÷ total packets) is a key network performance metric. High loss degrades TCP performance, causing congestion, retransmissions, increased latency, and reduced throughput.

1. Where can loss happen?

Using Nginx as an example, we run hping3 -c 10 -S -p 80 192.168.0.30 to test connectivity. The output shows 10 packets sent, only 5 replies received (50% loss) and RTT ranging from 3 ms to 3 s, indicating serious loss.

# -c sends 10 packets, -S uses TCP SYN, -p sets port 80
hping3 -c 10 -S -p 80 192.168.0.30

HPING 192.168.0.30 (eth0 192.168.0.30): S set, 40 headers + 0 data bytes
len=44 ip=192.168.0.30 ttl=63 DF id=0 sport=80 flags=SA seq=3 win=5120 rtt=7.5 ms
... (output truncated)
10 packets transmitted, 5 packets received, 50% packet loss
round-trip min/avg/max = 3.0/609.7/3027.2 ms

The loss could occur anywhere in the protocol stack. A diagram (not shown) illustrates that every layer—from the virtual machines to the socket layer—can drop packets.

VM‑to‑VM transmission errors (congestion, line errors)

Ring buffer overflow on the NIC

Link‑layer frame errors or QoS drops

IP‑layer routing or MTU issues

Transport‑layer port or resource limits

Socket‑layer buffer overflow

Application‑layer crashes

iptables filtering

2. Link‑layer inspection

Check NIC statistics with netstat -i and ethtool. The NIC shows no errors, but a tc qdisc netem rule is configured with a 30% loss probability.

tc -s qdisc show dev eth0
qdisc netem 800d: root refcnt 2 limit 1000 loss 30%
 Sent 432 bytes 8 pkt (dropped 4, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0

Removing the rule fixes the loss: tc qdisc del dev eth0 root netem loss 30% After deletion, running hping3 again shows 0% loss.

10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 3.3/7.9/15.0 ms

3. Network and transport layers

Use netstat -s to view protocol counters. TCP reports 11 failed connection attempts, 4 retransmissions, 11 embryonic SYN resets, 4 SYN retransmits, and 7 timeouts, confirming TCP‑level issues but not pinpointing the root cause.

# netstat -s (excerpt)
Tcp:
  11 failed connection attempts
  4 segments retransmitted
  11 resets received for embryonic SYN_RECV sockets
  4 TCPSynRetrans
  7 TCPTimeouts

4. iptables check

Inspect the filter table. Two DROP rules using the statistic module drop 30% of all packets on INPUT and OUTPUT chains.

iptables -t filter -nvL
Chain INPUT (policy ACCEPT)
 pkts bytes target prot opt in out source destination
   6   240 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.3
Chain OUTPUT (policy ACCEPT)
   6   264 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 statistic mode random probability 0.3

Delete both rules:

iptables -t filter -D INPUT -m statistic --mode random --probability 0.30 -j DROP
iptables -t filter -D OUTPUT -m statistic --mode random --probability 0.30 -j DROP

5. tcpdump investigation

Capture traffic on port 80 while running curl. The handshake completes, but after 3 seconds the client sends a FIN, causing the curl timeout. No HTTP GET packet is observed.

tcpdump -i eth0 -nn port 80
... (output shows SYN, SYN‑ACK, ACK, then FIN after 3 s)

Checking NIC counters with netstat -i reveals a large receive‑drop count (RX‑DRP = 344) and an unusually low MTU of 100 on eth0.

netstat -i
Iface  MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR
eth0   100 157   0     344    0      94    0     0     0

The tiny MTU fragments packets, causing the GET request to be dropped. Increase MTU to the standard 1500: ifconfig eth0 mtu 1500 After the change, curl receives the full HTML response from Nginx, confirming that both the netem rule and the MTU misconfiguration were the culprits.

<!DOCTYPE html>
<html>...
<p><em>Thank you for using nginx.</em></p>
</body>
</html>

In summary, the packet‑loss problem was solved by removing a random‑drop netem rule and correcting the NIC MTU, restoring normal HTTP service.

Flow graph showing handshake and FIN after timeout
Flow graph showing handshake and FIN after timeout
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

network troubleshootingiptablesMTUtcpdumpPacket Loss
MaGe Linux Operations
Written by

MaGe Linux Operations

Founded in 2009, MaGe Education is a top Chinese high‑end IT training brand. Its graduates earn 12K+ RMB salaries, and the school has trained tens of thousands of students. It offers high‑pay courses in Linux cloud operations, Python full‑stack, automation, data analysis, AI, and Go high‑concurrency architecture. Thanks to quality courses and a solid reputation, it has talent partnerships with numerous internet firms.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.

Sign in to comment