My Spotify free account has stopped connecting on both my PC and my iPad. I have verified that Pi-Hole is the issue by disabling it, and Spotify (as well as LinkedIn, which was also blocked) works perfectly. I have manually added in the following domains on my Whitelist:
What's the latest status of Spotify and Pi-Hole? Most of the relevant articles on here are a couple years old. How can I get it to work? I'm happy to let them play ads as long as I can keep blocking everything else.
@peic FWIW, I am not having any issues accessing Spotify from my Mac with Pi-hole. I did not have to enter any Whitelist entries to do so. My Pi-hole is currently set up with the default Blocklist item. Did you add any additional Blocklists to your Pi-hole that may be the reason for not being able to access it?
Pi-hole Version v4.3.2 Web Interface Version v4.3.2 FTL Version v4.3.1 on a RPi 3 B+, running Raspbian stretch
Yes, I have a bunch of regex exceptions and some specific sites blocked, but this all started just a few days ago. I'm trying to remember what I did, but so far it escapes my memory. Here is what a pihole -t shows:
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-kqlj.ap.spotify.com from 192.xxxx is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-lbcm.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list guc3-accesspoint-a-lbcm.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-7x8d.ap.spotify.com from 192.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list guc3-accesspoint-a-7x8d.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-wgkr.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list guc3-accesspoint-a-wgkr.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-pj3x.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list guc3-accesspoint-a-pj3x.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] guc3-accesspoint-a-ndwr.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list guc3-accesspoint-a-ndwr.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] gew1-accesspoint-a-l758.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list gew1-accesspoint-a-l758.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] gew1-accesspoint-a-q0ft.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list gew1-accesspoint-a-q0ft.ap.spotify.com is 0.0.0.0
Jan 4 13:44:39 dnsmasq[666]: query[A] gae2-accesspoint-a-03sg.ap.spotify.com from 1992.xxxx
Jan 4 13:44:39 dnsmasq[666]: /etc/pihole/regex.list gae2-accesspoint-a-03sg.ap.spotify.com is 0.0.0.0
Even after putting the above into a whitelist, they are blocked (or else they are getting changed each time I try to log in from the desktop).
...
I remember now what I did. I ran a query and saw a bunch of things that were getting hits, so I figured, why not block them and see what happens. Do you know if any of the following are critical for Spotify to work?
Are you entering URLs or regex filter entries in the regex.list file? For the latter, have you debugged them to make sure they are syntactically correct?
Not a very scientific method to go by. Again, as I mentioned to you in another of your posts, I gave you a list of URLs that are called when running Spotify in a browser.
Please provide the output for: cat /etc/pihole/regex.list
You may need to go back and remove all of the entries that you made in the regex.list file and see if this fixes Spotify for you.
I would not claim to be scientific about coding, which I barely can navigate. I was using the console provided by Pi-Hole, and in the Query Log I was clicking on "blacklist" next to the recent query that looked fishy.
Prior to this time, I was adding individual domains or URLs to the blacklist as I found things I wanted to block. And for good measure, I also blocked a number of top-level domains to see if I could discover a pattern that would work without having to put in individual URLs.
I'm assuming that Spotify uses only .com, correct?
Some of these I found could circumvent my filtering, and some were on a list of "top abused TLDs."
The TLDs are entered in the Blacklist function of the console. And I did take this list from my output of cat /etc/pihole/regex.list. I just restricted the data dump to the TLDs. What else might matter?
According to an online forum, this is associated with Spotify.
Here is an update: I got Spotify to work on my PC this morning. This was the traffic below. It almost looks like there are multiple "access point" URLs, and as long as one if them is whitelisted, I can sign in. Or else it has something to do with that URL being cached. But it's luck of the draw.
I have expanded my whitelist for access point URLs to the following, and for now it seems to be working. I sure wish there were a wildcard entry that would cover them all, however.
Turns out Spotify used another access point the next time I tried, so I had to whitelist that one, too. I wonder if this is some sort of countermeasure?
At 2020-03-07, here is the list of whitelisted URLs that I have had to enter to get this thing to work. It seems like I have to add another five to ten URLs every time I connect: