2026年6月20日
2026年6月20日
KeyCDN 導入後のトラブル事例と対処法(WordPress)
KeyCDN を WordPress に導入した直後に起きる不具合の多くは、「アイコンフォントが表示されない」「CSS の更新が反映されない」「独自ドメインで証明書エラーが出る」といった、原因がほぼ決まっているものです。この記事では、よくあるトラブルを起きやすい順に並べ、それぞれについて症状の見分け方、確認コマンド、直し方を説明します。読み終えるころには、CDN 側の問題かオリジン側の問題かを自分で切り分けられるようになります。
KeyCDN の管理画面の項目名や、WordPress 側で使う CDN Enabler プラグインの設定表記はバージョンによって変わることがあります。以下は(2026年10月現在)の一般的な構成を前提にしているため、画面の名称が違う場合は同じ目的の設定を探してください。
まず切り分けの基本:CDN経由とオリジン直の比較
どのトラブルでも、最初にやることは同じです。問題のファイルを CDN の URL とオリジンの URL の両方で取得し、応答ヘッダーを比べます。
# CDN 経由(Zone URL または独自ドメインの CDN ホスト名)
curl -sI https://cdn.example.com/wp-content/themes/mytheme/style.css
# オリジン直
curl -sI https://www.example.com/wp-content/themes/mytheme/style.css
CDN 経由の応答に、キャッシュ状態を示すヘッダー(KeyCDN では X-Cache などが付くのが一般的です)や Age があるかを見ます。オリジン直では正常なのに CDN 経由だけおかしいなら、CDN の設定かキャッシュの問題です。両方おかしいなら、WordPress かサーバー側を先に調べます。ブラウザでは開発者ツールの Console と Network タブを開き、赤いエラーの内容と、失敗しているリクエストの URL を控えておくと、以下のどの事例に当たるかがすぐ分かります。
事例1:アイコンフォントやWebフォントが表示されない
Font Awesome などのアイコンが四角い記号になったり、Webフォントだけが反映されなかったりする場合、ほとんどは CORS(クロスオリジン)の問題です。ブラウザの Console に「blocked by CORS policy」や「No 'Access-Control-Allow-Origin' header」といったメッセージが出ていれば、これに当たります。
フォントファイルは、ページと異なるホストから読み込むときに Access-Control-Allow-Origin ヘッダーが必要です。CDN のホスト名がサイトと違うため、導入した途端に発生します。
対処
- KeyCDN のゾーン設定にある CORS 関連の項目を有効にし、フォントに許可ヘッダーが付くようにする
- またはオリジンの Web サーバーでフォントファイルに
Access-Control-Allow-Originを付け、CDN がそのヘッダーを保持して配信するようにする - 設定後はゾーンをパージする。古い応答(ヘッダーなし)がキャッシュに残っていると直らないように見えます
curl -sI -H "Origin: https://www.example.com" https://cdn.example.com/…/font.woff2 を実行し、応答に Access-Control-Allow-Origin が含まれれば解決です。
事例2:CSSやJSを更新しても古いまま
テーマを編集したのに見た目が変わらない場合、CDN のキャッシュが古いファイルを返しています。WordPress は wp_enqueue_style() や wp_enqueue_script() で読み込むファイルに ?ver= を付けるため、バージョンを上げれば別の URL として扱われるはずです。それでも変わらないときは、ゾーン設定でクエリ文字列を無視する設定が有効になっていないか確認してください。有効だと ?ver=1.0 と ?ver=1.1 が同じキャッシュとして扱われます。
対処
- クエリ文字列を無視する設定を見直す(画像などで意図的に有効にしている場合は、CSS/JS の更新時にパージする運用にする)
- テーマ開発時は、
filemtime()でファイルの更新時刻をバージョンにすると、更新のたびに URL が変わる - 急ぎの場合は KeyCDN の管理画面から URL 単位またはゾーン全体をパージする
// 子テーマの functions.php:更新時刻をバージョンにして CDN キャッシュを避ける
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
);
} );
事例3:独自ドメイン(Zone Alias)で証明書エラーになる
cdn.example.com のような独自ドメインで配信しようとして、ブラウザに証明書エラーが出る事例です。原因はたいてい次のどれかです。
- DNS の CNAME が KeyCDN の Zone URL を向いていない:
dig +short cdn.example.com CNAMEで確認します。 - CNAME を設定する前に証明書の発行を試みた:無料証明書の発行は、ドメインが KeyCDN を向いていることを前提にしています。DNS の反映を待ってから再発行します。
- 独自証明書をアップロードしたが中間証明書が抜けている:
openssl s_client -connect cdn.example.com:443 -servername cdn.example.com -showcertsで、チェーンが揃っているかを確認します。
証明書が正しくなるまでは、CDN Enabler の配信先 URL を Zone URL(xxxx.kxcdn.com 形式)にしておくと、サイトの表示を止めずに済みます。
事例4:画像が404になる・一部だけ表示されない
CDN 経由の画像だけが 404 になる場合は、オリジンの指定と Host ヘッダーの扱いを疑います。
- オリジン URL の誤り:ゾーンに設定したオリジンが
https://www.example.comかhttps://example.comかで、リダイレクトやバーチャルホストの振り分けが変わります。オリジン直の URL で同じパスが 200 を返すか確認します。 - Host ヘッダーの転送設定:1台のサーバーで複数サイトを運用している場合、CDN からのリクエストの Host がどう渡るかで、別サイトのドキュメントルートに振り分けられることがあります。ゾーンの Host ヘッダー転送に関する設定を確認します。
- オリジン側のファイアウォールやセキュリティプラグイン:短時間に多くのリクエストが来るため、CDN のアクセスを攻撃と判定して遮断することがあります。オリジンのアクセスログやエラーログで 403 や 429 が出ていないか確認します。
事例5:管理画面やログインの表示が崩れる
管理画面の CSS が読み込めない、ブロックエディターが動かない、といった症状は、CDN Enabler の書き換え対象が広すぎる場合に起きます。プラグインには書き換えから除外する文字列を指定する設定があるので、.php や /wp-admin/ などが除外されているか確認してください。HTML まで CDN 経由で配信している場合は、ログイン Cookie(wordpress_logged_in_ で始まるもの)を持つリクエストをキャッシュしない構成になっているかも見直します。
事例6:混在コンテンツの警告が出る
ページは HTTPS なのに、画像が http:// の CDN URL で出力されていると、ブラウザが警告を出したり読み込みを止めたりします。CDN Enabler の配信先 URL が https:// で始まっているか、WordPress の「サイトアドレス」が HTTPS になっているかを確認します。投稿本文に直接書かれた古い URL は、プラグインの書き換え対象外になることがあるため、データベースの一括置換が必要な場合はバックアップを取ってから WP-CLI の wp search-replace を --dry-run 付きで試してください。
再発を防ぐ運用
- 設定変更はステージング環境や一部のファイルで試し、問題がなければ本番に広げる
- CSS/JS はバージョン付きで出力し、パージに頼らない更新の流れを作る
- トラブル時に戻せるよう、CDN Enabler を無効化すればオリジン配信に戻ることを把握しておく
まとめ
- 切り分けは「CDN 経由とオリジン直の応答ヘッダー比較」から始める
- フォントが出ないのは CORS、更新が反映されないのはクエリ文字列の扱いとキャッシュが典型的な原因
- 独自ドメインの証明書エラーは CNAME の向き先と発行の順序を確認する
- 404・管理画面の崩れ・混在コンテンツは、オリジン指定、書き換えの除外、URL の https 化を順に見る