AidiPanel

Theme

Cache & Performance ​

"Change not showing up" ​

Common — this is the #1 cache support question on every panel that ships page caching You edited a post, changed a menu, or updated something, and the live site still shows the old version.

First, figure out which kind of change it was — this determines whether it should have auto-purged:

The Nginx Helper plugin (installed via --install-nginx-helper) purges automatically only when a post or page is published or updated. It does not auto-purge on:

  • menu changes
  • widget or Customizer changes
  • theme switches or theme-option edits
  • plugin install / activate / update

If your change falls into one of those categories, the old page is still being served correctly by design — it just needs a manual purge:

bash
aidipanel cache:purge --domain example.com

Or from the panel: Cache tab → Purge next to the domain.

If it was a post/page edit and it still didn't purge automatically:

  1. Confirm the helper plugin is actually installed and active in wp-content/plugins/
  2. Confirm cache is actually enabled for the domain: aidipanel cache:status
  3. Purge manually as a workaround, then check the plugin's own settings page (WordPress admin → Settings → Nginx Helper) for its cache path setting — it needs to match /var/cache/nginx/fastcgi to find and clear the right files

If purging doesn't help either: you're probably looking at browser or CDN caching rather than server-side cache — try a hard refresh (Ctrl/Cmd+Shift+R) or an incognito window before assuming the server is still stale.

Slow despite cache being on ​

Common A few different things can cause this — work through them in order.

1. Confirm cache is actually enabled and being hit:

bash
aidipanel cache:status
curl -I https://example.com/
# Look for: X-FastCGI-Cache: HIT

If it says MISS every time (not just the first request), something is preventing pages from ever being cached — check the next point.

2. Check you're not accidentally always hitting a bypass rule.

Testing while logged into WordPress, or with a query string in the URL (?utm_source=... from an ad campaign, for example), will always show BYPASS — that's correct behavior, not a bug. Test from an actual incognito window on a clean URL to get a fair read.

3. Check overall hit rate, not just one page:

bash
aidipanel cache:status

A low hit rate (well under 80%) across the whole site suggests either very low-traffic pages that expire before being requested again (inactive=60m default — a page nobody requests within 60 minutes falls out of cache and has to be rebuilt), or a busy site sharing the default zone with other sites and getting evicted early — see dedicated cache zones below.

4. Remember what FastCGI Cache does not speed up:

Page cache only helps anonymous, cacheable requests. If your actual traffic is mostly logged-in users (a membership site, a SaaS dashboard, WooCommerce checkout flows), page cache was never going to help those requests — see Logged-in users and cache below, and consider Redis object cache instead for that traffic.

5. Cache isn't the only variable. If hit rate is genuinely high (>80%) and it's still slow, the bottleneck likely isn't Nginx/PHP at all — check database query performance, third-party embeds/scripts, or image sizes. A cache hit serves the page shell fast; it doesn't fix a 5MB hero image or a slow third-party analytics script loading in the browser.

Logged-in users and cache ​

Expected behavior, not a bug If logged-in users (WordPress admins, WooCommerce customers with items in cart) report seeing something stale, that's actually the opposite of a cache problem — logged-in and cart-bearing traffic is explicitly excluded from cache by the default rules, specifically so no one is ever served a cached response meant for someone else.

If a logged-in user is seeing outdated content, the cause is almost always something else entirely: browser caching, a CDN in front of AidiPanel (Cloudflare, etc.) caching independently at its own layer, or an actual application-level issue unrelated to FastCGI Cache. Confirm with:

bash
curl -sI -b "wordpress_logged_in_test=1" https://example.com/ | grep X-FastCGI-Cache
# Should always show: BYPASS

If this shows HIT instead of BYPASS, that is a real problem worth stopping and investigating immediately — see Multi-PHP & WooCommerce Cache → What to verify after enabling.

Noisy neighbour (low hit rate on a busy site) ​

Occasional, on multi-site boxes By default every site shares one FastCGI cache zone. Cache keys are host-scoped so entries from different domains never collide or leak into each other — but the eviction budget is shared, so a very high-traffic site can push a quieter site's cached pages out sooner than its own TTL would otherwise allow.

If cache:status shows a specific busy domain with a lower hit rate than expected, give it a dedicated zone:

bash
aidipanel cache:zone --action enable --domain example.com --keys 64m --max-size 5g
aidipanel cache:zone --action status --domain example.com

Full explanation: FastCGI Cache → Dedicated cache zones. Most sites never need this — reach for it only after confirming via cache:status that eviction is actually the problem, not one of the other causes above.

High server load in general (not cache-specific) ​

If the whole server feels sluggish rather than one particular site:

bash
# What's actually consuming resources right now
aidipanel system:info
top

Common causes on a shared multi-site VPS: one site getting a traffic spike and its PHP-FPM pool consuming most of the CPU/RAM (isolated per-site pools mean this shouldn't crash other sites, but it can still slow the box overall if RAM is genuinely exhausted), a runaway cron job or import script, or simply being under-provisioned for the number/size of sites hosted — compare current usage against the recommended specs for a sanity check.