Running the tailf command produces no output as I browse the web with my PC. This leads me to conclude your earlier statement about the pi-hole not logging any of the clients' activities is true.
Further, this:
Has no change in status. Result:
C:\Users\dimitar>nslookup pi.hole 192.168.0.1
Server: UnKnown
Address: 192.168.0.1
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pi.hole
I made mistake, it should have been below:
tailf /var/log/pihole.log | grep 192.168.0.1
Or better:
tailf /var/log/pihole.log | grep pi[.]hole
And run the nslookup again on PC:
nslookup pi.hole 192.168.0.1
Lets see if the router forwards the query to Pi-hole.
EDIT: added another tailf
Running tailf /var/log/pihole.log | grep 192.168.0.1 produces the following:
root@orangepizero:/etc/pihole# tailf /var/log/pihole.log | grep 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] www.facebook.com from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] connect.facebook.net from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] connect.facebook.net from 192.168.0.1
Sep 15 22:49:15 dnsmasq[1130]: query[A] www.reddit.com from 192.168.0.1
Sep 15 22:49:16 dnsmasq[1130]: query[A] safebrowsing.googleapis.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditstatic.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:17 dnsmasq[1130]: query[A] www.redditmedia.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gateway.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] gql.reddit.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] preview.redd.it from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] googleads.g.doubleclick.net from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] www.googletagmanager.com from 192.168.0.1
Sep 15 22:49:18 dnsmasq[1130]: query[A] www.googletagservices.com from 192.168.0.1
HOWEVER, running CODE produces:
root@orangepizero:/etc/pihole# tailf /var/log/pihole.log | grep pi[.]hole
Sep 15 22:51:31 dnsmasq[1130]: query[A] pi.hole from 192.168.0.1
Sep 15 22:51:31 dnsmasq[1130]: /etc/pihole/local.list pi.hole is 192.168.0.24
Sep 15 22:51:51 dnsmasq[1130]: query[A] pi.hole from 192.168.0.1
Sep 15 22:51:51 dnsmasq[1130]: /etc/pihole/local.list pi.hole is 192.168.0.24
This last input I was only able to get when trying to access pi.hole/admin from the Windows 10 PC (client).
No change in the nslookup pi.hole 192.168.0.1:
C:\Users\dimitar>nslookup pi.hole 192.168.0.1
Server: UnKnown
Address: 192.168.0.1
*** No internal type for both IPv4 and IPv6 Addresses (A+AAAA) records available for pi.hole
So it appears Pi-hole receives the query, answers correctly to the router, but the router not returning the expected reply to the client.
Am clueless.
Might be some safety feature/hidden setting etc.
Thank you for your quick reply!
Might I bother you for an elaboration on how you reached that conclusion? I feel like there's a learning opportunity here.
Look for DNS Rebind Protection. This is a feature that is designed for security and preventing a rogue DNS server on the local network from doing bad things. In our case though we want it to be able to answer queries and return local addresses.
When you access pi.hole/admin in the browser, the browser looks up pi.hole against the DNS server(s) configured in ipconfig /all --> 192.168.0.1.
Same way as how nslookup does.
The router doesnt know the pi.hole domain so it forwards the query to Pi-hole as the logs show.
Pi-hole replies with the correct answer:
"/etc/pihole/local.list pi.hole is 192.168.0.24".
But your router doesnt:
"No internal type for both IPv4 and IPv6 Addresses"
But from the windows PC, it does reply:
Its only pi.hole thats failing, other queries do get through.
Could this also be Rebind Protection ?
I have nothing of the sort, unfortunately. This is my Advanced Options config page:
It's possible. There may be some kind of trigger for .hole TLD. Something that tells the router to not forward or answer unreachable domains.
I have just gotten a reply from my ISP:
Thank you for your e-mail. There has been no change to the routers policies.
It's correct, that the DNS on your PC will be 192.168.0.1, unless you change the DNS settings directly on the PC's NIC.
Your PC's DNS will be the router, and the routers DNS will be either default or whatever you choose to change it to.
Come to think of it, when I do set custom DNS settings on my router as 192.168.0.24 (the Orange Pi w/ the Pi-Hole), I do get ads blocked. So despite my ipconfig /all stating that my PC will use as a DNS my router at 192.168.0.1, the router still forwards the request to the Pi-Hole and gets its response from there.
So the question remains why I can't access pi.hole/admin and why I am cannot seem to get proper query logging as I used to just a few weeks ago. I used to be able to tell each and every device's traffic and get the correct separate counters.
I was leaning toward the fault being in a new update of the router, but given that did not happen, it's more likely a Pi-Hole or an OS issue. Just to put it out there, I have tried uninstalling pihole by running
pihole uninstall
and following it with
sudo rm -rf /etc/.pihole /etc/pihole /opt/pihole /usr/bin/pihole-FTL /usr/local/bin/pihole /var/www/html/pihole
as mentioned by How to fully uninstall pihole - #2 by RamSet
The only thing is that I DID NOT delete the associated packages it asks me to review one by one. I avoided deleting them because I am uncertain what each and every one of them is used for and I do not wish to mess up my headless server. However, given the circumstances, when I get home today, I will remove each and every one of them during the pihole uninstall and then also run the second command. Other than flashing a brand new OS on the server, I don't think I can get a cleaner install.
Its your router thats pushing the DNS server IP address 192.168.0.1 via DHCP to the clients and not Pi-hole!
If the clients dont query Pi-hole directly, you wont see individual stats.
And as we already figured out, the DNS route:
Client --> Router --> Pi-hole --> upstream DNS server(s)
doenst work for the pi.hole domain.
Probably bc of some router safety feature
EDIT: Mail your ISP to figure out how to disable DHCP on the router and let Pi-hole do this part.
EDIT2: reason this, if DNS fails (Pi-hole), everything on your LAN becomes useless anyway as most work with names instead of IP's.
So why not let here do DHCP as well.
EDIT3: When do so, you even have more control over your network then you ever can with the router DHCP.
I shall attempt to do so!
What's weird about this is that I never touched my router and it stopped working. I only ever updated the server and the Pi-Hole. <- This also being the reason why I opened this topic, instead of somewhere else, more relevant to my router.
I'm halfway through a complete uninstall of the Pi-Hole, as I said in my last post. By the way, @deHakkelaar, if you're here, should I purge any of these packages while I'm at it?
apt-utils dialog debconf dhcpcd5 git iproute2 whiptail cron curl dnsutils iputils-ping lsof netcat psmisc sudo unzip wget idn2 sqlite3 libcap2-bin dns-root-data resolvconf libcap2 lighttpd php7.0-common php7.0-cgi php7.0-sqlite3
If this cleanup doesn't yield acceptable results, I am resetting the router.
No dont purge any 
apt-utils and iproute2 are vital for the functioning of your system.
Purge iproute2 and you break networking.
Purge apt-utils and you wont be able to install/uninstall anny.
Your realy looking at the wrong end.
But if want to know what packages Pi-hole installed, I believe the install log shows:
less /etc/pihole/install.log
I haven't run the installer for a while so things might have changed 
Above 4 are safe to purge if really need to purge anything 
sudo apt purge <PACKAGE1> <PACKAGE2> ...
If want to know more bout a package:
apt show <PACKAGE>
If want to know content of an installed package:
dpkg -L <PACKAGE>
If want to know reverse dependencies of a package:
apt rdepends <PACKAGE>
Cleanup, as expected, didn't help.
Going to reset the router when I have the chance and report back. It annoys me I haven't touched the router, yet it stopped functioning.
Did we ever came to a plausible solution for the detected here:
[LOGS]
Not sure.
Do you know why you have a dummy interface ?
Where and how is this one defined, in dhcpcd.conf or in /etc/network/interfaces ?
Some bridging going on ?
sudo brctl show
Its also a bit weird the eth0 interface reported as not being connected at first (no carrier):
The dummy interface on the Orange Pi Zero H2+ used to be the wireless antenna. It got disabled by the developers of the OS at one point due to it infamous performance issues.
Within /etc/dhcpcd.conf I have:
# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.
# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel
# Inform the DHCP server of our hostname for DDNS.
hostname
# Use the hardware address of the interface for the Client ID.
#clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
duid
# Persist interface configuration when dhcpcd exits.
persistent
# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit
# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu
# A ServerID is required by RFC2131.
require dhcp_server_identifier
# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private
interface eth0
static ip_address=192.168.0.24/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1
Within /etc/network/interfaces I have:
# armbian-config created
source /etc/network/interfaces.d/*
# Local loopback
auto lo
iface lo inet loopback
# Interface eth0
auto eth0
allow-hotplug eth0
iface eth0 inet static
address 192.168.0.24
netmask 24
gateway 192.168.0.1
dns-nameservers 8.8.8.8
The sudo brctl show command has nothing listed. I have never established any bridges.
What's weird is that if I run ifconfig -a the wlan0 interface is there and working. I have gone and disabled them via ifconfig wlan0 down and ifconfig dummy0 down, but they seem to reactivate upon reboot.