Hello! I have the same problem! My virtual Host for nextcloud is here :
nano /etc/nginx/conf.d/nextcloud.meinedomain.de.conf
my configuration is here:
server {
listen 443 ssl http2;
listen [::]:443 ssl http2;
server_name nextcloud.####.de;
# SSL configuration
# RSA certificates
ssl_certificate /etc/letsencrypt/nextcloud.meinedomain.de/rsa/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/nextcloud.meinedomain.de/rsa/key.pem;
# ECC certificates
ssl_certificate /etc/letsencrypt/nextcloud.meinedomain.de/ecc/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/nextcloud.meinedomain.de/ecc/key.pem;
# This should be ca.pem (certificate with the additional intermediate certificate)
# See here: https://certbot.eff.org/docs/using.html
# ECC
ssl_trusted_certificate /etc/letsencrypt/nextcloud.meinedomain.de/ecc/ca.pem;
# Include SSL configuration
include /etc/nginx/snippets/ssl.conf;
# Include headers
include /etc/nginx/snippets/headers.conf;
#
# Nextcloud configuration
#
# Path to the root of your installation
root /var/www/nextcloud/;
# set max upload size
client_max_body_size 10G;
fastcgi_buffers 64 4K;
# Enable gzip but do not remove ETag headers
gzip on;
gzip_vary on;
gzip_comp_level 4;
gzip_min_length 256;
gzip_proxied expired no-cache no-store private no_last_modified no_etag auth;
gzip_types application/atom+xml application/javascript application/json application/ld+json application/manifest+json application/rss+xml application/vnd.geo+json application/vnd.ms-fontobject application/x-font-ttf application/x-web-app-manifest+json application/xhtml+xml application/xml font/opentype image/bmp image/svg+xml image/x-icon text/cache-manifest text/css text/plain text/vcard text/vnd.rim.location.xloc text/vtt text/x-component text/x-cross-domain-policy;
# Pagespeed is not supported by Nextcloud, so if your server is built
# with the 'ngx_pagespeed' module, uncomment this line to disable it.
#pagespeed off;
# Specify how to handle directories -- specifying '/index.php$request_uri'
# here as the fallback means that Nginx always exhibits the desired behaviour
# when a client requests a path that corresponds to a directory that exists
# on the server. In particular, if that directory contains an index.php file,
# that file is correctly served; if it doesn't, then the request is passed to
# the front-end controller. This consistent behaviour means that we don't need
# to specify custom rules for certain paths (e.g. images and other assets,
# '/updater', '/ocm-provider', '/ocs-provider'), and thus
# 'try_files $uri $uri/ /index.php$request_uri'
# always provides the desired behaviour.
index index.php index.html /index.php$request_uri;
# Rule borrowed from '.htaccess' to handle Microsoft DAV clients
location = / {
if ( $http_user_agent ~ ^DavClnt ) {
return 302 /remote.php/webdav/$is_args$args;
}
}
location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}
# Make a regex exception for '/.well-known' so that clients can still
# access it despite the existence of the regex rule
# 'location ~ /(\.|autotest|...)' which would otherwise handle requests
# for '/.well-known'.
location ^~ /.well-known {
# The following 6 rules are borrowed from '.htaccess'
location = /.well-known/carddav { return 301 /remote.php/dav/; }
location = /.well-known/caldav { return 301 /remote.php/dav/; }
# Anything else is dynamically handled by Nextcloud
location ^~ /.well-known { return 301 /index.php$uri; }
try_files $uri $uri/ =404;
}
# Rules borrowed from '.htaccess' to hide certain paths from clients
location ~ ^/(?:build|tests|config|lib|3rdparty|templates|data)(?:$|/) { return 404; }
location ~ ^/(?:\.|autotest|occ|issue|indie|db_|console) { return 404; }
# Ensure this block, which passes PHP files to the PHP process, is above the blocks
# which handle static assets (as seen below). If this block is not declared first,
# then Nginx will encounter an infinite rewriting loop when it prepends '/index.php'
# to the URI, resulting in a HTTP 500 error response.
location ~ \.php(?:$|/) {
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
set $path_info $fastcgi_path_info;
try_files $fastcgi_script_name =404;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $path_info;
fastcgi_param HTTPS on;
fastcgi_param modHeadersAvailable true; # Avoid sending the security headers twice
fastcgi_param front_controller_active true; # Enable pretty urls
fastcgi_pass php-handler;
fastcgi_intercept_errors on;
fastcgi_request_buffering off;
fastcgi_read_timeout 600;
fastcgi_send_timeout 600;
fastcgi_connect_timeout 600;
fastcgi_param PHP_VALUE "upload_max_filesize = 10G
post_max_size = 10G
max_execution_time = 3600
output_buffering = off";
}
location ~ \.(?:css|js|svg|gif)$ {
try_files $uri /index.php$request_uri;
expires 6M; # Cache-Control policy borrowed from '.htaccess'
access_log off; # Optional: Don't log access to assets
}
location ~ \.woff2?$ {
try_files $uri /index.php$request_uri;
expires 7d; # Cache-Control policy borrowed from '.htaccess'
access_log off; # Optional: Don't log access to assets
}
I daresare you dont have the SAME problems. Perhaps they might be SIMILAR - as you commented on a 3+ years old thread. Things have evolved from that point on.
so I transferred your posting to your thread.
which turns out to be neccessary, though since you provide a lot more of information that before
@aaaa You probably have a duplicate virtual host listening on port 443.
First of all, try nginx -t. Then look for the main nginx configuration (which directories are used for vHosts). Take a look at every single vHost and remove the duplicate listening on 443.
@aaaa Just take alook at the virtual hosts of nginx: At least two hosts probably have the same server_name and the same port (443). So nginx couldn’t find out which host should handle the request. The combination of server_name and port has the be unique.