Guide CloudPanel Varnish Cache Showing Old Pages or Breaking Logins: How to Fix

**JAY** · (This post was last modified: 10-23-2026, 09:37 AM by JAY.)

CloudPanel Varnish cache showing old pages or breaking logins: how to fix

Varnish makes CloudPanel sites very fast by keeping a ready-made copy of each page in memory. The downside: when it caches the wrong thing, you see old content, or logged-in pages (account, cart, checkout) behave strangely. This guide shows how to check what Varnish is doing and how to fix the usual problems. For the basics, see CloudPanel cron jobs, logs and Varnish cache.

Step 1: Is Varnish serving this page?
Look at the response headers:

Code:

Age greater than 0, or a cache "HIT" header: the page came from the cache.
Age 0 or a "MISS" every time: not cached (expected for excluded pages).
Set-Cookie on normal pages: the app sets cookies everywhere, which affects caching. More on that below.

Run it twice; the second run should show a higher Age if caching works.

Problem 1: changes don't show up
You edited a page, but visitors still see the old version.

Purge the cache: open the site in CloudPanel, go to Varnish Cache and use Purge Entire Cache. You can also purge a single URL or tags. From SSH, as the site user:
Code:
clpctl varnish-cache:purge --purge=all
(or
Code:
--purge='https://example.com/page/'
for one URL).
WordPress: install CloudPanel's Varnish plugin (linked from the site's Varnish Cache section) so pages are purged automatically when you save posts.
Still old? Something else caches too: a WordPress cache plugin, Cloudflare, or your browser. Purge each one, then test in a private window.
Lower the cache lifetime in the Varnish settings if content changes often.

Problem 2: logins, carts or forms break
Symptoms: you log in and get logged out, a customer sees someone else's cart, a form says "expired" or "invalid token". This means a personal page was cached and served to the wrong person. Never let personal pages into the cache.

In the site's Varnish Cache > Settings, add the paths that must never be cached to Excludes. Examples for common apps:

Code:

^/wp-admin/
wp-login.php
^/my-account/
^/cart/
^/checkout/

After adding excludes, purge the cache, because pages already cached stay there until purged.

Pages with special query parameters can be excluded through Excluded Params too (for example a parameter your app adds for logged-in previews).

Problem 3: nothing gets cached at all
Usually the app sends cookies or

Code:

Cache-Control: no-cache / private

headers on every page, which tells Varnish not to cache. Check the headers from Step 1. Common reasons:

A plugin starts a PHP session on every page (look for a
Code:
PHPSESSID
cookie).
A security or analytics plugin sets cookies for every visitor.
You're testing while logged in. Test in a private window.

Fix the plugin or configure it to skip anonymous visitors.

Problem 4: site broken after turning Varnish on
Turn Varnish off for the site first to confirm it's the cause. If the site works without it, turn it on again and add excludes for the broken parts step by step. If you see 502/503 errors instead, see Fix 502 Bad Gateway in CloudPanel.

Is Varnish worth it for my site?
Varnish helps most on sites with many anonymous visitors and pages that rarely change: blogs, magazines, brochure sites. For a busy shop or members site where most visitors are logged in, its benefit is smaller and the excludes list gets long.

Sources: CloudPanel: Varnish Cache settings · Varnish documentation

More CloudPanel troubleshooting

Applies to CloudPanel v2 on Ubuntu and Debian, October 2026. Replace

Code:

example.com

with your domain.

Possibly Related Threads…matched by title
Guide Fix High CPU and Memory Usage in CloudPanel DEV	Replies:0Views:120	10-16-2026, 06:23 AMDEV
Guide CloudPanel Cron Jobs, Logs and Varnish Cache: Complete Guide JAY	Replies:0Views:132	10-14-2026, 01:10 PMJAY