"My Wi-Fi is slow" is almost never about Wi-Fi: a triage framework that holds up

A woman at a site I used to support ran over her own Ethernet cable with her desk chair. Not once. On a rough schedule, every few weeks, and every few weeks the same ticket came back with the same four words: internet keeps dropping again.

We swapped her switch port. We swapped her dock. Someone deleted and rebuilt her network profile, which is the IT equivalent of turning it off and on again while looking thoughtful.

You could feel the flat spot in that cable with your thumb.

I open with her because "my Wi-Fi is slow" is the most common sentence in this profession and it is almost never about Wi-Fi. It is a mood, translated into the only vocabulary the person has to hand. Sometimes the wireless link genuinely stinks. More often a page took four seconds, or a file share sits on the far side of a saturated site link, or the laptop is at 99% full and swapping itself to death, or the person has been on wired Ethernet for eleven months and does not know it.

What makes this ticket hard for a junior is that it offers no obvious first move, so they guess. People guess where their knowledge is deepest, which in 2026 means DNS, or the VPN client, or some browser extension nobody has heard of.

Start lower than that. Start dumber.

Before it is a configuration problem it might be a cabling problem

The order of operations I have used for twenty years, and have never once regretted: check the physical medium, let the link layer negotiate, check address resolution, and only then start suspecting IP, TCP, or the application.

Physical means the actual objects. Crimps. Punch-downs. Whether the cable has been chewed, kinked, stapled, or parked on. And the one almost nobody checks: whether the twists were maintained all the way to the connector, or whether the installer stripped back two inches because it is easier to crimp that way.

That last one matters more than it sounds. Gigabit and above run at frequencies not far off radio, and the whole reason twisted pair works is that interference couples equally onto both wires of a differential pair and cancels out. Untwist the last inch and it stops coupling equally. Now you have a link that works, mostly, until the elevator motor next door starts up.

A nicked conductor or a lazily terminated jack produces symptoms that look exactly like a software bug: intermittent, time-of-day correlated, "it was fine yesterday." That is how a physical fault sends a competent admin chasing their tail for two days inside packet captures.

The advice that has expired. For years the received wisdom was to turn auto-negotiation off and hard-set speed and duplex on anything that mattered. I repeated that advice long after it stopped being true, and I taught it to people who then taught it to other people, which I am not thrilled about. Auto-negotiation is trustworthy now. So is auto-MDIX, which silently deleted an entire ticket category (the crossover-versus-straight-through confusion) by having the switch detect and remap the pairs itself.

So when a link comes up clean and no data moves, do not go back to fighting negotiation. Suspect two bad pairs that happen not to be the negotiating pairs. I have seen exactly that: link light solid, speed correct, zero throughput, and four hours burned before anyone put a tester on it.

Four layers, not seven

The seven-layer OSI model is a fine thing to have been taught and a poor thing to troubleshoot with, mostly because it never actually described TCP/IP. Four layers do: link, internet, transport, application. That maps onto what you can see in a capture, which is the entire point.

Here is the payoff. When you look at a hung connection in netstat, tcpdump, or Wireshark, the TCP state name tells you which side owns the problem. A socket parked in SYN_SENT on the client? The SYN left and nothing came back. A connection that reaches SYN_RECV and dies means the two machines can absolutely reach each other and something local is refusing to finish the handshake.

Host firewall or network firewall. That is the fork, and the state name hands it to you for free.

One graph beats an hour of guessing

On a Mac, hold Option and click the Wi-Fi menu bar icon, open Wireless Diagnostics, then go to Window and choose Performance. Ignore most of what appears. The graph you want is the bottom one, plotting signal and noise.

As long as those two lines stay well apart, the wireless link is healthy and your problem lives somewhere else. When they converge, stop debugging software and go look for a physical or RF cause. That is the whole reading. I now teach it to end users directly, including relatives, because a person who can describe their own graph is a person who has stopped guessing.

Three cases that graph explained, none of which I would have reasoned my way to:

The copy room. Signal fell apart for anyone sitting near the big multi-function printer. The printer was innocent. The wall of stacked paper next to it turned out to be very nearly radio-opaque, which is obvious the moment someone says it out loud and occurs to nobody beforehand.

The microwave. Sporadic, unreproducible network chaos at one site, and the tickets clustered around morning break and lunch. Someone had set a network switch on top of the break room microwave oven, because it was a flat surface at a convenient height.

The airport. A school sat at the approach end of a runway. Its Wi-Fi died periodically, and eventually the pattern matched a specific airport radar sweeping toward the building during certain landing approaches. Fully diagnosable. Completely unfixable, short of moving the school. Sometimes the deliverable is an accurate name for the thing.

The sequence, written down

Print this. The value is in doing the same thing every time, especially at 4:50pm on a Friday when you badly want to skip to step five.

When a connection does not work at all:

