Ubuntu 24.04 naar 26.04 upgraden op een VPS

Wanneer kunt u upgraden van Ubuntu 24.04 naar 26.04?

U kunt op een VPS upgraden van Ubuntu 24.04 naar 26.04 zodra de 26.04.1 point release verschijnt, gepland voor 27 augustus 2026. Tot die tijd zal een 24.04-server de nieuwe release bewust niet zien. Ubuntu 26.04 LTS (Resolute Raccoon) werd uitgebracht op 23 april 2026, maar Canonical stelt het upgradepad van LTS naar LTS pas open bij de eerste point release. Deze release bevat namelijk de oplossingen voor installatie- en upgradefouten die in de eerste maanden zijn gevonden.

Voer de controle uit op een 24.04-systeem begin augustus 2026 en u krijgt dit resultaat:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Dit is geen fout op uw server. /etc/update-manager/release-upgrades bevat Prompt=lts op Ubuntu Server, wat betekent dat de tool alleen de volgende Long Term Support-release aanbiedt, en pas zodra de .1 point release bestaat. Het instellen van Prompt=normal zou u in plaats daarvan achtereenvolgens door 24.10, 25.04 en 25.10 leiden; dit zijn interim-releases die inmiddels het einde van hun levenscyclus hebben bereikt. Laat de instelling op lts staan en wacht af. Data in het schema van Canonical kunnen verschuiven, dus controleer het opnieuw als de datum geruisloos voorbijgaat.

Elk onderstaand commando voert u zelf uit op uw eigen server, in de opgegeven volgorde. Een release-upgrade kan niet worden geoefend op de machine die u upgradet. Het proces vervangt de kernel en de C-library, en vereist een herstart om te voltooien.

Is upgraden überhaupt nodig?

Ubuntu 24.04 ontvangt standaard beveiligingsupdates tot 2029, dus een werkende productieserver heeft geen harde deadline. Upgrade alleen als u functionaliteit nodig heeft die 26.04 biedt: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 of de 7.0 kernel. "Het versienummer is hoger" is geen reden om een machine die klanten bedient aan te passen.

Voer geen in-place upgrade uit als een van de volgende punten van toepassing is:

• U heeft nog nooit de console van uw provider (VNC of serieel) geopend en bent er nog nooit via ingelogd. Die console is de enige manier om weer toegang te krijgen tot de server als SSH niet meer werkt; ontdekken dat deze niet functioneert terwijl u bent buitengesloten, is te laat.
• U kunt zich geen uur downtime veroorloven en heeft geen rollback-plan.
• Uw stack is afhankelijk van een repository van derden die nog niet is gepubliceerd voor resolute.
• De server is in de loop van twee jaar handmatig opgebouwd en niemand weet precies wat erop staat.

Het alternatief is vaak beter: bouw een nieuwe 26.04 VPS, installeer uw stack, zet de data terug en wijzig de DNS zodra de server correct reageert. U houdt de oude server draaiende totdat de nieuwe zich heeft bewezen; een rollback is dan slechts een DNS-wijziging in plaats van een restore. Als u voor deze methode kiest, begin dan met de eerste tien minuten op een nieuwe VPS en bouw de nieuwe server op de juiste manier op.

Stap 1: maak een back-up die u kunt herstellen

Gebruik twee lagen, omdat deze op verschillende manieren kunnen falen. Een snapshot van de provider dekt de gehele schijf en herstelt binnen enkele minuten, maar wordt gemaakt terwijl uw databases schrijven; het is daarom crash-consistent in plaats van applicatie-consistent. Een back-up op bestandsniveau met restic, opgeslagen buiten de server biedt u individuele bestanden en een kopie die behouden blijft als uw account wordt geblokkeerd.

Dump de databases eerst handmatig. Een dump is de enige back-up van een database die u kunt vertrouwen zonder deze te stoppen.

sudo -u postgres pg_dumpall | sudo tee /var/backups/pg-all.sql > /dev/null
sudo mysqldump --all-databases --single-transaction --routines | sudo tee /var/backups/mysql-all.sql > /dev/null
sudo tar czf /var/backups/etc-before-upgrade.tgz -C / etc
sudo chmod 600 /var/backups/pg-all.sql /var/backups/mysql-all.sql

