I can't install nextcloud

I can’t install netxcloud, it always gives me a Gateway Timeout error

The gateway did not receive a timely response from the upstream server or application.
I have put the connection data to the database and create the tables but suddenly this error pops up.

I have expanded:
max_execution_time, max_input_time, etc … as recommended by nextcloud and in vestacp it could perfectly

This problem also happens to me when importing a database.

What should I do?

Change the time out of Apache2.

By default Hestia uses FPM instead modphp

You mean in the general configuration of apache2 or where do I change it and what do I put?

currently I have modified these parameters to:
max_execution_time 3600 and max_input_time 3600

Those are for php you will need to modify the Apache config / Nginx

I have set the values to 300s and it does not work, always error 504 gateway!

What values of both php and NGINX do I have to set? Has someone managed to install it? what values does it have?

It is essential for me that it works!

Have it working here, using apache2+nginx default stack, nothing special, copied the source code in public_html and followed the installation guide. Mostly https://docs.nextcloud.com/server/20/admin_manual/installation/source_installation.html#prerequisites-for-manual-installation should give you all informations you need.

If I have followed that guide and it does not put values to put, in vestacp I had never touched these values and it has always worked, it is with hestiacp that it fails me

I have tried a clean install of vestacp and it works fine
Please help, without this I cannot complete my migration to hestiacp

I just tried a fresh installation of nextlcoud, basicly just running it on a ubuntu 18.04 with apache2+nginx+fpm stack, pointed the web domain to use php7.4. I now removed all files in public_html, downloaded the nextcloud source code and runned the installer, added database credentials and done:

I’m not able to reproduce your issue, nextcloud v20 works fine with hestia.


Good for you but with debian 10 and the default settings do not work well, can you do a test with debian 10?

It doesn’t work for me and what’s more, I have migrated a nexcloud that has worked but when doing an update from nexcloud it has been left half and the same gateway error appears

Usualy, I would say “no” - just because of the “good for you” - but hey, I got a good day, here we go:

Freshly installed hestia 1.2.4 on debian 10, 6 minutes uptime. This time i skipped the additional packages part and run it under admin user (NEVER do this!), just to speed up the things a bit. Installation went trough without any issue.

Probaly you want to adjust the timeouts or use their command line tool for the upgrade process, which would be probaly the better way: https://docs.nextcloud.com/server/20/admin_manual/configuration_server/occ_command.html

So just to confirm once again: Nextcloud is working properly on a fresh installed Hestia v1.2.4 with default stack/settings.

I had a issue when installing the database. How ever after reload it was fine.

Maybe change

Timeout 30
KeepAlive Off
MaxKeepAliveRequests 100
KeepAliveTimeout 10

Keep alive time is quite short on default maybe in those cases increase it to 30

you mean mariadb, apache2 or NGINX configuration?

My config
max_execution_time: 3600
max_input_time: 3600
memory_limit: 512
post_max_size: 16G
upload_max_filesize: 16G

worker_processes: auto
worker_connections: 1024
client_max_body_size: 256m
send_timeout: 60s
proxy_connect_timeout: 30s
proxy_send_timeout: 180s
proxy_read_timeout: 300s
gzip: on
gzip_comp_level: 6
charset: utf-8

max_connections: 200
max_user_connections: 50
wait_timeout: 10
interactive_timeout: 50
max_allowed_packet: 32M

max_execution_time: 3600
max_input_time: 3600
memory_limit: 512
post_max_size: 16G
upload_max_filesize: 16G

Al those settings are for PHP…

It’s how I have it today …
I will reassemble everything hestiacp to verify that it is not my error. I’ll give it one last chance :pensive:

I am thinking of leaving hestia and returning to vestacp or another panel, whenever I update netxcloud the same thing happens to me and this is very serious for me!

What I can do?


504 Gateway Timeout

Gateway Timeout
The gateway did not receive a timely response
from the upstream server or application.


Server globals

user www-data;
worker_processes auto;
worker_rlimit_nofile 65535;
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

