Nginx Proxy Manager Synology NAS Setup Instructions!

Today we are going to look at how to set up Nginx Proxy Manager on a Synology NAS.

If you’re exposing any services on your network, using a reverse proxy is a great way to increase security and performance. A reverse proxy is a server that sits in front of your web servers and forwards client requests to the web servers. In layman’s terms, you only have to expose one server (using ports 80/443) and will be able to expose as many web services as you want.

This is an example of the network flow of a reverse proxy (simplified):

Please keep in mind that this is an alternative to Synology’s Application Portal where you can set up a Reverse Proxy. If your intentions are to only create a reverse proxy, you might want to use that instead, as there is no configuration necessary (other than the reverse proxy settings)!

1. Setup Instructions - Nginx Proxy Manager Synology NAS

This tutorial will utilize a Synology NAS and Docker. Since Nginx Proxy Manager uses a database, we will need to install two different containers. One for our database and one for Nginx Proxy Manager. By default, Synology uses ports 80 and 443 so using our host network interface isn’t ideal. For this reason, we will create a macvlan network interface (in Docker) that will allow us to bypass this port conflict.

1. Install Docker from Synology’s Package Center.

2. We need to create a few folders that we will be mapping our Docker containers. By default, the Docker package will create a folder named docker after it’s finished installing. Inside of this folder, we are going to create a folder named mariadb and nginx-proxy.

nginx proxy manager synology

3. Inside of the nginx-proxy folder, create two sub-folders named data and letsencrypt.

nginx proxy manager synology

4. Create and upload a file named config.json to the nginx-proxy folder. This file must contain the contents below. Ensure that you change SYNOLOGY_NAS_IP to the IP Address of your Synology NAS!

{
"database": {
"engine": "mysql",
"host": "SYNOLOGY_NAS_IP",
"name": "nginxproxymanager",
"user": "nginxproxymanager",
"password": "nginxproxymanager",
"port": 3306
}
}

5. The folder setup is complete!

1.1 Macvlan & Bridge Docker Network Interface Setup

1. Ensure you can SSH into your Synology NAS. Open Control Panel, select Terminal & SNMP, and Enable SSH service. If you are using Synology’s Firewall, ensure that you allow port 22 traffic. I created a video on how to SSH into your Synology NAS if you have any problems.

2. SSH into your Synology NAS using your favorite SSH tool.

3. We need to create a Docker macvlan network interface. First, we need to determine what network interfaces currently exist (on your Synology NAS) and note down the adapter name. To do this, run the command below and note down the network interface name that has your Synology NAS’s IP address (in this example, mine is eth0).

ifconfig

nginx proxy manager synology

4. Next, you need to run the command below while substituting the correct subnet (most are 192.168.1.0/24 or 192.168.0.0/24 by default). You also need to pick an IP address that you’d like to use that’s not currently in use. I will be using 192.168.1.198. NOTE: npm_network will be the name of the network (you can substitute this as you’d like).

sudo docker network create -d macvlan -o parent=eth0 --subnet=192.168.1.0/24 --gateway=192.168.1.1 --ip-range=192.168.1.198/32 npm_network

nginx proxy manager synology

5. Our network is now created. We can now exit our SSH session and disable it in DSM (if you won’t be using it). If you are disabling it and created a firewall rule for it, you should inactivate the firewall rule as well.

6. Next, we need to create a bridge network. This is what will allow our host (NAS) to communicate with our Nginx Proxy Manager container. Open Docker and navigate to the Network section. Select Add and enter a subnet that’s not currently in use. The IP address of the bridge I am creating will be 192.168.10.2.

nginx proxy manager synology

7. Both network interfaces have now been set up!

1.2 MariaDB Install and Configuration

Nginx Proxy Manager requires a database to be set up in order for it to work properly. While Synology offers a MariaDB package, I like to separate it out by creating a second Docker container for the database only.

1. Open Docker, navigate to the Registry, and search for MariaDB. Download the latest version of MariaDB.

nginx proxy manager synology

2. After the image has finished downloading, navigate to the Image section, and double click mariadb to set up a new container.

3. Give the container a name and then select Advanced Settings.

nginx proxy manager synology

4. Select Enable auto-restart.

nginx proxy manager synology

5. In the Volume section, select Add Folder and then select the mariadb folder we created earlier. In the Mount Path section, type /var/lib/mysql.

6. In the Port Settings section, change the Local Port to 3306. NOTE: If you have to use something other than 3306 as the port, you need to update the config.json file we created earlier.

7. In the Environment section, we need to create four variables. These variables are what will store our root password, database name, username, and password. NOTE: if you don’t want to use the values below (nginxproxymanager), you can change this to whatever you’d like. Just ensure that you update the config.json file that we created earlier with the new information.

8. Select Apply and create the container. The database has now been created!

1.3 Firewall Setup - Nginx Proxy Manager Synology NAS

Since we are using a macvlan network interface, there are no firewall rules that we need to set up for Nginx Proxy Manager. However, the MariaDB container is using the host network interface and for that reason, needs a firewall rule to allow traffic. If you haven’t set up Synology’s firewall, I created a tutorial on how you can do it (and suggest that you do).

1. Open the Control Panel, select Security, then Firewall. Select Edit Rules and add an allow rule for port 3306. NOTE: If you are using a different port in the config.json file that we created above, you will need to use that port instead of 3306.

1.4 Nginx Proxy Manager Container Setup - Synology NAS

1. Open Docker, navigate to the Registry, and search for nginx-proxy-manager. Download the latest version of jc21/nginx-proxy-manager.

nginx proxy manager synology

2. After the image has finished downloading, navigate to the Image section and double click jc21/nginx-proxy-manager to set up a new container.

nginx proxy manager synology

3. Give the container a name and select Advanced Settings.

nginx proxy manager synology

4. Select Enable auto-restart.

nginx proxy manager synology

5. In the Volume section, we need to create two folder mappings and one file mapping. Select Add Folder and add the data folder and add the mount path /data. Next, select the letsencrypt folder and add the mount path /etc/letsencrypt. Select Add File and select the config.json file we created earlier with the mount path /app/config/production.json.

6. Under Network, add the npm_network and npm_bridge networks and remove bridge.

7. Match the Port Settings to be like the image below. If you are using 4443, 8080, or 8081 for anything, you can change the ports to something not currently being used.

8. Select Apply and create the container! Give the container a few minutes and you should be able to access the web admin portal through the npm_network IP address and port 81!

http://[npm_network]:81

2. Nginx Proxy Manager Setup - Synology NAS

1. Login with the email address [email protected] and password changeme.

nginx proxy manager synology

2. When prompted, change your name and email address, then set up your password.

3. Nginx Proxy Manager is now set up! Ensure that you port forward ports 80 and 443 on your router to the macvlan network we created above.

BAD GATEWAY ERROR

Certain people are experiencing “bad gateway” errors when they try and login and after a while, I was able to figure out why. It appears like Synology uses Port 3306 for something (or a package is using it) which is why certain people get a “bad gateway” error. There are really two ways to fix this:

1. If your NAS has multiple NIC’s and you have multiple IP addresses assigned to it, in the “config.json” file, enter the other IP address of your NAS. This should avoid the port conflict.

2. Rather than using port 3306 when we configure MariaDB/config.json, use a totally different port (8725 for example). This should avoid the port conflict.

3. Using Nginx Proxy Manager

Now that we set up Nginx Proxy Manager, it’s important to know how to use it! I created a tutorial that you can follow that will show you how to expose Plex and setup an SSL certificate. The tutorial is fairly straight forward, but highlights how you can expose practically any web server quickly, easily, and securely!

4. Conclusion

This was a fairly complex tutorial, but I am hoping that it’s broken down enough to be easily understood. It’s not normal that you need to set up two different Docker containers to get one container to work, but in my opinion, this is the best way to get Nginx Proxy Manager working on a Synology NAS.

Thank you for reading the tutorial. If you have any questions, please leave them in the comments!

