Web Request Lifecycle Checklist for Website Operators
Most website problems become easier to debug when you understand the request lifecycle. A browser request does not go directly to WordPress. It usually passes through DNS, CDN, firewall, Nginx, PHP-FPM, WordPress, database and back again.
Core principle
When a website fails, do not guess. Find where the request stops. If DNS fails, the server may be fine. If Nginx works but PHP-FPM fails, WordPress cannot render. If PHP works but MySQL is down, dynamic pages fail.
Checklist
- Start with the browser error message.
- Check whether DNS resolves to the right IP.
- Check whether CDN or Cloudflare is involved.
- Check whether the VPS is reachable.
- Check whether Nginx is listening on port 80 and 443.
- Check whether Nginx routes the domain to the right server block.
- Check whether PHP-FPM is running for PHP pages.
- Check whether WordPress can connect to the database.
- Check whether the database is overloaded or down.
- Use logs to confirm the failing layer.
How to apply this elsewhere
This mental model applies to 404, 502, 504, SSL errors, DNS errors, WordPress errors and even AI automation dashboards behind reverse proxies.
When to Use This Checklist
Use this checklist when you need to understand where a website request fails between browser, DNS, server, Nginx, PHP, WordPress and database.
Required Tools
Browser, DNS access, VPS access, Nginx, PHP-FPM, MySQL or MariaDB, server logs, curl
Before You Start
Do not start by changing random settings. First identify the layer where the request stops.
Structured Checklist Steps
- Read the browser error.
- Check DNS resolution.
- Check CDN or Cloudflare status.
- Check VPS reachability.
- Check Nginx service.
- Check server block routing.
- Check PHP-FPM.
- Check WordPress database connection.
- Check database status.
- Read logs for the failing layer.
Verification Steps
- DNS points to the expected IP.
- Nginx responds.
- PHP-FPM is active.
- Database is reachable.
- Logs confirm the real failing layer.
Rollback Plan
If a change breaks the request path, restore the last known working DNS, Nginx or PHP-FPM configuration and test one layer at a time.
Common Mistakes
- Blaming WordPress before checking DNS.
- Changing Cloudflare, Nginx and WordPress at the same time.
- Ignoring logs.
- Testing only the homepage.
- Not separating static file problems from PHP problems.
Related Commands
dig example.com
curl -I https://example.com
sudo systemctl status nginx
sudo nginx -t
sudo systemctl status php8.2-fpm
sudo systemctl status mysql
sudo tail -n 100 /var/log/nginx/error.log