--single-transaction geeft alleen een consistente dump voor InnoDB-tabellen. Voor MyISAM-tabellen moet de database worden gestopt. De /etc tarball is het bestand dat u daadwerkelijk zult gebruiken, omdat het elk configuratiebestand bevat waarover de upgrade u vragen zal stellen.

Een back-up die u nooit heeft hersteld, is slechts een aanname. Haal nu één bestand uit de back-up, voordat u het onder tijdsdruk nodig heeft.

Stap 2: patch 24.04 eerst volledig

do-release-upgrade weigert te draaien op een systeem met een defecte pakketstatus, en een half gepatchte 24.04 maakt elke latere foutmelding moeilijker te begrijpen.

sudo apt update
sudo apt full-upgrade
sudo apt --purge autoremove
sudo dpkg --audit
apt-mark showhold

Als dpkg --audit niets weergeeft, betekent dit dat er geen pakket half geconfigureerd is. Als apt-mark showhold niets weergeeft, betekent dit dat er geen pakket vastgezet (pinned) is op een versie die de upgrade zou blokkeren. Geef elk pakket dat daar wordt vermeld vrij met sudo apt-mark unhold en de pakketnaam, of accepteer dat de blokkering een reden heeft en stop hier.

Start de server opnieuw op als de kernel is gewijzigd, zodat u de upgrade uitvoert vanaf een machine die de code draait waarvan hij denkt dat hij die draait.

[ -f /var/run/reboot-required ] && sudo reboot

Controleer vervolgens de schijfruimte. De upgrader downloadt de volledige nieuwe pakketset voordat er iets wordt geïnstalleerd, en breekt af met een melding waarin het bestandssysteem wordt genoemd als er onvoldoende ruimte is.

df -h / /boot

Bij minder dan 5 GB vrije ruimte op / gaat dit mis. Een /boot van minder dan 300 MB faalt later, tijdens de kernelinstallatie, met No space left on device. Oude kernels zijn meestal de oorzaak, en sudo apt --purge autoremove verwijdert deze.

Nog één ding om te stoppen voordat u begint: als automatische beveiligingsupdates halverwege het proces starten, houden ze de dpkg-lock vast en stopt de release-upgrader met Could not get lock /var/lib/dpkg/lock-frontend. Voer eerst sudo systemctl stop unattended-upgrades uit en start het proces opnieuw wanneer u klaar bent.

Stap 3: controleer externe repositories en vastgezette pakketten

do-release-upgrade schakelt elke apt-bron uit die niet van Ubuntu afkomstig is, omdat een pakket dat is gebouwd voor noble een resolute-systeem kan beschadigen. Het schakelt de bronnen die het herkent daarna weer in en laat de rest uitgeschakeld staan. Weet wat u gebruikt voordat de tool beslissingen voor u neemt.

ls /etc/apt/sources.list.d/
grep -rhE '^(deb |Types:|URIs:|Suites:)' /etc/apt/sources.list.d/
ubuntu-security-status --thirdparty
ls /etc/apt/preferences.d/

Ubuntu 24.04 gebruikt twee formaten in die map: de oude .list-bestanden met één regel en deb822 .sources-bestanden met Types:- en Suites:-velden. Beide worden door de upgrade uitgeschakeld. ubuntu-security-status --thirdparty geeft een lijst weer van de geïnstalleerde pakketten die niet door een Ubuntu-archief worden geleverd; dit is het exacte aantal pakketten dat u zelf heeft toegevoegd. Alles in /etc/apt/preferences.d/ is een pin, en een pin die is geschreven voor noble zal op de nieuwe release blijven kiezen voor een verouderd pakket.

Bevestig voor elke externe repository dat de leverancier een versie voor de nieuwe codenaam heeft gepubliceerd voordat u begint. De suites van Docker staan vermeld op https://download.docker.com/linux/ubuntu/dists/, en andere leveranciers gebruiken dezelfde mapstructuur. Een bron die verwijst naar een suite die niet bestaat, geeft de volgende melding bij de eerste apt update na de upgrade:

