Sakura Web Accelerator Problems on WordPress: Causes and Fixes

This article is a localized edition of the Japanese original. Read the Japanese original

Problems after introducing Sakura Web Accelerator (a CDN service from the Japanese hosting company Sakura Internet) to WordPress fall into a few types: "nothing is cached," "updates do not show up," "the redirect never stops," and "logged-in pages are visible to other people." This article explains the symptoms, how to check, and how to fix each one, in the order they are most likely to occur. Settings for reducing costs are covered in a separate article, so this one focuses on isolating problems.

Admin screen item names and supported features may be updated. The following assumes the general specifications as of October 2026, so check the official manual for the exact setting names.

Background: how Web Accelerator behaves

Web Accelerator is a type of CDN that decides whether to cache by looking at the response headers returned by the origin server (mainly Cache-Control and Expires). Rather than defining on the CDN side in detail things like "cache this extension for so many hours," the way the origin responds determines the result. So for many problems, looking at "what the origin is returning" gets you close to the cause.

When isolating a problem, compare the response through the CDN with the response directly from the origin. To reach the origin directly without changing DNS, it is convenient to specify the origin's IP with --resolve.

# Through the CDN
curl -sI https://www.example.com/

# Directly to the origin (203.0.113.10 is an example origin IP)
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/

Compare mainly four headers: Cache-Control, Set-Cookie, Location and Age. If Age is present and keeps increasing, you can tell the response is being served from the CDN cache.

Case 1: Caching hardly works

This is the case where page speed does not change after introduction, or the number of requests to the origin does not drop. Here are the causes, most common first.

1. The origin does not return Cache-Control: If the specification is that nothing is cached without the header, even static files are requested from the origin every time. In the web server configuration, add Cache-Control: public, max-age=... to images, CSS and JS.
2. Set-Cookie is present: A plugin that starts sessions, or an analytics mechanism, may be issuing a cookie on every page. Responses that issue cookies are hard to cache, so isolate which plugin is issuing it.
3. private or no-cache is present: A caching plugin or a server setting may be prohibiting caching unintentionally.

Check the above in the response directly from the origin, and after fixing, confirm that Age appears through the CDN.

Case 2: Updates to articles or CSS do not show up

Once caching starts working, the opposite problem appears: updates do not show up. If you give HTML a long max-age, it takes time for article corrections to reach users.

• CSS and JS: If you change the ?ver= version that WordPress outputs whenever you update, it is fetched as a new URL. For a child theme's CSS, using filemtime() as the version is an easy method.
• HTML: Use a shorter max-age, or operate by purging the cache at every publish or update. Web Accelerator has a cache purge feature (in the control panel and via an API), so either purge manually or set up a mechanism that calls the API from an update hook. Check the official documentation for the API specification and authentication method.

Case 3: A redirect loop occurs

If opening a page shows "The page isn't redirecting properly" (the browser's "redirected you too many times" message), the HTTPS detection is off. Even if the connection between the user and Web Accelerator is HTTPS, if the connection between Web Accelerator and the origin is HTTP, WordPress decides it was accessed over HTTP and redirects to HTTPS, and this repeats.

Checking and fixing

• Run curl -sI directly against the origin and check that Location does not point to the same URL
• If you can make the connection from Web Accelerator to the origin HTTPS, that is the simplest solution
• If you keep the setup that connects to the origin over HTTP, look at the forwarding headers the CDN adds (such as X-Forwarded-Proto; check the service specification for whether it is added) and set $_SERVER['HTTPS'] = 'on'; in wp-config.php. At the same time, restrict the source of access so the header cannot be forged through direct access to the origin

The HTTPS redirect in .htaccess or the server configuration may also be duplicated by a plugin's redirect (such as Really Simple Security), so consolidate on one of them.

Case 4: Logged-in pages or personal information are visible to other people

This is the most serious problem. Pages showing the admin bar, or pages containing a member's name, are cached and delivered to other visitors. As soon as you notice, give priority to purging the cache for the affected pages and temporarily stopping HTML from going through the CDN.

WordPress is implemented to send headers that suppress caching for logged-in requests, but if a caching plugin or the server configuration overwrites Cache-Control uniformly, this setting disappears.

• Check the Cache-Control directly from the origin in both the logged-in and logged-out states
• Check that the server configuration does not apply a uniform max-age to HTML
• For sites with a lot of per-person display, such as e-commerce or membership sites, consider a setup that serves only static files and keeps HTML off the CDN

Case 5: All access source IPs are the same, or security features misbehave

When you go through a CDN, the connection source as seen from the origin is the Web Accelerator server. As a result, problems like the following occur.

• The users' IPs are not recorded in analytics or logs
• A security plugin such as Wordfence, or the server's rate limiting, blocks the CDN's IP, and the whole site stops displaying
• Comment spam protection treats everyone as the same person

As a fix, configure the web server to trust the forwarding header that arrives from the CDN (Nginx's set_real_ip_from and real_ip_header, Apache's mod_remoteip and so on), and limit the trusted sources to the CDN's address ranges. Security plugins often also have a setting for choosing how to obtain the client IP, so check that too.

Case 6: A certificate error appears on a custom domain

In a setup that delivers on a custom domain, you need to set up a certificate on the Web Accelerator side.

• Check with dig +short www.example.com CNAME that the DNS CNAME points to the destination specified by Web Accelerator
• If you uploaded a certificate, check its expiry date and intermediate certificate with openssl s_client -connect www.example.com:443 -servername www.example.com -showcerts
• If you renew the certificate by hand, expiry is a typical cause, so watch the expiry date with an external monitoring service

Notes when working

Before changing settings, back up the server configuration files and WordPress. When switching DNS, shortening the TTL beforehand lets you roll back quickly if there is a problem.

Summary

• Web Accelerator follows the origin's response headers, so checking the response directly from the origin is the starting point for isolating problems
• The causes of caching not working are, in order of frequency, a missing Cache-Control, Set-Cookie, and a private directive
• A redirect loop is a protocol mismatch between the CDN and the origin. Fix it with an HTTPS connection or a forwarding header
• Stop an incident of logged-in pages being served as the top priority, and review how much HTML you put on the CDN
• Handling of the source IP and certificate expiry are also easy to overlook after introduction

• How to handle communication problems between a CDN and the origin
• Designing a cache strategy for the CDN and origin

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)