It happens when
Your command in first post did not use the --nginx plugin. But, your nginx config had many lines saying "managed by certbot". These lines come from using that plugin. So, I am thinking maybe you tried many different commands and perhaps this happened.
I guess that solved it. Now I have to check that IPv6 problem and why srtrak.click does not work (database does not connect through it like on other domains, i.e. .com, .top, .xyz) Strange...
IPv6 problem solved by itself after the restart... AND turning CloudFlare ON.
nmap -6 -Pn -p80,443 srtrak.click returns...
Starting Nmap 7.80 ( https://nmap.org ) at 2024-04-16 23:26 UTC
Nmap scan report for srtrak.click (2606:4700:3037::6815:1810)
Host is up (0.0080s latency).
Other addresses for srtrak.click (not scanned): 2606:4700:3034::ac43:d84a 104.21.24.16 172.67.216.74
PORT STATE SERVICE
80/tcp open http
443/tcp open https
Nmap done: 1 IP address (1 host up) scanned in 0.48 seconds
As for the database thing... I am clueless as all these tracking domains have the same root. 
I figured it out. It was actually not the proper root...
Anyway, thank you @MikeMcQ !!
Well, Cloudflare is now proxying your domain so I can't check IPv4 or IPv6 directly anymore. Tests just check to the Cloudflare CDN edge which are very reliable 
It might just have been nginx got stuck too. After making major changes to listening ports a restart is a good idea. A reload sometimes is not enough
I would remove the IP address from all your listen statements unless you need it for some very unusual reason. And, probably not since you didn't use them for port 443
And, make sure you are listening for IPv4 and IPv6 consistently in every single server block. You are not currently doing that. Probably because of mis-use of ipv6only=off
Anyway, I can't do much more now that you are behind the CDN
@countesscat one more side note https://decoder.link/sslchecker/www.srtrak.click/443
shows the presently being severed certificate was not issue by Let’s Encrypt, is that what you expect? (just a question not a judgment)
I just turned it off, to see, if the db thing was something cached... For some reason when CloudFlare is off 443 says it is closed for Ip6. Weird.
nmap -6 -Pn -p80,443 srtrak.click
Starting Nmap 7.80 ( https://nmap.org ) at 2024-04-17 00:00 UTC
Nmap scan report for srtrak.top (2a07:5740:400:13::9)
Host is up (0.00029s latency).
Other addresses for srtrak.top (not scanned): 91.132.60.212
PORT STATE SERVICE
80/tcp open http
443/tcp closed https
Might be. We do not restart servers like this one for hundreds of days... Usually is not a problem.
Probably it was for something backend, which does not require it or a domain...
What do you mean?
Turned it off for srtrak.click already. Will have to turn it back ON and send it to production...
Hit me up, if you want, let's do that and tell me your PayPal to buy you a beer.
Cloudflare uses both Google Trust Services and Let's Encrypt at their edge, so it is not odd to see GTS as the issuer when Cloudflare is enabled.
Not weird. Cloudflare prefers IPv4 to the origin when both IPv4 and IPv6 are available, so it ignores your broken IPv6. With the proxy enabled, you can reach Cloudflare over IPv6 and Cloudflare in turn proxies to your origin using IPv4.
A-haaa! So I guess we are fine. Thank you!
Your origin IPv6 address is still incorrect in Cloudflare. Removing it or correcting it would seem worth doing now while it is fresh in someone's mind. Other than that housekeeping opportunity, you should be fine as long as Cloudflare is enabled.
You are welcome.
You don't listen for IPv6 on any of your port 443 server blocks.
And, only one of your two port 80 server blocks for each root domain listens for IPv6. The other one for port 80 has the IPv6 listen commented out. I say you have two as one is the root name and one for the www subdomain of that.
Couldn't your port 80 server block listens also be much simpler
Can't you just do:
listen 80;
listen [::]:80;
instead of like this:
listen 91.132.60.212:80;
listen [2a07:5740:400:13:0000:0000:0000:0015]:80 ipv6only=off;
You have a different IPv6 address for each domain name. Yet, most of your IPv4 addresses are the same. I'm having a hard time imagining a valid use like that.
Your port 443 listens could just be like this (to get both IPv4 and v6)
listen 443 ssl;
listen [::]:443 ssl;
That's because nginx does not let me use the same IPv6 for the tracking domains and in more than 1 virtual host.
Could try, but I think it may not work because of the https rewrite, so I made on the 2nd part with the https redirect listen to 80 and with the SSL part to listen to 443 like you said, butwithout ipv6only = off. That worked without cloudflare. Thanks! Looks like the newer version of nginx allows me to do that. It was not possible before on 1.10 and I left it like it was. It was working... Anyway... Where to send that beer, you were saying?
That's very kind but I don't wish any gift. If you want to donate
Could you give an example of that?
Not really. Using a newer version now.
You should use the reply button on the specific post [not the reply at the bottom] when addressing a specific question.
That makes it easier for everyone to follow along.
Otherwise, we get:
Who are you replying to?
What question does that post answer?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.