E: The repository 'https://download.docker.com/linux/ubuntu resolute Release' does not have a Release file.

Laat die bron uitgeschakeld totdat de leverancier een update publiceert. Het wijzigen van de codenaam naar een versie die de leverancier wel heeft gebouwd, is de manier waarop u pakketten installeert die gekoppeld zijn aan de verkeerde systeembibliotheken.

Stap 4: voer de upgrade uit in tmux, niet in een standaard SSH-shell

Als uw verbinding wegvalt terwijl do-release-upgrade draait in een standaard login-shell, ontvangt het proces een SIGHUP en stopt het halverwege het uitpakken. Hierdoor blijft dpkg half geconfigureerd achter en beschikt de server mogelijk niet meer over een werkende netwerkstack om opnieuw verbinding mee te maken. Voer de upgrade daarom uit in een terminal multiplexer, zodat het proces op de server actief blijft wanneer uw client de verbinding verbreekt.

sudo apt install -y tmux
tmux new -s upgrade

Binnen die sessie:

sudo ufw allow 1022/tcp
sudo do-release-upgrade

De upgrader start een tweede SSH-daemon op poort 1022 voordat er wijzigingen worden doorgevoerd, en meldt dit ook:

To make recovery in case of failure easier, an additional sshd will be started on port '1022'. If anything goes wrong with the running ssh you can still connect to the additional one.

De tool opent uw firewall niet voor deze poort, omdat het zonder toestemming aanpassen van firewallregels ongewenst is. Open poort 1022 zelf voordat u begint en sluit deze weer af zodra u klaar bent met sudo ufw delete allow 1022/tcp. Houd er rekening mee dat uw provider mogelijk een tweede firewall in het configuratiescherm hanteert, buiten de server om.

Mocht de verbinding toch wegvallen, log dan opnieuw in en voer tmux attach -t upgrade uit. De upgrade is tijdens uw afwezigheid gewoon doorgegaan.

Stap 5: beantwoord de prompts voor configuratiebestanden weloverwogen

dpkg vraagt alleen om actie bij bestanden die u of een script heeft gewijzigd. Elke prompt betreft dus een bestand dat u bewust heeft aangepast; op enter drukken om de melding te laten verdwijnen is de manier waarop een beveiligde server ongemerkt verandert in een standaardinstallatie.

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

Druk elke keer eerst op D. Lees wat er is gewijzigd en behoud vervolgens uw eigen versie met N. De standaardkeuze is al N, wat het veilige antwoord is, omdat uw bestand momenteel correct functioneert en de versie uit het pakket nog nooit op deze machine is uitgevoerd.

Het behouden van uw bestand heeft een nadeel: u krijgt de nieuwe standaardinstellingen niet. Voer de vergelijking achteraf uit, zodra de server weer operationeel is en u niet onder tijdsdruk staat.

sudo find /etc -name '*.dpkg-dist' -o -name '*.dpkg-new'

Elk bestand dat wordt vermeld, is de versie van de beheerder, opgeslagen naast die van u. Vergelijk ze één voor één met diff en kopieer de instellingen die van belang zijn. Twee bestanden vereisen extra aandacht: /etc/ssh/sshd_config, omdat een onjuist antwoord uw sessie beëindigt, en uw webserverconfiguratie, omdat een onjuist antwoord de websites offline haalt.

De upgrade vraagt ook welke services opnieuw moeten worden opgestart via needrestart. Accepteer de volledige lijst. Een daemon die nog steeds draait met een gedeeld bibliotheekbestand dat van de schijf is verwijderd, zal bij een later verzoek crashen op een moment dat u niet meekijkt.

Stap 6: herstarten en de machine controleren

sudo reboot

Zodra de machine weer beschikbaar is:

lsb_release -a
uname -r
systemctl --failed
journalctl -p err -b --no-pager | head -50
sudo apt update && sudo apt full-upgrade
sudo apt --purge autoremove

lsb_release -a hoort Release: 26.04 en Codename: resolute te rapporteren. uname -r moet een 7.0 kernel tonen. systemctl --failed hoort nul units weer te geven; alles wat daar wel verschijnt, is uw volgende taak. Het laatste commando apt update haalt de updates op die zijn gepubliceerd sinds de release-images zijn gebouwd.

