I know it doesn't explain why (some) others have gotten their connection to work and some not. But I've had these issues on and off in the past as well. And now I decided to do some troubleshooting of it, and I think I may have found an issue which probably affects more people that just myself. (And I should perhaps mention that I work as a networking professional and have specialized in WiFi specifically the past 16 or so years (and with that comes a lot of LAN and IP network troubleshooting which is more generic.) The problem I've found is that when the Spotify app (I'm running iOS 13.3.1 on an iPhone 😎 does a search for the speaker(s) it sends a multicast DNS request on the local LAN to address 220.127.116.11 on UDP port 5353 (multicast DNS, mDNS) asking for _spotify-connect._tcp.local However, it does so with an IP TTL of only 1. And though the thought behind doing so (which most likely is to limit it to only the local subnet), is good, it overlooks the real meaning of the IP TTL and what the RFC for Internet Protocol says. The problem arrises in certain networking devices which are having different smart mechanisms to deal with mDNS (aka Bonjour). In my case I have access points from Aerohive Networks, which are enterprise class access points with something they call a “Bonjour Gateway” which is meant do help intelligently re-advertise certain select services across VLANs, based on configurable policy. However, even if not doing any re-advertising they still inspect the IP header (even in bridge mode) to inspect and decide if there is a Bonjour Gateway policy that requires them to do something. This inspection does, in accordance with RFC 791 (Internet Protocol, IP) require them to decrease the TTL before forwarding since they “process the IP header”. (It says about the Time-to-live field: “This field is modified in internet header processing.” and “If the field contains the value zero, then the datagram must be destroyed” (which is what happens before forwarding the packet). The limitation to advertise only on the local subnet is dealt with through the destination IP address, which falls in the 18.104.22.168/24 subnet, which according to RFC 5771 disallows the traffic to be forwarded off-link (the local link network). Further more, it’s worth noting that mDNS queries issued by Apple apps have an IP TTL of 255 (AirPrint, Airplay etc) and searches for Google Chromecast (not sure what piece of software triggers it in my case, but I see it in my wireless packet capture from my iPhone) has an IP TTL of 2. The ONLY queries observed with an IP TTL of 1 are those for Spotify Connect. I have also generated my own traffic to test my theory, and whenever I generate traffic to 22.214.171.124 with UDP port 5353 and IP TTL of 1 it does not get repeated out in the BSSID by the AP, but if I change the destination IP or the UDP port it does (which indicates that it’s the Bonjour Gateway functionality specifically). Also, if I change the IP TTL to 2 with the same test method, it get repeated (even if the payload is rubbish). I think that Aerohive are not the only ones that do mDNS inspection, and therefore I suspect that more people are hit by this without even knowing that they have such a feature. So in conclusion: If Spotify developers could just increase the IP TTL for these Spotify Connect discovery datagrams to 2 (or why not just do like Apple and set it to 255? (as explained above, the IP TTL is _not_ the way to limit traffic propagation to link local network only) this would likely eliminate the problem for at least some of the users.