include /etc/nginx/modules-enabled/*.conf;

Worker config

events {
worker_connections 1024;
use epoll;
multi_accept on;

http {
# Main settings
sendfile on;
tcp_nopush on;
tcp_nodelay on;
client_header_timeout 600s;
client_body_timeout 600s;
client_header_buffer_size 2k;
client_body_buffer_size 256k;
client_max_body_size 512M;
large_client_header_buffers 4 8k;
send_timeout 600s;
keepalive_timeout 30s;
keepalive_requests 100000;
reset_timedout_connection on;
server_tokens off;
server_name_in_redirect off;
server_names_hash_max_size 512;
server_names_hash_bucket_size 512;
charset utf-8;

# FastCGI settings
fastcgi_buffers                 4 256k;
fastcgi_buffer_size             256k;
fastcgi_busy_buffers_size       256k;
fastcgi_temp_file_write_size    256k;
fastcgi_connect_timeout         30s;
fastcgi_read_timeout            300s;
fastcgi_send_timeout            180s;
fastcgi_cache_lock              on;
fastcgi_cache_lock_timeout      5s;

# Proxy settings
proxy_redirect                  off;
proxy_set_header                Host $host;
proxy_set_header                X-Real-IP $remote_addr;
proxy_set_header                X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass_header               Set-Cookie;
proxy_buffers                   32 4k;
proxy_connect_timeout           600s;
proxy_read_timeout              600s;
proxy_send_timeout              600s;

# Log format
log_format  main    '$remote_addr - $remote_user [$time_local] $request '
                    '"$status" $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" "$http_x_forwarded_for"';
log_format  bytes   '$body_bytes_sent';
log_not_found off;
access_log off;

# Mime settings
include             /etc/nginx/mime.types;
default_type        application/octet-stream;

# Compression
gzip                on;
gzip_static         on;
gzip_vary           on;
gzip_comp_level     6;
gzip_min_length     1024;
gzip_buffers        16 8k;
gzip_http_version   1.1;
gzip_types          text/plain text/css text/javascript text/js text/xml application/json application/javascript application/x-javascript application/xml application/xml+rss application/x-font-ttf image/svg+xml font/opentype;
gzip_proxied        any;
gzip_disable        "MSIE [1-6]\.";

# Cloudflare https://www.cloudflare.com/ips
#set_real_ip_from  2400:cb00::/32;
#set_real_ip_from  2405:b500::/32;
#set_real_ip_from  2606:4700::/32;
#set_real_ip_from  2803:f800::/32;
#set_real_ip_from  2c0f:f248::/32;
#set_real_ip_from  2a06:98c0::/29;
real_ip_header     CF-Connecting-IP;

# SSL PCI compliance
ssl_session_cache   shared:SSL:20m;
ssl_session_timeout 60m;
ssl_buffer_size     1400;
ssl_protocols       TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_dhparam         /etc/ssl/dhparam.pem;
ssl_ecdh_curve      secp384r1;
ssl_session_tickets off;
resolver  valid=300s ipv6=off;
resolver_timeout    5s;

# Error pages
error_page 403 /error/404.html;
error_page 404 /error/404.html;
error_page 410 /error/410.html;
error_page 500 501 502 503 504 505 /error/50x.html;

# Cache settings
proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m inactive=60m max_size=1024m;
proxy_cache_key "$host$request_uri $cookie_user";
proxy_temp_path  /var/cache/nginx/temp;
proxy_ignore_headers Expires Cache-Control;
proxy_cache_use_stale error timeout invalid_header http_502;
proxy_cache_valid any 1d;

# Cache bypass
map $http_cookie $no_cache {
    default 0;
    ~SESS 1;
    ~wordpress_logged_in 1;

# File cache (static assets)
open_file_cache          max=10000 inactive=30s;
open_file_cache_valid    60s;
open_file_cache_min_uses 2;
open_file_cache_errors   off;

# Wildcard include
include /etc/nginx/conf.d/*.conf;
include /etc/nginx/conf.d/domains/*.conf;


probably best way would be leaving Hestia and returning to vesta or another panel.

sorry mate, but we can’t debug your system for you, that’s something you need to figure yourself.
not offense meant, but that’s what logfiles and stuff are for… first figure which upstream is gone away and why. could be apache, php-fpm or mysql.

you should not have to fiddle with the configs at all, I have nextcloud running without issues for quite some time and haven’t changed anything.

also could be specific to plugins/extensions that you use in nextcloud. or the workload, size of files etc. - we simply can’t know and that’s something you need to use your admin powers for to find out.
best of luck.


Well, if I can answer this, the problem is that hestia, even in this latest version, when you change the wait_timeout parameter in MariaDB that by default comes to 10sec (very low) and you set it to 600sec and save the changes, those changes They are not carried out and it remains in 10sec, you have to enter advanced properties to change it from the file itself. Besides, the changes are not applied well until you completely restart those changes.

timeouts are there for a reason. next time you are probably going to complain about your server being unresponsible because you reached a connection limit due to those connections not being properly terminated while wating for their high timeout. :man_shrugging:

raising a timeout by factor 60 without finding the real cause for your problem might be a temporary workaround but cannot be consider a proper solution.

and of course, if you change settings like that in the services config, they will only apply if you a) put it into the correct location and b) restart that service afterwards - that’s basic system administration…

anyway, good you found a way that made it work for you (for now).

1 Like

When you make a change in the config file of any service, you have to to a restart of that service in order to have the new config ‘read’ properly, how hard is it to understand mate ?

Besides, MySQL config change is a one-off change that you can do on a fresh server once and it will survive Hestia/Vesta updates too, what is there to complain or bitch about here ?

I don’t even see the point of this post at all.

I only know that nexcloud, prestashop and some other application always failed and it was dangerous to update, now they are no longer failing when I update and it has been as a result of changing those parameters.

I know I have to restart a service, but I thought that when saving it was already reloading and at least it did not do it for me and I had to restart manually.

I only try that you can take it into account in case someone else happens to him since it happened to me with a clean installation, that is my experience.