I followed YouTube videos and all my domain points to is “server not found.” My domain is through Cloudflare. My server’s ports have been opened at the router.

Proxy Host Settings: Domain name: newly.registered.domain Scheme: http (I’ve tried https too) Forward hostname/IP: local.server.ip.v4 Forward port: jelly_port Access list: Publicly accessible SSL: *.newly.registered.domain

I’d love to share my certificate info, but I don’t see a way to do that…but I set up the DNS thingy with a Cloudflare API token. I remember typing in my server’s public IP here too. Took many tries, but it finally accepted the settings as valid.

So what am I missing to get a reverse proxy? I thought it was supposed to work after all of that.

I’ve been trying to get this going for so long that it just feels like I’m beating my head against the wall until it randomly works, ya know?

  • brewery@feddit.ukEnglish
    5·
    8 days ago

    Did you open ports in docket for 80, 443 for nginx and a port for jellyfin (in docker compose under services add these but with tabs not spaces ports: - 443:443)

    Do you have ufw or a firewall running? This might be blocking the ports for jellyfin and/or nginx.

    It might be easier to create a bridge network called proxy (docker network create proxy) then in docker compose add the following under services networks: - proxy

    And at the bottom of the compose file

    networks: proxy: external: true

    Then in your nginx setting redirect to jellyfin:8096 (service name in docker compose: internal port jellyfin uses I.e. right hand side of ports mapping. Are you using straight nginx or nginx proxy manager (might be worth using this).

    Can you access jellyfin locally on your network (http://internal-ip-of-server:8096/ on a browser)?

    Has your DNS been setup to point to the correct ip your router is on? Are you behind a dynamic IP or cgnat? If cgnat, you have to use cloudflare tunnels. If ddns look into cloudflared docker image.

    Does your router forward those ports to the correct internal ip of your server? Have you fixed the internal IP of the server machine?

    Don’t share your certificate details but you can share your docker compose with personal information redacted or replaced

    It’s probably not a good idea to publish jellyfin to the internet. Look into tailscale or cloudflare tunnel with login security, or wireguard.

    • LazerDickMcCheese@sh.itjust.worksOPEnglish
      1·
      5 days ago

      Ok, this is an extensive answer (thank you), but also a lot to unpack. Before I go making a bridge network, I wanna make sure I’m following you. I’m pretty inexperienced with self-hosting in general outside of Docker, but I’m especially a novice with anything networking so pardon my ignorance here.

      Yes, Jellyfin is accessible locally. Performance is the best I’ve ever seen it too. I uninstalled Tailscale on my Ubuntu server (it was causing networking issues, frankly I didn’t understand how) and removed it from my tailnet dashboard, but Jellyfin is still remotely accessible via Tailscale (which is fine, I guess).

      At this point, my users and I are trying to avoid Tailscale on mobile devices when possible. Two reasons: 1. prevents maintaining regular VPN usage (deal breaker for a couple people) 2. switching between home wifi and mobile drops connectivity, required turning networking off and on again (deal breaker for me, I got spoiled by Synology’s reverse proxy and can’t go back)

      From what I can tell, there’s no CGNAT trickery at play (actually the internet says otherwise). My DNS is a local Pihole+Unbound, in case that matters. The Ubuntu IP is static. Were you requesting the yaml of Jellyfin or Nginx?

      And I believe I was hoping to set up a “Cloudflare tunnel.” I think I was under the impression that this “tunnel” *is *a reverse proxy.

      • brewery@feddit.ukEnglish
        1·
        11 hours ago

        Sorry, the post didn’t have the formatting I expected and is generally quite unclear now I’m reading back through it. I was trying to point out a few different things that I’ve had to learn the hard way when things go wrong! You learn the terminology to search for or have to search for lots of acronyms until you learn them haha.

        Public IP

        So your server is on a fixed IP address. Do you men locally that the machine has a fixed IP within your home lan setup (like e.g 192.168.1.10) or is your public IP fixed (this will depend on your ISP)? Most home providers, like mine, have dynamic IP so every once in a while my public IP will change so everything would go down as my DNS is pointing to the wrong address. Some providers use CGNAT which is even worse and won’t accept any connections originating from outside.

        If dynamic, you can use a DDNS tool like cloudflared to keep checking your public IP and updating your DNS records if it changes. Your services will only go down for however long the polling on this is set. Note that cloudflared does a few things and this is just one one aspect of the tool.

        If you have CGNAT you have to use cloudflare tunnels or similar to create the permanent bridge to your server that all external requests can pass through even if originating from outside.

        Docker bridge networks

        Note this is not essential but can be actually easier to manage and keep more secure. It was hard to get my head around but once I did it was easier.

        You can create a bridge network so the containers you add to that network can talk to each other but the other containers can’t. It also means not opening ports in the docker compose so the system can’t access those containers directly using up ports. A container can have multiple networks too.

        For instance, my nextcloud main server is on proxy and nextcloud-internal networks. The other containers in that docker compose are on nextcloud-internal. My proxy manager (caddy) is on proxy. The various nextcloud containers can talk to each other on the internal network. My proxy and the nextcloud server can also talk to each other through the proxy network. My server cannot talk to any of them directly (unless you also expose ports). Caddy cannot directly talk to my nextcloud database container. Hope it make sense, I can share my docker compose files if helpful. After this info, my original message may make more sense.

        You probably expose ports for jellyfin so can access it locally through 192.168.1.10:8080 or whatever it might be.

        Reverse proxy

        This is separate to a tunnel but tools like cloudflared tunnels and pangolin combine them.

        The reverse proxy is something you setup to pick up a server domain address and deliver it to the requesting computer. It turns cloud.domain.com to 192.168.1.10:8000 and for a website delivers the HTML, images, php etc to client browsers. In the self hosting space it let’s you access different services on one domain (like www.domain.com, cloud.domain.com, request.domain.com as much as you like)

        I have caddy on docker but previously used nginx proxy manager, and for each public service I would setup a reverse proxy to the actual service. For my business website I tell it to send and domain.com and www.domain.com requests to my website in a different docker container. For nextcloud I tell it to send cloud.domain.com requests to my nextcloud server container on its port (on proxy network - see above, in caddy I say reverse proxy to nextcloud-server:80 but if exposing ports it could be your internal server IP like 192.168.1.10:8000 or whatever you are using).

        Tunnel

        This is just connecting two servers or clients and gives them a local IP on each end that can be used to encrypt and tunnel those connections over the internet.

        I don’t actually have a tunnel for my external services as I use my business VPS. I do have a tunnel between my home server and my VPS to create an encrypted and usable tunnel between those separate internal networks.

        I believe cloudflare tunnels and pangolin work the same way, where a user visits your service.domain.com and the service expects you to login. If logged in, it will forward the requests to your home server through an encrypted tunnel (so your ISP and others can’t see it, and your users never see your public IP address), and it also reverse proxies the request to the correct service on your server (like nextcloud). It does both jobs for you. The authentication stage might be optional, I’m not sure.

        It is easier to use these but you’re more tied in to one service.

        Cloudflare proxy

        If you use cloudflare DNS and opt into their proxy, they will hide your home server’s public IP from external users using services through your domain. If you lookup a domain like “dig domain.com” in the CLI, you will see Cloudflared public IP instead of your own. The connection packets will go to Cloudflare, who internally change it to your public IP so the end client cannot see it. It does mean they can track all your header information and unencrypted traffic, and if it goes down nobody can access your services externally using the domain.

        Incidentally, I notice some IPTV services use this to try to hide their public IP but in reality, broadcasters could get the real IP from Cloudflare, especially with a court case.

  • frongt@lemmy.zipEnglish
    4·
    7 days ago

    You’re trying to run before you can walk. Run a “hello world” HTTP container, no cloudflare or proxy, and make sure you can reach it. But test it with your phone on mobile data, or https://downforeveryoneorjustme.com/, because it probably won’t work on the LAN without NAT loopback/hairpinning.

    Also, don’t put jellyfin on the internet anyway, it’s not designed for it. If you want external access, use a VPN.

    • LazerDickMcCheese@sh.itjust.worksOPEnglish
      1·
      5 days ago

      Thank you, that’s really solid advice. It turns out my efforts may have been misguided anyway. I think I was under the impression that “internet exposure” and “Cloudflare tunnel” had similar setups

      • CommanderShepard@lemmy.worldEnglish
        1·
        6 days ago

        You can use Tailscale and a personal domain. Run Tailscale on the same machine as your reverse proxy. Then point DNS records to the machine’s Tailscale IP. Now you can access any services from any machine connected to your Tailscale with a valid HTTPS certificate

      • frongt@lemmy.zipEnglish
        1·
        6 days ago

        Well, those do different things. Expose the VPN, connect via your domain name.

    • LazerDickMcCheese@sh.itjust.worksOPEnglish
      1·
      5 days ago

      Yes, I recently got it working. So LAN connectivity is fine and strangely I can remote access it via Tailscale even though the machine isn’t on a tailnet

  • irmadlad@lemmy.worldEnglish
    2·
    8 days ago

    This isn’t a solution to your issue, but a suggestion:

    Since you are already using Cloudflare for your domain name, and I assume they gave you some nameservers to use, why not explore the Cloudflare Tunnels/ZeroTrust? Cloudflare Tunnels don’t care if you are behind a dynamic IP, or cgnat. Cloudflare is unconcerned with what ports you open on your router/firewall. You don’t even have to adjust your UFW firewall settings. Cloudflare punches through all that with a tunnel in to your server and tunnel out to the internet.

    Admittedly, it did take me a couple tries to get everything worked out, but once I did, it’s easy peasy from there. If you decide this route, I’d be more than happy to clean up some of my notes and share them with you. Might help…might not. LOL

    • LazerDickMcCheese@sh.itjust.worksOPEnglish
      2·
      5 days ago

      See, this just shows how much I need to learn…I thought what I was trying to set up *was *the same thing as a “Cloudflare tunnel.” Honestly, don’t care how it gets implemented, I just assumed this was the easy way because that’s what all the youtubers were suggesting. My end goal here is “I’m on my phone 100 miles away from home, open Jellyfin/Nextcloud/whatever, use domain.actually.works” without needing to disable my Proton/Air/Mullvad connection.

      But I’ve followed 4 or 5 “you won’t believe how easy Nginx is” tutorials, and they’re not working for me…

      • irmadlad@lemmy.worldEnglish
        2·
        5 days ago

        Cloudflare has a ton of services from filtered/unfiltered DNS to Tunnels/ZeroTrust.

        but I set up the DNS thingy

        From this, I guessed you were attempting to use just the DNS portion like 1.1.1.1 or 1.0.0.1. If I misunderstood, me skuzi. What I’m talking about is:

        https://www.cloudflare.com/zero-trust/products/access/

        The caveat to use Cloudflare Tunnels/ZeroTrust is that you need a proper domain with which you can change the nameservers. Duckdns.org or similar won’t do. When you sign up for ZeroTrust, they will give you two nameserver entries. You take those to your domain registrar and insert those in place of the registrar’s nameservers. I got a domain name from NamesCheap for less than $5 USD.

        “I’m on my phone 100 miles away from home, open Jellyfin/Nextcloud/whatever

        Cloudflare Tunnels/ZeroTrust will do that and more. They have all kinds of bells and whistles that are available on their free tier. I didn’t need most of them. It will do all of that without having to adjust your server’s firewall like UFW. You don’t have to worry about port forwarding or such on your router. It just punches a hole in all of that, and delivers what you need. No muss, no fuss.

        To be fair, Cloudflare Tunnels/ZeroTrust is not unique. There are a plethora of ZeroTrust Tunnel providers. Ngrok comes to mind and seems to be the more popular of the alternatives, but there are others. Like I said previously, it took me a couple tries to get Cloudflare Tunnels/ZeroTrust down pat. Not so much that it was overly complicated, that’s just usually my modus operandi. I’m dense some days. LOL

        • LazerDickMcCheese@sh.itjust.worksOPEnglish
          2·
          5 days ago

          Let the record show that irmadlad saved the day here. I learned a lot about what I needed and no longer have to concern myself with something beyond my comprehension