The obvious question: Do you want to access your server only from within your network or also from anywhere else?

You set the A record to your internal ip address from within your router?

Nginx configs have a lot of options, you can route differently depending on the source context

So a couple questions:

1. Do you only want to access this from your local network? If so setting up a domain name in the broader internet makes no sense, you're telling the whole world what local ip within your switch/router is your server. Make your own dns or something if you just want an easier way to hit your local resources
2. do you want to access this from the internet, like when you're away from home? Then the ip address you add to your a record should be your isp's public ip address you were assigned, it will not start with 192.168, then you have your modem forward the port to your local system (nginx)

If you don't know what you are doing and have a good firewall setup do not make this service public, you will receive tons and tons of attacks just for making a public a record.

You can't point to 192.168.X.X that's your local network IP address. You need to point to your public IP address which you can find by just searching 'what is my IP'. Note that you can't be behind CGNAT for this, and either need a static IP or dynamic DNS configuration. Be aware of the risks involved exposing your home server to the internet in this manner.

This is a really good idea that I see dismissed a lot here. People should not access things over their LAN via HTTP (especially if you connect and use these services via WG/Tailscale). If you're self hosting an vital service that requires authentication, your details are transmitted plaintext. Imagine the scenario where you lose connection to your tailscale on someone else's WiFi and your clients try to make a connection over HTTP. This is terrible opsec.

Setting up letsencrypt via DNS is super simple.

Setting up an A record to your internal IP address is really easy, can be done via /etc/hosts, on your router (if it supports it, most do), in your tailnet DNS records, or on a self hosted DNS resolved like pihole.

After this, you'd simply access everything via HTTPS after reverse proxing your services. Works well locally, and via tailscale.

Try a different browser, or the curl command in another comment (but while on the LAN). Your understanding so far is correct, though unusual, typically it's not recommended to put LAN records in WAN DNS.

But if you've ever run HTTPS there before, Firefox might remember that and try to use it automatically. I think there's a setting in Firefox. You might also try the function to forget site information, both for the name and IP. I assume you haven't turned on any HTTP-to-HTTPS redirect in nginx.

Also verify that nginx is set up with a site for that name, or has a default site. If it doesn't, then it doesn't know what to do and will fail.

Your issue is using a non-routable IP on a public DNS provider, some home routers will assume it's a miss configuration and drop it.

If your only going to use the domain over a VPN and local network, I would use something like pihole to do the DNS.

If you want access from the internet at large, you will need your public IP in your DNS provider.

The IP address you've used as an example would not work. That is a 'local' address, ie home address. If you want DNS to resolve your public domain name to your home server, you need to set the A record to your 'public' IP address, ie the external address of your modem/router. Find this by going to whatismyip.com or something similar.

That will connect your domain name with your router. You then set up port forwarding on the router to pass requests to the server.

Why do you need a domain on an internet facing dns if you can just define it with your local dns? Unless you want to access your services via internet, in which case you would need a public ip.

You don't need a domain name for HTTPS.

192.168.x.x is always an IP address that is not exposed to the internet.

If you're trying to make your server accessible on the internet, you need to open a port (doesn't have to be 80 for 443) and have a reverse proxy direct connections to the services running on it.

Here's a post that explains the basics of how to set this up: https://lemmy.cif.su/post/3360504

Combine that with this and you should be good to go: https://www.digitalocean.com/community/tutorials/how-to-create-a-self-signed-ssl-certificate-for-nginx-on-debian-10

I do this exact thing on my network so I know it works, but why are you trying to downgrade https to http? if you've set up dns-01 properly it should just work with https.

how did you configure dns-01?

Do a curl http://mydomain.tld/ -i with your server off/while off-network.

Your registrar probably has a service to rewrite http accesses to https automatically. Curl -i shows the headers, which will probably confirm that you're being redirected without even connecting to anything in your network.

Have you considered using a mesh VPN instead of opening a port to the public? Nebula and TailScale are both great options that have a free tier which is more than enough for most home use cases. With Nebula you can even selfhost your discovery node so nothing is cloud-based, but then you're back to opening firewall ports again.

Anyway, its going to be more secure than even a properly configured reverse proxy setup and way less hassle.

One thing you probably forgot to check is if your TLD registrar supports DyDNS and you have it set on both sides of the route.

Sorry this will most definitely not work with your local IP address on an external DNS. That is not routable over the internet. I have a 192.168.10.20 IP address in my home network as well. You need to go to whatsmyip.com or ipchicken.com and get your external IP and put that in the DNS at your registrar. Most likely you will need a Dynamic DNS provider as your ISP probably gives you a dynamic public IP address that will change occasionally.

If you just want to resolve mydomain.tld INTERNALLY so you can use a mydomain.tld HTTPs certificate then you just need to add mydomain.tld to your INTERNAL DNS server pointing at your INTERNAL IP address for your server. Likely your router is set up as a DNS server but it just forward all requests to the external DNS which is why you just get sent to mydomain.tld instead of your internal server.

It's very likely that DNS servers aren't going to propagate that A name record because of it being an internal IP. What DNS settings are you using for Tailscale? You could also check that the address is resolving locally with the command host mydomain.tld which should return mydomain.tld has address 192.168.10.20 if things are set up correctly.

Edit: you can also do a reverse lookup with host 192.168.10.20 which should spit out 20.10.168.192.in-addr.arpa domain name pointer mydomain.tld.

The easy answer is to enable NAT loopback (also sometimes called NAT hairpinning) on your edge router.