Team,
Due to the WAF-policy there are a few devices that don't need ad blocking.
I have added the mac-addresses of these devices to the section called Client group management. And assigned them to a group that has no block-list attached to it.
This with the assumption that from that moment on these devices will not show up in the blocked-queries-list (i.e. Query Status: Blocked (gravity)). Is this a valid assumption? Anything else I should be aware of?
With warm regards - Will
That should exempt DNS requests originating from clients using those MAC addresses from being filtered.
If you provide a debug token, we could check your configuration.
You should be aware that the source IP is the only identifying data contained directly in a DNS request, so it would be preferred to define clients by IP.
MAC addresses (as well as their respective association to IP addresses) may not be static, e.g. if a client would employ MAC address randomisation, and they have same link visibility only.
@Bucking_Horn - thank you for the quick response.
The debug token is: https://tricorder.pi-hole.net/t4XMCd2N/
Be aware that this is not a straightforward pihole config - it heavily relies on DNSMASQ configs.
These devices have the dynamic mac capability disabled (where relevant and possible) - IP address may change over time as these are dhcp based.
One of the devices has a6:c4:8a:37:d4:55 - this is used in the client group list and shows up in the network view as well.
Your configuration looks OK:
You have defined clients by MAC and assigned them to a group which hasn't any adlists associated, and that group is also correctly enabled.
But your debug log indicates that you run your Pi-hole in a Docker container (and IIRC, you are running some kind of other virtualisation as well).
Depending on your VM/Docker network configuration, Pi-hole may be attached to a virtual link, i.e. your virtualisation may substitute each packet's MAC address information with its own virtual MAC, in which case Pi-hole may be seeing only the virtual switch's MAC for all DNS traffic.
I can also see you are heavily managing DHCP per VLAN using Pi-hole, and since that seems to work, it may mean that your virtual environment relays DHCP traffic accordingly, so that your Pi-hole may still receive a DHCP request's original MAC despite it originating from a separate link.
If you have control over IP assignments of the devices to be exempted, the safest option probably would be to assign them a fixed IP and use that in the client definition.
To ease configuration, you may also consider to set aside a specific IP range that only your unblocked devices would use, and use that range as a single client definition.
If that's not an option, you may need to investigate your virtual environment's network features.
You are right - Pihole is running in a Docker container and attached to the host network. The host is a LXC container which is hosted by PVE. This LXC container has a vlan interface for each subnet. Meaning Pihole is connected to each vlan interface (see the ss -tulpn below). The device with the mac is in vlan 220 (i.e. 192.168.220.0/24).
Anything specific I need to (double)check here?
ss -tulpn | grep 53
udp UNCONN 0 0 127.0.0.1:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=42))
udp UNCONN 0 0 192.168.10.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=40))
udp UNCONN 0 0 192.168.240.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=38))
udp UNCONN 0 0 192.168.210.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=36))
udp UNCONN 0 0 192.168.110.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=34))
udp UNCONN 0 0 192.168.100.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=32))
udp UNCONN 0 0 192.168.120.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=30))
udp UNCONN 0 0 192.168.220.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=28))
udp UNCONN 0 0 192.168.200.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=26))
udp UNCONN 0 0 192.168.230.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=24))
udp UNCONN 0 0 172.20.235.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=22))
tcp LISTEN 0 32 192.168.100.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=33))
tcp LISTEN 0 32 192.168.110.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=35))
tcp LISTEN 0 32 192.168.200.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=27))
tcp LISTEN 0 32 192.168.210.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=37))
tcp LISTEN 0 32 192.168.240.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=39))
tcp LISTEN 0 200 192.168.10.235:88 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=53))
tcp LISTEN 0 32 192.168.10.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=41))
tcp LISTEN 0 32 127.0.0.1:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=43))
tcp LISTEN 0 32 192.168.220.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=29))
tcp LISTEN 0 32 172.20.235.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=23))
tcp LISTEN 0 32 192.168.230.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=25))
tcp LISTEN 0 32 192.168.120.235:53 0.0.0.0:* users:(("pihole-FTL",pid=291070,fd=31))
One other observation: for the device(s?) in the client group list, the query log says Blocked (gravity) - which probably means that pihole is still blocking this? No other network infra part is involved?
It is my understanding that these settings are stored in gravity.db => perhaps a factory reset of gravity.db can be of help? How do I do that?
Run from one of your clients you expect to be exempted from blocking, please share the ouput of:
nslookup flurry.com
How did that client acquire its IP?
How do those nslookup queries register in Pi-hole's Query Log?
The nslookup without the client attached to the no-blocklist group:
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
The image below shows how this looks like in the query log.
Below the results when this (Windows-)device is attached to the no-blocklist.
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
PS C:\WINDOWS\system32> nslookup flurry.com
Server: morpheus.wired.lan
Address: 192.168.210.235
Name: flurry.com
Addresses: ::
0.0.0.0
Below how it then shows up in the query log.
Below the list of configured clients - part of which is Pandora - the one I tested with.
I have also created a new debug token:
https://tricorder.pi-hole.net/lVqXcF39/
This is the config with the pandora client attached to the no-blocklist group.
What's the purpose of running that nslookup 5 times?
Was it run from different clients?
And for the client under scrutiny:
It was running on the same client.
Running it multiple time for consistency check and easier searching in the query log.
Client IP was acquired via DHCP - like all other clients.
Dynamically or by fixed IP/DHCP reservation?
Via your router or Pi-hole?
And IIRC, you have a multi-VLAN setup for Pi-hole - in case of using Pi-hole's DHCP, would the client be joining multiple VLANs, or is it restricted to one VLAN exclusively?
Dynamically via pihole/dnsmasq.
That is correct - client-devices are restricted to one vlan.
Let's take a closer look how Pi-hole handles those unexpectedly blocked requests.
Please run:
sudo pihole-FTL --config debug.clients true
Afterwards, please rerun:
nslookup flurry.com
Please monitor /var/log/pihole/FTL.log (e.g. via Tools| Tail log files | FTL.log) for DEBUG_CLIENTS lines corresponding to that nslookup, and share the relevant portion.
When done, disable client debugging:
sudo pihole-FTL --config debug.clients false
2026-07-11 13:57:31.889 DEBUG_CLIENTS --> No record for 192.168.210.80 in the client table
2026-07-11 13:57:31.889 DEBUG_CLIENTS Using in-memory host name "pandora.wired.lan" of 192.168.210.80
2026-07-11 13:57:31.889 DEBUG_CLIENTS --> Querying client table for pandora.wired.lan
2026-07-11 13:57:31.889 DEBUG_CLIENTS --> There is no record for pandora.wired.lan in the client table
2026-07-11 13:57:31.889 DEBUG_CLIENTS Using in-memory interface :eth0.210 of 192.168.210.80
2026-07-11 13:57:31.889 DEBUG_CLIENTS Querying client table for interface :eth0.210
2026-07-11 13:57:31.889 DEBUG_CLIENTS --> There is no record for interface :eth0.210 in the client table
2026-07-11 13:57:31.889 DEBUG_CLIENTS Gravity database: Client pandora.wired.lan not found. Using default group.
2026-07-11 13:58:04.651 DEBUG_CLIENTS --> No record for 192.168.10.160 in the client table
2026-07-11 13:58:04.651 DEBUG_CLIENTS Using in-memory host name "scanline-1.tech.lan" of 192.168.10.160
2026-07-11 13:58:04.651 DEBUG_CLIENTS --> Querying client table for scanline-1.tech.lan
2026-07-11 13:58:04.651 DEBUG_CLIENTS --> There is no record for scanline-1.tech.lan in the client table
2026-07-11 13:58:04.651 DEBUG_CLIENTS Using in-memory interface :eth0 of 192.168.10.160
2026-07-11 13:58:04.651 DEBUG_CLIENTS Querying client table for interface :eth0
2026-07-11 13:58:04.651 DEBUG_CLIENTS --> There is no record for interface :eth0 in the client table
2026-07-11 13:58:04.651 DEBUG_CLIENTS Gravity database: Client scanline-1.tech.lan not found. Using default group.
At this time I was able to capture the results for pandora.wired.lan and scanline-1.tech.lan - both are showing the same results: "client not found" followed by "using the default group".
No idea what the messages about the interface means (i.e. "There is no record for interface ...").
Client debugging is now disabled.
So Pi-hole received a query for flurry.com from 192.168.210.80, but neither that IP nor its currently associated hostname has been configured for client specific filtering.
As explained, MAC addresses are absent from DNS requests, so they don't make a good client identifier.
My guess would be that a different IP was associated to the MAC address at the time of client definition, so the lookup for the current IP fails.
The one identifying data contained directly in a DNS request is the request's source IP.
The safest option probably would be to assign your exempted client a fixed IP and use that in the client definition (or use its hostname, provided you can assure that hostname's uniqueness, but note that hostnames are also derived data).
Thank you for the detailed explenations and patience! 
I will give it a try with the hostname because things are setup in such a way that fqdn is (kind-of) considered mandatory - will see how far this brings me.