WooCommerce Checkout Recovery on RHEL 9 VPS

Why checkout recovery matters on a live store

WooCommerce checkout recovery is often the fastest way to get a store moving again after a theme change, plugin update, SSL problem, or PHP crash. On a production VPS, the issue usually is not WooCommerce alone. It is the stack around it: RHEL 9 packages, PHP-FPM, Nginx, certificates, and file permissions.

This tutorial shows a safe recovery workflow on Hostperl VPS running RHEL 9-compatible systems. You will verify the services that matter, test the checkout path, and keep a rollback ready if a recent change caused the outage. If your store is part of a migration or cutover, pair this with WordPress migration cutover checks and staging before production updates.

What this tutorial covers on RHEL 9

You will:

• create a non-root sudo user and keep root access available until verification succeeds
• install the RHEL 9 packages needed for Nginx, PHP-FPM, MariaDB client tools, and SSL support
• restore checkout access after SSL, file permission, or PHP errors
• check logs and service state in a way that helps you isolate the real fault
• test a rollback so you are not guessing during an outage

This procedure is specific to RHEL 9, Oracle Linux 9, and AlmaLinux 9. Package names and SELinux behavior matter here. Debian-family commands are different, so do not copy them onto a RHEL server.

Connect and confirm the operating system

On your local computer, open your first SSH session to the server. Use the example IP below, then replace it with your real server address.

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the public IP assigned to your VPS. If your provider gives you a default admin account, connect with that account instead, but keep the same example IP style.

On the VPS as root, identify the system before you install anything.

cat /etc/os-release

You should see a RHEL 9-family release string such as AlmaLinux, Rocky Linux, Oracle Linux, or Red Hat Enterprise Linux 9.

Create a non-root admin and keep root open

Do not disable root access yet. First, create a working sudo account and test it in a second terminal. That keeps you from locking yourself out if SSH or sudo is misconfigured.

On the VPS as root, create the administrator account and grant sudo access.

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy

This creates deploy, sets a password, and adds the user to the wheel group. On RHEL-compatible systems, wheel is the standard sudo path.

Now prepare SSH access.

mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

If you manage keys manually, place the correct public key in /home/deploy/.ssh/authorized_keys. Permissions matter here. Too-open SSH files will block login.

On your local computer, open a second terminal and test the new login.

ssh deploy@203.0.113.10

Replace 203.0.113.10 with your real IP. If login works, test sudo in the new session.

On the VPS as the non-root sudo user, confirm sudo works before you change root login settings.

sudo -v
sudo whoami

The second command should return root. If it does, keep both sessions open and continue.

Update the RHEL 9 stack and install recovery tools

WooCommerce checkout recovery often depends on fixing the runtime, not WooCommerce itself. On RHEL 9, install the services and diagnostics you need.

On the VPS as the non-root sudo user, update the system and install the packages.

sudo dnf update -y
sudo dnf install -y nginx php-fpm php-cli php-common php-mysqlnd php-opcache php-gd php-xml php-mbstring php-curl php-zip mariadb-server policycoreutils-python-utils firewalld curl unzip tar

These packages give you Nginx, PHP-FPM, database connectivity, SELinux tools, firewall control, and basic recovery utilities. If your store uses a different PHP version from the repository defaults, keep the version aligned with your application and theme requirements.

Check the installed PHP version.

php -v

You should see the PHP CLI version that matches the FPM runtime you are about to enable.

Start the database and web stack safely

Before touching the store, make sure the services that power checkout are running.

On the VPS as the non-root sudo user, enable and start the required services.

sudo systemctl enable --now firewalld mariadb php-fpm nginx

That starts the firewall, database, PHP-FPM, and Nginx on boot. If your store already uses MySQL or MariaDB with an existing data directory, do not reinitialize it unless you are recovering from a clean migration.

Check service state.

sudo systemctl status nginx php-fpm mariadb --no-pager

Each service should show active (running). If one fails, inspect its logs before restarting it again.

Open the firewall without breaking SSH

Open web access first, then leave your SSH rule in place. Never remove the SSH path before you confirm the new one works.

On the VPS as the non-root sudo user, allow web traffic.

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload
sudo firewall-cmd --list-all

You should see SSH, HTTP, and HTTPS listed. If your store already uses a custom SSH port, add that port before changing any SSH settings.

Set up Nginx for WooCommerce checkout traffic

Checkout pages fail when Nginx points to the wrong root, serves stale PHP, or blocks the store from reaching wp-admin/admin-ajax.php. Start with a simple, predictable server block, then tune it later.

On the VPS as the non-root sudo user, create the site configuration.

sudo tee /etc/nginx/conf.d/example.com.conf > /dev/null <<'EOF'
server {
    listen 80;
    server_name example.com www.example.com;
    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_pass unix:/run/php-fpm/www.sock;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    }

    location ~* /(wp-admin|wp-includes|wp-content/uploads)/.*\.php$ {
        deny all;
    }
}
EOF

Replace example.com with your domain and /var/www/example.com/public with your document root. This file is a starting point for a live store, not a full hardening policy.

Test the configuration before you reload Nginx.

sudo nginx -t

If the syntax check passes, reload Nginx.

sudo systemctl reload nginx

Point PHP-FPM at the store correctly

