Full Diagnostic Tree & Step-by-Step Overview
What specific error message or browser behavior occurs when attempting to visit your website?
- DNS lookup fails completely (DNS_PROBE_FINISHED_NXDOMAIN or ERR_NAME_NOT_RESOLVED)
- HTTP 5xx Server Error (500 Internal Server Error, 502 Bad Gateway, 503, or 504 Timeout)
- SSL/TLS Security Warning (NET::ERR_CERT_DATE_INVALID, ERR_SSL_PROTOCOL_ERROR, or ERR_TOO_MANY_REDIRECTS)
- Connection refused or timed out (ERR_CONNECTION_REFUSED, Cloudflare Error 522 / 524)
Did you recently register or renew the domain, change registrars, or update DNS records?
- Domain registration may have expired, or nameserver (NS) records are unassigned at the registrar
- Updated A/AAAA records or migrated hosts recently, but DNS is failing to resolve globally
Renewing Domain Registration & Re-binding Registrar Nameservers
Solution:
Root Cause: Expired Domain Registration or Invalid Nameserver Delegation
When a domain registration expires or its official WHOIS nameservers (NS records) are wiped by the registrar, global DNS resolvers cannot return IP addresses for your domain, triggering NXDOMAIN errors.
# Step-by-Step Fix:
Verify WHOIS Status & Expiration:Open a terminal or WHOIS lookup tool and run: whois yourdomain.comCheck the Registry Expiry Date and Domain Status (ensure it does not say clientHold or autoRenewPeriod expired).If expired, log in to your registrar portal (GoDaddy, Namecheap, Cloudflare, etc.) and renew the domain immediately.Verify Nameserver Delegation:In your registrar dashboard, verify that Custom Nameservers point correctly to your active DNS host (e.g., ns1.cloudflare.com or your hosting provider's nameservers).Verify via CLI: dig NS yourdomain.com +shortFlush Local DNS Caches:Windows: Open Command Prompt as Administrator and run ipconfig /flushdnsmacOS: Open Terminal and run sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponderAllow up to 24–48 hours for global DNS propagation to complete.
Correcting DNS A/AAAA Record Mismatches & Clearing Propagation Caches
Solution:
Root Cause: Incorrect A Record IP Target or Stale DNS Cache
If your domain's DNS A record points to a decommissioned web server IP, an incorrect reverse proxy target, or has stale cached records across public resolvers, client traffic cannot reach your server.
# Step-by-Step Fix:
Audit DNS A/AAAA Records:Log into your DNS management panel (Cloudflare, Route 53, cPanel, etc.).Ensure your root (@) and www A records point to your origin server's exact public IPv4 address.Verify that your server actually listens on IPv6 before configuring AAAA records; delete incorrect AAAA records if IPv6 is unsupported.Trace Global Propagation:Query global resolvers using Google Public DNS or Cloudflare via CLI:dig A yourdomain.com @8.8.8.8 +shortdig A yourdomain.com @1.1.1.1 +shortUse online DNS propagation tools to identify failing geographic locations.Lower TTL & Purge Proxy Caches:Set DNS TTL (Time To Live) to 300 seconds during IP migrations.If using Cloudflare, toggle the Proxy status (orange cloud) to Gray, then back to Orange, or trigger a full cache purge.
Is the HTTP 5xx error originating from local application crashes or an upstream proxy timeout?
- HTTP 500 Internal Server Error (occurs immediately on page load)
- HTTP 502 Bad Gateway or HTTP 504 Gateway Timeout
Fixing Fatal Script Errors, Memory Limits, & Corrupted .htaccess
Solution:
Root Cause: PHP Fatal Exceptions, Exhausted Memory Limits, or Syntax Errors in Web Server Rules
HTTP 500 Internal Server Error indicates that Apache or Nginx successfully received the request, but the underlying application runtime (e.g., PHP-FPM) crashed due to fatal code exceptions, memory limit exhaustion, or invalid rewrite rules.
# Step-by-Step Fix:
Inspect Server Error Logs:Nginx/Apache: Run tail -n 50 /var/log/nginx/error.log or tail -n 50 /var/log/apache2/error.log via SSH.WordPress / PHP: Enable debugging by setting define('WP_DEBUG', true); in wp-config.php, or inspect error_log in the web root.Reset .htaccess / Web Rules File:Rename your .htaccess file to .htaccess_bak.Create a clean .htaccess file with standard rewrite directives to rule out syntax errors.Increase PHP Memory Limit:Edit php.ini and update: memory_limit = 256MRestart PHP-FPM: sudo systemctl restart php8.2-fpm (adjust for installed version).Isolate Plugin/Extension Conflicts:Rename the plugins directory or disable recently installed application extensions.
Restarting Upstream PHP-FPM Processes & Tuning Timeout Thresholds
Solution:
Root Cause: Unresponsive Upstream PHP-FPM Service or CGI Gateway Timeout
HTTP 502 Bad Gateway / 504 Gateway Timeout occurs when a reverse proxy (Nginx, Cloudflare) receives an invalid response or times out waiting for the upstream application server (PHP-FPM, Node.js, Python WSGI) to process requests.
# Step-by-Step Fix:
Check Upstream Service Status:Connect via SSH and run: sudo systemctl status php8.2-fpm (or gunicorn / pm2)If inactive or failed, restart the service: sudo systemctl restart php8.2-fpmIncrease Proxy Timeout Settings:Nginx: Open your server block configuration file (/etc/nginx/sites-available/) and add/adjust:fastcgi_read_timeout 300;proxy_read_timeout 300;proxy_connect_timeout 300;Reload Nginx: sudo nginx -t && sudo systemctl reload nginxTune PHP-FPM Process Manager (pm):Edit /etc/php/8.2/fpm/pool.d/www.conf.Increase pm.max_children and pm.max_requests if logs report "server reached pm.max_children setting, consider raising it".
Is the SSL error caused by an expired certificate, missing SAN name, or a redirect loop behind Cloudflare?
- Browser displays expired certificate date, untrusted CA warning, or NET::ERR_CERT_DATE_INVALID
- Infinite redirect loop (ERR_TOO_MANY_REDIRECTS) or SSL handshake failure behind a CDN proxy
Renewing Expired TLS Certificates & Fixing CA Intermediate Chains
Solution:
Root Cause: Expired SSL/TLS Certificate or Missing Intermediate CA Bundle
Browsers block connection attempts when the presented SSL certificate's validity date has passed, or when the web server fails to send the full Certificate Authority (CA) chain required to establish trust.
# Step-by-Step Fix:
Re-issue / Renew Let's Encrypt Certificate:Connect to your server via SSH and run: sudo certbot renew --dry-runIf dry run succeeds, execute force renewal: sudo certbot renew --force-renewalEnsure port 80 is accessible during HTTP-01 challenge validation.Fix Missing Intermediate Certificate Bundle:Ensure your Nginx configuration points to fullchain.pem (certificate + intermediate bundle) rather than cert.pem alone:ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;Reload Web Server & Verify:Run: sudo systemctl reload nginx or sudo systemctl reload apache2Verify certificate health using Qualys SSL Labs SSL Test.
Aligning Cloudflare SSL/TLS Encryption Modes & Fixing Redirect Loops
Solution:
Root Cause: Mismatched SSL/TLS Encryption Modes Between CDN and Origin Server
Setting Cloudflare SSL/TLS mode to 'Flexible' while your origin server forces HTTPS redirects causes an infinite 301 redirect loop (ERR_TOO_MANY_REDIRECTS). Conversely, setting it to 'Full (Strict)' without a valid origin certificate triggers SSL handshake failures.
# Step-by-Step Fix:
Set Cloudflare Encryption Mode to Full (Strict):Log into Cloudflare Dashboard -> select domain -> navigate to SSL/TLS > Overview.Switch encryption mode from *Flexible* to Full (Strict).Install Cloudflare Origin CA Certificate:Go to SSL/TLS > Origin Server in Cloudflare.Click Create Certificate, generate a 15-year RSA certificate, and copy the Certificate and Private Key.Save these files on your origin server and update your Nginx/Apache SSL configuration.Disable Conflicting HTTPS Redirect Plugins:Disable application-level SSL forcing plugins (e.g., Really Simple SSL) if Cloudflare *Always Use HTTPS* is enabled.
Is the web server daemon stopped, or are firewall rules blocking traffic on HTTP/HTTPS ports?
- Web server service (Nginx / Apache / LiteSpeed) is inactive or crashed
- Web server daemon is running, but port 80/443 connection is refused or timing out (Cloudflare Error 522)
Restarting Crashed Web Server Daemons & Fixing Port Binding Conflicts
Solution:
Root Cause: Unresponsive Web Server Process or Socket Port Conflicts
When Apache, Nginx, or LiteSpeed crashes due to memory exhaustion, invalid configuration syntax, or port binding collisions (e.g., another process occupying port 80/443), client browsers receive ERR_CONNECTION_REFUSED.
# Step-by-Step Fix:
Check Service Status via SSH:Run: sudo systemctl status nginx (or apache2 / litespeed)Test configuration syntax before restarting:Nginx: sudo nginx -tApache: sudo apachectl configtestIdentify Port Conflicts:Check if another process is occupying ports 80 or 443:sudo netstat -tulpn | grep -E ':80|:443' or sudo ss -tulpn | grep -E ':80|:443'Terminate conflicting processes if necessary: sudo kill -9 <PID>Restart Service & Enable Auto-Start on Boot:Run: sudo systemctl restart nginxEnable persistence across system reboots: sudo systemctl enable nginx
Unblocking Ports 80/443 in System Firewall & Whitelisting CDN IPs
Solution:
Root Cause: Host Firewall Block or CDN IP Filtering at Origin Gateway
Cloudflare Error 522 / 524 or connection timeout errors occur when host firewalls (UFW, iptables, firewalld) or cloud security groups (AWS Security Groups, DigitalOcean Firewalls) block traffic on HTTP (80) and HTTPS (443) ports, or block CDN proxy IP ranges.
# Step-by-Step Fix:
Configure Linux System Firewall (UFW / firewalld):UFW (Ubuntu/Debian): Run sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw reloadFirewalld (RHEL/CentOS): Run sudo firewall-cmd --permanent --add-service=http --add-service=https && sudo firewall-cmd --reloadVerify Cloud Provider Security Groups:Log into your cloud host console (AWS, GCP, Azure, DigitalOcean).Ensure active Security Groups include Inbound Rules allowing TCP traffic on ports 80 and 443 from Source 0.0.0.0/0 (or CDN IP ranges).Whitelist Cloudflare IP Ranges:Fetch official Cloudflare IPv4/IPv6 ranges and add them to your origin firewall allowlist to prevent rate-limiting proxies.