This guide involves advanced modifications via SSH and the modification of system services. While these steps are safe when followed correctly, they can impact your network’s stability if misconfigured. Proceed with caution, ensure you have a recent backup of your UniFi configuration, and only apply these changes if you are comfortable using the Linux command line.
If you use Smart Queues (FQ_CoDel) on a UniFi Gateway (such as the UDM, UXG, or Gateway Max) to combat bufferbloat, you might encounter a frustrating issue: websites load extremely slowly, partially, or hang indefinitely during the TLS handshake.
The common advice is to lower MSS Clamping. But what if setting it to 1300 doesn’t help, and your MTU ping tests show a perfectly healthy 1500-byte path?
The Hidden Culprit: GSO vs. Smart Queues
The problem usually isn’t your ISP’s MTU. Instead, it’s a conflict with Generic Segmentation Offload (GSO) within the Linux kernel of your gateway.
In UniFi’s implementation, the internal quantum parameter (which defines how much data a queue can send per round) is often set too low (e.g., 300). When a 5 KB GSO block hits a queue with a 300-byte quantum, the processing becomes extremely inefficient. This creates massive jitter and timing issues, breaking sensitive HTTPS handshakes.
The Diagnosis
Connect to your Gateway via SSH and check the queue statistics while trying to load a problematic website: tc -s qdisc show dev eth4 (Replace eth4 with your WAN interface, e.g., eth8 or ppp0).
Look for the maxpacket value. If it shows something like 5616 despite your 1500 MTU, GSO is interfering with your Smart Queues.
The Solution (Step-by-Step)
Since the UniFi GUI doesn’t allow you to disable GSO or fine-tune the Smart Queue quantum, we must force these settings via the shell.
1. The Manual Test
Disable offloading on your WAN interface temporarily (no reboot required):
ethtool -K eth4 gso off tso off gro offIf websites immediately start loading fast, you have confirmed the issue.
2. Making it Permanent (Gateway Max / UDM / UXG)
Since these changes are lost after a reboot or a firmware provision, we need to create a custom system service using systemd.
Create the Script: Create a file at /data/custom/fix-offload.sh:
mkdir /data/custom
vi /data/custom/fix-offload.sh#!/bin/sh
sleep 20
ethtool -K eth4 gso off tso off gro offClose the vi editor with “:x”
Make it executable:
chmod +x /data/custom/fix-offload.shCreate the Systemd Service: Create the file /etc/systemd/system/fix-offload.service:
vi /etc/systemd/system/fix-offload.service[Unit]
Description=Fix Smart Queue Offload Issue
After=network-online.target
[Service]
Type=oneshot
ExecStart=/data/custom/fix-offload.sh
RemainAfterExit=yes
[Install]
WantedBy=multi-user.targetEnable the Service:
systemctl daemon-reload
systemctl enable fix-offload.serviceReboot the firewall and check if the page loads fast and the speed are limited.
Conclusion
If you need Smart Queues (essential for asymmetrical lines like 70/25 Mbit), disabling GSO on the WAN is often the only way to ensure stability for modern, complex websites. While this slightly increases CPU load, it ensures that packet processing remains consistent, reliable, and compatible with the Smart Queue algorithms.