Como atualizar o Ubuntu 24.04 para 26.04 num VPS

Quando pode atualizar o Ubuntu 24.04 para 26.04?

Pode atualizar o Ubuntu 24.04 para 26.04 num VPS agora. Desde 29 September 2026, quando a Canonical ativou as atualizações a partir do 24.04 LTS, do-release-upgrade num servidor 24.04 oferece o 26.04.1. O Ubuntu 26.04 LTS (Resolute Raccoon) foi lançado em 23 April 2026, mas a Canonical só abre o caminho de atualização entre versões LTS depois de sair a primeira point release, porque essa versão reúne as correções dos problemas de instalação e atualização encontrados nos primeiros meses. Desta vez, a espera ultrapassou a própria point release: a 26.04.1 foi lançada em 27 August 2026, e a Canonical adiou a atualização por mais algumas semanas devido a backports planeados para corrigir regressões numa versão recente do rust-coreutils. Se a numeração for nova para si, 26.04.1 não é um Ubuntu diferente, mas o mesmo 26.04 com quatro meses de correções integradas na imagem, e é precisamente por isso que é a primeira versão que a Canonical disponibiliza para um servidor existente.

Até 29 September, executar a verificação num servidor 24.04 mostrava isto:

sudo do-release-upgrade

Checking for a new Ubuntu release
No new release found.

Isso não indicava uma falha no servidor. Se ainda vir essa mensagem hoje, verifique a definição de que ela depende. /etc/update-manager/release-upgrades contém Prompt=lts no Ubuntu Server. Isso significa que a ferramenta oferece apenas a próxima versão de suporte de longo prazo, e apenas depois de a Canonical abrir o caminho para ela. Ainda assim, mantenha-a em lts, porque numa versão posterior normal também ofereceria as versões intermédias de suporte curto. Durante a espera, a Canonical disponibilizou do-release-upgrade -d a quem não quisesse aguardar. Agora que o caminho está aberto, o comando simples é o que o anúncio da Canonical indica para os servidores. Leia o que mudou no 26.04.1 e quando o caminho de atualização foi aberto antes de começar. Um servidor que ainda esteja no 22.04 não pode fazer esta atualização diretamente, porque o atualizador só oferece a próxima versão LTS. Por isso, atualizar o 22.04 para o 26.04 através do 24.04 explica o primeiro salto e o snapshot a criar antes do segundo.

Cada comando abaixo deve ser executado por si, no seu próprio servidor, pela ordem indicada. Não é possível testar uma atualização de versão na máquina que está a ser atualizada. O processo substitui o kernel e a biblioteca C, e precisa de um reboot para terminar.

Deve mesmo atualizar?

O Ubuntu 24.04 recebe atualizações de segurança padrão até 2029, portanto um servidor de produção funcional não está sujeito a nenhum prazo. Atualize porque precisa de algo que o 26.04 oferece: PHP 8.5, PostgreSQL 18, MySQL 8.4 LTS, OpenSSH 10.2 ou o kernel 7.0. "O número aumentou" não é motivo para alterar uma máquina que atende clientes.

Não faça uma atualização no local quando qualquer uma destas condições se aplicar:

• Nunca abriu a consola do seu provedor (VNC ou serial) nem iniciou sessão através dela. Essa consola é a única forma de recuperar o acesso ao servidor se o SSH falhar. Descobrir que ela não funciona depois de ficar bloqueado é tarde demais.
• Não pode suportar uma hora de indisponibilidade e não tem rollback.
• A sua stack depende de um repositório de terceiros que ainda não publicou pacotes para resolute.
• O servidor foi configurado manualmente há mais de dois anos e ninguém sabe o que está instalado nele.

