When networks go wrong, the focus almost always points in one direction: from A to B. ping works, traceroute eventually stops, the port on the other side doesn't respond. The packet arrives on the target system — tcpdump shows it — and so the network is mentally considered dealt with. If the application on the other end doesn't respond, the blame quickly lands on it.
This is one of the typical logical fallacies on Linux systems.
Not because the tools lie, but because we prematurely draw overall conclusions from a correct partial answer. A positive finding initially only says something about the exact point you just tested.
The tcpdump Fallacy
The fallacy with tcpdump lies in its position within the system. Packet capture hooks in directly at the interface. A packet that tcpdump displays there has therefore by no means arrived at the application — the kernel processes it further afterward and can still silently discard it on the remaining path.
Incoming TCP SYNs are dutifully shown by tcpdump. A millisecond later, the kernel drops the packet for some reason. The application at the local socket doesn't notice a thing: It never saw the SYN and consequently sends no SYN-ACK. Anyone who only trusts the capture at the interface doesn't see what the kernel does with it afterward.
A concise example of this behavior is reverse path filtering ( rp_filter). Simply put, the kernel checks whether the source address would be reachable via the interface the packet just arrived on. In strict mode, this interface must match the best return path. If it doesn't, the packet is silently dropped — no log entry, no ICMP Unreachable, and no TCP-RST.
Both on hosts with multiple network interfaces and in environments with VPN tunnels, container bridges, or more complex routing tables, situations with asymmetric traffic can quickly arise. Requests come in over one interface, while the answer according to the routing table would go out over another. rp_filter kicks in, and the connection dies before a socket ever learns about it.
Correct Answers, Wrong Conclusions
The fundamental problem, however, isn't limited to reverse path filtering.
It runs through virtually all the tools you use during troubleshooting: They do answer technically correctly, but often to a completely different question than the one you actually had in mind.
tcpdump only confirms that a packet was visible at the observed interface. ping merely shows that the IP stack of the remote end responds to ICMP echoes — but says absolutely nothing about whether a service is listening on port 443 or a firewall is dropping TCP traffic.
It looks similar directly on the host. systemctl cheerfully reports an active service because the process is running. But if the application only listens on 1127.0.0.1 or is still bound to an old address after an interface change, external connection attempts will fail regardless — before a single byte is even processed. The process monitoring tool reports green while the network socket is dead silent.
DNS Resolution and Connection Logic
Another proven field for such fallacies is DNS resolution.
When a connection feels sluggish, the first reflex usually reaches for dig or nslookup. When the tool delivers a clean answer after two milliseconds, many people check off the DNS topic: The IP is there, so the error must be elsewhere.
Again, the tool only answers a very specific question. dig sends a direct DNS query to the configured resolver. It ignores local host files just as much as the system rules by which name queries are actually supposed to be processed, and has nothing to do with how the application ultimately evaluates the result itself.
If the name server returns both A and AAAA records, for example, but the IPv6 path in the network isn't cleanly routed or dead-ends along the way, the application hangs. Depending on how the client handles the responses — whether modern Happy Eyeballs or waiting long times until timeout — seconds pass before the fallback to IPv4 kicks in. From the outside, the system looks like it has a sluggish network. dig was completely right: The name can be resolved.
But that says little about how the process actually reaches the address in practice. How important a well-thought-out DNS and routing concept is in practice was shown to me again when building my PowerDNS architecture in the homelab.
Over the years, what changes less is the toolbox than the reflex during troubleshooting. You learn to no longer take the first finding as proof, but as evidence. Not because the tools are unreliable, but because a Linux system consists of many layers that influence each other.
Where Observations Diverge
When two tools seemingly deliver opposite signals, they don't necessarily contradict each other.
If ss shows a listener and tcpdump simultaneously sees incoming packets, but the connection still doesn't establish, the tools are merely observing different points in the chain. Especially in such moments, the information isn't in the individual finding but in the gap between them. Instead of adjusting configurations on suspicion or immediately digging into an unusual output, the key is to figure out at which point processing breaks down between the two observations.
If you need more granularity at the socket level than an interface dump provides, modern eBPF approaches often offer the necessary depth (see also: Little Snitch on Linux: Network Control via eBPF).
When it's said in a ticket or chat again that the network is broken, my first reaction hasn't changed much over the years. Most of the time the statement is even correct — just rarely in the way it was intended. It's rarely the switch that gave up the ghost, or the cable that someone pulled.
And sometimes it's simply a system doing exactly what it was configured to do.
Only unfortunately, not what you yourself expected from it at that moment. This doesn't necessarily make troubleshooting shorter, but at least saves the blind groping. You stop reconfiguring firewalls on suspicion and start figuring out at which point the system's behavior diverges from your own expectations.