# Common Issues

> Troubleshooting guide for the most frequently encountered problems when managing servers and sites on FlyWP.

Source: https://flywp.com/docs/faqs/common-issues/

When something breaks on your server or site, finding the cause quickly is what matters most. This page walks you through the most common problems FlyWP users run into — from blank white screens to failed deployments — with clear steps to get things working again. If your issue is not listed here, check the [FAQ](https://flywp.com/docs/faqs/faq/) or reach out to FlyWP support.

## Site Not Loading After Domain Change

![DNS Manager showing domain records](https://flywp.com/images/docs/screenshots/dns-overview.png)

**Symptom:** You changed your site’s domain or pointed a new domain to your server, but the site shows a browser error or still loads the old site.

**Cause:** DNS changes take time to spread across the internet — a process called **DNS propagation**. Each DNS record has a TTL (Time to Live) value that controls how long servers around the world cache the old information. Propagation can take anywhere from a few minutes to 48 hours depending on your DNS provider and TTL setting.

Here is what to check:

1. Verify that your DNS records are correct — the **A record** (which maps a domain name to an IP address) for your domain should point to your server’s IP address. Check this in the [DNS Manager](https://flywp.com/docs/server/dns-management/) or your DNS provider’s dashboard.
2. Wait at least 15–30 minutes for propagation. Most changes take effect within this window when using Cloudflare.
3. Clear your browser cache and try loading the site in an incognito or private window.
4. Use a DNS lookup tool (like `dig` on the command line, or an online DNS checker) to confirm the domain resolves to the correct IP address.

:::tip
If you are using Cloudflare, check the proxy status for your domain’s A record. An orange cloud means traffic routes through Cloudflare’s network (proxied), while a gray cloud means it points directly to your server (DNS-only). Make sure the setting matches what your site needs.
:::

## SSL Certificate Not Provisioning

**Symptom:** Your site shows a browser security warning, or the SSL certificate status in FlyWP shows an error or stays in a pending state.

**Cause:** FlyWP uses Let’s Encrypt (a free, automated certificate authority) to issue SSL/TLS certificates — the technology that enables the padlock icon and HTTPS in browsers. Let’s Encrypt verifies that you own the domain by reaching your server over HTTP. If your DNS records are wrong or propagation is still in progress, that verification fails.

Work through these steps:

1. Confirm that the **A record** for your domain points to the correct server IP address.
2. If you are using Cloudflare with the proxy enabled (orange cloud), temporarily switch to **DNS-only** (gray cloud) and retry SSL provisioning. Once the certificate is issued, you can re-enable the proxy.
3. Make sure **port 80** is open in your server’s [Firewall](https://flywp.com/docs/server/firewall/) rules — Let’s Encrypt uses port 80 for domain validation.
4. Wait for DNS propagation to complete, then retry SSL provisioning from your site’s [SSL settings](https://flywp.com/docs/site/custom-ssl-management/).

If your domain has a **CAA record** (a DNS setting that restricts which certificate authorities are allowed to issue certificates for your domain), make sure `letsencrypt.org` is on the allowed list. A misconfigured CAA record blocks Let’s Encrypt from issuing a certificate entirely.

## 502 Bad Gateway

**Symptom:** Visitors see a “502 Bad Gateway” error page when accessing your site.

**Cause:** Nginx (the web server software that handles incoming traffic) is running, but it cannot reach PHP-FPM (the process that actually runs your PHP code). This usually means the PHP process has crashed or is overwhelmed by too many requests at once.

To resolve it:

1. Go to your server’s **Manage** tab and restart **Nginx Proxy**.
2. If the error persists, restart the site’s PHP service from the site settings.
3. Check whether your server is running out of resources — visit the **Status** tab to monitor CPU, RAM, and disk usage. A server that runs out of memory will cause PHP processes to crash and stop responding.
4. Review your site’s error logs for specific PHP errors that point to the root cause, such as a broken plugin or theme.

:::note
If 502 errors happen frequently, your server may be undersized for the amount of traffic it receives. Consider upgrading to a larger server plan.
:::

## White Screen of Death

**Symptom:** Your WordPress site shows a completely blank white page, often with no error message.

**Cause:** A fatal PHP error is occurring, but WordPress has error display turned off (as it should be on live sites). Common triggers include a broken plugin, a theme conflict, or PHP running out of memory.

Work through these steps in order:

1. **Check error logs** — access your site’s error logs through FlyWP or via SSH (Secure Shell, a way to connect to your server’s command line) to identify the specific PHP error.
2. **Increase PHP memory limit** — in your site’s PHP settings, try raising the `memory_limit` value (for example, from 256M to 512M). This gives PHP more room to run complex operations.
3. **Disable plugins** — if you recently installed or updated a plugin, connect via SSH or SFTP (Secure File Transfer Protocol, used to manage files on your server) and rename the `wp-content/plugins` folder to `wp-content/plugins-disabled`. If the site loads, re-enable plugins one at a time to find the culprit.
4. **Switch themes** — rename your active theme’s folder to force WordPress to fall back to a default theme, helping you rule out a theme conflict.
5. **Enable debug mode** — set `WP_DEBUG` to `true` in your `wp-config.php` file to surface the specific error. Disable it again once you have identified the problem.

## Cannot Connect via SSH

**Symptom:** Your SSH (Secure Shell) connection is refused, times out, or prompts for a password you do not have.

**Cause:** Firewall rules may be blocking the connection, the SSH key may not be configured correctly, or you may be using the wrong server credentials.

Check each of these in turn:

1. Verify you are using the correct **IP address**, **SSH port**, and **username** (`fly`) from the server’s [Manage tab](https://flywp.com/docs/server/managing-services/).
2. Confirm that your **SSH key** — a cryptographic credential that proves your identity without a password — has been added to the server on the **SSH Keys** tab.
3. Verify that **port 22** (or your custom SSH port) is open in the server’s **Firewall** rules.
4. If using a private key file, make sure its permissions are set correctly: `chmod 600 ~/.ssh/your_key`. Overly permissive key files are rejected for security reasons.
5. Try connecting with verbose output to get more detail on what is failing: `ssh -v fly@your-server-ip`.

:::tip
If you are locked out and cannot access SSH from your machine, use the **browser-based SSH terminal** in FlyWP’s Manage tab as a fallback. It connects through a different pathway and may still work when your local connection is blocked.
:::

## Database Connection Errors

**Symptom:** Your WordPress site displays “Error establishing a database connection.”

**Cause:** WordPress cannot reach its MySQL database (the software that stores all your site’s content, settings, and users). This happens when credentials are wrong, the MySQL service has stopped, or the server’s disk is full.

Work through these steps:

1. Go to your server’s **Manage** tab and verify that the **MySQL** service is running. Restart it if needed.
2. Check the **database credentials** in your site’s WordPress configuration. The database name, username, and password must match what FlyWP has on record (visible in the server’s **Database** tab).
3. If MySQL keeps crashing, check the **Status** tab for available disk space. A full disk prevents MySQL from writing data, causing it to shut down.
4. Confirm the credentials work by connecting to the database manually via SSH using the MySQL command-line client.

## Deployment Failures

**Symptom:** A Git deployment fails, and your site does not update with the latest code.

**Cause:** Deployment scripts may contain errors, the Git repository (the version-controlled codebase where your site’s code lives) may be inaccessible, or a post-deployment command may be failing.

Here is how to diagnose it:

1. Check the **deployment logs** on your site’s [Deployment](https://flywp.com/docs/site/git-deployment/) tab. The log output almost always contains the specific error message.
2. Verify that your **Git provider** (GitHub, GitLab, or Bitbucket) is still connected in your [Account Settings](https://flywp.com/docs/account/account-settings/).
3. Make sure the **branch** configured for deployment exists in the repository and has recent commits.
4. If you use a **deployment script**, test those commands manually via SSH to confirm they work outside of the deployment process.
5. Check that your server has enough **disk space** — a full disk causes Git operations to fail silently.

:::note
Failed deployments do not affect your live site. FlyWP only activates the new code after a fully successful deployment. If a deployment fails, your site continues running on the previous version.
:::

## Related Pages

- [FAQ](https://flywp.com/docs/faqs/faq/)
- [Glossary](https://flywp.com/docs/faqs/glossary/)
- [Managing Services](https://flywp.com/docs/server/managing-services/)
- [SSL Certificates](https://flywp.com/docs/site/custom-ssl-management/)
- [Backups](https://flywp.com/docs/site/backups/)