A alternativa costuma ser melhor: crie um VPS 26.04 novo, instale a sua stack e restaure os dados. Depois, altere o DNS quando o novo servidor responder corretamente. Mantenha o servidor antigo em funcionamento até o novo comprovar que está operacional. Assim, o rollback é uma alteração de DNS, e não uma restauração. Se seguir esse caminho, comece por os primeiros dez minutos num VPS novo e configure corretamente o novo servidor.

Etapa 1: faça uma cópia de segurança que possa restaurar

Use duas camadas, porque elas falham de formas diferentes. Um snapshot do fornecedor cobre todo o disco e é restaurado em minutos, mas é criado enquanto as bases de dados estão a escrever. Por isso, é consistente com uma falha, e não consistente com a aplicação. Uma cópia de segurança ao nível dos ficheiros com restic, armazenado fora do servidor permite recuperar ficheiros individuais e mantém uma cópia que sobrevive ao bloqueio da sua conta.

Faça primeiro um dump manual das bases de dados. Um dump é uma forma de fazer uma cópia de segurança de uma base de dados em execução.

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 produz um dump consistente apenas para tabelas InnoDB. As tabelas MyISAM precisam de bloqueios para produzir um dump consistente. O tarball /etc é aquele que irá realmente utilizar, porque contém todos os ficheiros de configuração sobre os quais a atualização está prestes a fazer perguntas.

Uma cópia de segurança que nunca foi restaurada é apenas uma suposição. Recupere agora um ficheiro dela, antes de precisar dele sob pressão.

Etapa 2: atualize completamente o 24.04 primeiro

do-release-upgrade recusa-se a executar num sistema com o estado dos pacotes danificado, e um 24.04 atualizado apenas parcialmente torna mais difícil interpretar todas as falhas posteriores.

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

dpkg --audit sem saída significa que nenhum pacote está parcialmente configurado. apt-mark showhold sem saída significa que nenhum pacote tem um dpkg hold. Isto não mostra os APT preference pins, que são um mecanismo separado e também podem impedir a atualização de um pacote; a Etapa 3 verifica esses pins. Libere tudo o que showhold listar com sudo apt-mark unhold e o nome do pacote, ou aceite que o hold existe por um motivo e pare aqui.

Reinicie se o kernel tiver mudado. Assim, a atualização é feita a partir de uma máquina que está a executar o código que considera estar a executar.

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

Depois, verifique o espaço em disco. O atualizador descarrega todo o novo conjunto de pacotes antes de instalar qualquer coisa. Se não houver espaço suficiente, aborta e indica o sistema de ficheiros afetado.

df -h / /boot

Os kernels antigos são normalmente a causa, e sudo apt --purge autoremove remove-os.

Há mais uma coisa que deve parar antes de começar: se as atualizações automáticas de segurança forem executadas durante o processo, mantêm o bloqueio do dpkg, e o atualizador da versão termina com Could not get lock /var/lib/dpkg/lock-frontend. Execute sudo systemctl stop unattended-upgrades primeiro e inicie novamente quando terminar.

Passo 3: verificar repositórios de terceiros e pacotes fixados

Por predefinição, do-release-upgrade comenta todas as fontes APT que não são do Ubuntu, porque um pacote criado para noble pode danificar um sistema resolute. A opção --allow-third-party mantém essas fontes ativadas, com exatamente esse risco. Saiba o que está a manter antes de deixar a ferramenta decidir por si.

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/

O Ubuntu 24.04 usa dois formatos nesse diretório: os ficheiros antigos .list de uma só linha e os ficheiros .sources deb822, com os campos Types: e Suites:. Ambos são desativados por uma atualização predefinida. ubuntu-security-status --thirdparty lista os pacotes instalados que nenhum arquivo Ubuntu fornece. Esse é o número real do que foi instalado adicionalmente. Um ficheiro em /etc/apt/preferences.d/ só é lido como pin se o nome não tiver uma extensão ou terminar em .pref e contiver apenas letras, dígitos, hífenes, sublinhados e pontos; o APT ignora qualquer outro ficheiro, normalmente com um aviso. Um pin que nomeie noble pode manter um pacote numa versão antiga depois da atualização, dependendo das versões que continuam disponíveis e da prioridade definida pelo pin. Por isso, leia cada ficheiro e decida se ainda deve permanecer.

