Wordpress LScache Plugin: 403 responses are being cached by LiteSpeed
Last Updated on: Wed, 15 Apr 2026 00:00:02 Hello, Report number: OOUCBYSW I am experiencing an issue with 403 responses being cached when I dont want them to be. This is happening across a wide range of sites with a variety of plugins and themes but the common factors are: LiteSpeed plugin is used for page caching WordFence plugin is used for dynamic access control (e.g to block spammers and hackers) CloudFlare is used for caching of static resources only ? no page caching In the LiteSpeed config the following settings have been set: 403 status code TTL is set to 0 Serve Stale is off Guest mode is off My issue appears to be the same as this issue that was raised two and half years ago. It can happen to any page that can be cached by LS and purging the 403 cache instantly fixes the problem. Naturally, this is an intermittent issue that only arises when an abusive visitor is blocked by WordFence and the subsequent 403 response is then cached by LS. This response then gets served indiscriminately to site visitors. However, to confirm that these 403s are being cached by LS, please see the following server response headers. I expected that setting 403 TTL to 0 would fix the issue, but it doesnt seem to have worked. Are there any other settings I may have missed or could this be a bug? Edit: the issue persists even when I circumvent CloudFlare by adding my server origin IP to my hosts file, so it is clearly not an issue with CF caching anything. This topic was modified 6 months ago by Ian Pegg. This topic was modified 6 months ago by Ian Pegg. Reason: Added further debug details The page I need help with: https://eggcupwebdesign.com/ I expected that setting 403 TTL to 0 would fix the issue, but it doesnt seem to have worked. Are there any other settings I may have missed or could this be a bug? I cannot quarantee that I am right, but this problems is the mother of all problems with status codes and other headers and is not a isolated problem of cache plugin. The question is when is the status code set in the number when headers are set? That means if Wordfence code is executed after cache plugin code, then cache plugin cant be notified backwards. This is more a problem of PHP than cache plugin and occurs in multiple situations. To solve it, the web server should do this job and not a PHP code, but for this LiteSpeed web server doesnt support Expressions like Apache does it. Read more about it: https://www.litespeedtech.com/support/forum/threads/how-to-prevent-error-pages-with-status-code-500-from-being-cached.20595/#post-119491 I already requested this feature, but LiteSpeed seems not to have much interests to implement it. please try make it 403 1 and purge all Thanks @CacheCrawler ? touch wood, this appears to have fixed the problem. I would like to understand why this has fixed the problem though. It seems counterintuitive to set 403 cache expiry to 1 second when what I actually want is for 403s to not be cached at all. Is this a bug or a feature? well , I am not exactly sure whether to classified it as bug or feature logically , for TTL in that section , 0 means no-cache , but that field probably wont accept 0 value , and you can not use other setting to cover this so my middle way is like to make it 1 , which is accepted value , and for 1 second, its also literally like no-cache Not a bug, but should be a feature. It makes no sense to cache pages that are !=200 I suspected that was your reasoning. What matters is that it appears to be working. If I were to enable Serve Stale then I can imagine that could cause the 403 response to be served even after 1 second has passed ? until the cache is rebuilt? Could be worth adding a note to the LiteSpeed docs or the in-product documentation that explains the above behaviour. Thanks for your help! no , serve stale doesnt work like that it only works when there are multiple requests to same page at exact same second , then first request will trigger cache regeneration , and rest will have stale , but after that second , all will have new cache generated/triggered by first user
LiteCache Rush: Speed comes from using less, not from doing it faster
Reference