Having trouble setting up Nginx

Submitted ⁨⁨19⁩ ⁨hours⁩ ago⁩ by ⁨pirateMonkey@lemmy.world⁩ to ⁨selfhosted@lemmy.world⁩

I’m trying to set up a domain to more easily access my services on my home network, using a vanity URL instead of IP:port. With my current setup, my browser is not able to see the server (‘we can’t connect to the server’ at e.g. plex.mydomain.xyz).

I registered the domain through Cloudflare. In Cloudflare, I set up my DNS records (A - mydomain.xyz - content = 192.168.x.x; A - www; CNAME - *), and got my API token. Nginx is running in Docker (as are the services I am trying to access), using the jc21 container and their docker compose template. I used the API token to generate an SSL certificate in NPM with *.mydomain.xyz as the domain, then added a proxy host using the URL mentioned above as the Domain Name, the IP of the server that’s running all my containers for the forward hostname/IP, and the appropriate port for forward port. Then in the SSL tab told it to force SSL and HTTP/2.

I’m not sure what I’m doing incorrectly, the only thing I have running that might interfere with the network service is a PiHole, and it appears to be sending the request on. Also tried using localhost (127.0.0.1) to no avail. I’ve seen some others say they had to restart NPM a few times, so I’ve tried that as well. Thanks for any help!

source

Comments

Sort:hotnew top

Lyra_Lycan@lemmy.blahaj.zone ⁨17⁩ ⁨hours⁩ ago
Hi, Cloudflare DNS needs to point to the external IP address, aka 201.172.48.922. 192.168.x is internal and only used by the router. Changing this, and port forwarding 80 and 443 to the NPM host, will allow everything to work remotely.

That said, in a comment you said you’re only aiming for local access. The only requirement for this is setting your Plex client to the internal IP of the server, 192.168.x. Only when setting up external access do you need a cert, domain and DNS records.

Finally, if you can set your router’s DNS servers, set one to the NPM server. That may allow local devices to find the internal IP by querying the FQDN (domain).