Para cada repositório de terceiros, confirme que o fornecedor publicou uma versão para o novo codename antes de começar. As suites do Docker estão listadas em https://download.docker.com/linux/ubuntu/dists/, e os outros fornecedores disponibilizam o mesmo diretório. Uma fonte apontada para uma suite inexistente apresenta esta mensagem no primeiro apt update depois da atualização:

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

O Docker publica agora uma suite resolute. Mantenha desativada qualquer fonte cuja suite esteja em falta até o fornecedor a publicar. Alterar o codename para outro que o fornecedor tenha criado é uma forma de instalar pacotes ligados às bibliotecas de sistema erradas.

Passo 4: execute a atualização no tmux, não numa shell SSH simples

O atualizador do servidor normalmente é executado dentro do GNU screen e suporta voltar a ligar-se depois de uma quebra de ligação. Por isso, perder a ligação SSH não interrompe, por si só, a atualização. Execute-o também na sua própria sessão tmux, para ter uma sessão com nome à qual possa voltar a ligar-se.

sudo apt install -y tmux
tmux new -s upgrade

Dentro dessa sessão:

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

O atualizador inicia um segundo daemon SSH na porta 1022 antes de alterar qualquer coisa e informa-o:

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.

Não abre essa porta na firewall, porque abrir uma exceção sem pedir autorização seria uma alteração inesperada. Abra a porta 1022 manualmente antes de iniciar e feche-a quando terminar com sudo ufw delete allow 1022/tcp. Tenha em conta que o seu fornecedor pode executar uma segunda firewall no painel de controlo, fora do servidor.

Se a ligação cair mesmo assim, volte a iniciar sessão e execute tmux attach -t upgrade. A atualização continuou a ser executada enquanto esteve desligado. Se não continuou e encontrar um dpkg parcialmente configurado ou fontes do apt que estejam em parte noble e em parte resolute, recuperar uma atualização de versão falhada explica como reparar o estado dos pacotes e saber quando deve deixar de tentar reparar e restaurar o snapshot.

Passo 5: responda deliberadamente aos pedidos sobre ficheiros de configuração

O dpkg só pede confirmação para ficheiros que você ou um script alteraram. Por isso, cada pedido corresponde a um ficheiro que você ou um script alteraram. Premir Enter mantém a versão atual por predefinição.

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] ?

Prima D primeiro, sempre. Leia o que mudou e decida se mantém a sua versão com N ou instala a versão do maintainer. A predefinição já é N, mas manter o ficheiro antigo não é seguro para todos os pacotes: algumas alterações de configuração são necessárias para o sistema atualizado funcionar.

Manter o seu ficheiro tem um custo: não recebe as novas predefinições. Faça a reconciliação depois, quando o servidor estiver operacional e já não estiver sob pressão de tempo.

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

Cada ficheiro que aparece na lista é a versão do maintainer, guardada junto da sua versão. Compare-os individualmente com diff e copie as definições relevantes. Dois ficheiros exigem atenção especial: /etc/ssh/sshd_config, porque uma resposta errada termina a sua sessão, e a configuração do servidor Web, porque uma resposta errada deixa os sites indisponíveis.

Desde o Ubuntu 24.04, needrestart reinicia automaticamente, por predefinição, os serviços afetados. Se restaurou o modo interativo, aceite a lista completa. Um daemon que ainda utilize uma biblioteca partilhada antiga continua exposto a erros corrigidos pela atualização até ser reiniciado.

Etapa 6: reinicie e verifique a máquina

sudo reboot

