So, the part that selects what hostname it serves is the server_name directive. What those http://lemmy and http://lemmy-ui point to is the backend services. In this case, it’s assuming the Docker setup where the containers are named lemmy and lemmy-ui respectively. They’re completely invisible to the user, and in this case relies on Docker directing those names to the appropriate containers automatically. You don’t need to change those, unless you’re not using Docker. If you’re not using Docker, then those need to point to the address to reach lemmy and lemmy-ui. So for example, you might want to set that to http://127.0.0.1:1236.

Essentially, traffic comes in at port 80/443 or whatever your listen directives say, then NGINX receives the connection and processes the host header in the request to match it against which server{} block serves that server_name, or falls back to whichever server block defines listen ..... default_server, or if there isn’t any, it usually falls into whichever server block happens to be first loaded in by the server. Pretty much only the listen and server_name directives are relevant here in terms of handling incoming traffic from the outside, mostly. Things like ssl_* will also configure how to handle incoming HTTPS connection, but that happens slightly after the server block has been identified using the listen and server_name directives. Most other directives are about how to handle the request once it’s in the server block.

Then, it processes the request entirely within that server block. In this particular case, there’s a bit of logic so that it proxies it to lemmy-ui unless it’s an ActivityPub request or anything not a GET/HEAD request, in which case it tries to proxy it to the lemmy backend service. That’s what the if directives accomplish here. Usually we put those in location blocks, in this case the location / block so it handles all paths except other location blocks that override it. Some directives can be put directly in the server block and will apply to all locations unless overridden. Technically NGINX processes the location blocks first in order of precision (ie. /foo/bar/42/comments is more specific than /foo, and when there’s a tie it’s based on configuration order in the config file).

There’s also a location block to map some URLs like /.well-known and /pictrs that also gets proxied to the lemmy backend directly. The way those work is say, you want to handle something at http://example.com/demo, you can add a location /demo {} block and the directives in that block will only apply when the URL is /demo/*.

Does that clarify things for you?

you tell it what you mean by lemmy and lemmy-ui earlier in the config file outside of the server {} block

upstream lemmy {
# this needs to map to the lemmy (server) docker service hostname
server “127.0.0.1:8536”;
}
upstream lemmy-ui {
# this needs to map to the lemmy-ui docker service hostname
server “127.0.0.1:1234”;
}