WooCommerce often breaks checkout when PHP-FPM is running but Nginx is not sending requests to the right socket, or when SELinux blocks access to the document root.

On the VPS as the non-root sudo user, confirm the pool config and enable the service.

sudo grep -n '^[^;].*listen' /etc/php-fpm.d/www.conf
sudo systemctl restart php-fpm
sudo systemctl status php-fpm --no-pager

The socket path should match the one used in the Nginx config. If it does not, edit either the pool file or the Nginx file so they match exactly.

Check the PHP-FPM logs if the service refuses to start.

sudo journalctl -u php-fpm -n 50 --no-pager

Repair common checkout failures

Now isolate the issue by symptom. This is where most store recoveries succeed.

1. HTTPS or mixed-content checkout failures

Check whether the site answers on HTTP and whether SSL is redirecting correctly later. For now, confirm the server is reachable.

curl -I http://example.com

If you see a 200 or a redirect, the web path is alive. If you see connection errors, recheck the firewall, DNS, and Nginx status.

2. Permission errors after a plugin update

Look for denied writes in the logs.

sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u php-fpm -n 50 --no-pager

File ownership problems usually appear as permission denied or failed to open stream. Fix them with the correct web ownership for your application tree, then retest.

3. SELinux blocks after migration

RHEL 9 uses SELinux by default. Check the denial trail.

sudo ausearch -m AVC,USER_AVC -ts recent

If you see AVC denials for the document root, label the files correctly.

sudo restorecon -Rv /var/www/example.com/public

If the store writes uploads or cache data in a custom path, label that path explicitly rather than disabling SELinux.

Install SSL and confirm the checkout path

WooCommerce checkout should not stay on plain HTTP. Once the web stack responds, request a certificate and test the final redirect path.

On the VPS as the non-root sudo user, install Certbot and request a certificate. The exact package names can vary slightly by RHEL-compatible repository, but the flow is the same.

sudo dnf install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Replace example.com with your real domain. Certbot should update the Nginx server block and set up automatic renewal if the validation succeeds.

Test the renewal path before you depend on it.

sudo certbot renew --dry-run

Then confirm HTTPS is serving a valid response.

curl -I https://example.com

Smoke test the store like a customer

At this point, do not stop at a service check. A store is only recovered when a buyer can move through the purchase path.

On your local computer, open the site in a browser and test:

• home page loads over HTTPS
• cart adds a product
• checkout page opens without redirects to a broken URL
• payment method loads, even if you stop before placing a real order
• order confirmation page loads after a test checkout in sandbox mode

If you have CLI access to the site files, you can also check the active WordPress health path.

curl -s https://example.com/wp-json/ | head

A valid JSON response confirms the application is answering and PHP is functioning.

Rollback if the last change made things worse

If checkout broke after the last update, roll back one layer at a time. Undo the latest web config change first, then service changes, then package changes.

On the VPS as the non-root sudo user, keep a copy of the working Nginx file before editing production settings.

sudo cp /etc/nginx/conf.d/example.com.conf /etc/nginx/conf.d/example.com.conf.bak
sudo nginx -t && sudo systemctl reload nginx

If the new config fails, restore the backup and reload again.

sudo cp /etc/nginx/conf.d/example.com.conf.bak /etc/nginx/conf.d/example.com.conf
sudo nginx -t
sudo systemctl reload nginx

For database-side rollback, stop changing schema or plugin tables until you have a backup. If you need a store-level restore drill, Hostperl’s restore planning guide is useful for the same discipline, even when your live app is WooCommerce rather than PostgreSQL-backed.

Harden after the store is stable

Once checkout is back, reduce the chance of another outage. Keep the non-root login, update packages on a schedule, and leave logs easy to inspect.

On the VPS as the non-root sudo user, make sure the key services start at boot and the system is current.

sudo systemctl enable nginx php-fpm mariadb
sudo dnf update -y

If you use automated patching, schedule it during a maintenance window and test checkout again afterward. For uptime-sensitive stores, pair this with a monitored release process. Hostperl’s health-check pattern shows the same operational discipline for app releases.

FAQ

Why does WooCommerce checkout fail after an SSL change?

Usually because WordPress is still generating HTTP links, Nginx is redirecting inconsistently, or the certificate was installed without updating the site URL. Check the browser redirect chain and the server block first.

What logs should I check first?

Start with /var/log/nginx/error.log, then journalctl -u php-fpm, then SELinux AVC events. Those three usually reveal the fault faster than WordPress plugin logs.

Should I disable SELinux to make the store work?

No. On RHEL 9 systems, fix file labels and access rules instead. Disabling SELinux hides the real problem and makes the server easier to compromise later.

How do I know the recovery is complete?

You should be able to load the site over HTTPS, add a product to the cart, open checkout, and complete a test order in sandbox mode without errors.

What if the store was broken by a plugin update?

Restore the last known good plugin version, clear caches, and test checkout again before applying any other changes. If the site is business-critical, keep a staging copy ready for the next update cycle.

Final verification checklist

Run these checks before you close the incident:

sudo systemctl status nginx php-fpm mariadb firewalld --no-pager
sudo nginx -t
curl -I https://example.com
sudo certbot renew --dry-run
sudo reboot

After reboot, reconnect from your local computer and confirm SSH, the web stack, and checkout still work. That last test tells you the fix is persistent, not temporary.