Quando voltar a arrancar:

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 deve apresentar Release: 26.04 e Codename: resolute. uname -r deve mostrar um kernel 7.0. systemctl --failed deve listar zero unidades; qualquer unidade listada é a sua próxima tarefa. O apt update finaliza a atualização dos índices de pacotes, e apt full-upgrade instala as atualizações publicadas desde que a atualização do sistema obteve os pacotes.

PostgreSQL 16 para 18: o cluster que fica silenciosamente para trás

Ubuntu 24.04 inclui PostgreSQL 16 e 26.04 inclui PostgreSQL 18. A atualização instala o 18 ao lado do 16 e não move os seus dados. A camada postgresql-common do Debian cria um cluster principal durante a instalação do pacote do servidor apenas quando ainda não existem clusters. Por isso, um cluster PostgreSQL 16 existente não adquire automaticamente um cluster 18 vazio na porta 5433. A aplicação continua a comunicar com a porta 5432 e nada parece estar errado. É por isso que este problema só é descoberto meses depois.

pg_lsclusters

Uma entrada da versão 16 significa que esse cluster ainda está na versão 16. Se pg_lsclusters também listar um cluster 18 main, confirme que está vazio antes de o remover com sudo pg_dropcluster --stop 18 main, porque pg_upgradecluster não escreve num cluster de destino que já exista. Faça a migração quando puder parar a aplicação:

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

O método predefinido faz um dump do 16 e volta a carregá-lo no 18. Por isso, precisa de espaço livre em disco aproximadamente igual ao tamanho da base de dados. -m upgrade usa pg_upgrade, em vez desse método, e é muito mais rápido numa base de dados grande. Quando terminar, leia a coluna Port: o novo cluster assume a porta 5432 e o antigo fica parado. O hook de atualização fornecido pelo pacote executa automaticamente uma passagem de analyze; o comando acima repete-a explicitamente.

Teste a aplicação com o novo cluster durante alguns dias. Só depois remova o antigo:

sudo pg_dropcluster 16 main
sudo apt purge postgresql-16

O diretório de dados do cluster antigo é a forma mais rápida de fazer rollback. Não o elimine no dia da atualização.

MySQL 8.0 para 8.4: a opção removida que impede o servidor de iniciar

26.04 atualiza o MySQL da versão 8.0 para a 8.4 LTS, e duas alterações afetam os servidores.

Primeiro, mysqld recusa iniciar quando a configuração contém uma opção removida na nova versão. default_authentication_plugin é o caso mais comum, porque muitos guias antigos recomendam defini-la. O serviço falha, e journalctl -u mysql -n 50 identifica diretamente a variável desconhecida. Remova essa linha do ficheiro em /etc/mysql/mysql.conf.d/ e execute sudo systemctl start mysql.

Segundo, o plugin mysql_native_password já não fica ativado por predefinição na versão 8.4. Por isso, uma conta que ainda o utilize não consegue iniciar sessão. Verifique enquanto ainda estiver na versão 8.0:

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

Migre todas as contas que apresentem mysql_native_password antes da atualização. Depois, atualize a palavra-passe na configuração da aplicação:

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

Se uma biblioteca cliente for demasiado antiga para utilizar caching_sha2_password, pode reativar o plugin antigo na versão 8.4. Para isso, adicione mysql_native_password=ON em [mysqld]. Use esta solução apenas como medida temporária e defina uma data para a remover, porque o MySQL removeu o plugin na versão 9.0.

PHP 8.3 para 8.5: os seus vhosts apontam para um socket que já não existe

24.04 inclui PHP 8.3 e 26.04 inclui PHP 8.5. Os pacotes são instalados em caminhos versionados e nada reescreve a configuração do seu servidor web. Um vhost do nginx que contém fastcgi_pass unix:/run/php/php8.3-fpm.sock; passa a apontar para um socket que nenhum processo cria. Por isso, todos os pedidos PHP devolvem 502 e o log de erros do nginx mostra:

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

