Nextcloud 30 pe VPS dă timeout? Repară PHP-FPM, Redis, cron, MariaDB și reverse proxy-ul ca instanța să nu moară dupa 3 luni

Dacă instanța ta Nextcloud 30 de pe VPS merge bine în prima săptămână, apoi începe să arunce timeouturi, sincronizări lente, background jobs blocate sau erori 502 și 504 aparent aleatorii, problema nu este de obicei că „Nextcloud e prost”. Problema este stackul din jurul lui. Modelul sigur pentru producție este simplu: rulează Nextcloud 30 pe PHP 8.3-FPM, MariaDB 10.11 sau PostgreSQL, Redis pentru locking și cache distribuit, APCu pentru cache local, un runner real de cron la fiecare 5 minute și un reverse proxy configurat corect pentru uploaduri mari și requesturi PHP de durată. Asta este combinația care rămâne stabilă după ce trece entuziasmul primei instalări.

Motivul real pentru care Nextcloud începe să dea timeout după câteva săptămâni

Instalările proaspete de Nextcloud te păcălesc. În ziua 1 totul pare curat, pentru că baza de date este mică, preview-urile abia încep să fie generate, background jobs nu s-au acumulat, lockingul pe fișiere este redus și probabil ai un singur utilizator. Luna 3 este momentul în care apare sistemul real. Thumbnail-urile există. Clienții mobili lovesc WebDAV constant. Joburile de cleanup și mentenanță sunt restante. Câteva foldere mari se sincronizează. Poate s-a activat Talk sau Office. Poate cineva a lăsat instanța pe AJAX background jobs doar pentru că interfața funcționa și nimeni nu s-a mai uitat.

Din experiența noastră cu servere Linux în producție, tiparul comun de eșec arată așa:

• PHP-FPM rulează încă pe un pool implicit, prea mic pentru requesturi concurente.
• Redis lipsește, așa că transactional file locking cade în baza de date.
• Background jobs sunt încă pe AJAX sau Webcron, așa că cleanupul și mentenanța rămân în urmă.
• MariaDB rulează, dar cu setări implicite suficient de bune pentru a porni, nu pentru concurență susținută.
• NGINX sau reverse proxy-ul este suficient pentru un site simplu de prezentare, dar greșit pentru uploaduri mari prin WebDAV și requesturi PHP de durată.
• Preview generation, antivirus scanning sau integrări Office au fost adăugate fără să fie refăcută dimensionarea de RAM, CPU și ferestre cron.

De aceea articolul acesta nu este încă un „instalează Nextcloud în 10 minute”. Conținutul acela există deja pe internet, iar tu ai deja un ghid mai vechi pe ServerSpan. Acesta este despre cum faci stackul să supraviețuiască utilizării reale.

Stackul pe care chiar l-am considera de încredere pe un singur VPS de producție

Pentru o firmă mică, un cloud de familie sau o instanță internă de echipă care trebuie să stea online fără babysitting constant, asta este baza de la care am porni:

• Debian 12 sau Ubuntu 24.04 pe un VPS KVM, nu pe un mediu ieftin și obscur care ascunde realitatea despre storage și CPU.
• NGINX în fața lui PHP 8.3-FPM.
• MariaDB 10.11 pentru un deployment single-node, sau PostgreSQL dacă echipa ta îl preferă și îl stăpânește bine.
• Redis pe UNIX socket pentru locking și distributed cache.
• APCu pentru local cache.
• System cron la fiecare 5 minute, sau un systemd timer care rulează cron.php la fiecare 5 minute.
• Data directory în afara web root-ului.
• Fără SQLite pentru producție. Este în regulă pentru testare. Este alegerea greșită pentru un VPS real cu mai mulți utilizatori.

