I've heard DuckDNS has become more unreliable. You could try another service like afraid.org and see if it makes a difference.
this post was submitted on 18 Nov 2024
15 points (94.1% liked)
Selfhosted
40246 readers
765 users here now
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
Yeah, I suspect it's simply an issue on the side of DuckDNS. :/
- Is your uptime kuma server on the same machine as your other services?
- Are you using docker/podman? If so can you try to curl your services' domain from inside the container and see if they resolve?
Yes, Uptime-Kuma is running on the same domain as the other services, except the Nginx-Proxy-Manager, which runs on a VPS which I access via WireGuard.
And yes, I'm using Docker. I tried curl'ing one of the domains from the Uptime-Kuma container and got the folllowing error:
curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to service.datenprolet.duckdns.org:443.
So thanks, now I have an idea about what I should investigate.
Are uptimekuma and whatever you're trying to monitor on the same physical hardware, or is it all different kit?
My first feeling is that you've got some DNS/routing configuration that's causing issues if you're leaving your local network and then going through two layers before coming back in, especially if you have split horizon DNS.
Well, I'm monitoring the GUI of Proxmox on which I run a Debian VM which itself runs Uptime-Kuma and Nextcloud in Docker, so yes that's on the same hardware.
If you ping the domain from inside the container, does it succeed?
Yep
seems like your DNS works fine but your certs doesn't. Are you able to connect to your services on your browser normally, with SSL?
Edit: please also try curl -4 and curl -6 to your services from within the uptime kuma container to see if theres an ipv4/v6 issue
Another edit: seems like there is a dataprolet URL in your post and a datenprolet URL in your comments. It might just be a typo so also check that too.
Yeah, it works fine through my browser. Sometimes the websites load a little longer. I feel like it's an issue with DuckDNS as it's seemingly random when it works and when not.
IPv6 doesn't work:
docker exec -it Uptime-Kuma curl -6 proxmox.datenprolet.duckdns.org
curl: (6) Could not resolve host: proxmox.datenprolet.duckdns.org
Besides that the issue has disappeares since last night. I automatically restart all containers at night and moved from uptime-kuma:1 to uptime-kuma:latest. That shouldn't make a difference, but maybe it did?
And it's not a typo in my config, but in my post. But good catch. ;)
Sorry I'm a bit confused. What kind of tracker are you using in uptime-kuma and what address is it pointing to?
What do you mean by tracker? I'm monitoring local domains, that point to local services and their respective web interfaces like Proxmox or Nextcloud. The local domains have a wildcard SSL certificate via DuckDNS.
Which one of those. You pick one when adding something new to monitor. Actually just send a screenshot of the uptime-kuma settings of one of the services that are giving you problems.
It's HTTPS, what else should it be, when I monitor a domain?
Well you keep saying monitor a domain, in that case a DNS monitor would make more sense than HTTP(s) since that's for monitoring a service. That's why I was a bit confused. But yeah try to enable the ignore SSL option and see if that changes anything. You didn't include a screenshot of the settings which makes a bit difficult to diagnose the problem so I will leave it here.