Nginx reverse proxy, slow webdav performance on nextcloud

Hi guys,

So I got my reverse proxy to work for both pihole and nextcloud, only issue now is when accessing webdav via my audio player on android, it takes forever to find and play the files. I know it’s not an issue with nextcloud as it works perfectly, but when setting up nginx as a reverse proxy, it has drastically slowed everything down.

Without looking into your apache and nginx logs, this might be difficult to solve.

So first things first:

  • Did you follow known good configs like that one: https://help.nextcloud.com/t/nginx-configuration-for-reverse-proxy/23777
  • Is the machine you are using as reverse proxy sufficiently spec’d to handle the traffic?
  • Have you adapted your config.php to reflect the reverse proxy?
  • Please provide your NC version as well so troubleshooting is much easier and we don’t chase known issues

Thanks for your help with this,

  1. I have followed a configuration, but not that on specifically, my current one works well when it comes to accessing Pihole and Nextcloud on the same system, just when using Webdav my media player takes a long time to fetch the files.

  2. So I am using raspberry pi 3b+ to do this, I can say that Webdav performance is fine without the Nginx reverse proxy.

  3. I have altered the default config under ~/nginx/sites-enabled/default, but not so much in the way for the nginx.conf.

  4. I am currently using the latest version of Nextcloud which is 18.0.1.

I have attached the error log found under the var/log directory for both Nginx and apache2 if those are the ones you are asking for? I hope it helps?? apache2error.txt (23.9 KB) nginxerror.txt (2.3 MB)

TL;DR: There seem to be a few configuration issues on nginx. Look at the lines the log is complaining about in nginx.conf.
Slow WebDAV used to be an issue some releases ago, not sure if it was fixed. But those nginx errors are a start. Also check that the hostname you are using is set on the machine and can be resolved.

From what I can see it looks like a you’re looping a bit (I get that from the worker threads not being enough. Might not be the issue but points to it.)
Is everything on the same RasPI?
Look in your nginx configs. and also do a
netstat -ant | awk '$6 == "LISTEN" && $4 ~ /:80$/'
If there is anything else running on 80 (eg. nginx), and you are redirecting to 80 (eg. your apache/nextcloud) you are looping.

The logs show that (assuming) one request to a file in
/nextcloud/remote.php/dav/files/qbit/exts1/Music/
results in 4 GET at least. For other locations in www root (favico & nextcloud), it seems fine, indicating a config issue.

A line like
2020/02/15 00:57:53 [error] 977#977: *18 upstream prematurely closed connection while reading response header from upstream, client: 192.168
indicates that there might be other issues as well.

Also this:
2020/02/15 17:49:19 [emerg] 1683#1683: "default_type" directive is duplicate in /etc/nginx/nginx.conf:32 2020/02/15 17:50:09 [emerg] 1722#1722: "gzip_vary" directive is duplicate in /etc/nginx/nginx.conf:62 2020/02/15 17:50:39 [emerg] 1741#1741: unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:120 2020/02/15 17:51:17 [emerg] 1760#1760: unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122 2020/02/15 17:51:59 [emerg] 1778#1778: "server" directive is not allowed here in /etc/nginx/nginx.conf:74 2020/02/15 17:52:34 [emerg] 1797#1797: unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122 2020/02/15 17:52:49 [emerg] 1815#1815: unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122 2020/02/15 17:53:20 [emerg] 1835#1835: unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:123 2020/02/15 17:53:36 [emerg] 1853#1853: host not found in upstream "documentserver" in /etc/nginx/nginx.conf:98

EDIT: Found an article regarding the issue in NC 11: https://help.nextcloud.com/t/slow-webdav-performance/11255

Thanks for your time in looking into that,

I can say that I am running pihole,nextcloud and Nginx on the same raspberry pi, Nginx I think is listening on port 80, Nextcloud is on 8081 and Pihole is on 8080.

when running the command netstat -ant | awk '$6 == "LISTEN" && $4 ~ /:80$/' I get the following result

tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN
tcp6 0 0 :::80 :::* LISTEN

I have been altering my config a lot to find exactly what is causing the issue. But I always run

sudo nginx -t 

To spot any issues in the config, if I notice an error from the output then I go and fic that first then rerun the above command until all is ok, then I run

sudo systemctl restart nginx

To see if the new configuration solves the issue.

It seems to make sense there is some looping going on somewhere, but I have no idea where that is happening.

Running the apache2 -t command gives me the following
[Sat Feb 15 20:19:29.601736 2020] [core:warn] [pid 4287] AH00111: Config variable ${APACHE_RUN_DIR} is not defined

Have you re-configured or restartet nginx since 17:49 Server time?
Because that’s the last time the log reports errors. Let me paste them one line at the time:

"default_type" directive is duplicate in /etc/nginx/nginx.conf:32
"gzip_vary" directive is duplicate in /etc/nginx/nginx.conf:62
unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:120
unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122
"server" directive is not allowed here in /etc/nginx/nginx.conf:74
unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122
unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:122
unexpected end of file, expecting "}" in /etc/nginx/nginx.conf:123
host not found in upstream "documentserver" in /etc/nginx/nginx.conf:98

Most are just “close your statements” but there seems to be a hostname issue too. Change it to the one you want it to have/use. Also maybe change the ServerName variable in /etc/apache2/apache2.conf