source
- pirateMonkey@lemmy.world ⁨16⁩ ⁨hours⁩ ago
  Part of the idea here is to get comfortable with what’s happening here in a safe/unexposed environment before trying something that I would expose to the internet, and I’m of the understanding that you can do it this way (pass it to the internet, which will then return that internal IP that Nginx should route appropriately.
  
  source
marsara9@lemmy.world ⁨18⁩ ⁨hours⁩ ago
Are you wanting to access your sites remotely or only via the local LAN?

If you’re aiming for remote access then you can’t use the 192.168.* range as that’s the up address behind your NAT/router. You have use your public IP and do port forwarding from your router.

source
- pirateMonkey@lemmy.world ⁨18⁩ ⁨hours⁩ ago
  Yeah, just looking for internal access right now so I don’t have to remember the correct port for every service. Will use a VPN (leaning toward Tailscale) for remote access once I get this set up.
  
  source
  - marsara9@lemmy.world ⁨18⁩ ⁨hours⁩ ago
    Are you able to query to see what IP address that domain returns? Does it return the 192.168.x address that you set?
    
    source
    -> View More Comments
frongt@lemmy.zip ⁨18⁩ ⁨hours⁩ ago
What’s in the logs?

source
- pirateMonkey@lemmy.world ⁨18⁩ ⁨hours⁩ ago
  I’m still very much in a learning mode here, so forgive my ignorance - which logs? Nginx? I’m seeing a fallback_error and fallback_access (which has nothing interesting). There are also some empty files for the host I have set up (proxy-host-1_access/error)
  
  2025/09/01 12:34:54 [error] 193#193: *1 connect() failed (111: Connection refused) while connecting to upstream, client: 192.168.1.181, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “127.0.0.1:3000”, host: “192.168.1.196:81”, referrer: “192.168.1.196:81/nginx/certificates”
  
  Where, presumably obviously, 196 is the server and 181 is a laptop. FWIW I don’t see the directory it’s mentioning, /nginx/certificates, but I’m looking at the host’s directory rather than in the container.
  
  source
  - frongt@lemmy.zip ⁨18⁩ ⁨hours⁩ ago
    The upstream refused the connection. You have it there as 127.0.0.1, but for inter-container communication usually you’d use the name. 127.0.0.1 would refer to the same container.
    
    Docker (and other container platform) networking is a bit tricky and I’ll admit I don’t fully understand how it works, because it doesn’t work like regular networking. But a simple scenario like yours shouldn’t be difficult.
    
    source
    -> View More Comments
damnthefilibuster@lemmy.world ⁨14⁩ ⁨hours⁩ ago
Huh. I made a big comment reply to this and missed a crucial detail. Are you trying to just make it so that sitting in your own home, you can go to plex.mydomain.xyz instead of the IP?

What are you running plex on? Windows or Linux? On Linux, you can run this thing called Avahi. With it, you can set it up so that your computer starts advertising locally as whatever domain you specify. So I have server.local and newserver.local internally. I just go to server.local on my browser inside my home and it takes me to the landing page of the server where I’ve got Heimdall running, which has links to plex and a bunch of other internal services I’m running.

I don’t know what the equivalent is in Windows, but we can jigger something up. Let me know what OS you’re running on what boxes.

source
damnthefilibuster@lemmy.world ⁨14⁩ ⁨hours⁩ ago
TL;DR - don’t do this. Plex on Cloudflare is a bad idea. Read my last notes. Get the Plex Remote Watch Pass instead.

So, regular Cloudflare DNS is not the answer here. Your homelab is almost always natted. As in, there’s a public IP assigned to your home, but your internal network (192.168…) is… internal. Cloudflare doesn’t know of it.

One solution is to expose a port on your router. That would mean that if you go to plex.mydomain.xyz, Cloudflare DNS will send it to your home’s public IP and your router will send it to your internal computer based on that port request. This is NOT recommended. For one, your home’s public IP can change at any time. It’s your ISP’s choice what IP they want to assign to you. They can and will change it when they want to. Second, this opens up your internal network to a barrage of attacks.

Seriously, don’t do this.

A separate alternative is to use something like DynDNS (only if your router supports it). Then folks will go to yourplex.dyndns.io (or something) and that will send them to your router’s public IP, no matter how many times it changes. But if you want to use plex.mydomain.xyz then DynDNS charges you money and, afaik, it’s expensive. So no real point.

The better alternative is Cloudflared and Cloudflare Tunnels. This sits under one.dash.cloudflare.com → Networks → Tunnels.

Hit “Create a Tunnel” and select Cloudflared. Give it a name. Let’s call it “homeserver” (it doesn’t matter).

Once it’s created, click on the name and click Edit. (or maybe the instructions vary if you’re running it the first time). Select Docker, and it’ll give you instructions to run cloudflared as a docker container. The command will look like -

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token CLOUDFLARE_ASSIGNED_TOKEN

Then, you’ll have a tunnel. Once you have it up and running, go to Public Hostnames under the same “homeserver” tunnel edit option.

Add a Public hostname. Subdomain would be plex and domain would be mydomain.xyz (from the dropdown). No path.

For the “service” - type is HTTP mostly (unless you’re running SSL inside your home). And the URL is the internal IP address and port for you. So for Plex it’ll be

192.168.x.y:32400 (internal IP of the computer running Plex)

Once it’s saved and Cloudflare has propagated the change (usually a few seconds), you can go to plex.mydomain.xyz and it’ll show your application 🙂

What’s going on here? Cloudflare’s Tunnel solution sidesteps the Cloudflare DNS feature. You still need your domain attached to your Cloudflare account. Cloudflare gets the request, realizes it’s a Tunnel request, finds the cloudflared container which you’re running inside your network, establishes a secure connection all the way to it. From there, the connection is inside your home, from your cloudflared docker container to your Plex installation and back.

NOTE: Once you do this, everyone who can go to plex.mydomain.xyz (basically the entire internet) will be able to see your Plex setup. Make sure to include strong login credentials. If you do not have any login credentials, you can easily end up with complete strangers streaming your Plex library.

ALSO: This is against Cloudflare TOS. If you’re just using it once in a while, you might get away with it. But if not, Cloudflare will find out and boot your domain and might even close your account.

So… If you are building this for friends and family, get the Plex Remote Watch Pass. It’s $20/year and one possible way for you to give Plex access to people. In this method, you do not need to use cloudflare tunnels or expose a port. Everyone creates a free account on Plex (or you create one account for everyone, and they create their own profiles, whatever) and you grant them access to your libraries. Then they go to app.plex.tv instead of plex.mydomain.xyz, login, and get to your content.

Last Note: I use cloudflare tunnels a LOT. I use it for everything from RSS feeds to Calibre Web. All of my usecases are low traffic scenarios. Cloudflare is chill with those. Video streaming through their network is a whole different ballgame. Do NOT risk it.

This took me way too long to write. Cheers!

source
e0qdk@reddthat.com ⁨17⁩ ⁨hours⁩ ago

Nginx is running in Docker

Are you launching the container with the correct ports exposed? You generally cannot make connections into a container from the outside unless you explicitly tell Docker that you want it to allow that to happen… i.e. assuming you want a simple one-to-one mapping for HTTP and HTTPS standard ports are you passing something like -p 80:80 -p 443:443 to docker run on the command line, adding the appropriate ports in your compose file, or doing something similar with another tool for bringing the container up?

source
- pirateMonkey@lemmy.world ⁨17⁩ ⁨hours⁩ ago
  Yes, I’m using this container: github.com/NginxProxyManager/nginx-proxy-manager using the compose file as written (except I’m naming it nginx instead of app). It maps ports 80 and 443 for traffic and 81 for the manager, which is running.
  
  source

Having trouble setting up Nginx

Comments

Seriously, don’t do this.