Aponte-o para o novo socket, teste a configuração e recarregue-a:

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

No Apache com mod_php, o sintoma é diferente: o Apache não inicia de todo e sudo apache2ctl -t informa que não consegue carregar libphp8.3.so porque o ficheiro não existe. O módulo ativado é um symlink para um pacote que já foi removido.

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

Se instalou o sistema seguindo uma stack LAMP no Ubuntu 24.04, vale a pena verificar ambos os caminhos, porque o guia deixa uma versão de módulo e um socket versionados.

A configuração de otimização de php.ini também não é transferida. memory_limit, upload_max_filesize e qualquer outro valor que tenha definido estão em /etc/php/8.3/, e a nova árvore começa com os valores predefinidos. Compare os dois ficheiros e copie os valores manualmente. Copiar o ficheiro antigo inteiro para cima do novo introduz os valores predefinidos do 8.3 numa instalação 8.5. Depois execute php -m e compare: uma extensão instalada como php8.3-redis precisa do pacote php8.5-. Se tiver vindo de um PPA, o atualizador desativou essa origem e a extensão simplesmente não está instalada.

Os certificados merecem uma verificação própria. Execute sudo certbot renew --dry-run --run-deploy-hooks depois da atualização. O comando testa todo o processo de renovação, incluindo o hook de recarregamento do servidor web, sem alterar o certificado em utilização. Um hook que chama um nome de serviço ou um binário que mudou falha aqui, de forma visível, em vez de falhar silenciosamente na próxima renovação. Certbot com Let's Encrypt no nginx explica como esses hooks devem ser configurados.

SSH: a falha que encerra a sessão em que está a trabalhar

O prompt sshd_config é onde as pessoas ficam sem acesso ao servidor. Responder Y instala o ficheiro do maintainer e descarta o seu PermitRootLogin, PasswordAuthentication, AllowUsers, Port e todas as outras linhas que adicionou. Se a firewall permitir apenas uma porta personalizada e a configuração do pacote escutar na porta 22, a ligação seguinte será recusada e a sessão em que está será a última disponível.