Pentru dimensionare, încetează să mai încerci să rulezi un Nextcloud „serios” pe resurse de jucărie. Un lab box este una. O instanță de producție cu desktop sync, thumbnails, uploaduri mari și mai mulți utilizatori este altceva. Pentru un deployment Nextcloud dedicat și mic, 4 GB RAM este punctul în care viața începe să fie mai puțin stupidă. Dacă adaugi Office, Talk, biblioteci foto mari, scanări de external storage sau antivirus, trebuie să te aștepți să urci mai sus.

Dacă ai nevoie mai întâi de infrastructura de bază, serverele virtuale ServerSpan îți oferă acces root complet și spațiu real pentru a regla stackul corect. Dacă nu vrei să rămâi proprietarul tuturor problemelor Linux pentru totdeauna, aici intră în scenă administrarea Linux ca handoff normal.

Poolul PHP-FPM care oprește problema de tip „merge bine până când doi oameni dau click în același timp”

Documentația oficială Nextcloud este directă aici: setările implicite PHP-FPM pot cauza timpi de încărcare excesivi și probleme de sincronizare. Asta se potrivește perfect cu ceea ce vedem și noi în deploymenturi reale. Poolul standard este de multe ori reglat pentru „există PHP”, nu pentru o aplicație grea pe WebDAV, care deschide requesturi concurente în cascadă.

Pe un VPS de 4 GB dedicat în principal lui Nextcloud, acesta este un punct de plecare sigur pentru un pool dedicat în /etc/php/8.3/fpm/pool.d/nextcloud.conf:

[nextcloud]
user = www-data
group = www-data

listen = /run/php/php8.3-fpm-nextcloud.sock
listen.owner = www-data
listen.group = www-data
listen.mode = 0660

pm = dynamic
pm.max_children = 12
pm.start_servers = 3
pm.min_spare_servers = 2
pm.max_spare_servers = 4
pm.max_requests = 500

request_terminate_timeout = 300s
request_slowlog_timeout = 10s
slowlog = /var/log/php8.3-fpm/nextcloud-slow.log

php_admin_value[memory_limit] = 768M
php_admin_value[upload_max_filesize] = 10G
php_admin_value[post_max_size] = 10G
php_admin_value[max_execution_time] = 3600
php_admin_value[max_input_time] = 3600
php_admin_value[output_buffering] = 0

De ce valorile astea? Pentru că ai nevoie de suficienți workeri paraleli ca să absorbi bursturi de sync și ai nevoie de dovezi clare când un request scapă de sub control. Slowlogul contează. El îți spune dacă blocajul este în cod PHP, într-un external storage mount, în preview generation sau într-o așteptare pe baza de date. Cei mai mulți oameni îl sar. Asta este prost.

După ce dai reload la PHP-FPM, urmărește presiunea reală, nu presupunerile:

systemctl reload php8.3-fpm
journalctl -u php8.3-fpm -n 100 --no-pager
tail -f /var/log/php8.3-fpm/nextcloud-slow.log
ps --no-headers -o "rss,cmd" -C php-fpm8.3 | sort -nr | head

Dacă workerii FPM individuali consumă mult mai multă memorie decât te așteptai, nu „rezolva” problema urcând pm.max_children până când intră OOM killerul în conversație. Repară mai întâi workloadul. Și articolul tău mai vechi despre PHP-FPM vs. OOM killer este relevant aici.

Configurația de cache și locking care scoate presiunea inutilă din baza de date

Documentația Nextcloud recomandă APCu plus Redis pe instalări single-server și spune explicit că file locking bazat pe baza de date pune o presiune semnificativă pe motorul SQL. Asta este unul dintre cele mai mari motive de dezastru în „luna 3”, pentru că sistemul pare funcțional și fără Redis, dar îmbătrânește prost când apare activitatea reală de sync.

Instalează mai întâi pachetele:

apt update
apt install -y redis-server php8.3-redis php8.3-apcu

Apoi preferă UNIX socket-ul, fiindcă Redis este pe aceeași mașină:

grep -E '^(port|unixsocket|unixsocketperm)' /etc/redis/redis.conf

usermod -a -G redis www-data
systemctl restart redis-server
systemctl restart php8.3-fpm

