2026年9月21日

BunnyCDN（bunny.net）導入後によくあるトラブル事例と原因別の直し方

ネットワーク・接続

BunnyCDN（現在のサービス名は bunny.net）を WordPress に導入した直後に起きやすいのは、「更新が反映されない」「ログイン中の画面がほかの人に見える」「フォントや画像が読み込まれない」「オリジンが CDN を遮断してしまう」といった、キャッシュとヘッダーにまつわる問題です。この記事では事例ごとに、症状の見分け方、確かめ方、直し方を順に説明します。

bunny.net の管理画面の項目名や、WAF にあたる Bunny Shield などの提供範囲・有料機能の区分は変わることがあります。ここでは（2026年10月現在）の一般的な構成を前提に、設定は「何のための設定か」で説明します。正確な名称は公式ドキュメントで確認してください。

まず CDN を通っているかを確かめる

どの事例でも最初にやることは同じで、問題のリクエストが CDN を経由しているか、キャッシュから返っているかを確認します。

# Pull Zone のホスト名（xxx.b-cdn.net）や独自 CDN ドメインで確認
curl -sI https://cdn.example.com/wp-content/themes/your-theme/style.css

bunny.net 経由の応答には、Server ヘッダーに BunnyCDN を示す値や、キャッシュの当否を示すヘッダー（CDN-Cache: HIT / MISS など）が付きます。ヘッダー名は変わる可能性があるため、出力の中から CDN 名やキャッシュに関する行を探すつもりで見てください。同じ URL を2回取得して HIT に変わるなら、キャッシュは動いています。

事例1：CSS や画像を更新しても反映されない

最も多い相談です。CDN は一度取得したファイルを有効期限まで配信し続けるため、オリジン側で上書きしても古いものが返ります。

確認方法は、上の curl -sI で Last-Modified や Age を見ることです。古い日時や大きな Age が返っていればキャッシュが原因です。

直し方は2段階あります。

当面の対処：管理画面からキャッシュを削除（Purge）します。URL 単位とゾーン全体の削除があり、まずは該当 URL だけ削除するほうが、オリジンへの負荷が一度に集中しません
再発防止：テーマの CSS・JS をバージョン付きで読み込みます。wp_enqueue_style() の第4引数にファイルの更新時刻を渡せば、更新のたびに URL が変わります

// 子テーマの functions.php
add_action( 'wp_enqueue_scripts', function () {
    $path = get_stylesheet_directory() . '/style.css';
    wp_enqueue_style(
        'child-style',
        get_stylesheet_uri(),
        array(),
        file_exists( $path ) ? filemtime( $path ) : null
    );
} );

この方法はクエリ文字列（?ver=）でキャッシュを分けるので、Pull Zone 側でクエリ文字列をキャッシュキーに含める設定になっているかも確認します。クエリを無視する設定だと、URL が変わっても同じキャッシュが返ります。

事例2：ログイン中の画面やカートの中身が他人に見える

サイト全体を CDN に載せた（HTML まで CDN 経由にした）場合に起こる、優先度の高いトラブルです。管理バーが表示された HTML や、WooCommerce のカート・マイアカウントページがキャッシュされると、別の訪問者にその内容が配信されることがあります。

原因の多くは、オリジンの Cache-Control を無視して HTML を長くキャッシュする設定になっていることです。確認と対処は次のとおりです。

問題のページを curl -sI で取得し、Cache-Control と CDN のキャッシュヘッダーを確認する
HTML までキャッシュするなら、オリジンのキャッシュ指示に従う設定を基本にする
wordpress_logged_in_ で始まる Cookie や WooCommerce のカート関連 Cookie を持つリクエストはキャッシュしないルールを入れる
/wp-admin/、/wp-login.php、カート・チェックアウト・マイアカウントのパスはキャッシュ対象から外す

切り分けがつくまでは、静的ファイル（/wp-content/ と /wp-includes/ 配下）だけを CDN に載せる構成に戻すのが安全です。HTML のキャッシュは、ページキャッシュプラグインとの二重キャッシュによる不整合も起こしやすいため、効果と運用負荷を比べて判断してください。

事例3：Web フォントやアイコンが表示されない（CORS）

CDN のドメインがサイトのドメインと異なると、ブラウザは Web フォントを別オリジンのリソースとして扱います。オリジンや CDN の応答に Access-Control-Allow-Origin が無いと、フォントが読み込まれずアイコンが四角形になります。

ブラウザの開発者ツールのコンソールに CORS のエラーが出ていれば、この事例です。対処は、オリジン側でフォントファイルにヘッダーを付けるか、bunny.net 側の CORS ヘッダーを付与する設定（拡張子を指定する形式）を有効にすることです。Nginx なら次のように書けます。

location ~* \.(woff2?|ttf|otf|eot)$ {
    add_header Access-Control-Allow-Origin "https://example.com";
    expires 30d;
}

ヘッダーを付けた後も、古いキャッシュはヘッダー無しのまま残っているため、フォントファイルのキャッシュ削除が必要です。

事例4：画像が 403 になる、オリジンが遮断する

CDN 経由のアクセスはすべて bunny.net のエッジサーバーの IP からオリジンに届きます。そのため、オリジン側の WAF、Wordfence などのセキュリティプラグイン、fail2ban のレート制限が「同じ IP から大量のアクセス」と判断して遮断することがあります。

オリジンのアクセスログで、403 を返している相手の IP を確認してください。bunny.net はエッジサーバーの IP 一覧を公開しているので、それと照合できます。対処は、エッジの IP を許可リストに入れることと、本来の訪問者 IP を X-Forwarded-For などのヘッダーから正しく取得できるようにすることです。後者を設定しないと、セキュリティプラグインのログやコメントスパム対策がすべて CDN の IP を基準に動いてしまいます。ヘッダーを信頼するのは、エッジの IP から来たリクエストに限定してください。

逆に、CDN 側の WAF やホットリンク保護、トークン認証を有効にしたことで正規のアクセスが 403 になることもあります。この場合は設定を一時的に緩めて再現するかを確認し、原因の設定を特定してから戻します。

事例5：独自 CDN ドメインで証明書エラーが出る

cdn.example.com のような独自ドメインを Pull Zone に割り当てたのに HTTPS でエラーになる場合は、DNS の CNAME が Pull Zone のホスト名を向いているか、bunny.net 側で無料証明書の発行が完了しているかを確認します。

dig +short CNAME cdn.example.com
openssl s_client -connect cdn.example.com:443 -servername cdn.example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -dates

CNAME を設定する前に証明書を要求すると発行に失敗するため、DNS の反映を確認してから再要求します。CAA レコードを使っている場合は、bunny.net が使う認証局が許可されているかも確認対象です。

導入時に気をつけたいこと

WordPress から URL を書き換えるには、bunny.net 公式の WordPress プラグインや、WP Rocket などキャッシュプラグインの CDN 設定が使えます。どれを使う場合も、作業前にバックアップを取り、ステージング環境で表示・ログイン・決済の流れを一通り確かめてから本番に適用してください。問題が起きたときに CDN を外せるよう、URL 書き換えを無効にする手順を事前に把握しておくと、復旧が早くなります。

まとめ

最初に curl -sI で CDN 経由か、キャッシュから返っているかを確認する
更新が反映されないときは Purge で当面対処し、ファイル更新時刻を使ったバージョン付けで再発を防ぐ
HTML をキャッシュするならログイン Cookie とカート・管理画面を除外し、迷ったら静的ファイルだけに戻す
フォントの CORS、オリジンによる CDN の遮断、独自ドメインの証明書は、それぞれヘッダー・ログ・DNS で原因を確かめる