PostgreSQL 16 naar 18: de cluster die stilletjes achterblijft

Ubuntu 24.04 levert PostgreSQL 16 en 26.04 levert PostgreSQL 18. De upgrade installeert 18 naast 16 en verplaatst uw data niet. De postgresql-common-laag van Debian maakt een nieuwe, lege cluster aan voor de nieuwe hoofdversie op de eerstvolgende vrije poort. Hierdoor behoudt 16 poort 5432 met al uw data, terwijl 18 leeg op 5433 blijft staan. Uw applicatie blijft communiceren met 5432 en alles lijkt in orde, wat de reden is dat men dit vaak pas maanden later ontdekt.

pg_lsclusters

Wanneer er twee clusters worden vermeld, heeft u de migratie nog niet uitgevoerd. Doe dit op een moment dat u de applicatie kunt stoppen:

sudo pg_dropcluster --stop 18 main
sudo pg_upgradecluster 16 main
pg_lsclusters
sudo -u postgres vacuumdb --all --analyze-only

Verwijder eerst de lege 18-cluster, omdat pg_upgradecluster niet naar een doelcluster schrijft die al bestaat. De standaardmethode maakt een dump van 16 en laadt deze in 18; u heeft hiervoor dus vrije schijfruimte nodig die ongeveer gelijk is aan de grootte van de database. -m upgrade gebruikt in plaats daarvan pg_upgrade en is aanzienlijk sneller bij een grote database. Wanneer dit proces is voltooid, leest u de kolom Port: de nieuwe cluster neemt poort 5432 over en de oude blijft gestopt achter. Voer de analyze-stap zelf uit, omdat een vers geladen cluster geen statistieken bevat en de eerste queries anders traag zullen zijn.

Test de applicatie gedurende enkele dagen met de nieuwe cluster. Verwijder de oude pas daarna:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

De datadirectory van de oude cluster is de snelste manier om een rollback uit te voeren. Verwijder deze niet op de dag van de upgrade.

MySQL 8.0 naar 8.4: de verwijderde optie die de server stopt

26.04 brengt MySQL van 8.0 naar 8.4 LTS, en twee wijzigingen zorgen voor problemen op servers.

Ten eerste weigert mysqld te starten wanneer de configuratie een optie bevat die in de nieuwe versie is verwijderd. default_authentication_plugin is de meest voorkomende, omdat veel oudere handleidingen adviseren deze in te stellen. De service faalt en journalctl -u mysql -n 50 benoemt de onbekende variabele direct. Verwijder die regel uit het bestand onder /etc/mysql/mysql.conf.d/ en voer daarna sudo systemctl start mysql uit.

Ten tweede is de mysql_native_password-plugin niet langer standaard ingeschakeld in 8.4, waardoor een account dat deze nog gebruikt niet kan inloggen. Controleer dit terwijl u nog op 8.0 werkt:

sudo mysql -e "SELECT user, host, plugin FROM mysql.user;"

Migreer elk account dat mysql_native_password toont vóór de upgrade en werk daarna het wachtwoord bij in uw applicatieconfiguratie:

ALTER USER 'appuser'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'a new password';

Als een clientbibliotheek te verouderd is om caching_sha2_password te ondersteunen, kunt u de oude plugin in 8.4 weer inschakelen door mysql_native_password=ON toe te voegen onder [mysqld]. Beschouw dit als een tijdelijke overbrugging, aangezien de plugin op termijn volledig zal verdwijnen.

PHP 8.3 naar 8.5: uw vhosts verwijzen naar een socket die niet meer bestaat

24.04 levert PHP 8.3 en 26.04 levert PHP 8.5. De pakketten worden geïnstalleerd in paden met versienummers en niets past automatisch uw webserverconfiguratie aan. Een nginx vhost die fastcgi_pass unix:/run/php/php8.3-fpm.sock; bevat, verwijst nu naar een socket die door geen enkel proces wordt aangemaakt. Hierdoor geeft elk PHP-verzoek een 502-foutmelding en toont het nginx-foutenlogboek:

connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory)