Și pune asta în config/config.php:

'memcache.local' => '\OC\Memcache\APCu',
'memcache.distributed' => '\OC\Memcache\Redis',
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => [
    'host' => '/run/redis/redis-server.sock',
    'port' => 0,
    'timeout' => 1.5,
],

Repară și comportamentul APCu pentru CLI, ca execuțiile de cron să nu se plângă și să nu se comporte diferit:

echo 'apc.enable_cli=1' > /etc/php/8.3/cli/conf.d/99-nextcloud-apcu.ini
php -i | grep apc.enable_cli

Detaliul ăsta mic este ratat constant. Apoi lumea se întreabă de ce interfața web este în regulă, dar joburile cron încep să se plângă de cache sau de background execution.

Baza de date configurată minim corect pentru concurență reală

Nextcloud 30 suportă oficial MariaDB 10.6, 10.11 și 11.4, iar SQLite este recomandat doar pentru testare și instanțe minimale. Pentru un deployment real pe VPS, rulează MariaDB 10.11 sau PostgreSQL și configurează corect lucrurile de bază. Dacă folosești MariaDB sau MySQL, Nextcloud cere și READ COMMITTED drept nivel de izolare și fie binary logging dezactivat, fie BINLOG_FORMAT = ROW.

Aceasta este o bază rezonabilă pentru MariaDB pe un nod Nextcloud single-server, pe un VPS de 4 GB, în /etc/mysql/mariadb.conf.d/60-nextcloud.cnf:

[mysqld]
transaction_isolation = READ-COMMITTED
binlog_format = ROW

innodb_buffer_pool_size = 1G
innodb_log_file_size = 256M
max_connections = 100

character-set-server = utf8mb4
collation-server = utf8mb4_general_ci

Apoi restartează și verifică:

systemctl restart mariadb
mysql -e "SHOW VARIABLES LIKE 'transaction_isolation';"
mysql -e "SHOW VARIABLES LIKE 'binlog_format';"
mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"

Nu rula orbește occ files:scan --all de fiecare dată când baza de date pare lentă. Comanda este utilă în contextul potrivit. Este și una dintre cele mai rapide metode de a crea lucru suplimentar pe o mașină care deja suferă.

Runnerul de background jobs care oprește degradarea tăcută a mentenanței

Recomandarea oficială Nextcloud este cron, nu AJAX și nu Webcron, pentru orice instanță reală. AJAX este cea mai puțin fiabilă opțiune, iar Webcron este potrivit doar pentru setupuri foarte mici. Asta se potrivește cu realitatea. Dacă instanța ta este folosită zilnic, background jobs nu trebuie să depindă de vizite în interfață.

Poți folosi cron clasic. Poți folosi și un systemd timer care rulează cron.php la fiecare 5 minute. Pentru muncă reală pe VPS Linux, noi preferăm varianta systemd, pentru că logurile și statusul sunt mai curate.

# /etc/systemd/system/nextcloudcron.service
[Unit]
Description=Nextcloud cron.php job

[Service]
User=www-data
ExecCondition=php -f /var/www/nextcloud/occ status -e
ExecStart=/usr/bin/php -f /var/www/nextcloud/cron.php
KillMode=process

# /etc/systemd/system/nextcloudcron.timer
[Unit]
Description=Run Nextcloud cron.php every 5 minutes

[Timer]
OnBootSec=5 min
OnUnitActiveSec=5 min
Unit=nextcloudcron.service

[Install]
WantedBy=timers.target

systemctl daemon-reload
systemctl enable --now nextcloudcron.timer
systemctl list-timers --all | grep nextcloud
journalctl -u nextcloudcron.service -n 100 --no-pager

Setează și o fereastră de mentenanță, astfel încât joburile care nu sunt sensibile la timp să stea departe de orele de lucru:

sudo -u www-data php /var/www/nextcloud/occ config:system:set maintenance_window_start --type=integer --value=1

