that works, certs are downloaded. But the same - regular, no staging - fails:
Certbot failed to authenticate some domains (authenticator: webroot). The Certificate Authority reported these problems:
Detail: SOME.IP: Invalid response from http://some.xyz/.well-known/acme-challenge/xv52V43h1P9Zk6VpnwsbRwyqM: 404
Probably a cached validation on the staging server being reused, so successful issuance without trying a new validation attempt whereas there actually is an issue currently.
You could try --dry-run instead of --staging to see what happens. --dry-run also makes use of the staging environment, but disables cached validations first before attempting to get a certificate, thus triggering a validation attempt every time.
If --dry-run fails, then you know something has happened between a previous succesful validation and the current situation. If --dry-run succeeds but an attempt on the production environment doesn't, then something strange is going on.
Which 'duckduckgo' would be a redirection from one of the other virtual hosts - which one? I don't how Nginx decides to which it "fails-over", but!...
...question in such case I want to ask is - why LetsEncrypt would bother with '/' or anything other than '/.well-known/acme-challenge' ? and if that what has to happen for Letsencrypt works this way then..
...is it possible to have a 'server' - with Nginx - to work with certbot 'auto-updates' and redirect HTTP do HTTPS (for everything other LetsEncrypt)?
Let's Encrypt doesn't "bother", it just requests a certain path (starting with /.well-known/acme-challenge/ on a certain FQDN and it follows any redirect it receives. It's up to the webserver to either serve the challenge token or provide a correct redirect to that challenge token.
Often webservers are mis-configured, however, without the actual FQDN we can't test that remotely. Note that providing the exact domain name is mandatory to actually get help on the Community, as shown by the questionnaire which should have been provided to you when you opened this thread in the #help section:
Please fill out the fields below so we can help you better. Note: you must provide your domain name to get help. Domain names for issued certificates are all made public in Certificate Transparency logs (e.g. crt.sh | example.com), so withholding your domain name here does not increase secrecy, but only makes it harder for us to provide help.
My domain is:
I ran this command:
It produced this output:
My web server is (include version):
The operating system my web server runs on is (include version):
My hosting provider, if applicable, is:
I can login to a root shell on my machine (yes or no, or I don't know):
I'm using a control panel to manage my site (no, or provide the name and version of the control panel):
The version of my client is (e.g. output of certbot --version or certbot-auto --version if you're using Certbot):
As @Osiris said there FQDN is needed to remotely check what is happening, we are trying to figure out why your site configuration isn't working with Let's Encrypt. Obviously you have to supply the FQDN to your ACME agent to get any certificate from Let's Encrypt.
That's just the http-01 challenge of the ACME protocol. Please see RFC 8555 for more details about the ACME protocol, but rest assured, the http-01 challenge will request a path starting with /.well-known/acme-challenge/. What happens next is NOT due to Let's Encrypt, but due to webserver (mis)configuration.