Verwijs naar de nieuwe socket, test de configuratie en herlaad:

sudo sed -i 's/php8.3-fpm.sock/php8.5-fpm.sock/' /etc/nginx/sites-available/example.com
sudo nginx -t
sudo systemctl reload nginx

Bij Apache met mod_php is het symptoom anders: Apache start helemaal niet op en sudo apache2ctl -t meldt dat het libphp8.3.so niet kan laden omdat het bestand niet bestaat. De ingeschakelde module is een symbolische koppeling naar een pakket dat niet meer aanwezig is.

sudo a2dismod php8.3
sudo a2enmod php8.5
sudo systemctl restart apache2

Als u de server heeft opgezet op basis van een LAMP-stack op Ubuntu 24.04, zijn beide paden het controleren waard, aangezien de handleiding u achterlaat met een versienummer in de modulenaam en de socket.

Uw php.ini-instellingen worden eveneens niet automatisch overgezet. memory_limit, upload_max_filesize en alle andere instellingen bevinden zich in /etc/php/8.3/, en de nieuwe installatie begint met standaardwaarden. Vergelijk de twee bestanden met diff en kopieer de waarden handmatig. Het volledig overschrijven van het nieuwe bestand met het oude bestand brengt 8.3-standaardwaarden naar een 8.5-installatie. Voer daarna php -m uit en vergelijk: een extensie die is geïnstalleerd als php8.3-redis heeft het bijbehorende php8.5--pakket nodig. Als deze afkomstig was uit een PPA, heeft de upgrade-tool die bron uitgeschakeld en ontbreekt de extensie simpelweg.

Certificaten verdienen een eigen controle. Voer sudo certbot renew --dry-run uit na de upgrade. Dit doorloopt het volledige vernieuwingspad, inclusief de herlaad-hook van de webserver, zonder het actieve certificaat aan te passen. Een hook die een servicenaam of een binair bestand aanroept dat is gewijzigd, faalt hier direct voor uw ogen, in plaats van geruisloos over 60 dagen. Certbot met Let's Encrypt op nginx beschrijft hoe deze hooks eruit moeten zien.

SSH: de fout die de sessie waarin u werkt beëindigt

De sshd_config-prompt is de plek waar gebruikers zichzelf buitensluiten. Het beantwoorden met Y installeert het bestand van de beheerder, waardoor uw PermitRootLogin, PasswordAuthentication, AllowUsers, Port en elke andere regel die u heeft toegevoegd, worden verwijderd. Als uw firewall alleen een aangepaste poort toestaat en de standaardconfiguratie op 22 luistert, wordt de volgende verbinding geweigerd en is de sessie waarin u zich bevindt de laatste die u heeft.