Asta folosește ora 01:00 UTC ca început al ferestrei de mentenanță. Ajustează la perioada ta reală de liniște. Pe o instanță business din România, asta chiar contează, fiindcă abordarea implicită de tip „oricând” lasă joburi grele să se lovească de utilizarea reală din timpul zilei.

Setările de reverse proxy și NGINX care opresc falsele „timeouturi”

O mulțime de tichete despre „Nextcloud timeout” sunt, în realitate, greșeli de reverse proxy. Socket PHP-FPM greșit. Trusted proxy settings lipsă. Limite prea mici pentru upload. Gestionare greșită pentru /.well-known. O regulă globală de deny pentru dotfiles care rupe uploaduri mari, fiindcă Nextcloud folosește un URL care se termină în /.file. Sunt greșeli plictisitoare, dar foarte comune.

Pornește de la exemplul oficial NGINX pentru Nextcloud, apoi verifică mai întâi aceste părți:

upstream php-handler {
    server unix:/run/php/php8.3-fpm-nextcloud.sock;
}

server {
    listen 443 ssl http2;
    server_name cloud.example.com;
    root /var/www/nextcloud;

    client_max_body_size 10G;
    client_body_timeout 300s;
    send_timeout 300s;
    fastcgi_buffers 64 4K;
    client_body_buffer_size 512k;
}

location ~ \.php(?:$|/) {
    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;
    fastcgi_param front_controller_active true;
    fastcgi_pass php-handler;
    fastcgi_intercept_errors on;
    fastcgi_request_buffering on;
    fastcgi_read_timeout 600s;
}

location ^~ /.well-known {
    location = /.well-known/carddav { return 301 /remote.php/dav/; }
    location = /.well-known/caldav  { return 301 /remote.php/dav/; }
    return 301 /index.php$request_uri;
}

location ~ /\.(?!file).* {
    deny all;
}

Punctul operațional important este acesta: NGINX și PHP-FPM trebuie să fie de acord asupra aceluiași listener. Dacă NGINX trimite către /run/php/php8.3-fpm-nextcloud.sock, iar poolul tău ascultă încă pe 127.0.0.1:9000, nu ai deployat un stack. Ai deployat un generator de 502.

Dacă ești în spatele unui reverse proxy sau al unui terminator TLS, repară explicit detecția în Nextcloud:

'trusted_domains' => ['cloud.example.com'],
'overwrite.cli.url' => 'https://cloud.example.com',
'overwriteprotocol' => 'https',
'trusted_proxies' => ['127.0.0.1'],

Schimbă IP-urile proxy-ului astfel încât să corespundă traseului tău real. Nu face copy-paste mecanic în secțiunea asta. Setările greșite pentru trusted proxies creează și propriile probleme de securitate și logging.

Setările OPcache care merită schimbate și cele pe care ar fi mai bine să le lași în pace

Activează OPcache și păstrează comentariile activate. Partea asta este simplă. Partea care nu este simplă este over-tuningul pe revalidare doar pentru că cineva de pe un forum voia un screenshot de benchmark.

opcache.enable=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=16
opcache.max_accelerated_files=20000
opcache.save_comments=1

Pentru majoritatea deploymenturilor single-node pe VPS, lasă validarea timestampurilor activă și păstrează comportamentul implicit de revalidare, dacă nu ai un motiv clar să schimbi asta. Documentația Nextcloud avertizează că reglaje prea agresive pentru OPcache pot produce comportamente ciudate după upgradeuri sau schimbări de config, dacă uiți să restartezi PHP-FPM. Avertismentul este real. Nu te optimiza singur până intri în halucinații operaționale.

Cele două lucruri pe care oamenii le activează și care schimbă complet întrebarea despre hardware

Nextcloud Talk și workloadurile grele pe Office sau previews schimbă proiectul.

