That was the solution: UFW was blocking internal traffic. Running ufw allow from 172.16.0.0/12 fixed it.
Hello!
So until now, I’ve been self-hosting at home with my own machines, and this is the first time I’m working with a VPS.
I’m running Nginx Proxy Manager (NPM) and my application in separate Docker containers on my AlphaVPS VPS with the IP address 100.100.10.10. I’ve configured UFW to secure my server, and I’m trying to access my application through a domain using NPM, but I’m getting a 504 Gateway Timeout error.
Here’s what I’ve done so far with UFW:
1. Block All Incoming Traffic by Default
ufw default deny incoming
ufw default allow outgoing
2. Allowed Specific IPs
I’ve allowed specific IPs which are my home and work IP:
ufw allow from 100.100.10.11
ufw allow from 100.100.10.12
3. Allowed Ports for Nginx Proxy Manager
I’ve opened the necessary ports for HTTP (80) and HTTPS (443) to be accessible from the outside:
ufw allow 80
ufw allow 443
What I did in Nginx Proxy Manager:
- I created an A record for
sub.domain.comthrough my registrar, pointing to the VPS IP (100.100.10.10). - In Nginx Proxy Manager, I added a Proxy Host for the domain
sub.domain.com, set the IP address (100.100.10.10), and the port of my application inside Docker (e.g., 8000). - I also enabled SSL and requested a new certificate for
sub.domain.com.
Issue:
Even after setting up everything, I’m facing a 504 Gateway Timeout error when trying to access my application through the domain name.
Could someone help me troubleshoot why I’m getting the 504 Gateway Timeout error? I might have done something wrong as my understanding of this is very basic. Could it be a problem with the UFW setup, or is there something wrong with the Nginx Proxy Manager configuration?
Thanks in advance for your help!



Different angle on this, and it may or may not fit your setup, but it changed things for me.
I’ve been accumulating audio since the early 2000s. Twenty-some years of ripped CDs, vinyl rips from release groups, random downloads. Several thousand albums. At some point I accepted that tags were never going to be consistent across that pile, because the sources never agreed on anything in the first place: a 1979 vinyl rip tagged by whoever released it, a CD rip from 2004, and a modern FLAC have nothing in common metadata-wise, and no tagger reconciles that without me babysitting it.
So I stopped trying to fix the tags and leaned on the folder structure instead. My tree already carried everything I cared about: genre at the top, then artist, then Artist - Year - Album, with subfolders for live, compilations and singles. That structure took years to build and it’s reliable in a way my tags never were.
I run Velvet (mStream fork) as the server for it. It serves the library by folder structure rather than by tag database, so there’s nothing to scan, nothing to match, nothing to get wrong. And I vibe-coded Sharesonic, an Android client for it, because I wanted to browse my library the way it’s actually organized and share a track, a playlist or an entire folder as a public link without exporting anything. Personal project, it’s on GitHub if anyone wants it.
To be clear about what this does and doesn’t solve: it doesn’t repair your files. If Picard truncated audio on you, that’s a real problem and it needs fixing at the file level, not at the player level. Worth checking whether the audio itself is actually shorter or whether it’s just the duration metadata disagreeing with the stream, because both look identical from the player side and only one of them is destructive.
The trade-off is real. You lose cross-cutting queries: no “everything from 1977 across all artists”, no proper album artist handling for compilations. If that matters, stay on Jellyfin and keep grinding through Picard. If you mostly navigate by “I want to hear that specific album”, folders are faster than any tag database.