さくらのウェブアクセラレータを WordPress に導入した後のトラブルは、「キャッシュされない」「更新が反映されない」「リダイレクトが止まらない」「ログイン状態の表示が他人に見える」など、いくつかの型に分けられます。この記事では、起きやすい順にそれぞれの症状、確認方法、直し方を説明します。費用を抑えるための設定は別記事で扱う内容なので、ここではトラブルの切り分けに絞ります。
管理画面の項目名や対応機能は更新されることがあります。以下は（2026年10月現在）の一般的な仕様を前提にしているため、細かな設定名は公式マニュアルで確認してください。
前提：ウェブアクセラレータの動き方
ウェブアクセラレータは、オリジンサーバーが返すレスポンスヘッダー（主に Cache-Control や Expires）を見てキャッシュするかどうかを決めるタイプの CDN です。CDN 側で「この拡張子は何時間キャッシュ」と細かく決めるのではなく、オリジンの返し方が結果を左右します。したがって、多くのトラブルは「オリジンが何を返しているか」を見れば原因に近づけます。
切り分けでは、CDN 経由とオリジン直の応答を比べます。オリジン直へは、DNS を変えずに --resolve でオリジンの IP を指定して確認すると便利です。
# CDN 経由
curl -sI https://www.example.com/
# オリジン直（203.0.113.10 はオリジンの IP の例）
curl -sI --resolve www.example.com:443:203.0.113.10 https://www.example.com/Cache-Control、Set-Cookie、Location、Age の4つを中心に見比べます。Age が付いて増えていけば、CDN のキャッシュから返っていると判断できます。
事例1：キャッシュがほとんど効かない
導入したのに表示速度が変わらない、オリジンのアクセス数が減らない、というケースです。原因として多い順に挙げます。
- **オリジンが
Cache-Controlを返していない**：ヘッダーがないとキャッシュされない仕様の場合、静的ファイルも毎回オリジンへ問い合わせます。Web サーバーの設定で、画像・CSS・JS にCache-Control: public, max-age=...を付けます。 - **
Set-Cookieが付いている**：セッションを開始するプラグインやアクセス解析の仕組みが、すべてのページで Cookie を発行していることがあります。Cookie を発行するレスポンスはキャッシュされにくいため、どのプラグインが発行しているかを切り分けます。 - **
privateやno-cacheが付いている**：キャッシュ系プラグインやサーバー側の設定で、意図せずキャッシュを禁止していることがあります。
オリジン直の応答で上記を確認し、修正後に CDN 経由で Age が付くかを確かめます。
事例2：記事やCSSを更新しても反映されない
キャッシュが効くようになると、今度は更新が反映されない問題が出ます。HTML に長い max-age を付けると、記事の修正が利用者に届くまで時間がかかります。
- CSS・JS：WordPress が出力する
?ver=のバージョンを更新時に変えれば、新しい URL として取得されます。子テーマの CSS はfilemtime()をバージョンに使う方法が手軽です。 - HTML：
max-ageを短めにするか、公開・更新のたびにキャッシュを削除する運用にします。ウェブアクセラレータにはキャッシュ削除の機能（コントロールパネルや API）があるので、手動で消すか、更新フックから API を呼ぶ仕組みを用意します。API の仕様と認証方法は公式ドキュメントを確認してください。
事例3：リダイレクトループになる
ページを開くと「リダイレクトが繰り返し行われました」と表示される場合、HTTPS の判定がずれています。利用者とウェブアクセラレータの間は HTTPS でも、ウェブアクセラレータとオリジンの間が HTTP だと、WordPress は HTTP でアクセスされたと判断して HTTPS へリダイレクトし、それが繰り返されます。
確認と対処
- オリジン直で
curl -sIを実行し、Locationが同じ URL を指していないか確認する - ウェブアクセラレータからオリジンへの接続を HTTPS にできるなら、それが最も単純な解決策
- オリジンへ HTTP で接続する構成のままにする場合は、CDN が付ける転送ヘッダー（
X-Forwarded-Protoなど。付与の有無はサービス仕様を確認）を見て、wp-config.phpで$_SERVER['HTTPS'] = 'on';を設定する。このとき、オリジンへの直接アクセスでヘッダーを偽装されないよう、アクセス元の制限もあわせて行う
.htaccess やサーバー設定の HTTPS リダイレクトと、プラグイン（Really Simple Security など）のリダイレクトが二重になっていることもあるので、どちらか一方に寄せます。
事例4：ログイン中の表示や個人情報が他の人に見える
最も深刻なトラブルです。管理バーが表示されたページや、会員の名前が入ったページがキャッシュされ、他の訪問者に配信される状態です。気づいた時点で、該当ページのキャッシュを削除し、HTML を CDN 経由にするのを一時的にやめることを優先してください。
WordPress はログイン中のリクエストに対してキャッシュを抑止するヘッダーを送る実装になっていますが、キャッシュ系プラグインやサーバー設定で Cache-Control を一律に上書きしていると、この指定が消えます。
- ログインした状態とログアウトした状態の両方で、オリジン直の
Cache-Controlを確認する - サーバー設定で HTML に一律の
max-ageを付けていないか確認する - EC や会員サイトなど個人ごとの表示が多いサイトは、HTML を CDN に載せず、静的ファイルだけを配信する構成を検討する
事例5：アクセス元IPがすべて同じになる・セキュリティ機能が誤作動する
CDN を経由すると、オリジンから見た接続元はウェブアクセラレータのサーバーになります。その結果、次のような問題が起きます。
- アクセス解析やログで、利用者の IP が記録されない
- Wordfence などのセキュリティプラグインや、サーバーのレート制限が CDN の IP を遮断し、サイト全体が表示されなくなる
- コメントスパム対策が、全員を同じ人物として扱う
対処として、Web サーバーで CDN から届く転送ヘッダーを信頼する設定（Nginx の set_real_ip_from と real_ip_header、Apache の mod_remoteip など）を入れ、信頼する送信元を CDN のアドレス範囲に限定します。セキュリティプラグイン側にも、クライアント IP の取得方法を選ぶ設定がある場合が多いので、あわせて確認します。
事例6：独自ドメインで証明書エラーが出る
独自ドメインで配信する構成では、ウェブアクセラレータ側に証明書を設定する必要があります。
- DNS の CNAME がウェブアクセラレータの指定先を向いているかを
dig +short www.example.com CNAMEで確認する - 証明書をアップロードした場合は、有効期限と中間証明書を
openssl s_client -connect www.example.com:443 -servername www.example.com -showcertsで確認する - 証明書の更新を手作業で行っている場合、期限切れが典型的な原因になるため、外部の監視サービスで期限を見張る
作業時の注意
設定を変える前に、サーバー設定ファイルと WordPress のバックアップを取ります。DNS を切り替える作業は、TTL を短くしておくと、問題があったときに早く戻せます。
まとめ
- ウェブアクセラレータはオリジンのレスポンスヘッダーに従うため、オリジン直の応答確認が切り分けの出発点
- キャッシュが効かない原因は、
Cache-Controlの欠如、Set-Cookie、private指定の順に多い - リダイレクトループは CDN とオリジン間のプロトコルのずれ。HTTPS 接続か転送ヘッダーで解決する
- ログイン中ページの配信事故は最優先で止め、HTML を載せる範囲を見直す
- 接続元 IP の扱いと証明書の期限も、導入後に見落としやすい点