This Post Has 111 Comments

  1. [10/19/2020] [10:28:49 AM] [Global ] › ✖ error connect EHOSTUNREACH 192.168.1.2:3306

    When i try to log in to proxy mangager i get ”bad gateway”

    Can you help me

    1. This error states that Nginx Proxy Manager cannot access the database. A few things to check:

      1. Is the database container running and did you properly specify the username/password when you set it up (you can check the screenshots of how it should look)?
      2. If you are using Synology’s firewall, did you create an “allow” rule for 3306 on your NAS?

      Let me know how it goes and we can continue troubleshooting!

  2. I have this same problem as Peter does. I do not use the firewall.

    There are a few small things which are unclear to me:
    – does the docker container for MariaDB need to run on the same macvlan network? I can imagine this is why the NPM container cant connect to the MariaDB one. Btw i had to change the DB port to another port, so I did this in the config and in the docker container. (only the local one, not the docker port)
    – which password needs to be in the config? The Root password or the other one?

    1. Thanks for checking out the tutorial! A few notes:

      1. The MariaDB container should NOT be run on the same macvlan network. That macvlan network is only for the Nginx Proxy Manager container.
      2. If you changed the database port (from 3306), you need to ensure that you set it up in the MariaDB container and the config file. If you’re using Synology’s firewall, you need to create an “Allow” rule for that port as well. You are correct that it should only be done on the local port, not the container port.
      3. The config file should have the username/password (not the root password). Honestly though, it’s probably easier to just keep them all the same since this container won’t be used for anything other than NPM.

      Hopefully this helps, but if you have any other issues, please let me know!

  3. Dumb question, but which of these ports needs to be set up for port forwarding on the router? Is it 443:443 and 80:80 or 443:4443 and 80:8080?

    1. Never a dumb question! Just 443/80 to the macvlan network IP address. The other ports are just mapping container ports to local ports on the NAS.

      If you have any other questions, please let me know!

      1. So in the container’s port settings, is the “host” port the app’s internally used port, and the “container” port the one that is used to access the front end–or the other way around?

        1. The “Local Port” is the host (NAS’s) port and the “Container Port” is the containers ports. Ironically, if you’re using a macvlan network, the “Container Port” is actually the port that you use to connect (192.168.1.198:81 in the tutorial).

          Hopefully this makes sense, but if you have any further questions, please let me know!

  4. That’s what threw me off. So even with the macvlan driver, a port is still used on the NAS network interface? Does this mean that firewall rules opening those ports to the NAS IP are still required (router/firewall and NAS software firewall) or does this approach only require firewall rules and port forwarding for the container’s IP and ports?

    1. As I understand it, the host needs to have ports assigned because the macvlan network interface is a virtual network interface (behind the host’s physical network interface). So basically, even though we are accessing a virtual network interface (macvlan) with its own port configuration, it’s still running through the hosts network interface, so it needs to be mapped to an open port on the host.

      You should NOT have to create any host (NAS) firewall rules. You ask a really great question though and it made me double check to see if I had any rules allowing traffic that I wasn’t aware of, but I don’t. You have the right train of thought, though, and I need to do some further research to tell you exactly why you don’t need to open the containers port. For now, my best assumption is that the NIC is capable of handling everything on its own.

      Seriously great question that will certainly teach me something. Let me know if you have any other questions!

  5. hi Wunder Tech,

    Thanks for the tutorial! But unfortunately I’ve got the same error as Peter and Leon, when trying to login I’ve got the “bad gateway” error.
    mariaDB is running, I’ve followed the tutorial 3 time already and still the same issue. On the log I’ve got this message though “error connect EHOSTUNREACH local_nas_ip_address:3306.

    Again port 3306 is allowed on sync firewall and I’ve followed everything on the tutorial. Any thought?

    Thanks for your help

    1. Thanks for checking out the tutorial! Unfortunately, a lot of people ran into this issue and from what I’m finding, it’s due to the NAS model that they’re using. More specifically, the NIC that the NAS has which may or may not have specific features needed to get this to work. I haven’t updated the tutorial yet because I’m not clear on what NIC is required, but I can tell you that it works on a DS1019+. What NAS model are you using?

      1. I’m using ds218+ . Tried to look on forums but no luck so far 🙁

        1. My assumption is that’s what it is, sadly. Have you considered using Synology’s built-in reverse proxy? If you’re interested in using that, I have a video coming out for that tomorrow on YouTube!

          I will do a little further research to see if I can figure anything out. If I can answer any other questions, please let me know!

  6. Following these directions, mariadb keeps restarting with error:
    2020-11-16 4:18:15 0 [Warning] Can’t create test file /var/lib/mysql/mariadb.lower-test
    /usr/sbin/mysqld: Can’t change dir to ‘/var/lib/mysql/’ (Errcode: 13 “Permission denied”)

    I’m not sure where I might have gone wrong. I even deleted it and redid everything and it still seems to have the exact same issue. Any help for this noob would be appreciated.

    1. I know people have had issues connecting but I haven’t seen that error in specific. If you allow the Docker container to run with high privilege, does it still happen?

      Let me know and we can continue troubleshooting!

      1. Yes, even with high privilege it does the same thing.

        1. Is that error the only error in the log? Is there anything else in the log that might point us in the right direction?

          I googled the error message and have been trying to find information on what it could be, but there is very little helpful info. I’m hoping that there’s a different error message that we might be able to use to get additional information.

  7. Any solution to the bad gateway error on a DS1621+ yet? Getting it…sucks…

    1. I’m surprised the DS1621+ has the issue. I expected that to be one of the ones that works as it tends to be a little more premium than the others.

      Are you receiving ANY errors in the Docker logs? Anything that can point us towards what it could be? From what I’ve found, it appears to be NIC related which makes it a very difficult issue to resolve (if it’s not something easy like the firewall). Let me know!

  8. Following your good tutorial, I was able to setup everything as suggested by you. However, only when trying to connect to nginx-proxy-manager (IP 192.168.2.198:81 in my case) I receive the message “unable to connect”. I checked firewall on NAS and enabled port 3308 – as I use that port – and set port forwarding on my router for 80 and 443 for IP 192.168.2.198. I tried with firefox and chrome browser, cleared cache, but all these measures did not help.
    You did not mention to forward port 81 also to container IP? Is this required? I tried with and without forwarding, however, nothing worked.
    Any suggestion from your side what to do?

    1. No, you should not be forwarding port 81. Have you created a firewall rule for port 81 on your Synology NAS? That seemed to be needed for others. If that doesn’t work, can you try disabling your Synology NAS firewall and seeing if it works? Definitely don’t keep it disabled, but just to temporarily test. If it works, then it’s a firewall rule or lack of firewall allow rule that’s causing the problem.

      Let me know and we can continue troubleshooting!

  9. I am very thankful that someone is taking a lot of time to make tutorials for those out of the loop…

    Here is a screenshot with probably not very helpful information…
    https://imgur.com/a/EPTv53l

    I tried to go through this with as little variables as possible – the only thing I changed was the npm_network ip to 202 instead of 198.

    I am not getting specific bad gateway errors like the others but merely a connection timeout.

    The ‘substituting the correct subnet’ part really confused me as I don’t really understand how you would ‘find’ the correct subnet – so I just put in “192.168.1.0/24” hoping it was correct.

    Hopefully, this is just a very simple noob mistake but would greatly appreciate any advice on how to get this working. Please let me know if you need any more detail on logs, screenshots, etc.

    – Jay

    1. Thanks for providing all of this info and for the kind words!

      Can you please try and disable the firewall (temporarily) and check to see if it works? If it does, we have a firewall issue. For some people, it seems like allowing traffic on port 81 on the NAS is necessary. This is NOT the case for me, but to be honest, I haven’t had any of the bad gateway issues either so I am not the best example.

      Please let me know if it works and if not, we can continue troubleshooting!

  10. I tried with and without firewall rule for port 81 on my NAS and disabled firewall completely, however, everything without success. I can ping 192.168.2.198 from terminal. In my router I set internal and external port on 80/80 respectively 443/443; hope that is correct?
    Thxs for trying to help me.

    1. Are you trying to access the website using port 81? If your IP address is 192.168.1.198, you should navigate to the NPM webpage using http://192.168.1.198:81.

      Let me know and we can continue troubleshooting!

        1. Are you using the 192.168.2 subnet by default for all local devices? I apologize for the basic questions, I just haven’t seen this error before. If the firewall is disabled and you’re unable to get to the site, are there any errors in specific in the Docker logs?

          1. Yes, I use the 192.168.2 subnet for all my local devices in the LAN. The docker logs are ok; Nginx-Proxy-Server is running. I observed the following: when entering http://192.168.2.198 without the port :81, the website “Welcome to nginx!” opened: “If you see this page, the nginx web server is successfully installed and working. Further configuration is required.”
            Also, on the NAS under firewall settings the nginx-proxy-server is now listed as an internal application with the ports 4443, 8080 and 8081. I enabled the settings but still can’t access the IP 192.168.2.198:81.
            The proxy server is up and running and I can access my DSM under my domain with http and https.

          2. Something seems to be slightly off. When I do what you said (access 192.168.1.198 without port 81), I get this: “Congratulations! You’ve successfully started the Nginx Proxy Manager”.

            If you’re getting that page, it appears like the traffic is somehow being routed back to your NAS rather than the NPM container itself. You said in an earlier comment that the ports now match (8080, 8081, 4443). By any chance, did you initially configure with ports 80/81/443? If so, that could be the problem. You might need to recreate the Nginx Proxy Manager container with the correct port mappings.

            Let me know and we can continue troubleshooting!

          3. I deleted everything (container, network and directories in docker) and installed everything from the beginning. Still, I am unable to connect to the site 192.168.2.198:81. I have also two LAN’s on my NAS and tried with eth0 and eth1 as these are the interfaces and also tried different IP addresses for my NAS in config.json. Every time I changed the setup, I deleted everything and made a fresh install, however, without success.
            When I now try to ping 192.168.2.198 the response is: “Destination Host Unreachable”.
            Sorry, to trouble you, but I am completely lost now :(.

          4. It almost sounds like the macvlan network interface isn’t working properly.

            If you SSH into your NAS and run the command “ifconfig”, are you substituting the correct network interface (could be eth0, eth1, ovs_eth0, etc.) into the macvlan network interface creation command? If the container is running and the macvlan network interface is associated with it, at minimum, you should be able to ping it, which makes me think the network interface isn’t working properly.

            Let me know and we can continue troubleshooting.

          5. I think the interface setup should be ok; I checked it with portainer and the assigned ports are all shown correctly. Checking the ports of all the other container running in docker, I noticed that one app from home assistant is using port 80. Could this cause the port conflict? Also, what is with the web server on Synology using port 80? I unchecked that one, however, without success. When I ping from my iMac, the following is shown:
            [email protected]_DS:~# ping 192.168.2.198
            PING 192.168.2.198 (192.168.2.198) 56(84) bytes of data.
            From 192.168.2.125 icmp_seq=1 Destination Host Unreachable
            From 192.168.2.125 icmp_seq=2 Destination Host Unreachable
            It looks like the traffic is redirected to the NAS; don’t understand why?

          6. You aren’t using the same network interface for Home Assistant, right? As long as you’re not, there shouldn’t be any port conflicts.

            When you created the container, did you remove the bridge network?

            Basically, you should run the “ifconfig” command in terminal. Find the network interface name and add it to the command below:

            sudo docker network create -d macvlan -o parent=eth0 –subnet=192.168.2.0/24 –gateway=192.168.2.1 –ip-range=192.168.2.198/32 npm_network

            Create the NPM container, add the npm_network and remove the bridge network. The traffic should not be routed back to your NAS, so we need to try and solve that issue first (which is most likely causing it).

            Let me know how it goes and we can continue troubleshooting.

          7. I did all the steps as suggested by you. Home Assistant uses different network interfaces than Nginx. When running the ifconfig command, it shows the two interfaces:
            eth0 Link encap:Ethernet HWaddr 00:11:32:10:86:96
            inet addr:192.168.2.125 Bcast:192.168.2.255 Mask:255.255.255.0
            eth1 Link encap:Ethernet HWaddr 00:11:32:10:86:97
            inet addr:192.168.2.130 Bcast:192.168.2.255 Mask:255.255.255.0
            I created the npm_network command with eth0 and alternatively with eth1 – after deleting everything again -, however, both bring the same result “unable to connect” to 192.168.2.198:81.
            Also, correctly shown is the npm_bridge network when running the terminal command ifconfig and there is no conflict to other docker container address ranges or interfaces.
            docker-a1 Link encap:Ethernet HWaddr 02:42:65:6A:A1:0B
            inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0

          8. If the npm_network is configured properly (as it looks like it is), the next thing to check would be the firewall. Do you have Synology’s firewall enabled? If you do, can you temporarily disable the firewall and check to see if the container starts responding?

            I am starting to shift my focus to it being some sort of firewall rule blocking it. If it’s not, at least this will rule out the firewall as being the issue.

            Let me know how it goes!

          9. Today some other result. Now, after reinstalling everything again and also rebooting the Synology, I am getting the Bad Gateway. I set the port on 8725 and also tried with the second interface eth1, however. still getting Bad Gateway.

          10. In the config.json file, can you try and use the second IP address for your NAS? That has fixed the issue for other people.

            Let me know how it goes!

          11. Yes, I tried that already, however, without success.

          12. Unfortunately, it could be NIC related. It sounds like certain people with specific NAS models have problems with this tutorial and it comes down to the NIC that their NAS is using. If you changed the port and tried to use the other IP address and it still doesn’t work, that would be my unfortunate assumption.

  11. Thanks for the reply, I was reading through some comments and here are some things I have tried so far:

    1. Running both ‘MariaDB’ and ‘Nginx-Proxy-Manager’ containers using high privilege

    2. Trying the connection with “192.168.1.202:81” and “192.168.1.202:8081” in both Firefox and Chrome

    3. Adding a custom rule for Port 81 in Synology Firewall and also disabling Firewall

    4. Restarting Docker

    5. Using the command ‘sudo ping 192.168.1.202′ in PuTTY and getting the result “icmp_seq=23 destination net unreachable”

    I am using a DS918+ on “DSM 6.2.3-25426 Update 2” and MARIADB_VERSION 1:10.5.8+maria~focal and NPM_BUILD_vERSION 2.7.1

    I also have a Google Wifi with a DHCP reservation set for my NAS’ IP and no port forwarding rules on the router settings.

    Something tells me this has to do with my router or that subnet substitution thing that I still don’t understand
    I have skimmed other forums, all of which seem to have their own unique, meticulously detailed problems that dig far too much into terminal command line stuff I am not comfortable with

    I am mainly just trying to set up a reverse proxy as it seems Google Wifi does not directly support using a VPN and I just wanted to hook up a domain name I bought so others can connect to Jellyfin.
    It seems perhaps I am overcomplicating things but seems like it is a necessary evil…

    1. Have you considered using Synology’s built-in reverse proxy? I have a video on how you can set it up here: https://www.youtube.com/watch?v=iWvCN2j7xjo

      That’s not to deter you from using NPM, it just might be easier if you’re only using it for Jellyfin. If you are interested in using NPM, a few other questions:

      1. I assume that you’re trying to access this from a machine on your local network? Does that machine have any trouble accessing DSM?
      2. Is your router set up to use the 192.168.1.X subnet?

      Another option would be configuring OpenVPN on your Synology NAS. It runs very well and I have a tutorial up for that if you’re interested. However, it’s probably easier to use a domain name with Jellyfin since you’ll probably want to use it on multiple devices and some of them may not support OpenVPN.

      Let me know and we can continue troubleshooting!

  12. I think I finally understand the “correct subnet” part as my IP had “192.168.86.x” and I wasn’t reading closely enough… Google Wifi uses that as part of its default DHCP Pool (?) but once I redid the SSH part, I was able to get to the Nginx login page!

    Bad news is that I have the same exact problem as Richy (Peter, Leon) where we get the bad gateway on the login page, followed by “EHOSTUNREACH” error in the log of Nginx Proxy Manager

    https://imgur.com/a/TSYsho6

    I already have the firewall rule allowed for 3306 and also tried disabling the firewall but still get the same message.

    Again, I have a DS918+ so maybe this model also has to be blacklisted for NIC incompatibility?

    I’ll try out Synology’s Reverse Proxy solution for now (rly efficient tutorial btw) as I don’t think I’ll need to expose any other services remotely besides Jellyfin at the moment

    1. I figured out why the error is occurring! I have two NIC’s on my NAS with two separate IP addresses assigned to them. When I use the first, I get the “bad gateway” error, but when I use the second, it works. My assumption is that port 3306 is being used for something by default and using the second NIC avoids the port conflict.

      So if you have two ethernet cables plugged in to your NAS, in the config.json file, can you please try and change the “SYNOLOGY_NAS_IP” to the other IP address? That is, if you’re interested in using NPM. If you’d rather just use Synology’s reverse proxy server, that’s totally fine too! I really wish I used a different port to begin with because these errors would have never occurred.

      If I can answer any other questions, please let me know!

  13. My DS918+ has two ethernet ports but I am only using the ‘LAN 1’ portion. So I am not sure if changing to the ‘other’ IP makes much sense here. Did you mean switch the cable to the other port?
    Also, wouldn’t disabling the firewall essentially remove the problem of ports as far as “Bad gateway” is concerned?

    Regardless, I have tried updating the config.json to port “3333” and also updating those ports within the MariaDB container. After restarting the containers, I still get the same error (bad gateway) which you can see in the Nginx log of EHOSTUNREACH before even trying to login.

    I’m not really sure if MariaDB and its ports are the problem but maybe something with the npm_network when creating the subnet part…?

    In part of the command “–subnet=192.168.86.0/24 –gateway=192.168.86.1 –ip-range=192.168.86.198/32”, the default gateway under Network -> General shows Default gateway is “192.168.86.1” which is my Router LAN IP. Does the subnet also need to be 86.1/24 instead of 86.0/24? (apologies as I don’t understand the significance of the /xx part)

    There are other forums that talk about editing a Docker Compose file for the db or something but it seemed really confusing honestly (https://github.com/jc21/nginx-proxy-manager/issues/300#issuecomment-704025517)

    Sorry if I am making things more complicated but this has been the best source so far for setting up a nas so I can just use jellyfin

    1. When you say you’re only using the “LAN 1” portion, does that mean you only have one ethernet cable plugged in? I was wondering if you’d be able to plug a second one in so that you have two cables plugged in (and two IP addresses). This will allow you to access your NAS on the IP address that you already have set up and on a second IP address. Adding the second IP address to the config.json file is how I was able to resolve the “bad gateway” error.

      As far as just changing the port in the Docker configuration for MariaDB, I’m not sure that will work unfortunately. You might have to recreate the entire container if you want to use a new port. I don’t think it’s the macvlan network interface. You appear to have done everything right and have the subnet correct as 192.168.86.0/24.

      In summary, you can use a different port (3333 should be fine), but you will have to recreate the MariaDB container to use that port. Then, update the config.json file and my understanding (at least from my testing) is that the issue will be resolved.

      The second option is to leave everything as-is, plug a second ethernet cable in to your NAS and in the config.json file, use that second IP address rather than the current IP address you’re using.

      Sorry to drive you nuts. If you’d rather just use Synology’s reverse proxy, that’s totally cool too!

  14. I did only have one ethernet plugged in (didn’t see a reason to use the second one) but once I plugged the second one in, the IP reads as 225 for LAN 2 (224 is LAN 1).

    I added another DHCP Reservation for the second ethernet port through Google Wifi and restarted DSM.

    I tried to just update the config.json with the 225 IP instead (using port 3333) and began to receive a “Connection lost: The server closed the connection”

    Then I deleted the MariaDB container and removed the mariadb folder and recreated the mariadb folder and reconfigured from the image again.
    This time, I tried to just use 3306 and updated the config.json to reflect this with the new 225 IP. After mounting the /var/lib/mysql to docker/mariadb and setting both local and container ports to 3306, doing the environment variables…
    I still get the same “The server closed the connection” (High privilege doesn’t seem to matter either)

    I redid those above steps using port 3333 and still get the same “Server closed the connection” and if I change the IP back to 224 (LAN 1) on config.json, then I get the EHOSTUNREACH error.

    Regarding NPM or Synology’s Reverse Proxy, I was currently trying to get DynDNS configured since Namecheap domain provider isn’t part of Synology’s whitelist of Extended Access for DDNS and without DynDNS, I don’t think I can access my jellyfin through my domain name.
    There were all sorts of things regarding A Records, Wildcards for subdomains (won’t be using that for now I think) that made me think remote access jellyfin might be a lot more harder than I thought it would be. Sorry to get off topic, let me know if there was something I skipped over again!

    1. When you recreated the MariaDB container, did you use the same folders that you initially created, and if you did, did you delete the contents of them before running the container? I’m sorry, I know we’re doing a bunch of different things but without deleting the files (or creating new folders), it will use the existing data which is what you don’t want.

      1. If I were you (to simplify things), I would use either Synology’s DDNS or set up DuckDNS. I have a tutorial on how to do that here: https://www.youtube.com/watch?v=RhB6EAEi4D8

      2. Create a CNAME record in NameCheap pointing to the DDNS hostname (either Synology’s or DuckDNS).

      3. Create Synology’s reverse proxy and skip over Nginx Proxy Manager. While I do think that we can get it to work, for only exposing Jellyfin, I’m not sure it’s worth it.

      Let me know if you have any questions!

  15. PS I was modifying the firewall rules accordingly (adding rule for custom 3333 or 3306) but left the Nginx folders and containers unchanged!

  16. OK no more bad gateway! To be completely honest, I think I might have not deleted the contents of the MariaDB folder the first time I just deleted the container.

    I was definitely sure to delete the container and the contents the second time, but I was getting the same error using either port…

    This time I just used 3306 and simply changed the NAS IP to LAN 2. Really glad I didn’t have to redo the NPM part and macvlan creation so at least I think the problem of bad gateway does rest within the NIC like you suspected

    Anyway, I agree DuckDNS would have been more convenient but since I bought my domain name and went through the trouble of getting PositiveSSL working, I am fairly motivated to use it.

    Tried to follow the steps with DuckDNS replacing the DuckDNS portion with Namecheap but creating a xxx.Synology.me and pointing Namecheap to that domain and I feel like I am trying to untangle too many wires at once since I am lacking a lot of fundamentals of networking (if that wasn’t obvious).

    The main issue with Nginx proxy manager is now resolved but I think I will have to do some hw on how to properly configure things on Namecheap since I don’t really want to go through transferring the domain

    1. That’s amazing news! Glad to hear that it finally worked.

      As far as your domain, I think we are talking about the same thing, but I might not be explaining it well. I will try and explain it a little better now.

      When you have a dynamic IP address, a DDNS hostname will track your external IP address. If it changes, navigating to that DDNS hostname will still work, as the DDNS hostname is updated with the new IP address. Basically, you can be positive that your DDNS hostname is always your external IP address. If you have a static external IP address, a DDNS hostname is not required.

      So with that in mind, let’s assume that you want to expose Jellyfin using your own domain from Namecheap. In Namecheap, you will create a CNAME record. The name will be the subdomain you want to use (if you wanted to use jellyfin.yourdomain.com, the “Host” would be “jellyfin”). In the value section, you’d add the DDNS hostname you’re using (xxx.duckdns.org, for example). This is basically telling Namecheap to route traffic for the domain jellyfin.yourdomain.com to the xxx.duckdns.org IP address.

      From there, you would create a new record in Nginx Proxy Manager and point it back to your Jellyfin server, then create an SSL certificate. At this point, Jellyfin is exposed using jellyfin.yourdomain.com and DuckDNS is simply being used to update your external IP address if it changes.

      I realize that’s a lot, so if you have any specific questions, let me know. If you knew everything that I said above and just wanted to use your domain as the DDNS hostname, you can ignore all of this!

  17. Thanks so much for taking the time to write out that explanation. I added a CNAME Record and put the host to “Jelly” and I was able to land on the Nginx “Congratulations” page through the jelly.domain.tld but I don’t know if this actually means they’re both going to the right place.

    Maybe it would help first to understand how to set up the xxx.synology.me DDNS correctly within Nginx Proxy Manager? It seems straight forward by putting in your local NAS IP and port within the forward hostname…

    But I continue to get “internal error” with “some challenges failed” whenever I try to save the SSL request. Is this because I already have certificates (PositiveSSL & LetsEncrypt from Synology.me DDNS)? How would I point the certificates that I’ve acquired so that NPM knows I have them?

    I’m sure screenshots of what I’m looking at (as well as logs) would help a ton but I think there’s a lot of sensitive information on those pages that probably isn’t good to show in a public website

    I feel like I am noodling you for info because it’s the “next step of something I don’t understand” that this tutorial wasn’t meant to cover so I hope I’m not taking too much of your time!

    1. Not a problem at all, I’m happy to help!

      Just to confirm, you opened ports 80/443 to the macvlan IP address, correct?

      If you’re using Nginx Proxy Manager, you will have to create a new proxy host. This tutorial is for Plex, but the same principals apply for Jellyfin. Just make sure that you use Jellyfin’s internal IP address and port number: https://www.wundertech.net/setup-an-ssl-certificate-for-plex-using-nginx-proxy-manager/

      You can then request a new certificate through Let’s Encrypt (it’s in the tutorial as well) and accessing jelly.yourdomain.com should work. Also, if you’re trying to generate a new certificate through DSM, it will not work as ports 80/443 are opened to the macvlan network interface and not DSM. This is expected, but without getting too far into it, the synology.me DDNS hostname should still renew as it uses DNS as opposed to ports 80/443 for renewal. If you aren’t sure what I am talking about, don’t worry, but if you’d like to learn more about it, I’m happy to explain it.

      I’m hoping the tutorial I linked helps, but if I can answer any specific questions, please let me know!

  18. Sorry I didn’t disclose that I watched the followup Plex SSL tutorial. It’s where I realized that you can type in the internal IP address and port for Jellyfin when adding an Nginx Proxy Host.

    I did port forward 443->443 and 80->80 on that .198 macvlan which my router detected but I don’t have any other ports open on my router for any other device.

    I would have thought putting in hostname.synology.me as a proxy host in NPM and putting the internal IP and internal port should at least bring me to the DSM page but I get the default congrats page.
    I actually read one of your comments in a reddit thread and used “nslookup hostname.Synology.me” and do get the public IP; DSM also shows status as “Normal” and shows my public external IP.

    So it’s saying that my DDNS hostname is working but I still thought I should be brought to the DSM login page at least.

    And if this would be solved with the SSL certifiate request, I still get “internal error” when trying to configure the proxy host for hostname.synology.me

    Is there anything else we can rule out or is this mostly about ports and the proxy host not being configured properly?
    I want to get the DDNS working before worrying about getting the Jellyfin proxy host working.

    PS I just tried with duckdns.org via your DDNS Xpenology/Synology tutorial and get the same exact problem: both domains return 502 bad gateway even though the status is “Normal” in DSM DDNS – And the SSL request gets ‘internal error’

    1. It sounds like DDNS is working. The only goal of DDNS (at this point) is to point to your external IP address, so if “nslookup hostname.synology.me” returns your external IP address, you’re good!

      As for getting to the default DSM page, I wouldn’t recommend this, but you can test it quickly if you’d like. Add “hostname.synology.me” as the domain name in Nginx Proxy Manager, use “https” as the scheme and add your Synology NAS’s IP address in the forward hostname/IP. For the port, add 5001. If you changed the default ports from 5000/5001, you will have to put the HTTPS port there. After you save that, you should be brought to the default DSM login page. Keep in mind, we aren’t going to create an SSL certificate right now, we are just using this to test.

      As soon as you confirm it works, delete the proxy host. You don’t want to expose DSM to the outside internet and this process will do that, so make sure you delete the proxy host.

      Let’s get this to work first, and if it does, we can move on to Jellyfin.

      Let me know how it goes!

  19. So it doesn’t seem to matter whether we change the scheme or not because http scheme + http port or https scheme + https port still return me to the default congrats page (which is when nginx proxy manager is hit with an unknown host)

    I am going to assume that the port forwarding part is correct as we only need to add 80-internal, 80-external (TCP), and 443-internal, 443-external (TCP) through that macvlan we created earlier.

    I remember even turning off NPM and the firewall before adding port forwarding a few days ago and STILL not being able to access my hostname.synology.me

    I have no issues getting into DSM through the actual internal IP and port. However, whatever I change the default site to (What to show when Nginx is hit with an unknown Host), I ALWAYS get that page.

    How is it possible that I am not configuring the proxy host correctly??

    1. When you navigate to hostname.synology.me, you won’t actually be brought to any pages unless a web service is exposed. It’s correct that navigating to hostname.synology.me will not bring you to DSM. It actually won’t bring you to anything if you aren’t exposing anything on ports 80 or 443.

      Now, with that said, if you’re hitting the “Congratulations! You’ve successfully started Nginx Proxy Manager”, NPM is working, but something is off with the proxy host.

      Just to confirm, these are the settings I am hoping you can use:

      Domain Name: [your_subdomain].synology.me
      Scheme: http
      Forward Hostname/IP: Internal IP address of your Synology NAS
      Forward Port: 5000 (this should be the HTTP port. If you changed it, it will be something else).

      Save it, ensure port 80/443 is port forwarded to your macvlan network interface (198 IP). Use this site to ensure that both, port 80 and 443 are open: https://www.yougetsignal.com/tools/open-ports/

      Navigate to [your_subdomain].synology.me. As long as you aren’t using a DNS server, you’re supposed to be brought to the login page for DSM. If it isn’t working on your local machine, try and navigate to it using your cell phone if possible. Also, try using the mobile network if it initially doesn’t work.

      This is certainly a strange issue, but since you’re getting to the “congratulations” page, my assumption is it’s something small holding us back.

      Let me know how it goes!

  20. The website says that my public IP does not have port 80 or port 443 open. My settings in Google Wifi app says I do (unless I did this wrong somehow). Also restarted the router after port forwarding in case.

    https://imgur.com/a/8oNWLYj

    Using CMD, I can ping the macvlan IP address but cannot ping my nas (request timed out) but I don’t know if this is normal with the way NPM was set up.

    I noticed there is an option to configure the router in DSM under External Access – Do I need to do anything here?
    It gives me a red flag for “Checking network environment” and there was no option to enter Google Wifi as a manufacturer of routers…
    I do not have another router between the ONT terminal box so I’m pretty sure I do not have a double NAT issue nor any need to enable bridge mode.

    I just realized that my ISP Fios may be blocking ports 80 and 443 as it seems to be a common problem.

    Feel like this is opening another 5 cans of worms for configuring VPS/VPNs if that is the solution which seems a little complicated for remote jellyfin…

    1. You are correct in saying that the ISP is most likely blocking ports 80/443 which is why all of these issues are occurring. I can’t guarantee that, but if we can’t get those ports open, we won’t be able to get anything else to work. I can tell you that my ISP blocked port 80 (443 was able to be opened) and I had to go into my online account and “confirm” that I wanted port 80 opened. Just to check, can you try disabling the Synology firewall and using that port checker to see if ports 80/443 will then say opened? Your screenshot for opening the ports is correct.

      I had Fios at an old apartment and didn’t have issues with ports 80/443. You said it goes straight from the ONT terminal box to the router, so I assume that Fios disabled the coaxial connection and you’re using ethernet only?

      You are experiencing somewhat abnormal issues, but I think that you’re close. Once we can get 80/443 opened, it should be smooth sailing.

  21. If I remember correctly, the ONT box was connected by a thick white wire that looked a similar gauge to coaxial but didn’t screw into anything like coax normally would and looked like a green RJ45’ish head.
    Only one long ethernet cable connects from the now tiny, ONT box to the Google Wifi.

    To my surprise, the ports remain open once I disable the Synology firewall which gives me some hope again! But it still doesn’t work.

    Initially, I didn’t think to verify if the ports were open or not because disabling Synology’s firewall still returned “502 Bad Gateway” when using either my ‘hostname.synology.me’ or my ‘jelly.domain.tld’ (both of which have the internal IP and ports in proxy host configuration within NPM)

    So if:
    1) My ports are apparently not blocked by my ISP
    2) The router port forwarding to the Macvlan is done correctly
    3) DDNS and external IP reads as “Normal” in DSM for synology.me and duckdns
    4) My local internal IP services (e.g. Jellyfin, DSM) all work

    I feel like there is something within DSM that needs to be configured?

    Also, I remember in your Plex SSL tutorial that “remote access” would be turned off because we were using the reverse proxy to peep into our local network;
    In Jellyfin, there is an option to leave a box unchecked which would block all remote connections. I guess we leave this unchecked because reverse proxy is kind of masking the remote connection?

    1. That’s great news!

      So to add to your list, a few things that we should check:

      1) Google “what is my IP”. Google will return your public IP address. Then, run “nslookup [your.ddns.hostname]” and confirm that the IP address matches.
      2) If the IP address matches, did you create a proxy host in NPM and does it match your DDNS hostname? It needs to match exactly so that NPM knows where to route it.
      3) If it doesn’t work and you’re willing to experiment a little further, in Namecheap, create a CNAME DNS record with the value as your DDNS hostname. Set the subdomain to be jellyfin (or whatever you’d like to use). Wait about ten minutes or so and then run “nslookup [jellyfin.yourdomain.com]”. Does it return your external IP address? If so, create a new NPM Proxy Host:

      Domain Name: jellyfin.yourdomain.com
      Scheme: http
      Forward Hostname/IP: Internal IP address of Jellyfin
      Forward Port: 8096

      If this doesn’t work, I would have to do a little more research on why it is happening. Generally, 502 errors occur because the proxy server cannot get a valid response from the server. If you can access Jellyfin using http://[IP_ADDRESS] and you use that same information in the Proxy Host, it should be working.

      You are correct that you shouldn’t need to check off that box for blocking remote connections, but it can’t hurt to check it off if it still isn’t working after you try the steps above.

      It has to be something minor at this point, we just need to figure out what it is. Let me know if this doesn’t work and we will continue troubleshooting. I am hoping that breaking it down like this will help us find what step isn’t working as expected. Let me know how it goes!

  22. The result from google matches the external address found on DSM DDNS and the WAN from my router. The nslookup commands for my ‘hostname.synology.me’ and ‘jelly.domain.tld’ return my public IP address within “Non-authoritative answer:” (Hope that’s okay?)

    From some reading and from what I can understand, someone had a similar issue and had to change their “proxy_pass” to localhost from their domain name. I really wish I understood what this meant but people who encounter similar issues seem to be configuring nginx manually somewhere.

    https://www.reddit.com/r/Ubiquiti/comments/5v5kvw/port_forwarding_give_502_bad_gateway_error_with/

    Would there be something we can paste or write within NPM – Edit Proxy Host -> Advanced to override the settings within DSM for faster troubleshooting?

    1. I am scratching my head at this one if I’m being honest. 502 errors are generally web server errors which makes me feel like the macvlan network can’t connect to the Jellyfin web server. Do you have any services that aren’t on your NAS that you can try and connect to? Anything on a Raspberry Pi or Windows/Mac device?

      This isn’t to say that what you’re doing shouldn’t work because it should, I’m just having a hard time wrapping my head around why it’s not working. If we can isolate it as being a macvlan to NAS issue, we will be better off when trying to troubleshoot. Another option is to use Synology’s Reverse Proxy as well just to test if it works.

  23. I think you are right that the macvlan cannot connect in someway. The ports on my external IP address remain closed when I tried to use port forwarding to Macvlan (with NPM, MariaDB, Synology Firewall ON) and remain open if I disable Firewall (although I still get 502).

    I was about to give up but I tried to port forward 80/443 to my NAS IP on my router instead of the Macvlan. Using the built-in reverse proxy, I can finally use “https://hostname.synology.me” and reach Jellyfin remotely (tested using cellular data).

    The duckdns.org domain failed to validate before I forwarded those to the NAS IP but even when now validated, I’m getting “SSL_ERROR_BAD_CERT_DOMAIN” so I guess it did not validate?

    I see Firefox has a problem reading some certs but I thought the synology.me one also comes from Letsencrypt so I’m not really sure what’s the problem?

    1. Great news! Do you have a certificate for that DuckDNS domain setup and configured? If not, you will receive that error.

      In Nginx Proxy Manager (if you still want to try and get that to work), did you try the bridge network IP (192.168.10.2 in the tutorial) for Jellyfin (I am assuming Jellyfin is configured on the NAS)? I can’t believe that I had this mental block for so long, but the container needs to use the bridge to communicate with the host and vice versa. So while you might access Jellyfin using the NAS’s IP address from a browser window, you will need to use the bridge network IP in the proxy host configuration. I apologize for not thinking of this earlier, it’s just hard trying to troubleshoot without seeing it myself!

      You might be tired of testing/tinkering at this point, so feel free to use Synology’s Reverse Proxy if you’d like! I just don’t want to leave you stranded if you still want to use NPM.

      Let me know and thanks for all your testing!

  24. The ‘hostname.duckdns.org’ has the green lock issued by R3, with the expiry set ~ 3 months from now so I think it has been validated.
    The duckdns website does not show me if it has been validated or not so I am looking only at the certificate tab under DSM.

    https://i.imgur.com/0Q8SbQm.png

    Interesting note about using the “npm_bridge” IP under proxy host for jellyfin – I assume we use port 8096 but it ended up going to a warning page regarding HSTS.
    More importantly I think, ports 80/443 were also closed on the public IP once again if I try to port forward to the macvlan (198) on my router. I think this needs to work before being able to add that npm_bridge IP into the proxy host.

    There is a bridge mode I can enable in my router (as opposed to standard NAT) but I don’t think this has anything to do with why port forwarding on the macvlan does not seem to work.

    If I revist your tutorial for setting up the local and container ports within NPM, as long as we use port numbers that aren’t being used (like 8080), the macvlan IP should be able have the 80/443 from the router to the container, right?

    I think I am driving you more nuts than me but I guess I can live with the built-in reverse proxy as long as I can proceed to using duckdns first, then namecheap (which has its own problems outside of this tutorial).

    1. The error that you provided is actually very interesting! It looks like it’s trying to connect via HTTPS and an SSL certificate is not assigned.

      You are correct in stating that the SSL certificate will only validate when ports 80/443 are opened to your Synology NAS. However, when you’re using Nginx Proxy Manager, you will use SSL certificates inside of Nginx Proxy Manager as opposed to DSM.

      First, on Synology’s firewall, create three allow rules for ports 8080, 8081, and 4443. Then, check to see if the ports are opened. If they are, go into Nginx Proxy Manager (everything you have is setup properly, by the way), select the Proxy Host, go to “SSL” and request a new SSL certificate. As long as that validates properly, I am starting to think that it will work.

      I truly do apologize for the back and forth. I am basically trying to troubleshoot through messaging which isn’t always easy! Hopefully that will work – let me know how it goes!

  25. No problem about the back and forth but I realized that I had those firewall rules in place already (I just used the application checkbox instead of typing in 3 port numbers).

    https://imgur.com/a/2F3Tsl7

    When I put in those 3 ports as separate custom rules, I still get the same result: external IP says 80/443 are closed. When I turn that firewall off, 80/443 are open.
    But trying to launch the proxy host from NPM with “http://192.168.10.2:8096”, I get “NET::ERR_CERT_AUTHORITY_INVALID” from Chrome and “MOZILLA_PKIX_ERROR_SELF_SIGNED_CERT” when either the ports are open or not…

    So for whatever reason, port forwarding to the macvlan does not seem to open the ports to the external IP. If I use ‘LAN 2 IP’ which was used for that config.json file to avoid that NIC issue, the ports are open.

    I’ve tried to add a task scheduler to use some /bin/curl command to update Namecheap DDNS but it seems people have been having their scripts and workarounds all breaking and I think I may just go ahead and try to move the domain to an approved Synology DDNS domain.

    I guess I should be glad that at least the hostname.synology.me reverse proxy works and hopefully it is secure enough for my needs. I would definitely prefer not trying to SSH into the NAS playing blindfolded hopscotch as others seem to have no problem doing.

    1. Your firewall looks perfect. The good/bad news is that when you disable the firewall, the fact that the external ports open means that it’s 100% a firewall rule that’s blocking it. I am just having a hard time even guessing what you should open next, as literally every port (80, 443, 8080, 4443, 8081, 8096, 3306) are all opened. The honest answer is that it’s probably a combination of things causing the issue and trial and error will allow you to fix it, but like you said, I’m not sure it’s worth it if Synology’s reverse proxy is working properly. With that said, if you DO want to get it to work, I am happy to continue troubleshooting. The self-signed error can probably be bypassed by selecting “advanced” and proceeding to the site. A valid SSL certificate should get rid of that error.

      As far as using Namecheap for DDNS, outside of the actual domain name, I’m not sure it’s worth it. DuckDNS, Synology’s DDNS, or practically any other DDNS service will track your external IP address and do little more. With the CNAME record pointing to your DDNS hostname, you can still use your domain and everything will be pointed to the right place. I did a quick google search on Namecheap Synology DDNS and I wouldn’t suggest using any of the solutions. That’s not to say they wouldn’t work, but it’s always advised to use an “out-of-the-box” solution as opposed to a custom one. I use Synology’s DDNS service and I use my DDNS hostname for practically nothing (since I own my own domain). I just point my CNAME records to the DDNS hostname and get the same result. Obviously, you are free to do whatever you’d like! I just don’t think it’s worth the efforts since you own your own domain. Other than the hostname being in that CNAME record, you probably won’t use the DDNS hostname for anything else.

      Let me know how you’d like to proceed!

  26. I sincerely apologize for such a trivial mistake but I just forgot to hit configure after letting Synology DSM fetch the Letsencrypt… And obviously because I did not match the service with the newly assigned domain certificate, OF COURSE IT WOULDN’T MATCH

    So duckdns.org, the google domain (I bought out of frustration), namecheap, they all work now…………….. But I may take your suggestion and not use a custom provider to avoid dealing with query URLs and weird cURL tasks and just let DSM deal with that.

    While I would like to use the cheaper domain and SSL I paid for, I kind of don’t want to deal with DSM breaking the query URL in an update like I’ve seen happen to people in the past.

    Having purchased a TLD with HSTS, I don’t think I can get around having to type in exactly https:// before my domain.tld otherwise I am also brought to an invalid cert page.

    There are options to forward the domain so that “www” leads to “https://” but they come into conflict with the Dynamic DNS that I set up through Google since I can’t use host or @ twice. When I try to just add a CNAME record pointing to ‘hostname.synology.me’, I cannot establish a connection back to jellyfin.

    I would think the reverse proxy for external access would still use the domain.tld and that as long as DDNS for the Synology.me had “Normal”, that I could just point to it?

  27. Should have been a little more patient, my subdomain forward for http://www.domain.tld now works via google domains!

    Basically, I can enter the bare domain or http://www.domain.tld and now it will redirect to the bare domain (jellyfin) instead of being told I need to type in exactly “https://domain.tld” due to HSTS.

    I did not expect to go down this kind of rabbit hole but am really thankful for your patience throughout this process!

    Hopefully, I can now try to get hardware acceleration to work properly on Jellyfin as I had trouble trying to install the vappi driver? since Intel quicksync did not seem to work with my DS918+

    Thanks again!!!

    1. No need to apologize (from your last post). I’m very happy to hear that you got it working!! I was going to mention after reading your first comment that the HTTPS settings in the reverse proxy should clear that issue up.

      I wish I could help with the hardware acceleration, but I unfortunately haven’t set that up and don’t want to point you in the wrong direction. I am pretty sure that the docker container has to have the setting “Execute container using high privilege” enabled, but that’s the extent of what I remember reading (when I was considering setting this up).

      If I can help in any other way, please let me know!

  28. Hi WunderTech, quick question. Why is there a need to create the npm_bridge network? We have already created the macVLAN, isn’t the purpose of that to make it appear to be a physical network interface directly connected to the physical network? Why would the Synology NAS then have to communicate with the Nginx proxy manager?

    You don’t give too much explanation for creating the bridge network other than “This is what will allow our host (NAS) to communicate with our Nginx Proxy Manager container.” (WunderTech). But why is this? What role does the NAS have that it needs to communicate with it?

    1. The npm_bridge network is used for the host (NAS) to communicate with the container. If you have any services running on your NAS, you would need to use the bridge IP address in NPM. The bridge is the only way the host can see the container or the container can see the host. If you try and use the Synology NAS’s IP address from NPM, it won’t work as the macvlan network interface does not allow communication with the host.

      In summary, you will use the bridge IP address in NPM if you have to create a reverse proxy for any services running on your NAS’s IP address. Hopefully this clears it up a little (I acknowledge that it’s a little confusing), but let me know if I can clear it up further!

      1. I think I am understanding it now, thank you for the clarification. So in other words the npm_bridge network is used so the MariaDB has a network to live on, then we publish the port 3306 to our host the Synology NAS. Which will allow the Nginx proxy manager, (that now lives on the local network through the macvlan) to communicate with the host Synology NAS which is forwarding the port(3306) that connects back to MariaDB. And the reason for the macvlan is because of the port conflicts we would get with the Synology NAS services, that’s why we publish those ports on a new IP to avoid port conflicts using the macvlan. Is that correct? I think where some people are getting confused with your tutorial is within the networking aspect. You don’t really mention anywhere in the tutorial that you need to connect the Nginx proxy manager to the macvlan network(npm_network) and the MariaDB to the name specific bridge network(npm_bridge).

        1. You are 90% correct. The bridge network is not used on the MariaDB container (the host network interface is used there). The macvlan network interface does avoid the port conflicts that the Synology NAS will have by default. The bridge network is used so that the Nginx Proxy Manager container can communicate with the host.

          I will try and rewrite that section when I get some time to be a little clearer. If I can answer any other questions, please let me know!

        2. Hello Ramon & WunderTech,
          For me the “bad gateway” on first login is indeed due to a network problem.
          From Nginx container (npm_bridge|192.168.10.x or npm_network|192.168.1.x) i can’t access MariaDB container (bridge|172.x.x.x).
          I just modify the network of the MariaDB container, replace bridge (default Synology Docker network) to npm_bridge so that they are both in the same network and can comunicate. Problem solved for me.
          Does this change cause a problem?
          Merry Xmas 😉

  29. Hey Wundertech, thanks for the great tutorial. It looks like you have your hands full helping others, but unfortunately I am also stuck with the bad gateway issue at nginx login. I changed port 3306 to 8725 from the start so I’m a bit perplexed as to what I could be missing. 8725 is set in both the mariadb container and the config.json. I’m also running Google Wifi router with the gateway at 192.168.86.1 so for the npm_bridge I bumped the subnet up to 192.168.96.0/24. I’m using a DS218+ with only one ethernet port and I’m not using the synology firewall. Any ideas?

    1. You appear to have done everything right. This tutorial has been a problem for a lot of people and I’m somewhat perplexed as to why. I can replicate the issue, but can also resolve the issue on my side using the two suggestions I provided. By any chance, do you have the MariaDB Synology package installed?

      Let me know and I will try and provide additional help!

      1. Nope, the MariaDB Synology package is not installed. The only thing on there is Plex and Docker. Any suggestions are greatly appreciated. I spent some time reading through the comments section and so far no luck.

        1. Someone just commented that this worked for them, so I’m hoping that you can try it if you get some time!

          On the MariaDB container, replace the default bridge network with the npm_bridge network that we created. Then, you should be able to access the database using that npm_bridge IP address.

          Let me know how it goes!

          1. Went through the tutorial from scratch again and this time I replaced bridge with npm_bridge. Then when trying to launch the nginx container I received a docker api failed message. The logs came back with: Start container Nginx-Proxy-Manager failed: {“message”:”no available IPv4 addresses on this network’s address pools: npm_network

            I’m a bit out of my depth and haven’t had a chance yet to look into it. Totally possible that I whiffed and made a mistake along the way.

          2. Did you add both, the npm_bridge and npm_network to MariaDB or just the bridge? Try adding just the bridge if possible.

            I will also mention that I haven’t had a chance to test this out and it’s a suggestion from another viewer who said it works, but the idea of it makes sense. I will try and test this out when I get some time and hopefully provide full instructions to get it working!

  30. Thank you for this tutorial. I would like to give some information about the things I had to do to make things work on my DS918+ NAS with the macvlan setup, as I read about similar difficulties over here that I myself experienced as well (bad gateway).

    First, I had to setup a macvlan interface on the NAS itself as well as within docker. The docker part is mentioned in this tutorial, but on the NAS I had to do:

    (you might need to prepend sudo with these commands)

    ip link add macvlan0 link bond0 type macvlan mode bridge
    ip addr add 192.168.200.1/25 dev macvlan0
    ip link set macvlan0 up

    In my case the NAS would live in subnet 192.168.200.0/24 with 192.168.200.254 as the default gateway for that subnet. For the maclvan0 I used the first half of that subnet (/25) and 192.168.200.1 to be used as a gateway address as can bee seen in the commands. I also use bond0 instead of eth0 as that is how my NAS is physically connected to the network (LACP etherchannel). Should work the same for eth0 if that is what you have.

    The docker command for me looks like:
    docker network create –driver=macvlan –gateway=192.168.200.1 –subnet=192.168.200.0/24 –ip-range=192.168.200.0/25 –opt parent=bond0 name

    After the commands I would have:

    # ifconfig macvlan0
    macvlan0 Link encap:Ethernet HWaddr 7A:08:95:A0:D5:66
    inet addr:192.168.200.1 Bcast:0.0.0.0 Mask:255.255.255.128
    inet6 addr: fe80::7808:95ff:fea0:d566/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:110603 errors:0 dropped:0 overruns:0 frame:0
    TX packets:19396 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1
    RX bytes:30356512 (28.9 MiB) TX bytes:22121499 (21.0 MiB)

    This interface would not be there without the “ip” commands mentioned earlier and I could not use the docker command to create a network with macvlan driver.

    Another thing I had to do was to change a network settings on the NAS. Control Panel –> Network –> General and click on the “Advanced Settings” button under the DNS server fields. Then you will get a window with a few settings to turn on or off. One of them is called “Reply to ARP request if the target IP address is identical to the local address configured on the incoming interface”. I had to turn this one off to make everything work for me. I can imagine this might not be needed when you use MariaDB as a docker image as per this tutorial, but in my case I use MariaDB as a “normal” package running on the NAS. I guess this has to do with the fact that with the macvlan setup there are several IP addresses behind the NAS interface. To be able to communicate with the other (docker,macvlan) addresses the NAS needs to respons to ARP requests for those addresses as well and not only it’s own address.

    Because I have MariaDB running “outside” of Docker, I had to tell MariaDB that is was ok for user “npm” to access the “npm” database. For that to happen I had to run this SQL query in MariaDB:

    GRANT ALL PRIVILEGES ON npm.* TO ‘npm’@’l192.168.200.10’ IDENTIFIED BY ‘password’ WITH GRANT OPTION;

    192.168.200.10 is the IP address that NPM is using in docker and password should be replaced with the actual password that you would like to use for this database user. Without the SQL query a remote connection from NPM to the database would not be allowed by MariaDB. You would see timeout messages in the logs of your NPM docker container.

    Still need to figure out a few things. Whenever my NAS is rebooted, I have to recreate the macvlan0 interface (with the ip commands) and have to flip the ARP setting twice (turn on –> apply, turn off –> apply) to make NPM work again. If I do not do that, I get timeouts for NPM trying to connect to MariaDB. While the ARP setting is remembered, the double flip needs to happen for some reason. For the ip commands I probably need to find out a way for the NAS to configure this during boot.

    Anyway, with the above commands and settings I could get NPM to work fine with MariaDB running on the NAS itself (not as a docker container).

    Hope this info helps a few!

    1. This is truly great information and I can’t thank you enough for writing it! I will try and test this out when I get some time to see if I can get it to work. Hopefully, I’ll even be able to help with your reboot issue!

      Thanks again!

  31. same issues as everyone, on a DS920+ Bad Gateway from nginx, none of the fixed (port change or nic) work, I am only using one nic in my DS920+ but it has two in the back.

    1. Can you use the second? That’s one of the recommended fixes (and what personally works for me). Plug the second in, use the second IP address in the config file and it should push you through that error.

  32. There is clearly an issue involving IPV6 for I get

    ❯ Enabling IPV6 in hosts: /data/nginx

    [1/12/2021] [9:25:32 AM] [Global ] › ✖ error connect ECONNREFUSED 192.168.1.213:3306

    I admire the work you are doing, just wish I could resolve this with the limited docker knowledge I have.

    1. Are you using IPv6? I admit that I’m not, so I tailored the tutorial in a way that it uses IPv4. If you’re using IPv4, ignoring that error should allow you to proceed.

  33. I am using IPv4, yes, though it throws errors continuously.

    this is unrelated but the error log shows this:

    2021/01/13 05:42:47 [error] 245#245: *11 connect() failed (111: Connection refused) while connecting to upstream, client: 192.xxx.1.200, server: nginxproxymanager, request: “POST /api/tokens HTTP/1.1”, upstream: “http://127.0.0.1:3000/tokens”, host: “192.xxx.1.101:81”, referrer: “http://192.xxx.1.101:81/login”

    2021/01/13 05:42:49 [error] 251#251: *16 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”

    2021/01/13 05:42:54 [error] 251#251: *20 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”

    2021/01/13 05:42:55 [error] 245#245: *18 connect() failed (111: Connection refused) while connecting to upstream, client: 192.xxx.1.200, server: nginxproxymanager, request: “POST /api/tokens HTTP/1.1”, upstream: “http://127.0.0.1:3000/tokens”, host: “192.xxx.1.101:81”, referrer: “http://192.xxx.1.101:81/login”

    2021/01/13 05:42:59 [error] 251#251: *23 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”

    2021/01/13 05:43:04 [error] 247#247: *25 connect() failed (111: Connection refused) while connecting to upstream, client: 127.0.0.1, server: nginxproxymanager, request: “GET /api/ HTTP/1.1”, upstream: “http://127.0.0.1:3000/”, host: “127.0.0.1:81”

    So my host os is:
    192.xxx.1.100
    macvlan is:
    192.xxx.1.101
    desktop working from:
    192.xxx.1.200

    1. That makes it sound like the firewall is blocking it. Do you have the firewall enabled? Can you try disabling it temporarily to see if it works?

      Also, what functionality exactly isn’t working? Does the webpage not load?

  34. I found a solution for the bad-gateway error, in my case it was simply a wrong .json file. Check the logs of your nginx-docker, if you find something like this:

    UnhandledPromiseRejectionWarning: Error: Cannot parse config file: ‘/app/config/production.json’: SyntaxError: Unexpected token \ in JSON at position 1

    Double check your config. Since the code on your website contains some formatting, i.e background color, textedit in mac took those values and fu**ed up the file.

    But I love the tutorial! 🙂

    1. This is awesome! Thanks so much for sharing!

  35. When you say to connect to “http://[npm_network]:81”, does that mean the IP address associated with the “parent=eth0” argument in the macvlan setup, or the IP of the “–ip-range” argument (192.168.1.198 in your example)?

    I can get to the admin via my Syno’s IP address (any of the addresses, actually, even the ones I didn’t set as the parent), but not at the IP address I specified for the macvlan.

    The actual command I used was:
    sudo docker network create -d macvlan -o parent=eth2 –subnet=192.168.7.0/24 –gateway=192.168.7.1 –ip-range=192.168.7.221/32 npm_network

    And I can access the admin UI from 192.168.7.177 (bond0 for eth0 and eth1) or 192.168.7.197 (eth2), but not from 192.168.7.221.

    Is that expected?

    1. The macvlan network will be the “ip-range” IP address, so 192.168.1.198 in the example.

      As for accessing it from the Synology’s IP – I wouldn’t expect that behavior. When you created the container, did you add the mavclan network to the NPM container and remove the bridge network?

  36. Hi, Im on a DS918+ – I had to use the IP adress of the Docker container to get around the bad gateway error.

    ifconfig
    docker0 Link encap:Ethernet HWaddr XX
    inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
    inet6 addr: fe80::42:5eff:febf:b58f/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:0 errors:0 dropped:0 overruns:0 frame:0
    TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:0 (0.0 B) TX bytes:648 (648.0 B)

    1. I’m glad to hear you were able to resolve it, thank you for sharing!

  37. Hi i Have a DS920+

    i’m not very good with docker. Can you put this all in a docker-compose.yml, that its run with only docker-compose.yml

    1. Yes and no – you should be able to modify the Docker Compose file on this page to get it working: https://nginxproxymanager.com/setup/

      The issue is that Synology’s services use ports 80/443 and implementing NPM without using the maclvan network interface will result in it not working. I haven’t tested this out, but you CAN get it working with a docker compose file, it just needs to be modified.

      1. thanks i tried it with this tutorial but i get this error in my nginx docker

        connect EHOSTUNREACH 192.168.178.200:3333

        firewall is deactiv
        i changed the port from the mariadb from 3306:3306 to 3333:3306

      2. 2. trie

        I have it now installed with your tutorial also with a other port(3333) put I get

        [2/3/2021] [10:54:17 AM] [Global ] › ✖ error connect EHOSTUNREACH 192.168.178.200:3333

        1. I’m assuming that 192.168.178.200 is the IP address of your Synology NAS? Are you able to get to the web interface via the macvlan network interface IP?

          1. yes 192.168.178.200 is the 1.ip from the Nas and 192.168.178.201 is the 2. ip. 192.168.178.210 is the nginx ip.

            When i forword in my modem to 192.168.178.201 i’cant get a certificate. If i forward to 192.168.178.210 i can’t get a certificate. If i forward to 192.168.178.201 i can get the certificate but get an error if i call my domain.(502 Bad gatway)

          2. I know that you initially requested a Docker Compose file – is that what you used to create the container?

            As for not getting a certificate, are you using Cloudflare by any chance? Do you have ports 80/443 opened on your NAS?

  38. Hi,
    I’am using a ds918+ and getting the same “bad gateway” error.
    When i look to the logs, i get “enabling IPV6 in hosts” but i’am not using IPV6.
    I tried disabling the firewall, changing the port, …
    The logs in the MariaDB looks fine : “ready for connections”.
    I run already a jlesage nginx server but having trouble using hostnames when connected to my wifi netwerk and was hoping this could help me.
    If not, could you help me with a sollution for this?

    1. Since you’re using a DS918+, do you have two ethernet cables plugged in? If you do, can you try setting the IP address for your NAS in the config.josn file to be the other IP address?

  39. Hi,

    when I try to follow Macvlan & Bridge Docker Network Interface Setup to create network I got this error:
    “Error response from daemon: failed to allocate gateway (192.168.1.1): Address already in use”

    I think this error is due to Pi-Hole as I have done macvlan network following your other tutorial I did follow your tutorials on

    Can you make a tutorial on how to do this when you do have already macvlan network used by pi-hole?

    1. I will look into creating a tutorial for this in the future! Have you tried using a different IP address?

  40. Hello
    Love the Tutorials – I have already set up AdGuard which uses one macvlan
    The question is do I have to setup another macvlan for nginx on the other lan port or can I use the same macvlan which was set up for AdGuard already?

    1. Are you using AdGuard Home still? If you aren’t, you can certainly use that macvlan network!

Leave a Reply

Close Menu