WordPress の前に AWS CloudFront を置いたあとに起きるトラブルは、ほとんどが「ビヘイビア（パスごとの配信ルール）の設定不足」「オリジンへ渡すヘッダー・Cookie・クエリ文字列の不足」「AWS WAF のマネージドルールの誤検知」のどれかです。この記事では、導入後によくある事例を起こりやすい順に並べ、症状からの見分け方、確認方法、直し方を説明します。
CloudFront と AWS WAF のコンソール表記や既定値は更新されることがあるため、ここでは設定の目的と考え方を中心に説明します（2026年10月現在）。本番のディストリビューションを変更する前に、現在の設定を aws cloudfront get-distribution-config などで保存しておくか、ステージング用のディストリビューションで試してください。
切り分けの基本: どこで止まっているかを見る
まず、レスポンスが CloudFront のキャッシュから返っているか、オリジンから返っているか、CloudFront 自身がエラーを返しているかを確認します。
curl -sI https://www.example.com/ | grep -iE "^(x-cache|x-amz-cf-pop|x-amz-cf-id|location|server)"x-cache が Hit from cloudfront ならキャッシュ、Miss from cloudfront ならオリジンから取得しています。Error from cloudfront の場合は、CloudFront か WAF、またはオリジンがエラーを返しています。オリジンのアクセスログに該当リクエストが残っているかを見れば、CloudFront の手前で止まったのか、オリジンまで届いたのかが分かります。
事例1: ログイン後の画面や管理バーがキャッシュされる
ログインした人の画面が他の人に見える、管理画面が古い内容のまま、という事例です。デフォルトのビヘイビア1つだけでサイト全体をキャッシュしていると起きます。
直し方は、パスごとにビヘイビアを分けることです。
/wp-admin/*、/wp-login.php、/wp-json/*、プレビュー: キャッシュを無効にするキャッシュポリシー（マネージドポリシーの CachingDisabled など）と、ヘッダー・Cookie・クエリ文字列をすべて渡すオリジンリクエストポリシーを割り当てる。/wp-content/*、/wp-includes/*の静的ファイル: 長めにキャッシュするポリシーを割り当てる。- それ以外（記事ページ）:
wordpress_logged_in_で始まるCookieなどを考慮したキャッシュ設定にするか、キャッシュ時間を短くする。
WooCommerce を使っている場合は、カート・チェックアウト・マイアカウントもキャッシュしないビヘイビアに含めます。設定後はキャッシュの無効化（インバリデーション）を実行して、古いキャッシュを消してから確認します。
事例2: 投稿の保存やフォーム送信で403になる
ブロックエディターで保存できない、問い合わせフォームが送れない、という事例です。原因は大きく2つあります。
1つ目は、ビヘイビアの許可するHTTPメソッドが GET と HEAD だけになっていることです。この場合、POST は CloudFront が403で拒否します。管理画面やフォーム送信先のビヘイビアでは、POST を含むすべてのメソッドを許可します。
2つ目は AWS WAF の誤検知で、次の事例で詳しく説明します。x-cache: Error from cloudfront と403の組み合わせで、オリジンのログにリクエストが無ければ、どちらかが原因です。
事例3: AWS WAF のマネージドルールが正常な操作をブロックする
CloudFront に AWS WAF のWeb ACLを関連付け、コアルールセット（AWSManagedRulesCommonRuleSet）などのマネージドルールを有効にすると、WordPress の正当な操作がブロックされることがあります。よくあるのは次のパターンです。
- 長い記事を保存すると、リクエストボディのサイズを制限するルールに反応する。
- 投稿本文に含まれるHTMLやスクリプトタグが、クロスサイトスクリプティング対策のルールに反応する。
- 管理画面の一部の操作が、PHP 向けや WordPress 向けのルールセットに反応する。
確認には、Web ACLのサンプルリクエスト、またはWAFログ（CloudWatch Logs や S3 に出力）を使います。ブロックされたリクエストのURIと、terminatingRuleId などのどのルールが止めたかを示す項目を確認してください。
直し方の基本は、WAF全体を外すのではなく、反応したルールだけを調整することです。
- 該当ルールのアクションを、ルールグループ内で一時的にカウント（記録のみ）に上書きする。
- マネージドルールが付けるラベルと、パス（
/wp-admin/や/wp-json/）の条件を組み合わせた独自ルールを作り、それ以外のパスでは引き続きブロックする。 - 管理画面へのアクセスを社内IPなどに限定できるなら、IPセットでの許可と組み合わせて除外範囲を狭める。
CloudFront 用のWeb ACLは、米国東部（バージニア北部）リージョンで作成します。別リージョンで作ったWeb ACLは CloudFront に関連付けられません。また、CloudFront で検査するリクエストボディのサイズには上限があり、上限を超えた部分の扱いも設定で選べます（2026年10月現在）。
事例4: WordPress のURLがオリジンのホスト名に転送される
https://www.example.com/ を開くと、ALB やEC2のホスト名へ転送されてしまう事例です。CloudFront がオリジンへ送る Host ヘッダーがオリジンのドメイン名になっているため、WordPress が「サイトURLと違うホストで来た」と判断して転送しています。
直し方は、Host ヘッダーを含めてビューワーのヘッダーをオリジンへ渡すオリジンリクエストポリシー（マネージドポリシーの AllViewer など）を使うことです。この場合、オリジン側（ALBなど）の証明書に www.example.com が含まれている必要があります。
事例5: HTTPSにならない・リダイレクトが繰り返される
オリジンプロトコルポリシーを「HTTPのみ」にしていると、WordPress はHTTPでアクセスされたと認識し、HTTPSへ転送します。CloudFront のビューワー側でもHTTPSへ転送していると、往復が終わりません。
オリジンとの通信もHTTPSにするのが基本です。オリジンをHTTPのまま運用する場合は、オリジンリクエストポリシーで CloudFront-Forwarded-Proto ヘッダーを渡し、wp-config.php の require_once ABSPATH . 'wp-settings.php'; より上で判定します。
if ( isset( $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] ) && 'https' === $_SERVER['HTTP_CLOUDFRONT_FORWARDED_PROTO'] ) {
$_SERVER['HTTPS'] = 'on';
}このヘッダーはオリジンへ直接アクセスされると偽装できるため、後述のオリジン保護と組み合わせてください。
事例6: プレビューや検索、ページ送りが動かない
?s=（検索）、?p=、?preview=true などのクエリ文字列がオリジンへ渡っていないと、検索結果が常にトップページになる、プレビューが表示されない、といった症状になります。記事ページのビヘイビアでクエリ文字列をキャッシュキーに含めるか、オリジンへ渡す設定にします。
事例7: ログイン試行制限やコメントのIPがおかしい
オリジンから見た接続元は CloudFront のIPになります。本来の訪問者IPは X-Forwarded-For の先頭に入るほか、オリジンリクエストポリシーで CloudFront-Viewer-Address ヘッダーを追加できます。ログイン試行制限プラグインやセキュリティプラグインで、どのヘッダーからIPを取るかを設定してください。設定を誤ると、全員が同じIP扱いになってログインできなくなることがあります。
事例8: 504エラーやタイムアウト
重いインポート処理やバックアップを管理画面から実行すると、オリジンの応答がオリジン応答タイムアウトを超えて504になることがあります。タイムアウト値は調整できますが、上限があります。長時間の処理は WP-CLI でサーバー上から実行し、CloudFront を経由させない方が安全です。
オリジンを CloudFront 経由だけに制限する
CloudFront を導入しても、オリジンに直接アクセスできるとキャッシュやWAFを迂回されます。ALBやEC2のセキュリティグループで、AWS が提供する CloudFront のオリジン向けマネージドプレフィックスリスト（com.amazonaws.global.cloudfront.origin-facing）からの通信だけを許可すると、直接アクセスを防げます。さらに CloudFront からオリジンへ独自のカスタムヘッダーを付け、ALBのリスナールールでそのヘッダーがあるリクエストだけを通す方法もあります。値は推測されにくいものにし、定期的に変更してください。
まとめ
x-cacheヘッダーとオリジンのログで、キャッシュ・CloudFront・WAF・オリジンのどこで止まったかを切り分ける。- 管理画面・ログイン・REST API・カートは、キャッシュ無効かつ全メソッド許可のビヘイビアに分ける。
- WAFの誤検知はサンプルリクエストやログで反応したルールを特定し、そのルールだけをカウントにしてパス条件で除外する。Web ACLは米国東部で作成する。
- Host ヘッダーとプロトコルの扱いを揃え、リダイレクトの往復を防ぐ。クエリ文字列と訪問者IPのヘッダーも渡す。
- マネージドプレフィックスリストとカスタムヘッダーで、オリジンへの直接アクセスを制限する。