Fix Plesk update failures — FetchFailedException, 502, and conflicts

Plesk's autoinstaller fails in three recognisable ways: it cannot reach the mirror (FetchFailedException), the web UI returns HTTP 502 mid-run, or a 18.0.x → 18.0.60 upgrade aborts partway through with a package conflict. Each has a distinct fix; running plesk repair all blindly is the wrong first move.

This decision tree covers the three failure modes operators actually report, in the order to check them.

Symptom: FetchFailedException

The Package Update Manager logs a com.parallels.pum.exception.FetchFailedException and the UI shows "Unable to download the file". The autoinstaller cannot reach autoinstall.plesk.com or one of its mirrors.

Confirm it is network, not the mirror

curl -sI https://autoinstall.plesk.com/products.inf3
dig +short autoinstall.plesk.com

A non-200 response or empty dig output means DNS or egress is blocked. The common causes:

1. IPv6 misconfigured. The server prefers AAAA but has no working IPv6 route. Force IPv4: echo 'precedence ::ffff:0:0/96 100' >> /etc/gai.conf.
2. Outbound HTTPS blocked. Check the firewall: iptables -L OUTPUT -n | grep 443. Cloud provider security groups frequently block egress on freshly provisioned VMs.
3. HTTP proxy set system-wide but not for Plesk. Set it explicitly:

plesk bin server_pref --set-proxy -url http://proxy.internal:3128

Clear the stale catalogue

If the network works but the error persists, the local catalogue cache is corrupted:

rm -rf /root/parallels/autoinstaller/*.tmp
rm -f /root/parallels/PSA_*/products.inf3
plesk installer --check-updates

The next run rebuilds the catalogue from the mirror.

Symptom: HTTP 502 on the autoinstaller UI

You start an upgrade through Tools & Settings → Updates, the page hangs, and refreshes return 502. The autoinstaller is still running on the backend but sw-engine (Plesk's PHP-FPM) has dropped the proxy connection because the upgrade restarted it.

This is expected for the duration of the upgrade. Confirm with:

ps -ef | grep -E '(ai_run|psa_autoinstaller)'
tail -f /var/log/plesk/install/autoinstaller3.log

If the autoinstaller process is gone but 502 persists, restart sw-engine:

systemctl restart sw-engine sw-cp-server
plesk bin repair --restart-services

Symptom: 18.0.x upgrade conflicts

Upgrading to 18.0.60 (or any monthly micro-update) aborts with messages like "package psa-phpmyadmin has unmet dependencies" or "Conflict: requested operation would break existing installation". The catalogue contains a newer dependency than the local repo will resolve.

Reinstall the current patch first

The fix is to force a reinstall of the current patch level, which resyncs the package set, then re-run the upgrade:

plesk installer --select-product-id plesk \
  --select-release-current --reinstall-patch

This takes 5-15 minutes on a 2-vCPU VPS. When it completes, retry the upgrade through the UI or:

plesk installer --select-product-id plesk --select-release-latest

When reinstall-patch is not enough

If the conflict survives --reinstall-patch, a system package has been removed underneath Plesk (typically libpq, mariadb-common, or nginx-common after an unrelated apt operation). Repair the installation:

plesk repair installation -y

This is the safe, idempotent repair — it reinstalls Plesk's own packages without touching customer data. Only escalate to plesk repair all if plesk repair installation reports it cannot continue; repair all rewrites domain configs and is slow on busy servers. The deeper failure mode is covered in Plesk server components not configured.

After the repair, verify:

plesk version
plesk bin server_pref --show-update

The version line should show 18.0.60 (or whichever release you targeted) and the update channel should match what you expect.

Next steps

• If components still show as not installed, follow Plesk server components not configured.
• For a fresh install on Ubuntu 24.04, see install Plesk on Ubuntu 24.04.
• Renew or upgrade your Plesk licence before a major version bump to avoid mid-upgrade activation prompts.