Skip to main content

Web Server, PHP, and SSL Use Cases

This section ties the web server (Nginx/Apache/OLS), PHP runtime, and certificates together into practical workflows. Use these runbooks when you're making a change on a live WordPress site and you want a predictable sequence: change, validate config, reload, verify from the outside.

Quick Summary
  • Always validate configs (nginx -t, apachectl configtest) before reload.
  • After PHP changes, reload the correct PHP handler (FPM/Apache/OLS).
  • After certificate renewals, ensure the web server reloads so it serves the new chain.

Use case: Increasing WordPress upload limits​

Typical symptoms:

  • Media uploads fail.
  • Plugin/theme ZIP uploads fail.
  • Imports time out.

Checklist:

  • Update upload_max_filesize and post_max_size in php.ini.
  • Increase memory_limit if large plugins/themes are involved.
  • Reload the correct service (PHP-FPM/Apache/OLS).
  • Verify with a small test script and remove it.

Use case: Debugging a sudden 502/503 error​

Quick triage:

check-web-stack-services.sh
systemctl status nginx apache2 lsws php8.2-fpm mariadb --no-pager 2>/dev/null || true

If OpenLiteSpeed is used, tail the error log while reproducing:

tail-ols-error-log.sh
sudo tail -f /usr/local/lsws/logs/error.log

Common causes:

  • PHP handler down or misconfigured.
  • Worker limits reached (traffic spike/bots).
  • Disk full (uploads/logs/backups).

Use case: Moving from HTTP to HTTPS safely​

Runbook:

  • Ensure DNS points to the VPS and 80/tcp is reachable.
  • Issue a certificate with Certbot.
  • Configure the vhost to serve HTTPS.
  • Verify the served certificate (curl -Iv).
  • Update WordPress Site URL to HTTPS and validate login/admin.
warning

If you force redirect to HTTPS before certificates and vhosts are correct, you can lock yourself into a broken redirect loop. Validate HTTPS first, then redirect.

Use case: Adding HTTP/2 and (optionally) HTTP/3​

Runbook:

  • Enable HTTP/2 (low risk).
  • Verify with curl -I --http2.
  • If enabling HTTP/3, open 443/udp and verify with curl --http3.

Use case: Verifying changes without guesswork​

This is the general pattern for safe changes:

  1. Make the smallest possible change.
  2. Validate configuration syntax.
  3. Reload (prefer reload over restart when available).
  4. Verify from the network (curl/openssl) and from the application (WordPress).
  5. Roll back immediately if the symptom worsens.
example-verify-pattern.txt
Change -> Configtest -> Reload -> External verify -> App verify -> Document