1. Look at the physical medium. Cable condition, crimp quality, punch-down quality, twists intact to the connector. Swap the patch cable with a known-good one before you form a single theory.
2. Let the link layer do its job. Is there a link light, at the expected speed? Is PoE actually being delivered, and is the device drawing the class it should?
3. Check address resolution. arp -a to see the cache, arp -d to clear an entry that is stale or plain wrong.
4. Now, and only now, suspect IP. Address, mask, gateway, route table via netstat -rn.
5. Then transport. Look at TCP state names and decide whether the client or the server owns the stall.
6. Application last. It is almost never first.

When a machine is "slow":

1. Is the disk full? Ask this before anything else, every single time. A remarkable share of "slow computer" tickets end here.
2. Load average and memory footprint. top -o u sorted by CPU, footprint -a for per-process memory.
3. The process list itself, read carefully, looking for the thing that should not be there.

One nuance that matters more than any threshold you will find on a forum: build pattern recognition against your own baseline. An M-series machine tolerates a load average that would have an Intel machine on its knees. Numbers pulled from a blog post written for different hardware will lie to you. Numbers you have watched on your own fleet for six months will not.

Reimaging is not triage. It is what you do when triage has told you something, and doing it first means you learn nothing and will see the same ticket in March.

What already ships on the machine

Assume the worst case, because it is also the common case: a locked-down or offline machine where you cannot install anything. Airgapped government networks. Large regulated enterprises where staff can search the web all day but cannot get a package manager approved. Everything below is already there.

When you cannot remember what a tool is called, apropos <keyword> (or man -k, same thing, less typing) keyword-searches every man page on the box. Read the section number in the results to throw out noise: user commands, admin commands, networking, developer libraries. Then man the survivor.

The ones I reach for constantly:

• ifconfig for what the interfaces actually think they are doing.
• arp -a and arp -d, already mentioned, plus a trick worth having: take the MAC prefix of a device you cannot identify, paste it into a vendor lookup site, and you know who made it. I have used exactly that to work out which brand of unlabeled IP cameras a client had hanging in their ceilings.
• netstat -rn for routes, netstat -a for everything currently open.
• lsof paired with netstat, which is how you find the specific process holding a stuck connection open instead of guessing and killing something innocent.
• nc -l <port> to stand up a listener in one second, so you can prove whether a port is reachable without begging another team to build you a test endpoint.
• networkQuality for a speed, latency, and idle-latency test straight from a terminal, faster than opening a browser speed test.
• dns-sd and mDNS browsing to see what services a LAN is advertising: AirPlay, printers, whatever else is shouting.
• host_info for an instant core count, RAM total, CPU model, and kernel version.

Two cautions I learned the annoying way. If you are about to hand-edit a plist, copy it first, because restarts, software updates, and the owning daemon can all overwrite your careful edit without telling you. Convert binary plists to XML with plutil -convert xml1 before you touch them. And dd is a legitimate crude disk throughput test only if block size times count comfortably exceeds available RAM. Otherwise you are benchmarking the page cache and feeling great about numbers that mean nothing.

A tell worth memorizing. A print job that lights up like it is definitely going to print and then produces nothing is a driver incompatibility, reliably, not a network or queue problem. That single pattern has saved me hours of staring at print server logs.

A modern wrinkle. AI coding assistants cheerfully tell people to just install something with a package manager, and they are persuasive about it. So admins now find third-party packages appearing on managed machines that nobody consciously chose to install.

Cable and power, bought badly

Two rules for anyone who signs purchase orders.

Never buy copper-clad-aluminum cable. Not to save money, not for a temporary run, not for the closet nobody sees. It fails PoE and distance, and it fails later, once you have forgotten it is there.

And read the jacket instead of trusting the category on the box. One Cat5e run I inspected was printed as rated to 350MHz, comfortably above the 250MHz minimum for Cat6. The label on the spool is marketing. The print on the jacket is closer to a fact.

While you are in purchasing: check the total PoE budget, not the per-port number. Someone I know bought a switch advertising 78W per port, felt very well provisioned, and then discovered the whole chassis had a 400W budget. About 8 of the 12 planned access points could actually be powered. The per-port figure was true and useless.

The word slow

Every technical discipline has a word its users say when they mean "something in my day got worse and I cannot tell you why." In ours it is slow.

Treating that word as imprecise and therefore unserious is a mistake I made for a long stretch of my career. It is imprecise because precision is our job, not theirs. The person reporting it has given you the only honest description they have, and a method exists specifically so that you do not need them to be more accurate.

The method is unglamorous on purpose. Look at the physical thing. Let the layers negotiate. Check the cache. Read the graph. Ask whether the disk is full. It looks like plodding and it is closer to respect, because it ends with a real answer rather than a reimage and a shrug.

Even the airport radar counted as a win. Nobody fixed it. But a school stopped believing its network was cursed, which is worth something.

---

Foqal builds conversational ticketing for IT teams in Slack and Microsoft Teams, so a report like "my Wi-Fi is slow" arrives with enough context to start triaging.