Previna o problema antes de atualizar. O /etc/ssh/sshd_config no 24.04 começa com Include /etc/ssh/sshd_config.d/*.conf e, para a maioria das definições, o OpenSSH mantém o primeiro valor que lê. Por isso, um ficheiro drop-in incluído no início prevalece sobre a mesma definição mais abaixo. Algumas palavras-chave são exceções: Port e ListenAddress aceitam vários valores. Assim, uma linha Port num drop-in adiciona uma porta em vez de substituir a porta definida mais abaixo. Mova as suas definições para um ficheiro que o dpkg não controla:

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

Quando já não existir nada seu em /etc/ssh/sshd_config, esse prompt deixa de ser relevante: qualquer resposta mantém as suas definições, porque elas estão noutro ficheiro.

Uma porta personalizada requer mais uma verificação, porque pode não estar onde espera:

systemctl is-enabled ssh.socket

Se isso mostrar enabled, é o systemd que abre a porta de escuta, não o sshd. O Ubuntu usa ativação por socket para o sshd desde a versão 22.10. No 24.04, um gerador do systemd lê as definições Port e ListenAddress da configuração do sshd e transforma-as nos endereços de escuta do socket, mas apenas quando o systemd recarrega as unidades. É por isso que uma alteração de Port 2222 parece não produzir efeito: só entra em vigor depois de sudo systemctl daemon-reload && sudo systemctl restart ssh.socket, e o sshd_config fornecido pelo pacote inclui agora uma nota que explica isso. Para definir diretamente a porta na unidade do socket, use sudo systemctl edit ssh.socket:

[Socket]
ListenStream=
ListenStream=2222

O ListenStream= vazio é necessário. Ele limpa o valor herdado. Sem ele, o socket escuta na porta 22 e também na 2222. Aplique a alteração com sudo systemctl daemon-reload && sudo systemctl restart ssh.socket.

Depois da atualização, antes de fechar a sessão em que está:

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

Em seguida, abra um segundo terminal no seu próprio computador e inicie sessão novamente. Um shell funcional nesse segundo terminal é a única confirmação que conta. Mantenha a primeira sessão aberta até conseguir essa confirmação. Reforço da segurança do SSH numa VPS explica as definições que vale a pena manter nesse drop-in.

Se já for demasiado tarde, a consola Web do seu fornecedor permite iniciar sessão sem usar SSH. Inicie sessão nessa consola, corrija a configuração, execute sudo sshd -t e reinicie o serviço. Essa consola existe precisamente para testar o acesso antes de uma atualização, e não durante uma atualização.

FAQ

Por que do-release-upgrade informa "No new release found" no Ubuntu 24.04?

Desde 29 September 2026 isso não deveria acontecer, porque essa foi a data em que a Canonical habilitou as atualizações do 24.04 LTS para o 26.04.1. Antes disso, a mensagem era esperada: o Ubuntu 26.04 LTS foi lançado em 23 April 2026, o 26.04.1 foi lançado em 27 August, e o caminho permaneceu fechado por mais algumas semanas enquanto a Canonical fazia o backport de correções para regressões do rust-coreutils. Se a mensagem ainda for exibida, confirme se /etc/update-manager/release-upgrades contém Prompt=lts, que é o padrão do Ubuntu Server e oferece apenas a próxima versão de suporte de longo prazo. Mantenha essa opção em lts.

Preciso reiniciar o servidor para concluir a atualização?

Sim. A atualização instala um novo kernel, uma nova biblioteca C e um novo sistema init. O sistema em execução continua usando as versões antigas até ser reiniciado. do-release-upgrade solicita o reinício ao final, e uma máquina mantida em execução até "later" fica usando uma combinação de duas versões. Depois que ela voltar, verifique uname -r para confirmar o novo kernel e systemctl --failed para identificar os serviços que não voltaram.

Devo atualizar o servidor atual ou criar um servidor 26.04 novo?

Crie um servidor novo quando possível. Um VPS novo permite instalar a pilha, restaurar os dados e testar tudo enquanto o servidor antigo continua atendendo ao tráfego. Assim, o rollback consiste em alterar o DNS, em vez de restaurar um backup. Faça a atualização no servidor atual quando ele armazenar estado difícil de migrar, quando o provedor cobrar por máquina ou quando você tiver um snapshot e acesso ao console já testado. O processo de atualização no servidor atual é bem conhecido, mas funciona como uma operação de mão única durante a hora em que é executado.

O que acontece se minha conexão SSH cair durante a atualização?

O atualizador do servidor normalmente usa GNU screen. Portanto, uma conexão SSH interrompida não encerra a atualização por si só. Se você a iniciou dentro da sessão tmux nomeada acima, reconecte-se e execute tmux attach -t upgrade para retomá-la. O atualizador também inicia um daemon SSH auxiliar na porta 1022 como segunda forma de acesso. No entanto, ele não abre o firewall para essa porta. Portanto, permita a porta 1022 manualmente antes e feche-a depois.

Meu site PHP retorna 502 depois da atualização. O que foi alterado?

O caminho do socket do PHP FPM mudou com a versão. O Ubuntu 24.04 usa PHP 8.3 e o 26.04 usa PHP 8.5. Portanto, /run/php/php8.3-fpm.sock não existe mais, enquanto o vhost do nginx ainda faz referência a ele. O log de erros do nginx mostra connect() to unix:/run/php/php8.3-fpm.sock failed (2: No such file or directory). Atualize fastcgi_pass para o socket da versão 8.5, execute sudo nginx -t e depois recarregue o nginx. No Apache com mod_php, a correção equivalente é sudo a2dismod php8.3, seguida de sudo a2enmod php8.5 e de um reinício.