|
| 1 | +This folder contains sample reverse proxy configs for various docker images linuxserver provides. They are grouped in two: |
| 2 | +1. "subfolder" these will allow accessing services at https://yourdomain.com/servicename |
| 3 | +2. "subdomain" these will allow accessing services at https://servicename.yourdomain.com |
| 4 | + |
| 5 | +To enable the reverse proxies: |
| 6 | +1) rename the conf files and remove the ".sample" at the end (ie. "sonarr.subfolder.conf") and |
| 7 | +2) restart the letsencrypt container |
| 8 | + |
| 9 | +Make sure that your default site config contains the following lines in the appropriate spots as seen in the default version: |
| 10 | +1) for subfolder methods: "include /config/nginx/proxy-confs/*.subfolder.conf;" |
| 11 | +2) for subdomain methods: "include /config/nginx/proxy-confs/*.subdomain.conf;" |
| 12 | + |
| 13 | +To disable the configs, simply rename the files to add back the ".sample" to the end, and restart letsencrypt. |
| 14 | + |
| 15 | +If you are reverse proxying linuxserver containers installed on the same host with the recommended options, you shouldn't |
| 16 | +need to edit these conf files. However, some files require you to make changes to the service containers such as adding |
| 17 | +base urls in their settings. Each conf file lists the required changes on the first line. |
| 18 | + |
| 19 | +These confs also assume that the letsencrypt container can reach other containers via their dns hostnames (defaults to |
| 20 | +container name) resolved via docker's internal dns. This is achieved through having the containers attached to the same |
| 21 | +user defined docker bridge network. |
| 22 | +- If you are using docker-compose and the containers are managed through the same yaml file, docker-compose will automatically |
| 23 | +create a custom network and attach all containers to it. You don't have to do anything extra. |
| 24 | +- If you are starting the containers via command line, first create a bridge network via "docker network create [networkname]" |
| 25 | +and define that network in the container run/create command via "--network [networkname]". |
| 26 | +- If you are using a gui manager like portainer, you can create a custom bridge network in the gui, and select it when creating |
| 27 | +a new container. |
| 28 | +- If you are using unraid, create a custom network in command line via "docker network create [networkname]", then go to docker service settings (under advanced) and |
| 29 | +set the option "Preserve user defined networks:" to "Yes". Then in each container setting, do one of the following: |
| 30 | + 1) Unraid 6.5.0 or earlier - (under advanced) add "--network=[networkname]" into "Extra Parameters". |
| 31 | + 2) Unraid 6.5.1 or later - in the network type dropdown, select "Custom : [networkname]". |
| 32 | + You would have to do the above for the letsencrypt container as well, so they are all on the same custom network. The bridge |
| 33 | +network that unraid uses by default does not allow container to container communication. |
| 34 | + |
| 35 | +If the reverse proxied containers are not reachable via dns or they are running on a different machine, you will have to modify |
| 36 | +these confs to fit your needs. |
0 commit comments