I am still unable to reproduce but I will make sure to work on the related code during the next days.
If I can be of help, just let me know!!!
It'd be great if you could try
pihole checkout core fix/gravity_domain
and then run
pihole -g
again and see if something has changed
Just figured out the reason for this and already fixed it in development-v6:
Okay, thanks. This is - at least - a small improvement as there are fewer errors now. But still not perfect, obviously. I pushed another small update, please run said commands again.
I ran the update, see screenshot. Then updated via interface, see screenshot.
Then I ran the commands, watched it update successfully 4 times now.... 
I think we are good!!! Between the two of us, we will get (we got!!) this...
Yeah, this looks all fine now.
Do you really want to block s3.amazonaws.com ? I guess quite a few web services may stop working. You can check which list is responsible by running
pihole -q s3.amazonaws.com
on your Pi-hole or use the according web interface page
I have had it set for a while, no problems as far as I can tell. "Disabled" it, let's see what happens.
Question: If I disable the password, does the log in screen for Pi.Hole disappear? Logging in all the time is a pain!!! Remember me for 7 days was ok though.
Figured, I just try it. Now works without rebooting the container. I have removed the password for Pi-Hole!!!
When you have set a password, you can also use the option webserver.session.timeout to set how any long you want the session to be valid, this can even be months. Check out Settings -> All settings (only visible in Expert settings mode).
Set it to 604800 and set a password! Thank you for the pointer...
MAJOR PROBLEM!!!
Did not change anything, all of a sudden, no internet!!!!! And the max 150 message!!! I had that before, but very, very seldom!!! Never mattered, as far as I can tell!!!
Decided to update PI6 and that bombed totally.... 
I have rerouted my traffic, for some reason PI6 does not like me anymore....
Have a nice weekend.
I might add, I have ADGUARD in my HOME ASSISTANT and hit PI6 from there on 178.42. PI5 on 178.43 workes fine.
Have to leave ADGUARD for now, as I can not connect to SMA with my solardata, when ADGUARD is deactivated/uninstalled????? On my SMA ENERGIEMETER the light for the netconnection goes to red if ADGUARD is deactivated/uninstalled!!! I have not been able to find out why this is so. EVERYTHING else works....
Back to Pi5 (thank you Mr. Proxmox!!) and all is well. I did not do anything network related today. And then I got mail from SMA, that my converter (Wechselrichter) is overdue sending data.
Could not get into the net anymore with anything. After circumventing PI6 I was back online! Going back through PI6 I get the "150" message real quick and that is it for the internet!!!!
PI5 is running smoothly!!! My PI6 installation is a EXACT copy of PI5 using Proxmox. Only did the necessary updates for Pi6. And it was running fine until this morning!!!!
The last version is from the days ago, no changes happened in between. This 150 concurrent queries warning indicates that the upstream resolver used by your Pi-hole stopped responding. No wonder Pi-hole stopped working! I have never had this message seen myself in over 8 years of using Pi-hole at home so this indeed points into the direction of either an unreliable upstream or an overall unreliable internet connection.
Can you check that this upstream still works and is indeed identical between v5 and v6?
From your post I read that v5 still works so why do you also run Adguard home? How does it fit into the picture?
I'm wondering if you are using Adguard home as upstream destination for Pi-hole? Maybe this is the component that was updated and stopped working looking at that there were no Pi-hole updates in a few days. The "FTL update available" in your screenshot is incorrect and comes from that the updater was not able to get the latest version. We'll fix this but it doesn't have to do with the current issue.
Coming back to what I said above: To debug this, we first have to learn more about the upstream servers configured in your Pi-hole and how this relates to Adguard. Please also try something independent like 8.8.8.8 or 1.1.1.1, etc. just for testing if the issue persists even with those servers. This to exclude it is some other component in your network causing this.
All I changed is .42 (PI6) to .43 (PI5) and everything was fine!!!! Commenting out 192. etc and activating quad9 worked also.
For some reason I am not aware of, the ethernet connection on my SMA energy meter goes to red (light), when I stop the ADGUARD service. Just activating / deactivating ADGUARD via the interface is ok. So for the moment, I need to leave it in.
Since just changing .42 to .43 (PI5), everything works fine....
Just tried it again, going through Pi6. Worked so far, but then I switched back to Pi5.
Because: When I try to run an update when Pi6 ist active, it takes nearly FOREVER to load the files. No problems with Pi5!!!
PI5 just zooms through the install, PI6 takes forever to even load the first file. So I axed it and went back to Pi5. All I ever do is change that one digit in the ADGUARD config from 2 to 3.
The update of the PI6 container via PI5 is finished, whereas if I run it via PI6 it hasn't even loaded the first file in the time it is done completely under Pi5.
PI6 container is exact copy of Pi5 container plus PI6 updates!!!!
So it seems like your v6 server has upstream connection issues and, so far, we don't know why.
What are you using as upstream for them? Please check if this is still correctly configured or if something has gone wrong anywhere.
I have to idea, what you mean by this. PI6 was working until sometime around noon. No idea what changed, I did nothing.