nginx

You can follow this article pretty much all the way.

https://techjogging.com/redirect-www-to-https-in-synology-nas-nginx.html

However, it will fail if you use Letsencrypt to generate an SSL Certificate. So you simply need to add the following above the redirect line. Here’s how it should look.

server {
    listen 80 default_server{{#reuseport}} reuseport{{/reuseport}};
    listen [::]:80 default_server{{#reuseport}} reuseport{{/reuseport}};

    gzip on;
    
    location /.well-known/acme-challenge/ {
    # put your configuration here, if needed
    }

    server_name _;
    return 301 https://$host$request_uri;
}

Of course after you make this change you will need to restart Nginx

synoservicecfg --restart nginx

You can add as many locations as you like; once they’re matched, the request will not continue to the redirect at the end of the server {} container.

This was highlighted in the following Stack Overflow post.

https://serverfault.com/questions/874090/nginx-redirect-everything-except-letsencrypt-to-https

So I’ve been starting to deploy nginx on more systems, and working with php5-fpm and have had some great success. However a few issues have come to light, and it was hard to find information about these issues online. Lots of Google digging later I’ve found quite a bit about nginx and PHP5-FPM.

Configuring nginx and PHP5-FPM Chroot

The chroot function of PHP5-FPM is a great feature, however it’s rather hard to troubleshoot for instance when a blank page is displayed. This is usually related to the fact that nginx is not passing the right path and file name to PHP5-FPM. There are two important pieces of information both nginx and PHP5-FPM will need.

I’ve pasted below a copy of my nginx location code for PHP files:

location ~ \.php {
try_files $uri =404;
keepalive_timeout 0;
fastcgi_pass 127.0.0.1:9000;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME public_html/$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_script_name;
include /etc/nginx/fastcgi_params;
}

The “SCRIPT_FILENAME” and “PATH_INFO” variables are defined within the nginx configuration for this particular domain. This is required, as this will be passed on to the PHP5-FPM daemon that will be running and processing the PHP code.

Here’s the PHP5-FPM pool for the above domain.

[doc]
listen = 127.0.0.1:9000
listen.allowed_clients = 127.0.0.1
user = doc
group = doc
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 1
pm.max_spare_servers = 2
chroot = /home/doc
php_admin_value[session.save_path] = tmp

The “chroot” variable specifies the root directory the processes and children will run from, therefore they will not be able to go lower than this directory.

Looking at both pieces of code, you can see how its imperative to ensure both the “SCRIPT_FILENAME” and “chroot” variables are correctly set to ensure that paths are correctly specified. Failure to do so will result in a blank page and no real errors messages within any of the logs for nginx or PHP5-FPM.

PHP5-FPM Chroot and MySQL

If you’re using PHP5-FPM chroot, then you might run into some error messages that will make no sense at all. I ran into the follow error that was being displayed on a MediaWiki installation.

(Can't contact the database server: Can't connect to local MySQL server through socket '/var/run/mysqld/mysqld.sock' (2) (localhost))

Upon further investigation and some Google! I’ve found this following thread that talks about how PHP is compiled and

Synology Redirect Nginx HTTP to https + Allow Letsencrypt

Ubuntu PHP5-FPM NGINX

Configuring nginx and PHP5-FPM Chroot

PHP5-FPM Chroot and MySQL