Resource icon

Tutorial Synology Reverse Proxy under the hood

Currently reading
Tutorial Synology Reverse Proxy under the hood

one-eyed-king submitted a new resource:

Synology Reverse Proxy under the hood - Fed up with the limitation of the Synology reverse proxy?

Introduction
Rusty made a fabulous beginner friendly tutorial on how to configure reverse proxy configurations using the UI: Tutorial - Synology Reverse Proxy.

This tutorial is aimed for advanced users: if you feel unconfortable with working in the shell (or if you don't know what it means) this tutorial is probably not suited for you.

It covers the limitations of the reverse proxy...

Read more about this resource...
 
Great tutorial @one-eyed-king, tnx!

One question. I used this location /usr/local/etc/nginx/sites-enabled for my custom, "survive-the-DSM-update" location for specific RP configurations that, as you mentioned, do not show in the UI but they do work. The location you mentioned, is that related somehow or?

Haven't looked into it, so just asking of the bat.

Tnx for the resource.
 
Last edited:
Everytime I was asking myself where to place files for custom configurations.. and I am quite sure I am not the only one. It was time to put an end to this question :)

Actualy those are the include's defined underneath the nginx.conf's http block:
Code:
    include conf.d/http.*.conf;
    include app.d/server.*.conf;
    include sites-enabled/*;

And those are the target folders the symlinks point to:
Code:
root@dsm:~# ll /etc/nginx
...
lrwxrwxrwx  1 root root   20 Aug  1  2020 app.d -> /var/tmp/nginx/app.d
lrwxrwxrwx  1 root root   27 Aug  1  2020 conf.d -> /usr/local/etc/nginx/conf.d
...
lrwxrwxrwx  1 root root   34 Aug  1  2020 sites-enabled -> /usr/local/etc/nginx/sites-enabled
...

Potentialy all the includes from above can be used, BUT if you check where the symlinks point to, at least the app.d include does not look like a trustworty place to store permanent settings. I didn't pick sites-enabled either, because when using nginx in the wild, typical active configurations are symlinks to other places, rather that directly stored in it - even though this is a convention, nothing enforces it.. No reason to change your configurition. With conf.d I like that you can simply "disarm" an invalid WIP configuration by renaming it.
-- post merged: --

@BobW: I hope you didn't unleash the nginx-proxy-manager baremetal on your NAS. If two clever management systems fight over who has the lead in generating the configs... this will eventualy end in pain ^^

I did check it a while ago... looks nice.

Though, I am not the biggest fan of UIs - usualy they are oddly opinionated, cumbersome to use and limited in their funcationality.
 
Everytime I was asking myself where to place files for custom configurations.. and I am quite sure I am not the only one. It was time to put an end to this question :)

Actualy those are the include's defined underneath the nginx.conf's http block:
Code:
    include conf.d/http.*.conf;
    include app.d/server.*.conf;
    include sites-enabled/*;

And those are the target folders the symlinks point to:
Code:
root@dsm:~# ll /etc/nginx
...
lrwxrwxrwx  1 root root   20 Aug  1  2020 app.d -> /var/tmp/nginx/app.d
lrwxrwxrwx  1 root root   27 Aug  1  2020 conf.d -> /usr/local/etc/nginx/conf.d
...
lrwxrwxrwx  1 root root   34 Aug  1  2020 sites-enabled -> /usr/local/etc/nginx/sites-enabled
...

Potentialy all the includes from above can be used, BUT if you check where the symlinks point to, at least the app.d include does not look like a trustworty place to store permanent settings. I didn't pick sites-enabled either, because when using nginx in the wild, typical active configurations are symlinks to other places, rather that directly stored in it - even though this is a convention, nothing enforces it.. No reason to change your configurition. With conf.d I like that you can simply "disarm" an invalid WIP configuration by renaming it.
-- post merged: --

@BobW: I hope you didn't unleash the nginx-proxy-manager baremetal on your NAS. If two clever management systems fight over who has the lead in generating the configs... this will eventualy end in pain ^^

I did check it a while ago... looks nice.

Though, I am not the biggest fan of UIs - usualy they are oddly opinionated, cumbersome to use and limited in their funcationality.
No I didn’t unleash the NPM baremetal on my nas. I’m using the standard RP of Synology, but I did some testing with the docker version and it looked nice and promising...The standard version of Synology is enough for me for now.
 
Hi All,

I am running Nextcloud and using the NGINX proxy on DSM7. So far so good but I have a slight issue where the IOS app refuses to connect. When I try to connect, I get an error "Connection Error. Cannot parse response"

I have found a solution which requires me to add a directive to the custom header. "nginx proxy: proxy_hide_header Upgrade;" I cannot add this via the gui and I was wondering if any one has had this issue before please?

Cheers!

NextCloud access problem on iOS behind reverse proxy synology
 
Hi All,

I am running Nextcloud and using the NGINX proxy on DSM7. So far so good but I have a slight issue where the IOS app refuses to connect. When I try to connect, I get an error "Connection Error. Cannot parse response"

I have found a solution which requires me to add a directive to the custom header. "nginx proxy: proxy_hide_header Upgrade;" I cannot add this via the gui and I was wondering if any one has had this issue before please?

Cheers!

NextCloud access problem on iOS behind reverse proxy synology
Edit the reverse proxy connection and add a Custom header (second tab).

Choose WebSocket it will create the upgrade parameter. Then try via ios app
 
Please do not confuse directive with customer headers. While custom headers can be added from the ui, you have to live with the directive the ui auto generates for you. The tutorial explicitly lists all directives the ui creates. If the directive you are looking for can not be found there, then you will need to add your own config. The tutorial points out where custom configs can be stored and what "top level element" they should have.
 
You guys are amazing! Thanks for your inputs! :)

So far I have the following custom header directives in place to give access to NextCloud. It works well just the IOS app does not.

Should I remove the entries below and choose the WebSocket option to recreate it instead? My sincere gratitude to you all for your kind inputs.
1616862139017.png
 
Should I remove the entries below and choose the WebSocket option to recreate it instead?
No, It will do the same thing as you manually added.

Follow @one-eyed-king advice and make a custom RP for your needs using the tutorial. Or If this is the solution, then it means that something else is the problem.
 
Last edited:
You might want to start with this config: nextcloud/nextcloud-snap Then enable https/add certifcates (the example in the tutorial should provide the requried details) and the addition directive you need.

Note: even though, the wiki is for the snap package, the reverse proxy rules will be valid for all other installation type (=docker contaiener) as well.
 
Thanks for the tutorial. I tried to follow it to a T as well as this one on redirects but I still can't get requests by IP address: port to redirect to the corresponding domain name.

I created http.books.conf in /etc/nginx/conf.d, with the following:

Code:
server {
    listen 32767 default_server;
    server_name _;
    return 301 https://books.domain.tld$request_uri;
}

I reloaded nginx and tested the syntax successfully, but http://nasip:32767 doesn't redirect after a hard refresh in the browser. In the nginx error log I see:

bind() to 0.0.0.0:32767 failed (98: Address already in use)

It looks like my directive is conflicting with the rules I set via the Synology reverse proxy GUI or maybe the docker container having that port already reserved?
 
It looks like my directive is conflicting with the rules I set via the Synology reverse proxy GUI or maybe the docker container having that port already reserved?
if we are talking about the host side of a docker container port mapping, then yes, this is not going to work. Nginx must be able to bind itself to an unused port! Though for ports it is able to bind, you can use the same port for different server blocks with different unique server_name settings.
 
So ... Huston, we have problem.

Last night, NGIX RP decided to test my tolerance for problems on my primary home NAS.

After many years of trouble-free operation of Syno Nginx RP, I experienced the following state:
- random connection of my RP targets from WAN to NAS (some were available and some were not)
RP Targets:
the DSM itself and +12 containers

So far, till yesterday - all the RP targets have worked without problems on these settings:

Source: HTTPS + FQDN + 443
HSTS + HTTP / 2
Destination: HTTP / HTTPS (up to def) + locahost + target port

(no rocket science)

Tested, done:
1. LAN connection

http LAN_IP:local_target_port ----> NAS:local_target_port ...... OK for all of the targets

2. WAN connection
https FQDN:local_target_port ----> router PF to NAS (port:port) ----> NAS:local_target_port ...... OK for all of the targets

3. WAN connection
https FQDN ----> router PF to RP (433:433) ----> NAS RP 433 ----> NAS:local_target_port ...... doesn't work (dor all of the target)

4. WAN connection
https FQDN:443 ----> router PF to RP (433:433) ----> NAS RP 433 ----> NAS:local_target_port ...... doesn't work (dor all of the target) .... don't laugh, I've tried everything

5. Scenario - despair after 2:00am
In all previous cases (3 and 4) I prepared a combination of all possible parameters:
- localhost changed to NASP_IP (for each ethx) ... doesn't work
- localhost by http/https ... doesn't work
- HTTP/2 enabled/disabled ... doesn't work
- WebSocket (upgrade + connection) enabled/disabled ... doesn't work
- mix of all these scenarios.

6. Scenario
NAS Firewall switched on/off ... doesn't work

Verdict No. 1:
- there isn't a problem with router port forwarding or firewall side
- same for the NAS firewall


So deep dive to NAS side.

iptables --list

Checked
All as expected, incl. Docker, Firewall chain

SSL Certificates under NGINX command, check:

Bash:
/usr/syno/etc/certificate/ReverseProxy/
/usr/syno/etc/certificate/system/default/
All as expected - all of them are my valid Wildcard cert+key ...

NGINX config check:
all as expected, in line with definition from UI an @one-eyed-king this resource notes
Test configuration for validity: nginx -t
Success
Reload configuration: nginx -s reload
Success

Errors:
/var/log/nginx
error_default.log: ..... often recurring error
Bash:
1202#1202: signal process started
2021/11/04 02:30:23 [error] 1202#1202: open() "/run/nginx.pid" failed (2: No such file or directory)
but nginx is running

..... it is more than clear that the problem is in NGINX RP. I haven't found why yet.

PS: There isn't Syno NAS VPN in operation.

What do you think?
 
You haven't mentioned, but have you tried to reboot the docker itself or the nas itself just to see if it will make a difference? This is one of the reason I moved away from the Syno built in nginx. Since then I got more features, and none of the problems.

Had a similar problem as you, but cant recal the error from the the nginx error log. The problem was that Docker (and containers) was in some way unable (for some reason) to talk to my bare metal layer (all of a sudden). Reboot fixed it and it didn't occur again, but still, migrated to a different rp solution for the long run.
 
First things first: either nginx dies while starting (which would explain the absence of the pid file) or you have a different issue.

Let me share some experience regarding the second situation:
Once I had a situation where DSM threw an "can't find request page" error, samba and nfs went dark, my current SSH connection went crazy, and I wasn't able to establish new ones... at the same time all my containerized services keept on working like a charm. Nedless to say that this triggered the full-on panic mode.

With the established ssh connection I was able to see that /run and /process have been close to be emtpy - those are in-memory state folder. This was the explanation for the odd behavior... After a reboot everything went back to normal.

I wish I could have seen in the bash history what stupidy of mine caused that behavior... I managed to repeat it at least once after that, though the second time was more like a calm "damn, I need a reboot"...

Maybe you have a similar situation?
 
Uff, many times. Analytically written to spreadsheet all steps, changes, rewritten configs, ... include manual docker shutdowns, NAS shutdowns, Nginx restarts.
But there is also availability of the DSM itself one of the problem (out of the Docker environment).
 
Last edited:
Just to be sure: have you checked logs in /var/log
mentioned in my long post
-- post merged: --

Teamviewer from PC to NAS/DSM across WAN is also working
-- post merged: --

my shutdown approach:
1. container by container ... tests between them
2. Docket app was manually stopped .. tests between them
3. NAS was rebooted with stopped Docker app
Nothing.
 

Create an account or login to comment

You must be a member in order to leave a comment

Create account

Create an account on our community. It's easy!

Log in

Already have an account? Log in here.

Similar threads

Thank You for the great input. I try not to Muck around with SSH on the NAS. I mistakenly waited too long...
Replies
3
Views
2,281
BobW submitted a new resource: How to Setup Custom Error Pages for Nginx-Proxy-Manager (NPM) - Setup...
Replies
0
Views
843

Welcome to SynoForum.com!

SynoForum.com is an unofficial Synology forum for NAS owners and enthusiasts.

Registration is free, easy and fast!

Back
Top