Selfhosted

39503 readers

669 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:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago

MODERATORS

HybridSarcasm@lemmy.world

HybridSarcasm@lemmy.hybridsarcasm.xyz

Uptime-kuma & Docker: Timeouts when monitoring services on same host (lemmy.world)

submitted 1 year ago by outcide@lemmy.world to c/selfhosted@lemmy.world

9 comments fedilink hide all child comments

Hello.

Pretty sure I'm doing something stupid, but I can't find it.

I have Caddy and Uptime-kuma installed as Docker containers. They are on the same Docker bridge network. Both work fine (with the below exception).

I'm trying to monitor Caddy virtual hosts from Uptime-kuma and getting a timeout.

If I exec into the Uptime-kuma container, I can ping the host name I want to monitor (and the DNS is resolving correctly to the Docker hosts external IP).

But I can't reach port 80/443 using telnet or openssl.

Any suggestions for what I might be doing wrong?

Thanks!

you are viewing a single comment's thread
view the rest of the comments

[–] restlessyet@discuss.tchncs.de 1 points 1 year ago (1 children)

Are you hosting behind NAT / at home? If so, you may need to enable NAT reflection on your router.

[–] outcide@lemmy.world 1 points 1 year ago (1 children)

I am behind cgnat but why would that matter for trying to reach a service on the same box?

[–] restlessyet@discuss.tchncs.de 2 points 1 year ago (1 children)

It matters only if "the docker hosts external IP" your dns resolves is a public IP. In that case packets travel to the router which needs to map/send them back to the docker hosts LAN IP (NAT-Reflection). With cgnat this would need to be enabled on the carrier side, where you set up the port forwarding. If that's not possible, split-DNS may be an alternative.

If "the docker hosts external IP" is actually your docker hosts LAN IP, all of that is irrelevant. Split-DNS would accomplish that.

[–] outcide@lemmy.world 1 points 1 year ago

Sorry I'm being stupid. I'm on CGNAT at home but this is actually on a VPS.