Packet Loss Corrected on a Ubiquiti UniFi Mesh with a Dedicated Backhaul
A UniFi mesh showing 3 to 8 percent packet loss on the far AP usually points to a shared 5 GHz backhaul under load. UniFi Network, TX retry percentage, and the uplink type tell you whether the cure is copper, a dedicated radio, or a different bottleneck entirely.
From a wired machine, ping the far access point while someone in that room starts a 4K stream. On a two-hop UniFi mesh using wireless backhaul, the loss can climb from zero to somewhere between 4 and 9 percent almost at once. The far AP may still show usable signal while its 5 GHz radio is serving clients and relaying all traffic back toward the gateway. That half-duplex radio has to take turns, and the turn-taking breaks down first under sustained traffic.
The UniFi Network app usually exposes this pressure through retries. Open Insights, choose the meshed AP, then compare the WiFi Experience number with the TX retry percentage. Retries above 15 percent on the backhaul link mean frames are being resent because acknowledgements did not come back. Those resends consume airtime that client traffic also needs. The symptom looks like latency spikes on a video call or dropped frames in a game, while the root cause sits in how airtime is being scheduled.
The shared-radio ceiling
A single 5 GHz radio handling both clients and backhaul tends to top out at about half its rated throughput before walls, distance, and interference are counted. Once modulation drops, each frame occupies the channel for longer, so the rest of the traffic waits longer too.
Put the uplink on copper, then check what the AP actually chose
Cat5e already running to the room fixes the backhaul cleanly. Plug the meshed AP into the wired port and the UniFi Network app should change the device from Wireless Uplink to Wired within about 30 seconds. Packet loss to that AP then falls to zero because the backhaul has moved onto copper and the 5 GHz radio can serve clients without relaying every frame toward the gateway.
Some UniFi APs adopted over wireless keep using the wireless parent after a cable is connected. The parent remains reachable, so the AP may continue to mesh instead of reassessing the better path. Open the AP settings, go to Uplink, and set the wired port as the preferred uplink. Another route is to forget the device and adopt it again with the cable already connected. On UniFi OS 3.x and later, the manual uplink override sits under the device Settings tab. People often look under the global mesh toggle first, where that per-device override is absent.
Cable quality still matters. On older U6 and nanoHD units, a run longer than about 90 metres, or a marginal termination, can make the port negotiate at 100 Mbit instead of gigabit. Loss can return under load even though the traffic is travelling over wire. Check the port speed in the client details. A gigabit-capable AP showing 100 FDX on its uplink indicates a cabling issue, and changing mesh settings will leave that negotiation untouched.
Powerline adapters are tempting when the wall already has a socket and the cable route is ugly. A TP-Link AV1000 pair on the same ring circuit will pass traffic, and it can beat wireless backhaul on raw throughput. Consistency is the trade. Powerline jitter commonly sits around 10 to 40 ms depending on what else is drawing current, and that variation can appear as intermittent loss tied to appliances such as a fridge compressor.
If the AP lands on a switch port limited to 100 Mbit, the same reasoning applies. Copper removes the radio contention, then the slow wired link becomes the next ceiling. That failure mode is quieter because UniFi can still show a wired uplink while the speed field carries the clue.
When pulling a cable is impossible
A dedicated backhaul radio is the next best substitute for a real wire. A UniFi tri-band AP such as the U6 Enterprise or the older UAP-AC-HD has a third radio that mesh can use for the backhaul hop, leaving the client radios available for client devices. In practice, that separation can cut backhaul-induced loss from the 5 to 9 percent range to under 1 percent, because clients and backhaul stop competing on the same channel.
Placement changes once the backhaul has its own radio. With shared-radio mesh, the far AP usually needs to sit as close to the parent as the coverage goal allows. With a dedicated backhaul radio, the AP can often move farther out because the backhaul link can hold a higher modulation on a cleaner channel.
Manual channel choice helps here. Set the backhaul channel to a DFS channel such as 100 or 116 if the regulatory domain permits it. Those channels are often clear of neighbours even in a dense flat. DFS brings its own interruption mode: if the AP detects radar, it must vacate the channel for 30 minutes, and the backhaul drops during that window. Airports and coastal weather-radar areas can make some DFS channels unusable in practice.
The important distinction is airtime. A dedicated backhaul radio does not create infinite capacity, and it does not shorten the internet path beyond the house. It simply prevents the backhaul hop from occupying the same 5 GHz airtime that phones, laptops, TVs, and consoles are trying to use.
Loss can disappear while latency remains
After the backhaul stops dropping packets, a wired ping to the gateway often settles around 1 to 2 ms. A game server may still answer at 40 ms. That remaining round trip comes from the WAN path beyond the gateway.
On fibre, that number is usually stable enough that nobody notices. Starlink behaves differently because the satellite hop adds 25 to 60 ms and can reorder packets in a way that TCP interprets as loss even when every packet eventually arrives. A UniFi gateway behind Starlink may show WAN loss in Insights that reflects satellite path variation. Turning off gateway smart queue management and letting Starlink handle its own buffering can sometimes produce cleaner readings. Mesh tuning inside the house will not change a satellite uplink.
DNS can hide inside the same feeling of delay. If the gateway hands out an ISP resolver answering in 40 to 80 ms, every new connection feels sluggish on an otherwise clean network. Setting gateway DNS to 1.1.1.1 or 9.9.9.9 can trim first-byte time noticeably. On mobile devices roaming between mesh APs, a fast resolver can also reduce the stall felt during the handoff moment.
What the far-AP speed test is measuring
Run the built-in UniFi speed test from the gateway and it reports the WAN link. Run a speed test from a laptop sitting on the meshed AP and the number may collapse. That second result mixes the WAN, the client radio, the mesh hop, and any switch-port limit in between. In the UK, under Ofcom rules, the ISP speed obligation applies at the master socket.
The cleaner test is a wired laptop plugged directly into the meshed AP, tested against a local server. If that result is close to the AP port speed, the mesh uplink is healthy and the remaining shortfall is coming from the WAN or the wireless client link. A phone showing 80 Mbit on a 500 Mbit line three rooms away is often hitting the client-radio ceiling at that distance. The UniFi client details pane separates these failure modes if you look at the uplink type, retry rate, and port speed together.
The unresolved case is the third AP added to a wired backbone where the switch between APs is still limited to 100 Mbit. Does copper still beat a dedicated backhaul radio once the slow switch port becomes the quiet limiter?