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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

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

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
devve@lemmy.world
ayyy@sh.itjust.works
curbstickle@anarchist.nexus
curbstickle_lw@lemmy.world
23
What path does data take when connecting to a domain at my address? (sh.itjust.works)
submitted 13 hours ago* (last edited 4 hours ago) by jws_shadotak@sh.itjust.works to c/selfhosted@lemmy.world
19 comments fedilink hide all child comments
 

I have some subdomains that go to my home address (I know I should put it through a VPS first but I'll get to that when I have time).

If I connect to example.domain.tld and DNS records point back to my own IP, where does that data go to reach back to my device?

Edit: thanks for the responses everyone

you are viewing a single comment's thread
view the rest of the comments
[–] folekaule@lemmy.world 1 points 12 hours ago

Your diagram is almost right, but I think it will help to understand more of the details. It's important to understand the difference between DNS (domain name lookup) and IP routing.

To break your diagram down more, this is what happens when any computer looks up your website:

  1. The device does a DNS lookup of "example.com" using their name server, which may forward it to another DNS server (most home routers do this). I won't go into the multiple levels of DNS lookups and caching here.
  2. Through looking it up by DNS, the device now has the final IP. DNS is now out of the picture and we're doing IP routing.
  3. The device tries to make an HTTP connection to your external IP. HTTP is a protocol that runs over TCP/IP (UDP is used for QUIC/HTTP3). To keep things simple I'll stick with old fashioned HTTP over TCP without SSL. I am also skipping over NAT.
  4. For TCP, it performs a handshake, which the reverse proxy will negotiate. Once the connection is established, the browser speaks HTTP to the reverse proxy. It looks something like:
GET / HTTP/1.1
Host: example.com
...lots more headers...
<blank line>
  1. The reverse proxy then takes that request, maps it to an upstream (if any), and makes another request to it via the configured transport. If that part falls down, you will see a 503 error. Otherwise, you will see the response from the upstream, possibly with some modifications made by the reverse proxy (some will rewrite links and cookie paths, for example)
  2. The reverse proxy sends that response back to the client.

That's all very simplified, of course.

As others pointed out, things may seem to work differently from the "inside", if hairpinning is not available or enabled. This is not related to DNS, but to IP routing. The firewall doing NAT can get confused and not know what to do when an internal request goes to an external IP that it itself has. When it turns that around and routes it back to the internal network, that's called hairpinning.

One "fix" for this, often used in enterprises, is to use so-called split DNS. All that means is that if you're asking your internal DNS server for an internal name, it will give you the internal address (192.168.1.123 for example), but an external client would get an external IP.

TL;DR: DNS and IP routing are separate concerns and happen at different parts of the TCP/IP stack.