Bibliotecile foto mari cresc presiunea pe preview generation. Talk adaugă trafic în timp real și alt tip de comportament la nivel de sesiuni. Editarea bogată de documente aduce și mai multe componente în joc. Dacă use case-ul tău le include, fii sincer. Un VPS cu 4 GB poate încă să funcționeze, dar marja ta de siguranță dispare mult mai repede. Documentația Nextcloud recomandă Imaginary pentru preview-uri mai rapide, dar asta înseamnă încă un serviciu de rulat și nu este compatibil cu server-side encryption. Nu este un motiv să eviți Nextcloud. Este un motiv să încetezi să pretinzi că fiecare deployment înseamnă doar „fișiere și foldere”.

Checklistul real de triere când timeoutul a început deja

• Verifică dacă background jobs chiar rulează: journalctl -u nextcloudcron.service -n 100 --no-pager
• Verifică slowlogul PHP-FPM și erorile recente ale serviciului.
• Verifică permisiunile pe Redis socket și dacă www-data îl poate folosi.
• Verifică logul de erori NGINX pentru upstream timeout, bad gateway sau body-size failures.
• Verifică logul Nextcloud din /var/www/nextcloud/data/nextcloud.log
• Verifică avertismentele din panoul de administrare pentru cache, izolare în baza de date sau probleme de reverse proxy.
• Verifică dacă cineva a lăsat debug activ în config.php.

tail -f /var/www/nextcloud/data/nextcloud.log
tail -f /var/log/nginx/error.log
journalctl -u php8.3-fpm -u redis-server -u mariadb -n 200 --no-pager
sudo -u www-data php /var/www/nextcloud/occ status
sudo -u www-data php /var/www/nextcloud/occ config:list system

Dacă mașina folosește swap, repară mai întâi asta. Ghidurile oficiale de tuning Nextcloud spun clar că utilizarea swapului trebuie evitată cu orice preț. Sună dramatic, dar pe un VPS mic este corect. Un stack Nextcloud care intră în swap devine rapid o mașină de produs timeouturi.

Când încetează să mai fie o problemă de tuning și devine una de dimensionare

Fii sincer cu limita. Dacă utilizatorii sincronizează biblioteci media uriașe, dacă mai mulți oameni lovesc WebDAV toată ziua, dacă preview-urile nu termină niciodată, sau dacă Office și Talk fac parte din fluxul zilnic al afacerii, vine un punct în care „mai tunez puțin” este doar negare. Ai nevoie de mai mult RAM, storage mai rapid sau o arhitectură împărțită în roluri.

Asta este și motivul pentru care nu recomandăm pornirea unui Nextcloud de producție serios pe cel mai mic plan posibil doar pentru că bootează. O instanță de laborator și un cloud folosit zilnic sunt două categorii complet diferite de sistem.

Răspunsul practic

Dacă Nextcloud 30 de pe VPS continuă să dea timeout, încetează să dai vina mai întâi pe aplicație și auditează stackul. Mută background jobs pe cron real sau pe un systemd timer. Pune file locking pe Redis. Folosește APCu pentru cache local. Dă-i lui PHP-FPM un pool real și un slowlog. Rulează MariaDB cu setările de tranzacții și binary logging pe care le așteaptă Nextcloud. Repară reverse proxy-ul. Apoi dimensionează VPS-ul ca pe un sistem de producție, nu ca pe o jucărie.

Dacă vrei pașii de bază pentru instalare, ghidul tău mai vechi despre instalarea Nextcloud pe VPS acoperă încă bine partea de setup. Dacă vrei să decizi ce funcții merită păstrate cât mai lean, ghidul tău din 2026 despre aplicațiile Nextcloud este continuarea corectă. Dacă construiești un stack mai larg de aplicații self-hosted în jurul acestui server, ghidul vostru despre Git self-hosted se potrivește în același bucket operațional.

Dacă vrei un VPS care îți oferă control complet asupra acestui stack, începe cu hostingul VPS ServerSpan. Dacă vrei ca altcineva să tuneze, să repare și să țină în viață stackul Linux după ce tutorialul de instalare s-a terminat, folosește administrarea Linux ServerSpan.