this post was submitted on 28 Jun 2026
23 points (96.0% liked)
Selfhosted
60210 readers
832 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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.
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 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
Devices on your domain will typically do a DNS lookup, which gets your public IP. Then they connect to that public IP, which your router recognises and redirects back into your network. The router then forwards that to your reverse proxy.
If your router isnt doing that properly (timing out usually), look up a setting usually called "NAT loopback" or "NAT hairpinning". Thats the setting that detects your public IP, and redirects it back inward.
Also if you have your own net filter like PiHole or AdGuard Home with DNS rewrites set up, and you use it as a DNS server in WiFi settings, then it works a small bit differently. (I need to do this because my current ISP removed their DNS settings page for the new model). A public IP and NAT routing is never needed, as the device contacts the DNS server via the router Access Point, and the DNS server translates the service's FQDN into its internal IP. Aside from that, provided everything is set up correctly, all actual data packets go from device ←→ router ←→ service. If the router lost connection to the Internet this wouldn't break communications.
I had issues with that recently, I had a few of my internal services set to resolve internally, but pihole was making a mess of them and returning IPv6 addresses in addition to the IPv4 internal addresses. And then browsers would try use the broken ipv6 address and fail. I just happily rely on hairpinning now, it hardly makes a difference in the scheme of things.