We have not been able to pinpoint what your issue is yet.
Your most recent debug log shows your Pi-hole to reside at 192.168.130.24:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the wlp4s0 interface:
192.168.130.24/24
It also shows that the machine hosting Pi-hole points DNS to the localhost loopback address, where Pi-hole is listening:
*** [ DIAGNOSING ]: contents of /etc
(...)
-rw-r--r-- 1 root root 21 Jul 8 21:35 /etc/resolv.conf
nameserver 127.0.0.1
There is an instance of dnsmasq running on that machine, which normally would cause conflicts with Pi-hole over port 53/DNS. However, care has been taken to move dnsmasq to another (virtual bridge) network interface:
*** [ DIAGNOSING ]: Ports in use
(...)
[✗] udp:192.168.122.1:53 is in use by dnsmasq
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
In addition, there is a custom configuration file at /etc/dnsmasq.d/libvirt-daemon to have it coexist with Pi-hole:
*** [ DIAGNOSING ]: contents of /etc/dnsmasq.d
(...)
local-service
(...)
lrwxrwxrwx 1 root root 39 Jun 14 17:16 /etc/dnsmasq.d/libvirt-daemon -> /etc/dnsmasq.d-available/libvirt-daemon
bind-interfaces
except-interface=virbr0
As far as Pi-hole is concerned, this looks currently valid on first glance, though it may provoke unintended side effects if you would use Pi-hole's Settings| DNS UI to switch between different Interface settings.
(There may also be implications on the dnsmasq side, depending on the configuration files that dnsmasq would be using, but I can't really comment on those. Just note that by default, pihole-FTL and dnsmasq would use the same configuration files at the same location.).
I can't tell whether and why it would be required to have a separate DNS resolver (dnsmasq) to coexist on your system.
The common approach would be to uninstall or at least disable dnsmasq, so Pi-hole would be the sole DNS resolver on your system.
While this may be worth investigating, none of it would contribute to your observation of sites being blocked despite you having disabled Pi-hole.
My guess would be that something else is blocking access, like a browser based extension or a filtering upstream DNS server.
The latter does not seem to be the case for you, as your debug log shows Pi-hole to be configured for G**gle's DNS resolvers.
To further analyse this, please run the following commands twice - once with Pi-hole's blocking enabled, and once after temporarily disabling Pi-hole's blocking:
nslookup pi.hole
nslookup flurry.com
nslookup flurry.com 192.168.130.24