Title: Proxy Cache Purge
Author: Danila Vershinin
Published: <strong>જુલાઇ 15, 2011</strong>
Last modified: એપ્રિલ 2, 2026

---

પ્લગીન શોધો

![](https://ps.w.org/varnish-http-purge/assets/banner-772x250.png?rev=3052770)

![](https://ps.w.org/varnish-http-purge/assets/icon-256x256.png?rev=3027185)

# Proxy Cache Purge

 [Danila Vershinin](https://profiles.wordpress.org/dvershinin/) દ્વારા

[ડાઉનલોડ](https://downloads.wordpress.org/plugin/varnish-http-purge.5.9.0.zip)

 * [વિગતો](https://gu.wordpress.org/plugins/varnish-http-purge/#description)
 * [સમીક્ષાઓ](https://gu.wordpress.org/plugins/varnish-http-purge/#reviews)
 *  [સ્થાપન](https://gu.wordpress.org/plugins/varnish-http-purge/#installation)
 * [ડેવલપમેન્ટ](https://gu.wordpress.org/plugins/varnish-http-purge/#developers)

 [સપોર્ટ](https://wordpress.org/support/plugin/varnish-http-purge/)

## વર્ણન

**This plugin _does not_ install nor configure a cache proxy. It acts as an interface
with such services.**

One common method of caching content for websites is via the use of reverse proxy
caching. Common examples of this are [Varnish](https://www.varnish-cache.org/) and
[NGINX](https://www.nginx.org/). These systems allow a website to update content
and have the visitor’s experience cached without the need for complex plugins storing
the files locally and using up a user’s disk space.

A reverse proxy cache is installed in front of a server and reviews requests. If
the page being requested is already cached, it delivers the cached content. Otherwise
it generates the page and the cache on demand.

**The Proxy Cache Purge plugin sends a request to delete (aka flush) the cached 
data of a page or post every time it’s modified.**

#### How It Works

When content on a site is updated by WordPress, the plugin reaches out to the proxy
cache service with the URL of the page, requesting the cache be deleted.

Not all pages are deleted from the cache on every change. For example, when a post,
page, or custom post type is edited, or a new comment is added, _only_ the following
pages will purge:

 * The front page
 * The post/page edited
 * Any categories, tags, and/or custom taxonomies associated with the page
 * Related feeds
 * Associated JSON API pages

In addition, your _entire_ cache will be deleted on the following actions:

 * Changing themes
 * Pressing the **Empty Cache** button on the toolbar

Plugins can hook into the purge actions as well, to filter their own events to trigger
a purge.

On a multisite network using subfolders, only **network admins** can purge the main
site.

#### Development Mode

If you’re working on a site and need to turn off caching in one of two ways:

 1. Add `define( 'VHP_DEVMODE', true );` to your `wp-config.php` file
 2. Go to Proxy Cache -> Settings and enable Debug Mode for 24 hours at a time

That will break cache on page loads. It is _not_ recommended for production!

#### Cache Tags (BETA)

As of version 5.4.0, Proxy Cache Purge includes an **optional Cache Tags / Surrogate
Keys purge mode**. This feature is marked as **BETA** and is disabled by default.

When enabled, the plugin:

 * Adds cache-tag headers to WordPress responses (for example, tagging pages by 
   post ID, post type, taxonomy terms, author, and archives).
 * Uses tag-based purges instead of individual URL purges when content is updated,
   which can reduce purge traffic and improve consistency on complex sites.

Requirements:

 * A proxy cache that supports Cache Tags / Surrogate Keys and advertises this via
   standard `Surrogate-Capability` headers (for example, `Surrogate-Capability: 
   vhp="Surrogate/1.0 tags/1"`).

How to enable:

 * Go to **Proxy Cache  Settings  Purge Method** and check **“Use Cache Tags (Surrogate
   Keys)”**. The checkbox is only enabled when your cache tells WordPress it supports
   tags (or when you explicitly enable it via a define).
 * Alternatively, you can force-enable or force-disable detection via `wp-config.
   php`:
 * define( ‘VHP_VARNISH_TAGS’, true ); // Force treat cache as tag-capable
    define(‘
   VHP_VARNISH_TAGS’, false ); // Force treat cache as not tag-capable

Because this feature depends on your cache configuration, it is recommended that
you test it carefully in staging before enabling it on production.

#### Background Purging with WP-Cron

On busy sites, sending many PURGE requests directly from admin requests can slow
things down. When you define `DISABLE_WP_CRON` as `true` in `wp-config.php` (because
you are running a real system cron that calls `wp-cron.php`), Proxy Cache Purge 
automatically switches to an asynchronous mode:

 * Purge requests (both URL-based and tag-based, when Cache Tags are enabled) are
   collected into a small per-site queue.
 * The queue is processed by WP-Cron in the background, keeping your admin and content-
   editing actions responsive even when many URLs or tags must be invalidated.

Object-cache purges (the “Purge Database Cache” option) remain synchronous and are
not affected by this behaviour. The Proxy Cache settings page and Site Health integration
expose basic queue status so you can verify that background purging is healthy; 
if the queue appears large or very old, check that your system cron is correctly
invoking WordPress cron.

**Important: Cron Frequency and Cache Freshness**

When using background purging, the frequency of your system cron determines how 
quickly cache invalidations are processed. The longer the interval between cron 
runs, the longer visitors may see stale content after updates.

For minimal stale content, run your system cron every minute:

    ```
    * * * * * /usr/bin/php /var/www/html/wp-cron.php
    ```

If you can tolerate slightly longer delays, every 2-5 minutes is also acceptable.
However, running cron less frequently (e.g., every 15 minutes) means cache purges
may be delayed by that amount after content changes.

**Note:** Scheduled posts are handled specially. When a scheduled post is published
via WP-Cron, the cache is purged synchronously within the same cron run, ensuring
immediate cache invalidation without waiting for the next cron execution.

For detailed instructions on setting up a proper Linux-based WordPress cron, see:
[WordPress Cron Optimization](https://www.getpagespeed.com/web-apps/wordpress/wordpress-cron-optimization).

**Disabling Background Purging**

If you have `DISABLE_WP_CRON` defined but do not want background purging (for example,
on low-traffic sites where immediate purges are preferred), you can force-disable
cron-based purging by adding this to your `wp-config.php`:

    ```
    define( 'VHP_DISABLE_CRON_PURGING', true );
    ```

With this constant set, all cache purges will execute immediately during the request,
regardless of the `DISABLE_WP_CRON` setting.

### WP-CLI

**Purge**

Purge commands let you empty the cache.

 * `wp varnish purge` – Flush the entire site cache (equivalent to clicking “Empty
   Cache” in admin)
 * `wp varnish purge --all` – Explicitly flush the entire site cache
 * `wp varnish purge <url>` – Flush cache for a specific URL and all content below
   it (wildcard)
 * `wp varnish purge <url> --url-only` – Flush cache for only the exact URL specified(
   no wildcard)
 * `wp varnish purge --tag=<tag>` – Flush cache by tag (requires Cache Tags mode
   to be enabled)

Examples:

 * `wp varnish purge` – Purge entire site
 * `wp varnish purge --all` – Same as above, more explicit
 * `wp varnish purge https://example.com/hello-world/` – Purge this URL and everything
   below it
 * `wp varnish purge https://example.com/hello-world/ --url-only` – Purge only this
   exact URL
 * `wp varnish purge https://example.com/wp-content/themes/ --wildcard` – Purge 
   all theme files
 * `wp varnish purge --tag=p-123` – Purge all pages tagged with post ID 123
 * `wp varnish purge --tag=pt-post` – Purge all cached pages of post type “post”

**Debug**

Debugging can help you figure out why your cache isn’t working as well as it could.
The default is for your home page, but you can pass any URL on your domain.

 * `wp varnish debug [<url>]`

Available parameters:

 * `[--include-headers]` — Include headers in debug check output
 * `[--include-grep]` — Grep active theme and plugin directories for common issues

**DevMode**

Development mode allows you to disable the cache, temporarily.

 * `wp varnish devmode [<activate|deactivate|toggle>]` – Change development mode
   state

**Async purge queue (cron-mode)**

When you define `DISABLE_WP_CRON` as `true` and run a real system cron for WordPress,
Proxy Cache Purge can move heavy purge work into a small background queue that is
processed by WP‑Cron.

You can inspect and manage that queue via WP‑CLI:

 * `wp varnish queue status` – show whether cron-mode is active, if a full purge
   is queued, counts of queued URLs/tags, and the last queue run time.
 * `wp varnish queue process` – process any items currently in the queue (useful
   to run after deploys or cache‑sensitive operations).
 * `wp varnish queue clear` – clear the queue without sending any PURGE requests.

These commands do not replace your normal WordPress cron (you still need a cron 
entry that calls `wp cron event run --due-now` or hits `wp-cron.php`), but they 
give you a simple operational handle when using cron‑mode.

#### Understanding Purge Behavior

There are different types of cache purges, and they behave differently:

**Manual Purges (Admin Bar)**

 * **“Purge Cache (All Pages)”** – Sends a single regex purge request to invalidate
   the entire cache. Always executes immediately.
 * **“Purge Cache (this page)”** – Purges only the exact URL you’re viewing. Always
   executes immediately.

Manual purges are always immediate, even when background cron-mode is enabled. This
is intentional: when you click a button, you expect immediate results.

**Automatic Purges (Post Save/Update)**

When you save or update a post, the plugin automatically purges:

 * The post’s URL
 * The homepage
 * Category archive pages
 * Tag archive pages
 * Author archive page
 * Date-based archives
 * RSS feeds
 * Related REST API endpoints

This can be 20-50+ URLs depending on your site structure. When cron-mode is enabled,
these automatic purges are queued and processed in the background to avoid slowing
down the post editor.

**Key Difference**

 Action
 URLs Purged Uses Cron Queue?

 “Purge Cache (All Pages)”
 1 (regex) No – always immediate

 “Purge Cache (this page)”
 1 No – always immediate

 Post save/update
 20-50+ Yes (if cron-mode enabled)

If you need to immediately purge all URLs related to a specific post (not just the
post URL), save the post – the automatic purge will handle all related URLs.

## સ્ક્રીનશોટ

 * [[
 * Purge button on Right Now (Dashboard Admin)
 * [[
 * Toolbar menu (with cache enabled)
 * [[
 * Toolbar menu (with cache disabled)
 * [[
 * Scanner results
 * [[
 * Change Proxy IP address
 * [[
 * Activate Dev Mode
 * [[
 * Dev Mode Warning (24 hour notice)

## સ્થાપન

No special instructions apply.

If you have a 3rd party proxy service (such as Sucuri or Cloudflare) you will need
to add an IP address on the _Proxy Cache -> Settings_ page. Alternatively you can
add a define to your `wp-config.php` file: `define('VHP_VARNISH_IP','123.45.67.89');`

When using NGINX based proxies, your IP will likely be `localhost`.

#### Requirements

 * Pretty Permalinks enabled
 * A server based proxy cache service (such as Varnish or NGINX)

## એફએક્યુ (FAQ)

**Please report all issues in the [support forums](https://wordpress.org/support/plugin/varnish-http-purge)**

If you have code patches, [pull requests are welcome](https://github.com/dvershinin/varnish-http-purge).

### Don’t you work at DreamHost? Is this Official or DreamHost only?

This plugin was originally adopted and updated for DreamHost’s DreamPress server,
however it is not (and never has been) for DreamHost _only_.

I worked at DreamHost from 2012 to 2022, and have maintained the plugin since around
2014 or so.

As of October 2023, this plugin is _NO LONGER_ installed by default on DreamPress.

Today, the plugin is maintained by [GetPageSpeed](https://www.getpagespeed.com/),
with a focus on advanced NGINX and proxy caching deployments and strong compatibility
with the [NGINX cache-purge module](https://nginx-extras.getpagespeed.com/modules/cache-purge/)
from the [NGINX Extras](https://nginx-extras.getpagespeed.com/) collection.

### Is this plugin caching my data?

No. This plugin tells your cache system when content is updated, and to delete the
cached data at that time.

### Why doesn’t the plugin automatically delete the whole cache?

Speed and stability. Emptying too much of a cache on every change can slow a server
down. This plugin does its best to determine what needs to be deleted and when, 
while providing hooks for developers to use as necessary.

### How many cached files are deleted when a post is updated?

It depends on the post, but in general the tool will delete cached content for:

 1. The post name
 2. The front page of the site
 3. All first pages of related tags/categories
 4. The JSON API pages
 5. All related RSS feeds

### Is there a limit to how many pages I can purge at once?

Not really, but in order to prevent your site from crashing by running the same 
checks over and over, if you try to purge more than 50 URLs at once, the plugin 
will do a full purge. Normally this never happens, but there are some plugins that
hook into the options to add more pages to purge on an update.

You can change this value in your settings, or via the define VHP_VARNISH_MAXPOSTS
in your `wp-config.php` file.

Keep in mind, the count of 50 _does not_ include category/tags, API, or RSS pages.
It’s just the sheer number of individual posts/pages you’re trying to purge at once.

### Can I prevent purges for drafts or other post statuses?

Yes. If your environment doesn’t cache logged-in users and you want to avoid purge
noise from autosaves/drafts, you can exclude specific statuses network‑wide via `
wp-config.php` (multisite‑friendly).

Add a define to exclude drafts:

    ```
    define( 'VHP_EXCLUDED_POST_STATUSES', 'draft' );
    ```

Exclude multiple statuses (comma‑separated):

    ```
    define( 'VHP_EXCLUDED_POST_STATUSES', 'draft,pending' );
    ```

Or pass an array:

    ```
    define( 'VHP_EXCLUDED_POST_STATUSES', array( 'draft', 'pending' ) );
    ```

Developers can also use a filter to adjust the valid statuses programmatically:

    ```
    add_filter( 'varnish_http_purge_valid_post_statuses', function( $statuses, $post_id ) {
        return array_diff( $statuses, array( 'draft' ) );
    }, 10, 2 );
    ```

By default, the plugin considers these statuses for purge URL generation: `publish`,`
private`, `trash`, `pending`, `draft`.

### Can I delete the entire cache?

Yes. Click the ‘Empty Cache’ button on the “Right Now” Dashboard (see the screenshot
if you can’t find it). There’s also an “Empty Cache” button on the admin toolbar.

If you don’t see a button, then your account doesn’t have the appropriate permissions.
Only administrators can empty the entire cache. In the case of a subfolder multisite
network, only the _network_ admins can empty the cache for the primary site.

### Will the plugin delete my cache when I edit files on the server?

No. WordPress can’t detect those file changes so it can’t tell your cache what to
do. You will need to use the Empty Cache buttons when you’re done editing your code.

### Does every WordPress plugin and theme work with a proxy cache?

No. Some of them have behaviours that cause them not to cache, either by accident
or design. It’s incredibly hard to debug those, since many of the related issues
are contextual (like _if_ you save a page with a special setting). I’ve done my 
best to flag everything as possible issues with the debugger.

### I’m a developer, can I tell your cache to empty in my plugin/theme?

Yes. [Full documentation can be found on Custom Filters in the wiki](https://github.com/dvershinin/varnish-http-purge/wiki/Custom-Filters).

### Can I turn off caching?

Not permanently, and remember that this plugin is not actually caching your content.

You can use development mode to have WordPress attempt to tell your proxy service
not to serve cached content, but the content will still be cached by the service.

There are three ways to do this:

 1. Choose ‘Pause Cache (24hrs)’ from the Cache dropdown menu in your toolbar
 2. Go to Proxy Cache -> Settings and enable development mode
 3. Add `define( 'VHP_DEVMODE', true );` to your `wp-config.php` file.

The first two options will enable development mode for 24 hours. If you’re working
on long term development, you should use the define.

It is _not_ recommended you use development mode on production sites for extended
periods of time, as it _will_ slow your site down and lose all the benefits of caching
in the first place.

### Why is the restart cache button missing?

If you’ve disabled caching via the define, then you cannot restart cache via the
plugin. You would need to change `define( 'VHP_DEVMODE', true );` to `define( 'VHP_DEVMODE',
false );` in your `wp-config.php` file.

### Why don’t I have access to development mode?

Due to the damage this can cause a site, access is limited to admins only. In the
case of a multisite network, only _Network Admins_ can disable caching and they 
must do so via `wp-config.php` for security.

### Why do I still see cached content in development mode?

While development mode is on, your server will continue to cache content but the
plugin will tell WordPress not to use the cached content. That means files that 
exist outside of WordPress (like CSS or images) _may_ serve cached content.

The plugin does its best to add a No Cache parameter to javascript and CSS, however
if a theme or plugin _doesn’t_ use proper WordPress enqueues, then their cached 
content will be shown.

### Why can I still flush cache while in development mode?

Because the server is still caching content.

The plugin provides a way to flush the cache for those pages, as well as anything
not included in WordPress, for your convenience.

### How can I tell if everything’s caching?

From your WordPress Dashboard, go to _Proxy Cache > Check Caching_. There, a page
will auto-scan your front page and report back any issues found. This includes any
known problematic plugins. You can use it to scan any URL on your domain.

### Why is nothing caching when I use PageSpeed?

PageSpeed likes to put in Caching headers to say _not_ to cache. To fix this, you
need to put this in your `.htaccess` section for PageSpeed: `ModPagespeedModifyCachingHeaders
off`

If you’re using nginx, it’s `pagespeed ModifyCachingHeaders off;`

### Why aren’t my changes showing when I use CloudFlare or another proxy?

When you use CloudFlare or any other similar service, you’ve put a proxy in front
of the server’s proxy. In general this isn’t a bad thing, though it can introduce
some network latency (that means your site may run slower because it has to go through
multiple layers to get to the content). The problem arises when WordPress tries 
to send the purge request to your domain name and, with a proxy, that means the 
proxy service and not your website.

On single-site, you can edit this via the _Proxy Cache > Check Caching_ page. On
Multisite, you’ll need to add the following to your wp-config.php file: `define('
VHP_VARNISH_IP','123.45.67.89');`

Replace `123.45.67.89` with the IP of your _Proxy Cache Server_ (_not_ CloudFlare).**
DO NOT** put http in this define. If you’re on nginx, you’ll want to use `localhost`
instead of an IP address.

If you want to use WP-CLI, you can set an option in the database. This will not 
take precedence over the define, and exists for people who want to use automation
tools: `wp option update vhp_varnish_ip 123.45.67.89`

### Why are my posts timing out/not showing when I’m using CloudFlare?

This is usually related to CloudFlare’s APO setup.

I have an open ticket with CloudFlare trying to debug this, but basically whatever
they’re doing with APO doesn’t ‘like’ the flush command and times out (or crashes).

### Why do I get a 503 or 504 error on every post update?

Your IP address is incorrect. Check the IP of your server and then the setting for
your proxy cache IP. If they’re _not_ the same, that’s likely why.

### How do I find the right IP address?

Your proxy IP must be one of the IPs that the service is listening on. If you use
multiple IPs, or if you’ve customized your ACLs, you’ll need to pick one that doesn’t
conflict with your other settings.

For example, if you have a Varnish based cache and it’s listening on a public and
private IP, you’ll want to pick the private. On the other hand, if you told Varnish
to listen on 0.0.0.0 (i.e. “listen on every interface you can”) you would need to
check what IP you set your purge ACL to allow (commonly 127.0.0.1 aka localhost),
and use that (i.e. 127.0.0.1).

If your web host set up your service, check their documentation.

### What if I have multiple proxy cache IPs?

You may enter them, separated by a comma, on the settings page.

### What version of Varnish is supported?

So far this plugin has been reported to successfully function on Varnish v2 through
v6.5.

### Does this work with NGINX caching?

Yes. Set the cache backend to NGINX via the settings page (_Proxy Cache > Settings
> Cache Backend_) or add this to your wp-config.php:

    ```
    define( 'VHP_PURGE_BACKEND', 'nginx' );
    ```

When set to NGINX, the plugin uses a literal `*` wildcard instead of Varnish’s `.*`
regex pattern, which is what the NGINX cache-purge module expects. You should also
set your Proxy Cache IP to `localhost`.

### What should my cache rules be?

This is a question beyond the support of this plugin. I do not have the resources
available to offer any configuration help. Here are some basic gotchas to be aware
of:

 * To empty any cached data, the service will need to respect the PURGE command
 * Not all cache services set up PURGE by default
 * When flushing the whole cache with Varnish backend, the plugin sends a PURGE 
   command of `/.*` and sets the `X-Purge-Method` header to `regex`
 * When using NGINX backend, it sends `/*` instead (literal wildcard)
 * NGINX expects the IP address to be ‘localhost’

### How do I pass a Varnish control key or auth header?

Some providers require a control key, token, or Authorization header to accept PURGE
requests. You can set a header name and value via the settings page or via the following
constant:

    ```
    define( 'VHP_VARNISH_EXTRA_PURGE_HEADER', 'X-Control-Key: YOUR_CONTROL_KEY_HERE' );
    ```

Alternatively, you can inject any required header via a filter.

 1. Set where PURGE requests should be sent (host:port, no scheme):
 2. define( ‘VHP_VARNISH_IP’, ‘varnish.example.com:6081’ );
 3. Add your control key/auth header via a small MU plugin so it loads on every request.
    Create `wp-content/mu-plugins/varnish-purge-auth.php` with:
 4. <?php
     add_filter( ‘varnish_http_purge_headers’, function( $headers ) { // Example:
    provider expects a custom key header $headers[‘X-Control-Key’] = ‘YOUR_CONTROL_KEY_HERE’;
 5.     ```
        // Or use Authorization headers:
        // $headers['Authorization'] = 'Basic ' . base64_encode( 'username:password' );
        // $headers['Authorization'] = 'Bearer ' . 'YOUR_TOKEN_HERE';
    
        return $headers;
        ```
    
 6. } );

If your provider requires HTTPS for the purge endpoint, force the schema:

    ```
    add_filter( 'varnish_http_purge_schema', function() { return 'https://'; } );
    ```

Important: This plugin sends HTTP PURGE requests to your cache service. It does 
not use the Varnish management interface (varnishadm/secret on port 6082).

### How can I see what the plugin is sending to the cache service?

Yes _IF_ the service has an interface. Sadly NGINX does not. [Detailed directions can be found on the debugging section on GitHub](https://github.com/dvershinin/varnish-http-purge/wiki).
Bear in mind, these interfaces tend to be command-line only.

### Caching is detected but cannot be confirmed. What does that mean?

It means that somewhere your server’s headers aren’t returning the data the plugin
needs to see, in order to determine if the cache is working. The most common cause
is that your server isn’t returning the `X-Varnish` header or the `Age` header.

### I have renamed X-Varnish header for security reasons and Site Health Check says no cache service

You can use `varnish_http_purge_x_varnish_header_name` filter to customize this 
header name, like below to resolve this:

    ```
    function change_varnish_header( $default_header ) {
        return 'My-Custom-Header'; // Replace with the desired header
    }
    add_filter( 'varnish_http_purge_x_varnish_header_name', 'change_varnish_header' );
    ```

## સમીક્ષાઓ

![](https://secure.gravatar.com/avatar/b2331b01a5d353fa10b6484fb32e89bf9bc304dd453edf52d572d2801ea0e7eb?
s=60&d=retro&r=g)

### 󠀁[Finally!](https://wordpress.org/support/topic/finally-353/)󠁿

 [manuamaro](https://profiles.wordpress.org/manuamaro/) ફેબ્રુવારી 4, 2026

I had lot of problems with cache but this solved them! Thank you.

![](https://secure.gravatar.com/avatar/a31cd68e1c5de1a15c4a31dd99cc0e9eb0eb4f2aaedd3d3025a1e22d928b9a32?
s=60&d=retro&r=g)

### 󠀁[Simply Works](https://wordpress.org/support/topic/simply-works-287/)󠁿

 [Skrlance](https://profiles.wordpress.org/seanlance/) મે 1, 2025

The plugin simply works even for all types of cache servers. Only one things bothers
me about this plugin is its support for PHP 5.6+ where core itself doesn’t support
upto php 7.1 while WordPress recommends using PHP 7.4+. So, this plugin should be
compatible with PHP 7.4+. Using newer php code is good for security and performance
while deprecated codes might produce venerability!

![](https://secure.gravatar.com/avatar/40a391f97c70491b73623b7c26d68966a84f0d73ae133d93c7addb64c21f05ae?
s=60&d=retro&r=g)

### 󠀁[Age Header Missing](https://wordpress.org/support/topic/age-header-missing-2/)󠁿

 [bandsaw12](https://profiles.wordpress.org/bandsaw12/) સપ્ટેમ્બર 5, 2023 2 replies

Spent most of the day working on getting this working with a remote NGINX reverse
proxy. The plug-in keeps complaining about no age header in the response. Google
seems to suggest that etags and age headers no longer supported in dynamic content
with NGINX. Plug-in help is of no help on what header the plug in is expecting to
see in order to work. removed. Will have to keep deleting the cache the old manual
way.

![](https://secure.gravatar.com/avatar/035e2a5325882a7f0f1673fb066ce12e108b48d3477e37c082b10ca37c0fe0b2?
s=60&d=retro&r=g)

### 󠀁[Works Precisely As Advertised](https://wordpress.org/support/topic/works-precisely-as-advertised/)󠁿

 [random9q](https://profiles.wordpress.org/random9q/) એપ્રિલ 6, 2023

No complaints, it’s been working perfectly for years. Need it very, very seldom —
but when I do need it it works. When I don’t need it? It’s out of the way and doesn’t
advertise itself overmuch, like some of the other plugins I’ve used over time.

![](https://secure.gravatar.com/avatar/c3e57b88d4d5c059c954e38d5a7b7d8f0e256f478c8ba5b6ae3f2af4546cf4f0?
s=60&d=retro&r=g)

### 󠀁[ОТЛИЧНО, СПАСИБО ВАМ!](https://wordpress.org/support/topic/%d0%be%d1%82%d0%bb%d0%b8%d1%87%d0%bd%d0%be-%d1%81%d0%bf%d0%b0%d1%81%d0%b8%d0%b1%d0%be-%d0%b2%d0%b0%d0%bc/)󠁿

 [senatmedia](https://profiles.wordpress.org/senatmedia/) જાન્યુઆરી 22, 2023

ОТЛИЧНО, СПАСИБО ВАМ!

![](https://secure.gravatar.com/avatar/80c838b93c23e1188834951292bef5eabd69d9f171f22841d643b94cc7970430?
s=60&d=retro&r=g)

### 󠀁[Just saying thank you for this plugin](https://wordpress.org/support/topic/just-saying-thank-you-for-this-plugin/)󠁿

 [Dave Loodts](https://profiles.wordpress.org/davelo/) સપ્ટેમ્બર 1, 2022

Thanks for bringing out this plugin! Varnish can be quit “dogged” in it’s caching,
this plugin solves it very nicely. 1000% thanks!

 [ 26 સમીક્ષાઓ વાંચો ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/)

## ફાળો આપનાર & ડેવલપર્સ

આ ઓપન સોર્સ સોફ્ટવેર છે. નીચેના લોકો એ આ પ્લગિન માટે ફાળો આપ્યો છે.

ફાળો આપનારા

 *   [ Danila Vershinin ](https://profiles.wordpress.org/dvershinin/)
 *   [ Ipstenu (Mika Epstein) ](https://profiles.wordpress.org/ipstenu/)
 *   [ Mike Schroder ](https://profiles.wordpress.org/mikeschroder/)
 *   [ techpriester ](https://profiles.wordpress.org/techpriester/)
 *   [ Daniel Bachhuber ](https://profiles.wordpress.org/danielbachhuber/)

“Proxy Cache Purge” નું 6 ભાષામાં અનુવાદ કરવામાં આવ્યું છે. તેમના યોગદાન માટે [અનુવાદકો ](https://translate.wordpress.org/projects/wp-plugins/varnish-http-purge/contributors)
આપનો આભાર.

[“Proxy Cache Purge” ને તમારી ભાષામાં અનુવાદ કરો.](https://translate.wordpress.org/projects/wp-plugins/varnish-http-purge)

### વિકાસમાં રસ ધરાવો છો?

[કોડ બ્રાઉઝ કરો](https://plugins.trac.wordpress.org/browser/varnish-http-purge/),
જોવો[અસ્વીએન રેપોઝિટરીમાંથી](https://plugins.svn.wordpress.org/varnish-http-purge/),
અથવા સબ્સ્ક્રાઇબ કરો[ડેવલપમેન્ટ](https://plugins.trac.wordpress.org/log/varnish-http-purge/)
દ્વારા[આરઅસઅસ](https://plugins.trac.wordpress.org/log/varnish-http-purge/?limit=100&mode=stop_on_copy&format=rss).

## ચેન્જલૉગ

#### 5.8.1 (2026-03)

 * New: Regex purge URLs for category, tag, and blog listing pages to properly invalidate
   paginated archive pages (e.g., /category/news/page/2)

#### 5.7.0 (2026-02)

 * New: Detection of “Vary: Accept” header which causes severe cache fragmentation.
 * New: Contextual Cacheability Pro recommendations in cache diagnostics, post-purge
   messages, plugin action links, admin menu, E2E test results, and Site Health.

#### 5.6.4 (2026-01)

 * New: Added `VHP_DISABLE_CRON_PURGING` constant to force-disable background purging
   even when `DISABLE_WP_CRON` is enabled. Useful for low-traffic sites that use
   external cron but prefer immediate cache purges.

#### 5.6.3 (2026-01)

 * Fix: Manual cache purge actions now execute immediately regardless of WP-Cron
   mode. Previously, “Purge Cache All Pages” and “Purge This Page” were queued when
   DISABLE_WP_CRON was enabled.

#### 5.6.2 (2026-01)

 * Fix: Cacheability Pro recommendation moved to dismissable admin notice

#### 5.6.0 (2026-01)

 * New: Added recommendation for Cacheability Pro cache warming plugin on settings
   page.

#### 5.5.3 (2025-12)

 * New: End-to-End Cache Test in “Check Caching” admin page – a comprehensive 7-
   step test that verifies both caching AND purging work correctly, without relying
   on header detection heuristics.
 * Fix: Header Analysis tab now stays active after running a URL scan.
 * Fix: Removed duplicate introductory text in Header Analysis tab.

#### 5.5.2 (2025-12)

 * Fix: Removed development files from WordPress.org distribution.
 * Fix: Added concurrency control to CI workflows to prevent SVN deploy race conditions.

#### 5.5.1 (2025-12)

 * New: WP-CLI `--all` flag for explicit full site cache purge.
 * New: WP-CLI `--url-only` flag to purge exact URL without wildcard matching.
 * New: WP-CLI `--tag=<tag>` option for tag-based cache purging (requires Cache 
   Tags mode).
 * Doc: Fixed WP-CLI documentation – `wp varnish purge` correctly documented as 
   full site purge.
 * Doc: Fixed “WP CLI” typo to “WP-CLI”.
 * Dev: Added PHPCS/PHPStan linting infrastructure and GitHub Actions CI.
 * Dev: New pytest coverage for WP-CLI purge command variants.

#### 5.5.0 (2025-12)

 * Fix: Scheduled posts now properly purge cache when auto-published via WP-Cron.
   Previously, purges were queued but not processed until the next cron run, leaving
   stale content.
 * New: Added `transition_post_status` hook to handle future  publish transitions
   synchronously, ensuring immediate cache invalidation for scheduled posts.
 * New: Shortlink URLs (`?p=XXX`) are now purged when scheduled posts publish, clearing
   any cached 404 responses.
 * Doc: Added guidance on cron frequency for background purging mode – recommends
   every-minute cron for minimal stale content.
 * Dev: New pytest coverage for scheduled post publishing via WP-Cron.

#### 5.4.0 (2025-12)

 * New (BETA): Optional Cache Tags / Surrogate Key purge mode, controlled via the“
   Use Cache Tags” setting.
 * New (BETA): Tag-mode enablement based on standard Surrogate-Capability headers
   from surrogates (Edge Architecture spec) or the `VHP_VARNISH_TAGS` wp-config 
   define.
 * New: Admin UI improvements – properly associated labels for checkboxes and clearer
   explanatory copy.
 * Dev: Test VCL and pytest stack updated to cover tag-based purging behaviour.

#### 5.3.0 (2025-09)

 * New: `VHP_EXCLUDED_POST_STATUSES` define to exclude statuses (e.g. drafts) from
   purge triggers.
 * New: `varnish_http_purge_valid_post_statuses` filter to customize statuses programmatically.
 * Fix: REST URL generation for tags and custom taxonomies; respect `rest_base` 
   and use term IDs.
 * Fix: Avoid booleans in generated URL lists for REST entries.
 * Fix: Correct WP version check (pre-4.7 only) for deactivation logic.
 * Fix: Correct per-host IP loop in purge header filtering.
 * Fix: Properly strip query strings when deduplicating purge URLs.
 * Fix: Debugger `wp_remote_get` args and header checks (Via header scalar/array).
 * Polish: Typo fix in DevMode settings message.

#### 5.2.2 (2024-08)

 * Fix: Warning / Notices resolved.

#### 5.2.1 (2024-01)

 * New: Allow custom X-Varnish header name.

#### 5.2.0 (2023-07)

 * Fix: Debug if Via headers are an array.

## મેટા

 *  વર્ઝન **5.9.0**
 *  છેલ્લી અપડેટ: **2 અઠવાડિયા પહેલા**
 *  સક્રિય સ્થાપનો: **40,000+**
 *  વર્ડપ્રેસ વર્ઝન ** 5.0 અથવા ઉચ્ચતર **
 *  **6.9.4** સુધી પરીક્ષણ કર્યું
 *  PHP સંસ્કરણ ** 5.6 અથવા ઉચ્ચતર **
 *  ભાષા:
 * [Dutch](https://nl.wordpress.org/plugins/varnish-http-purge/), [English (Canada)](https://en-ca.wordpress.org/plugins/varnish-http-purge/),
   [English (UK)](https://en-gb.wordpress.org/plugins/varnish-http-purge/), [English (US)](https://wordpress.org/plugins/varnish-http-purge/),
   [French (France)](https://fr.wordpress.org/plugins/varnish-http-purge/), [Galician](https://gl.wordpress.org/plugins/varnish-http-purge/)
   અને [Russian](https://ru.wordpress.org/plugins/varnish-http-purge/).
 *  [તમારી ભાષામાં અનુવાદ કરો](https://translate.wordpress.org/projects/wp-plugins/varnish-http-purge)
 * ટૅગ્સ:
 * [cache](https://gu.wordpress.org/plugins/tags/cache/)[nginx](https://gu.wordpress.org/plugins/tags/nginx/)
   [proxy](https://gu.wordpress.org/plugins/tags/proxy/)[Purge](https://gu.wordpress.org/plugins/tags/purge/)
   [varnish](https://gu.wordpress.org/plugins/tags/varnish/)
 *  [વિગતવાર દૃશ્ય](https://gu.wordpress.org/plugins/varnish-http-purge/advanced/)

## પૉઇન્ટ્સ

 4.4 out of 5 stars.

 *  [  19 5-star reviews     ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/?filter=5)
 *  [  2 4-star reviews     ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/?filter=4)
 *  [  3 3-star reviews     ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/?filter=3)
 *  [  1 2-star review     ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/?filter=2)
 *  [  1 1-star review     ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/?filter=1)

[Your review](https://wordpress.org/support/plugin/varnish-http-purge/reviews/#new-post)

[બધા  સમીક્ષાઓ જુઓ](https://wordpress.org/support/plugin/varnish-http-purge/reviews/)

## ફાળો આપનારા

 *   [ Danila Vershinin ](https://profiles.wordpress.org/dvershinin/)
 *   [ Ipstenu (Mika Epstein) ](https://profiles.wordpress.org/ipstenu/)
 *   [ Mike Schroder ](https://profiles.wordpress.org/mikeschroder/)
 *   [ techpriester ](https://profiles.wordpress.org/techpriester/)
 *   [ Daniel Bachhuber ](https://profiles.wordpress.org/danielbachhuber/)

## સપોર્ટ

મુદ્દાઓનું છેલ્લા બે મહિનામાં નિવારણ:

     2 માંથી 2

 [આધાર ફોરમ જુઓ](https://wordpress.org/support/plugin/varnish-http-purge/)