Diagnose slow UniFi WiFi

Goal and prerequisites

Find which part of the connection is limiting performance before changing radio settings. This exercise separates the internet service, wired network, AP uplink, wireless path and client. It produces your own measurements; no speed result in this chapter is claimed to come from a tested installation.

Use a wired computer, one repeatable wireless test client and, ideally, a second wired computer running iperf3. Pause large downloads and cloud synchronisation during controlled tests. Record the internet plan, gateway model, switch port rates, AP model, client adapter, operating system and driver version. Keep the same test locations and server for comparisons.

Establish the bottleneck

  1. Describe the actual failure. Write a sentence such as "The office laptop is slow when transferring files to the NAS" or "All clients lose usable internet speed after dinner". Include whether the problem affects one client, one AP, one room or every device. File copying and internet browsing may have different bottlenecks.
  2. Measure the wired internet baseline. Connect a computer by Ethernet, disable its Wi-Fi and run three internet speed tests against the same server. Record download, upload and latency. If the wired result is already poor, examine the WAN, gateway settings and provider before blaming the AP.
  3. Inspect the wired links. In UniFi, check the gateway WAN, switch uplinks and AP uplink. Compare negotiated speed with the capabilities of both ends. Replace a suspect patch cable with a known-good one. A link unexpectedly negotiating at 100 Mbps deserves investigation even when the device is described as gigabit. Check errors and reconnect events as well as the displayed speed. [1]
  4. Prepare a local test server. On a trusted wired computer with iperf3 installed, identify its LAN address and run iperf3 -s. Permit the test connection through its host firewall only from the test LAN. Do not create an internet port forward. The default server port is TCP 5201. [2]
  5. Test near the AP. On the wireless test computer, substitute the server's real address in the commands below. 192.168.10.20 is an example if you have already created the Main network. Run each direction three times, allowing the test to finish before starting another.
iperf3 -c 192.168.10.20 -t 20
iperf3 -c 192.168.10.20 -t 20 -R

The first command sends from the wireless client towards the server; -R measures the reverse direction. Record the receiver summary and the middle result of the three runs. Stop the server with Ctrl+C after testing. [2]

  1. Repeat at the problem location. Keep the same server and test client. Record the connected AP, band, channel width, signal and negotiated PHY rates. A PHY rate is the radio link rate; it is not the same measurement as delivered application throughput. [3]
  2. Inspect radio conditions. Open the affected client and AP in Network. Look at signal, retries and airtime utilisation. Check whether the busy channel is carrying your own traffic or interference from nearby networks. Use the available AirView, Environment or radio views for the installed version. A full RF scan can interrupt clients, so schedule it when that interruption is acceptable. [3] [4]
  3. Test one plausible correction. For a weak signal, try a better AP position. For a crowded channel, review the channel plan or Channel AI suggestions. For a compatibility issue isolated to one computer, update that client's supported driver. Keep 2.4 GHz at 20 MHz as an initial configuration; evaluate 5 GHz width against actual channel conditions instead of assuming the widest setting is best. [5]

Interpret your measurements

Observation Most useful next investigation
Wired internet and wireless internet are both slow WAN service, gateway processing or background traffic
Local wireless transfer is good but internet is slow Internet path rather than the local radio link
Near-AP transfer is good and distant transfer is poor Coverage, obstructions or selected AP
Only one client performs poorly in the same position Client capability, driver, power policy or compatibility
AP uplink is slower than expected Cable, termination, switch port or link capability

These patterns narrow the diagnosis; they do not establish a cause by themselves. Confirm the suspected cause by changing one relevant item and repeating the same test.

Verify and recover

Repeat both the controlled transfer and the real application that originally failed. Keep the correction only if it improves the intended use without causing new problems elsewhere. Record the before and after settings, test times and results. Revert an unsuccessful radio change to the saved value, remove the temporary host-firewall exception and leave no test server running unnecessarily.

Sources

Back to the series

Leave a comment

Please note, comments need to be approved before they are published.