That’s a weird one. Does it happen for anonymous users and known users? (if a visitor has a cookie or not for your site)
The first thing I’d do is look at the cached files for your front page. Look in the meta-wp-cache-X.php file for each cached page and make sure you see a “Cache-Control” definition in there. That is for “known users”.
For anonymous users, that header is sent around line 267 of wp-cache-phase2.php. Look in there and use an error_log so you can figure out if it’s sending the header properly.
There’s no reason why the front page is handled differently. Very odd.
Hey Donncha … thx 4 your replay 🙂
It was a sleepless night. But we found the issue.
The issue were in the NGINX configuration in these lines:
location ~ / {
try_files /wp-content/cache/supercache/$http_host$cache_uri/index-https.html $uri $uri/ /index.php;
}
We serve all files over https, so we change for a long time the directive from:
try_files /wp-content/cache/supercache/$http_host$cache_uri/index.html $uri $uri/ /index.php;
to:
try_files /wp-content/cache/supercache/$http_host$cache_uri/index-https.html $uri $uri/ /index.php;
because “https” … all works fine but only on the front page (not logged in user) we’re missing a lot of header instructions (Cache-Control,Content-Encoding,Vary,Content-Security-Policy … ) … it was weird.
We change the directive back to:
try_files /wp-content/cache/supercache/$http_host$cache_uri/index.html $uri $uri/ /index.php;
and it works … we don’t know why???
Strange is: all .html cache files on our server are still: index-https.html files and not index.html files.
Maybe you can reproduce this issue.
I suspect your site is falling back to PHP serving the pages of your site. Enable the debug log and see what PHP executes when you view a cached page as an anonymous user with no cookies. If the pages are served by Nginx there shouldn’t be any logs for a cache page.
I don’t use Nginx, so I can’t help debug those rules, unfortunately.