Voorkom dit voordat u een upgrade uitvoert. /etc/ssh/sshd_config op 24.04 begint met Include /etc/ssh/sshd_config.d/*.conf, en OpenSSH behoudt de eerste waarde die het leest voor elke instelling. Een drop-in bestand dat bovenaan wordt ingeladen, krijgt daarom voorrang op alles wat daaronder staat. Verplaats uw instellingen naar een bestand dat niet door dpkg wordt beheerd:

sudo tee /etc/ssh/sshd_config.d/99-local.conf > /dev/null <<'EOF'
PermitRootLogin no
PasswordAuthentication no
AllowUsers deploy
EOF
sudo chmod 644 /etc/ssh/sshd_config.d/99-local.conf
sudo sshd -t && sudo systemctl restart ssh

Zodra er niets van u in /etc/ssh/sshd_config staat, is die prompt niet langer relevant: beide antwoorden behouden uw instellingen, omdat deze in een ander bestand staan.

Een aangepaste poort vereist nog een extra controle, omdat deze mogelijk niet op de plek staat waar u denkt:

systemctl is-enabled ssh.socket

Als dit enabled weergeeft, beheert systemd de luisterpoort en wordt de Port-regel in sshd_config genegeerd. Ubuntu gebruikt sinds 22.10 socket-activatie voor sshd, en dit is de reden waarom een bewerking in Port 2222 geen effect lijkt te hebben. Stel dit in plaats daarvan in op de socket-unit met sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

De lege ListenStream= is vereist. Dit wist de overgeërfde waarde; zonder deze regel luistert de socket zowel op 22 als op 2222. Pas dit toe met sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Na de upgrade, voordat u de sessie waarin u werkt sluit:

sudo sshd -t
sudo systemctl status ssh.socket --no-pager
sudo ss -lntp | grep -E ':(22|2222)'

Open vervolgens een tweede terminal op uw eigen machine en log opnieuw in. Een werkende shell in die tweede terminal is het enige bewijs dat telt. Houd de eerste sessie open totdat u dit heeft bevestigd. SSH beveiligen op een VPS behandelt de instellingen die het waard zijn om in die drop-in te behouden.

Als het al te laat is, biedt de webconsole van uw provider u een login die helemaal geen gebruikmaakt van SSH. Log daar in, herstel de configuratie, voer sudo sshd -t uit en herstart de service. Die console is precies de reden waarom u consoletoegang test vóór een upgrade in plaats van tijdens een upgrade.

FAQ

Waarom geeft do-release-upgrade de melding "No new release found" op Ubuntu 24.04?

Omdat /etc/update-manager/release-upgrades op Ubuntu Server de waarde Prompt=lts bevat, en die instelling biedt de volgende long term support-release pas aan nadat de eerste point release beschikbaar is. Ubuntu 26.04 LTS is uitgebracht op 23 april 2026, en 26.04.1 staat gepland voor 27 augustus 2026. Tot die datum ziet een 24.04-server geen nieuwe release. Wijzig deze instelling niet naar Prompt=normal, omdat u daarmee via de tussenliggende releases zou upgraden.

Moet ik de server herstarten om de upgrade te voltooien?

Ja. De upgrade installeert een nieuwe kernel, een nieuwe C-library en een nieuw init-systeem; het draaiende systeem blijft de oude versies gebruiken totdat het opnieuw opstart. do-release-upgrade vraagt aan het einde om een herstart, en een machine die tot "later" blijft draaien, draait in feite met een mix van twee releases. Controleer na de herstart uname -r voor de nieuwe kernel en systemctl --failed voor services die niet correct zijn opgestart.

Kan ik beter een in-place upgrade uitvoeren of een nieuwe 26.04-server bouwen?

Bouw bij voorkeur een nieuwe server. Op een nieuwe VPS kunt u de stack installeren, de data terugzetten en alles testen terwijl de oude server nog verkeer afhandelt. Een rollback is dan slechts een DNS-wijziging in plaats van een herstel vanaf een back-up. Kies voor een in-place upgrade wanneer de server data bevat die lastig te verplaatsen is, wanneer de provider per machine factureert, of wanneer u beschikt over een snapshot en betrouwbare console-toegang. Het in-place pad is beproefd, maar het is een eenrichtingsweg gedurende de tijd dat het proces draait.

Wat gebeurt er als mijn SSH-verbinding wegvalt tijdens de upgrade?

In een standaard login-shell ontvangt het proces een SIGHUP en stopt het halverwege, waardoor dpkg half geconfigureerd achterblijft. Start het proces binnen tmux of screen zodat het blijft draaien; u kunt dan opnieuw verbinden en tmux attach -t upgrade uitvoeren om het proces te hervatten. De upgrader start ook een extra SSH-daemon op poort 1022 als tweede toegangsweg, maar opent de firewall niet voor die poort. Sta poort 1022 daarom zelf toe en sluit deze na afloop weer.

Mijn PHP-site geeft een 502-fout na de upgrade. Wat is er mis?

Het pad naar de PHP FPM-socket is gewijzigd met de nieuwe versie. Ubuntu 24.04 draait PHP 8.3 en 26.04 draait PHP 8.5, waardoor /run/php/php8.3-fpm.sock niet langer bestaat terwijl uw nginx vhost hier nog naar verwijst. Het nginx-foutenlogboek toont connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Werk fastcgi_pass bij naar de 8.5-socket, voer sudo nginx -t uit en herlaad nginx. Bij Apache met mod_php is de equivalente oplossing sudo a2dismod php8.3, gevolgd door sudo a2enmod php8.5 en een herstart.