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:
Probaly you want to adjust the timeouts or use their command line tool for the upgrade process, which would be probaly the better way: Using the occ command — Nextcloud latest Administration Manual latest documentation
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
apache:
max_execution_time: 3600
max_input_time: 3600
memory_limit: 512
post_max_size: 16G
upload_max_filesize: 16G
NGINX:
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
MARIADB
max_connections: 200
max_user_connections: 50
wait_timeout: 10
interactive_timeout: 50
max_allowed_packet: 32M
apache:
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 
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?
Error:
504 Gateway Timeout
Gateway Timeout
The gateway did not receive a timely response
from the upstream server or application.
nginx.conf:
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;
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 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
#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_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";
ssl_dhparam /etc/ssl/dhparam.pem;
ssl_ecdh_curve secp384r1;
ssl_session_tickets off;
resolver 8.8.4.4 8.8.8.8 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. 
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).
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.