vampired

No it wasn’t, not sure why it is marked resolved but I kind of gave up.

I’m using Linode running:

nginx 1.2.7
php5-fpm 5.3.24-1
curl 7.21

Yes, I upgraded to 3.7 on all our sites.

No errors, everything “looks” like it is working fine. It just doesn’t purge. I’ve have yet to get purging working with anything except for SSH service varnish restart which has been a big pain but the only way I can manage to get a site updated when working on it.

If I use curl directly via SSH, I can purge as well using the syntax discussed earlier.

I replaced my config and used your config, just renamed wordpress.vcl to be default vcl and changed the IP.

Same issue, the button doesn’t clear anything, if I restart varnish, things refresh or using curl, but using the plugin doesn’t work. I added in the wp-config parameter as well. Still no dice.

I posted my config on pastebin in the comment above that.

Here it is:
https://pastebin.com/JcjgWRyE

I will look through yours in a few.

I’m not Varnish expert, but yes that’s my default.vcl. I used a published example that is commonly used by WordPress users.

Running the latest version of 3.x.

For some reason when I do it curl -X PURGE VarnishIP/URL -H HOST it doesn’t work, but when I do it as curl -X PURGE -H HOST VarnishIP/URL it works like a champ.

Curl -H Host VarnishIP/Url -X PURGE works as well.

I don’t have any special curl handlers, if you look at that serverfault post I posted my exact config there.

Is there anyway to see exactly what the plugin builds for a url? Can I hack a print statement in there somewhere to show me so I can see what it’s calling? I’m not a php/plugin dev type of person so I can’t make much sense of the plugin code.

Ok, I got somewhere!

I’m not sure what your plugin is doing, but I’m guessing it maybe backwards like we were initially doing.

While CloudFlare is active, if I issue the following command via SSH.

curl -X PURGE -H “Host:www.hostname.com” https://127.0.0.1/news

It gives me a purge 200 successful, it’s exactly what you said, but the -H “Host:” comes first, if I do https://127.0.0.1/news first, it gives me 404 not in cache.

So you have to issue the -H “Host: ” first, then specify the URL to purge with hostname being varnish IP instead.

In my case, it works with 127.0.0.1 or public IP as they both are authorized and varnish is on the same box.

I verified it a few times that it purges perfectly fine.

Right now both W3TC and your Varnish plugin are unable to purge Varnish when using CloudFlare.

I verified this multiple times and have been able to successfully purge individually pages via curl while CloudFlare is sitting in front of the host.

I removed the define parameter (while CloudFlare is still disabled for this test site).

I am pretty sure I want to be using 127.0.0.1, but either should work as they are both authorized and the same host.

I tried the last one you listed with both public and private IP and it says 404 not in cache. So some how the host part isn’t working.

Here is what I tried.

curl -X PURGE https://127.0.0.1/news -H “Host: https://www.hostname.com”

and

curl -X PURGE https://publicIPofVarnishandNGINX/news -H “Host: https://www.hostname.com”

I also tried Host: hostname.com instead of https://www.hostname.com.

Is there anyway to get the output of the purge request from the plugin, like some debug output or log to see what it’s actually requesting and what’s the response?

When I keep the configuration with CloudFlare disabled, curl -X PURGE https://www.hostname.com from the server’s SSH shell works. But the plugin will not purge. I tried it both with 127.0.0.1 and public IP. Which is likely the same reason when CloudFlare is enabled, because curl -X PURGE VarnishIP won’t actually purge any content (outside of content that is cached when visiting directly by IP; which never happens).

I posted that on ServerFault earlier.

I turned off CloudFlare and flushed DNS. I pinged https://www.hostname.com and verified it is indeed going directly to my server and not CloudFlare.

I then issues curl -X PURGE https://www.hostname.com and I got a 200 Purged confirmation.

So yes, without CloudFlare it works perfectly fine. I just can’t get it to stop sending it to CloudFlare, maybe the plugin is working fine and it does send it to IP, but that won’t actually purge the cache because ip/somepage is not the same cache as https://www.hostname.com/samepage.

Yes, if I do https://direct.hostname.com or https://iP but it only purges content that I visit those specific addresses (which no user would ever and no content actually exists.

In reality, no, I haven’t found a way to make it work. Because if I use the real hostname and url, it gets sent to CloudFlare, if I use IP/direct.hostname.com it goes to an address that isn’t being cached.

I can’t seem to find a way around this. I spent a lot of time trying to figure this out with W3 Total Cache getting a way that it can purge, and came across your plugin and couldn’t get that to work either.

I would love to have a way to get it to work as I can’t seem to find any.

Right, but if you purge somehostname/somepage it is not the same content as someip/somepage. Varnish sees it as different.

Most so, when the IP is used by 10 different sites, someip/somepage may be the same for multiple sites.

When I issue a purge for someip, it says content not cache, if I visit the site via just an IP, then do a purge it will give me a purge successful message, but if I visit via hostname, then go and try to purge by IP, it will still say no content cached.

IP is not the same as virtual hosts, so purging one doesn’t purge the other and as far as varnish sees (at least in my configuration) they are completely different.

If I use direct.hostname.com it will “successfully issue a purge command to my varnish rather than cloudflare” but it will do nothing as there is no content being served from direct.hostname.com.

Using IP is the same issue, it will try to purge content at that IP, which would be all sites hosted on that IP, but no content is served from IP, but in fact served from hostnames, so that wouldn’t work either.

Varnish and nginx are on the same box as I mentioned earlier.

Varnish is running at port 80 and forwarding to nginx on port 8080.