Either that, or I’m too sick to think straight.

The apache error indicates you started apache by “apache2” not by “apache2ctl” so your /etc/apache2/envvars might not be used. (Not using Debian most of the time, this is just what I remember)
See /usr/share/doc/apache2/README.Debian.gz which should exist on raspian since it is Debian based. But apache seems to work fine, so no idea if it makes a difference.

Yes, I have restarted Nginx, many times. at this current point in time, My last log entry stops at around 9:30 and I am accessing the site and WebDAV, but nothing appears in both apache2 and Nginx error logs at this time. But when accessing my music files via my audio player on android it is very slow at scanning the files dispite my libary is not all that big.

09:30… pm? Your log is in Military (or European) time. So no errors since the last restart? No entries at all?

Sorry I should have made that clear :laughing:

Yes 9:30 PM UK time.

So what changed from this afternoon (the last entry was 5:53 pm) to now?

Ok then. How about the nextcloud logs? can you provide those?
Also have you tried accessing webdav a different way to check if it is only the android device that is slow or webdav itself?

EDIT: typo

I reset the nginx.conf to default settings after adapting a config, and went back to my last known config for Nginx /sites-enabled/default that I know that works , but with the main issue at hand still a problem.

I have used the Nextcloud app on my Linux install on my main machine that I am using, and it was performing pretty well.

Unfortunately I am not sure where I can find the logs for Nextcloud, other than accessing them from the login via the browser as admin.

should be /var/log/nextcloud.log

I thought you were going to say that, but unfortunately there does not appear to be one.

ok, can you search for it?
a sudo find / -name nextcloud.log should do

nextcloud.txt (778.0 KB)

There we go

A lot of that:
"You are using a fallback implementation of the intl extension. Installing the native one is highly recommended instead. at /var/www/html/nextcloud/3rdparty/patchwork/utf8/src/Patchwork/Utf8/Bootup/intl.php#18"

So while this is only a warning, maybe you can fix that. It is sending a message to no-one since you are connecting via an app.

The last lines say that your SQL has gone away. Did you restart there again?

“message”:{“Exception”:“Doctrine\DBAL\Exception\DriverException”,“Message”:“An exception occurred while executing ‘SELECT id, numeric_id, available, last_checked FROM oc_storages WHERE id = ?’ with params [“local::\/var\/www\/html\/nextcloud\/data\/”]:\n\nSQLSTATE[HY000]: General error: 2006 MySQL server has gone away”,

I have to go to bed now. But we can continue later.

Can you also check if there are any warnings in nextcloud?
Also please check if it is faster using a non-admin user with your app

I did have a look at trying to resolve the “You are using a fallback implementation of the intl”

But I have not had much success, as I seem to keep getting that error message.

To the later part of your reply, most likely I did perform a reboot there.

Did you check your Nextcloud for errors? In the Overview part of Admin Settings.

Also did you check if performance improves with non-admin users for webdav? In previous versions, this was the case.

So these are the errors I am getting in the Nextcloud overview section

Your data directory and files are probably accessible from the Internet. The .htaccess file is not working. It is strongly recommended that you configure your web server so that the data directory is no longer accessible, or move the data directory outside the web server document root.

The PHP memory limit is below the recommended value of 512MB.
Accessing site insecurely via HTTP. You are strongly advised to set up your server to require HTTPS instead, as described in the security tips ↗.

Your web server is not properly set up to resolve "/.well-known/caldav". Further information can be found in the documentation.
Your web server is not properly set up to resolve "/.well-known/carddav". Further information can be found in the documentation.
No memory cache has been configured. To enhance performance, please configure a memcache, if available. Further information can be found in the documentation.
The database is missing some indexes. Due to the fact that adding indexes on big tables could take some time they were not added automatically. By running "occ db:add-missing-indices" those missing indexes could be added manually while the instance keeps running. Once the indexes are added queries to those tables are usually much faster.
    Missing index "calendarobject_calid_index" in table "oc_calendarobjects_props".
    Missing index "schedulobj_principuri_index" in table "oc_schedulingobjects".
This instance is missing some recommended PHP modules. For improved performance and better compatibility it is highly recommended to install them.
    imagick
Some columns in the database are missing a conversion to big int. Due to the fact that changing column types on big tables could take some time they were not changed automatically. By running 'occ db:convert-filecache-bigint' those pending changes could be applied manually. This operation needs to be made while the instance is offline. For further details read the documentation page about this.
    mounts.storage_id
    mounts.root_id
    mounts.mount_id

I don’t think it’s an admin account issue as I use the same account to access on my phone, but is just slower on my phone and not on desktop. If I remove Nginx from the system, WebDav is as fast on my phone as it is on Desktop.

What I recommend would be clearing those errors one by one. If you are the only one using NC, the OPCache is not that important. The DB warnings are. They can cause issues. So we might want to solve them first

Yes, I understand that the issue arose after you enabled nginx. I still suppose that there are configuration errors and suggest looking up known good configurations as to not have to post your configs here. Still from my experience the performance with non admin accounts should be better, if it’s the same issue like in the previous versions. To clarify: I’m not suggesting using a different account all the time, I only ask you to try to see if this has an impact. If yes -> known issue, no need to search the haystack further, needle found. If no -> anything might cause it. Most probably your nginx config.