There’s a specific kind of frustration that comes from spending $2,500 on Sonos speakers, only to have one of them disappear from the app every few days. The kitchen Era 100 plays fine. The patio Move shows up. The dining room Five is grayed out — “Unable to connect.” You reboot it, it comes back for an hour, then drops again.
We see this constantly across the Wasatch Front, and almost every time, it’s the same story: the speakers are fine, the Wi-Fi is “fine,” and the network underneath is doing something the homeowner’s router never told them about. Here’s what’s actually going on, and what finally fixes it for good.
Why Sonos is so sensitive to network problems
Sonos isn’t a normal Wi-Fi device. A speaker that’s playing a stereo pair with another speaker in a different room has to stay tightly synchronized — we’re talking sub-millisecond audio sync — and that requires multicast traffic. Multicast is how one device says “hey, anyone listening for this group?” and gets answered by all the other Sonos speakers on the network at once.
Multicast works beautifully on a clean, simple, consumer-grade flat network. It starts breaking the moment you do anything “enterprise” with the network — add VLANs, add a managed switch, add a second access point, turn on certain security features. Sonos was designed for people plugging a cable into the back of their ISP modem and calling it a day. The minute you go past that, the features that make Sonos work also become the features that make Sonos break.
The five things that actually cause Sonos drops
1. IGMP snooping is on, but no querier is configured
This is the number one cause we see. IGMP snooping is a feature on managed switches that tries to be efficient about multicast traffic — instead of flooding multicast packets to every port, it only sends them to ports that asked for the group. Sounds great. The problem is that IGMP snooping requires an IGMP querier somewhere on the network to keep the membership table fresh. If the querier is missing or misconfigured, the switch slowly forgets which ports want which multicast groups, and Sonos speakers silently drop out of each other’s view.
The fix is one of two things: turn IGMP snooping off on the VLAN your Sonos lives on, or configure a proper querier (UniFi gateways, EdgeRouters, and most business-grade firewalls can do this). On UniFi, the option is buried in Settings → Networks → [your VLAN] → Advanced → Multicast DNS / IGMP Snooping. We almost always recommend just disabling snooping on the Sonos/IoT VLAN — the bandwidth saved isn’t worth the support calls.
2. STP (Spanning Tree Protocol) is reconverging
If Sonos drops at the same time every day — say, every morning at 3:14 AM your kitchen speaker goes offline for 30 seconds — that’s usually STP. Spanning Tree is a switch-level protocol that prevents network loops. When it recalculates the network topology (which it does periodically, or any time a port comes up or down), it briefly blocks traffic on certain ports.
For most devices, this is invisible. For Sonos, with its multicast-heavy chatter and short timeouts, a two-to-five-second STP reconvergence is enough to drop speakers off the group. The fix is to enable RSTP (Rapid Spanning Tree) on your managed switch and to configure the ports going to APs and Sonos devices as “edge ports” so they skip the listening/learning delay. UniFi calls this “PortFast” in some places — same thing.
3. SonosNet vs. standard Wi-Fi confusion
Older Sonos speakers — Play:1, Play:3, Play:5 (gen 1), Connect — created their own private mesh network called SonosNet, which used the wired speaker (called the “Boost” configuration) as a base station. Newer Sonos hardware (Era, Beam, Arc, Ray, Move, Roam, Five gen 2) is Wi-Fi-only and joins your house Wi-Fi directly.
Mixed households — a couple of older speakers and a couple of new ones — end up in a half-SonosNet, half-Wi-Fi state where some speakers talk over your Wi-Fi and some talk over the SonosNet mesh. When the two paths get out of sync, drops happen. The fix in 2026 is almost always to retire SonosNet entirely. If every speaker in the house is recent enough, switch the system to Wi-Fi-only mode and let your real network do the work.
4. The Sonos VLAN can’t reach the controller VLAN
If you’ve set up proper VLAN segmentation — main network for phones and laptops, IoT VLAN for cameras and speakers, guest VLAN for visitors — Sonos gets confused if the speakers live on a different VLAN than the phones controlling them. The Sonos app finds speakers via mDNS (Bonjour) and SSDP, both of which are broadcast/multicast protocols that don’t cross VLANs by default.
The fix is mDNS reflection (sometimes called “Avahi reflector” or “Bonjour gateway”), which copies discovery packets between the two VLANs so the phone on the main network can still see the speaker on the IoT network. UniFi has this built in — Settings → Networks → enable Multicast DNS. EdgeRouters and pfSense need an Avahi package. Without it, the speakers will still play, but the app on a different VLAN can’t see them, which looks identical to a “dropped” speaker.
5. Wi-Fi roaming and band steering
Stationary Sonos speakers don’t need to roam. They pick an AP and they should stay there forever. But aggressive band steering and 802.11k/v/r roaming features can decide that the kitchen Era 100 should hop from the downstairs AP to the upstairs AP at 2 AM, and during the handoff it briefly disappears.
The cleanest fix is to put the Sonos speakers on a dedicated 2.4 GHz / 5 GHz SSID with band steering off, or to use static AP assignment if your controller supports it. UniFi lets you tune minimum RSSI per AP so the speaker stays put. This is a five-minute change that eliminates a class of intermittent drops most homeowners have lived with for years.
The order to actually try fixes in
If your Sonos has been driving you crazy, here’s the sequence we run through on a service call:
- Update every speaker to the latest firmware. Old bugs are old bugs.
- Disable IGMP snooping on the VLAN the Sonos lives on. Single biggest fix, every time.
- Confirm RSTP is on, and that AP/speaker ports are configured as edge ports.
- If the system is mixed-generation, retire SonosNet and put everything on Wi-Fi.
- Enable mDNS reflection between the controller VLAN and the Sonos VLAN if they’re different.
- Turn off band steering for the Sonos SSID and pin speakers to a single band.
- If a single speaker still drops, swap it with a known- good one to rule out a bad radio.
In our experience, 80% of Sonos drop problems on Wasatch Front installs are fixed at step two. Another 15% are fixed by step five. The remaining 5% are actually bad hardware or a fundamentally broken Wi-Fi design that needs more APs.
Why this happens more on “upgraded” networks
Here’s the irony. Homeowners who upgrade from a consumer mesh kit to a real UniFi or wired AP install often start having Sonos problems they never had before. The new network is technically better in every way — but it ships with security features and managed- switch behaviors that consumer routers don’t have, and Sonos was tuned against the consumer-router default.
This is a setup problem, not a Sonos problem and not a UniFi problem. A properly configured managed network is a better home for Sonos than any consumer router will ever be — once you’ve walked through the multicast, STP, and VLAN settings. The first 24 hours after a network upgrade is when the call usually comes in.
What we do during a Sonos-aware install
When we’re scoping a whole-home audio system with Sonos, the network configuration is part of the job, not an afterthought. That means:
- Sonos lives on the IoT VLAN, with mDNS reflection enabled to the main VLAN so phones can see the speakers.
- IGMP snooping is off on that VLAN. Multicast floods a few hundred extra packets per minute. Nobody cares.
- Every Sonos speaker has either a wired Ethernet connection (preferred — the Era 100, Era 300, Five, Amp, Port, and Beam Pro all have an Ethernet port) or a strong, single-band Wi-Fi connection to a nearby AP.
- The Sonos app is installed on at least one device on the main VLAN as the “canonical” control point, so we can verify the system from a known state during commissioning.
A Sonos system installed this way doesn’t drop. We have clients in Holladay, Park City, and Cottonwood Heights running 8–14 speakers across three floors with multi-zone playback running 24/7 for years without a single ticket. That isn’t a Sonos miracle — that’s the network underneath being correctly set up.
When Sonos isn’t the right answer
If your network is a hostile environment for multicast — apartment building, dorm, complicated office network — and you can’t fix it, Sonos is going to be a bad time forever. The alternatives we look at: a hardwired matrix amp like Sonance Sonamp Mag with ceiling speakers and a dedicated streamer per zone, or a HEOS / Bluesound system on a similarly designed network. Both are less network-sensitive because they lean less heavily on multicast for sync.
But for the typical Utah single-family home with a proper wired AP install and a managed switch, Sonos can absolutely be solid. It just needs the network to behave.
Bottom line
Sonos drops are almost always a network problem, not a Sonos problem. The five suspects are IGMP snooping without a querier, STP reconvergence, mixed SonosNet/Wi-Fi setups, missing mDNS reflection across VLANs, and aggressive band steering. Walk through them in that order and the system stabilizes.
If you don’t want to learn what an IGMP querier is, that’s a perfectly reasonable position to take. That’s the job.
Keystone Integration installs and tunes Sonos systems across Holladay, Park City, Cottonwood Heights, and the rest of the Wasatch Front — on networks built to keep multi-zone audio rock-solid for years. See our full service list, or get in touch if your Sonos has been driving you crazy.