I’m having difficulties making WP Super Cache work on my wordpress blog, because it’s behind an HTTP reverse-proxy (it works pretty well when accessed directly).
I found a workaround but I would like to really fix the issue.
The symptom is that the cache files are never refreshed. The admin interface of WP-super-cache reports 0 cached files, but they exist and are properly sent to the users. Asking to clear the cache in the admin interface has no effect : the cached files are still there and sent to the users.
There are 2 servers in my config :
– server1 is directly accessible from the Internet, with a public IP & hostname. This server1 handles SSL encryption, among many other things. It only hosts an Apache server, configured as a reverse-proxy for server2 (see https://httpd.apache.org/docs/2.2/en/mod/mod_proxy.html#proxypassreverse)
– server2 is where WordPress and WP-super-cache are installed, and where all the PHP is executed
When the cache is activated, I see that the cache files are stored (on server2) in a directory /wp-content/cache/supercache/server2/
It looks like some parts of the plugin code are looking for cache files in directory /wp-content/cache/supercache/server1/ , when they are in fact stored in /wp-content/cache/supercache/server2/.
The workaround I found is to create a symbolic link so that both directories lead to the same content :
ln -s /wp-content/cache/supercache/server2/ /wp-content/cache/supercache/server1/
I read paragraph 16 of the Troubleshooting FAQ : it might be the same reason. Maybe somewhere the hostname of server2 is used, and somewhere else the wordpress site_url is used.
Unfortunately, I cannot put the server1 hostname in /etc/hosts of server2…
Any ideas or hints to solve that in a cleaner way?
NB : Apache adds “X-Forwarded-*” HTTP headers to the requests sent to server2, so that server2 can know the real client IP, and the real public hostname of server1. See https://httpd.apache.org/docs/2.2/en/mod/mod_proxy.html#x-headers
- The topic ‘[Plugin: WP Super Cache] Cache not refreshed behind a reverse-proxy workaround’ is closed to new replies.