5 Common VPS Problems and How to Troubleshoot Them

When a VPS stops responding or an application slows down, first find the failing layer. DNS, a blocked port, an exhausted worker pool and a full disk can produce similar symptoms, but each needs a different fix.

The five sections below follow the same sequence: collect evidence, make a targeted change, then repeat the check that exposed the problem. They apply to a self-managed Linux VPS. Confirm the recovery options available from your provider before an incident makes them necessary.

Before changing anything

Record when the problem started, which users or services are affected, and the last known working state. Note recent deployments and configuration changes, along with the commands you run during the investigation.

Keep an existing administrative session open while changing access rules. Before changing production storage, packages, authentication or application configuration, confirm a usable backup and a recovery procedure. Make one controlled change at a time so its effect can be identified.

1. SSH or the application is unreachable

Identify where the connection fails

A timeout, a refused connection and a rejected login point to different stages. Start from a known working client: check the hostname's DNS result and test the intended address and port. Failure to answer ping does not prove the server is down because ICMP may be filtered.

For SSH, use verbose output to see the last successful stage. Replace admin and server.example with your own account and host, and include your configured port if it differs from the default.

ssh -vvv admin@server.example

From an existing authorised session on the server, inspect its addresses, routes, listeners and failed services:

ip address
ip route
ss -lntp
systemctl --failed

Compare the result with recent DNS, firewall, routing, SSH or deployment changes. If access is completely lost, use the provider's documented recovery method if one is available.

The OpenSSH client manual explains verbose diagnostics, and the ss manual covers socket inspection. Reading process details may require elevated privileges. Check UDP listeners separately if the affected application uses UDP.

Correct the failed layer and reconnect

Restore the intended DNS record if resolution is wrong. Check the route if traffic goes to the wrong interface, the service's bind address if it is listening only locally, and the relevant firewall rule if the port is blocked. Validate daemon configuration before reloading it.

Test a new administrative connection through the intended hostname, address, port and account before closing the original session. Check the application both locally and from an external client. If the change fails, restore the recorded configuration and reconsider the diagnosis rather than opening every port or adding another speculative change.

2. Access looks suspicious or security settings are incomplete

Distinguish a configuration gap from compromise

Repeated failed logins can be background scanning. An unknown privileged account, authorised key, scheduled job or outbound connection needs closer investigation. Record timestamps and preserve relevant logs before cleaning up.

Review authentication and service events, accounts, administrative groups, keys, scheduled jobs and listeners. Identify installed package versions and relevant security advisories. The journalctl manual explains how to narrow journal queries by time and service.

Treat an ordinary hardening gap differently from unexplained privilege or persistence. The latter may require isolation and evidence preservation rather than an in-place configuration tidy-up.

Restore control and verify access

For a baseline gap, establish a named administrator account, key-based login, appropriate sudo access, an inbound allowlist and a patch process. Test the replacement access path before disabling the old one.

If credentials were exposed, revoke them and rotate affected secrets from a trusted system. For credible compromise, contain the host where safe, protect independent backups and determine the incident's scope. Rebuild from trusted software and verified data when the host's integrity cannot be established. Installing a firewall or Fail2Ban will not undo an existing compromise.

Verify that authorised users can connect, prohibited access is blocked, required services work and updates have not left failed units. Investigate unexpected listeners or persistence. A clean-looking process list alone does not prove that a compromised host is trustworthy.

3. The server is slow or processes keep stopping

Measure the slow period

Record when latency, errors, queue depth or worker restarts increase. Look for exhausted memory, swapping, a saturated core, elevated CPU steal time, storage delays, full filesystems or exhausted inodes.

Collect a short sample during the affected workload:

uptime
free -h
vmstat 1 10
df -h
df -i
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head

Interpret the commands together. For example, Linux uses memory for reclaimable cache, and process percentages do not by themselves explain a latency spike. Check the journal for out-of-memory kills and failed services. The first vmstat report covers averages since boot; subsequent samples cover the requested interval.

Where available, use iostat for storage activity and /proc/pressure/ for stalled work. The Linux pressure-stall documentation explains the CPU, memory and I/O measures. Correlate system activity with application logs and the actual request or job that slowed down.

Fix the bottleneck and repeat the workload

If workers exhaust memory, review concurrency and queue limits. If database queries dominate, investigate the query plan and indexes. If storage is full, identify its owner and rotate or remove only confirmed disposable files. Address a runaway job's cause rather than repeatedly killing it.

Add caching where the data and invalidation rules support it, then measure the result. Resize or redesign the service when its expected workload cannot meet the target within the available resources.

Repeat the same workload and sampling interval. Compare response time, errors, queues, memory, swapping, CPU and storage behaviour. Keep the previous application or worker configuration so you can restore it if the change worsens performance. Confirm that the original symptom is resolved; a larger plan alone does not establish that.

4. Backups exist but recovery is uncertain

Check what the copies contain

A job can report success while omitting the database, uploaded files or configuration needed to rebuild. A copy on the same VPS can also disappear with the source.

Map each service to its data, configuration, secrets, dependency versions and restore order. Check backup location, encryption, deletion permissions, retention, last successful run and most recent usable recovery point. Confirm who receives failure alerts.

Set recovery expectations: how much recent data can be lost and how long the service can remain unavailable. A provider snapshot or same-server archive may be useful, but it is only part of the recovery design.

Build and test an independent recovery path

Use the application's supported export or quiescing procedure for consistent data. Keep at least one protected copy outside the VPS's failure domain, with access designed to survive loss or compromise of the primary credentials. Preserve the information needed to rebuild the software as well as its data.

The rsync manual explains file transfer. Copying files successfully does not establish that a live database is consistent or that its application will start.

Restore into an isolated target. Check representative records or files, permissions, secrets, startup and an application health path. Measure the recovery time and identify the restored data's cutoff point.

Keep the last tested backup process and copies until the replacement has produced a recovery point that you have successfully restored. If a test fails, repair the new process while retaining the known working recovery set.

5. Packages or application dependencies conflict

Identify the incompatible component

Read the application's maintained support matrix and upgrade notes. Record the operating system, architecture, package repositories, runtime and database versions, configuration and exact error.

Determine whether the problem is a package-source conflict, unsupported platform, missing dependency, configuration change or data-schema migration. Reproduce the installation or upgrade in a disposable environment with matching versions and representative data before changing production.

A container starting successfully does not establish that its networking, permissions, persistence and application dependencies work. Include those paths in the investigation.

Use a supported upgrade and rollback path

Use the operating system's supported repositories or the application's documented vendor repository, following its signing-key instructions. Pin a version only with an owner and a plan for future updates. Apply configuration and database migrations in the required order.

Use containers when the application supports that deployment and your team can manage image provenance, secrets, data, networking and updates. They can isolate dependencies but cannot fix incompatible application code or data.

Before upgrading, retain the package list, working deployment artifact, configuration and a usable data backup. Review installation scripts before giving them privileges; avoid piping an unreviewed download directly into a shell.

Run the application's health and functional checks, inspect logs and verify that it survives a service restart. Exercise the real database or dependency connection. If the change fails, restore the matching software, configuration and data state through the supported rollback procedure. A binary downgrade against an incompatible newer schema can make recovery harder.

Keep a useful incident record

Save the symptom, start time, affected services, evidence, diagnosis, exact change, recovery point and verification result. Record the final state and an owner for unresolved work.

That history gives the next operator a starting point. Recheck the evidence when a similar symptom returns, because the same visible failure can have a different cause.