分析中です…しばらくお待ちください

MIKIYA KUBO

ABOUT   WORK   BLOG   CONTACT   AI

こんにちは、投稿者のKuboです。本記事では、CloudflareのWAFとCDNをWordPressに適用して
表示速度の最大化と攻撃耐性の強化を同時に達成するための最新ベストプラクティスを、
実運用目線で丁寧に解説します。APO、Cache Rules、Turnstile、Bot対策、TLS設定、レート制限まで一気通貫で整理します。

1. Cloudflareを使う理由（WordPress運用の観点）

CloudflareはグローバルCDNとWAFを統合し、静的資産だけでなく設定次第でHTMLもエッジ配信できます。
結果としてTTFB短縮とオリジン負荷の削減を同時に実現し、マネージドルールやボット対策も一元化できます。
複数サービスを寄せ集める設計より管理が簡素になり、障害点の特定も容易になります。

APOはWordPress向けの加速機能で、HTMLを含めてエッジから配信します。広域で応答の一貫性が高まり、
体感速度が向上します。

2. 設計の前提：DNSプロキシとTLSモードの選定

CDNとWAFの恩恵を得るには、DNSレコードをプロキシ有効（オレンジ雲）にします。
暗号化はFull（strict）を基本とし、オリジンにも適切な証明書を配置してCloudflare—オリジン間のTLSを常時有効化します。

3. 速度最適化：APOとCache Rulesの正しい組み合わせ

APOはWordPressプラグインと連携し、公開HTMLを含むサイト全体をエッジ配信します。
現行のCloudflareでは、個別最適のPage Rules依存から脱却し、Cache Rulesで
「何を」「どれだけ」キャッシュするかを集中管理する設計が主流です。

3.1 APO導入の実務ポイント
  • Cloudflareプラグインを導入し、APIトークンを設定してAPOをオン。
  • テーマやSEOプラグインの出力するヘッダーに矛盾がないか確認。
  • 記事更新時の自動パージが機能しているかを実測で検証。
3.2 キャッシュ可否の可視化

配信状況はレスポンスヘッダーで確認します。

# HTMLがエッジ命中なら HIT / MISS などが返る
curl -I https://example.com/ | grep -i "^cf-cache-status\|^cf-ray\|^age"

3.3 Cache Rulesの基本パターン

動的ページを除外しつつ、公開HTMLは積極的にキャッシュします。以下はGUIでの設定に対応する考え方の例です。 

# 例：公開HTMLはキャッシュ、管理/ログイン/プレビューは除外
IF (http.request.method in {"GET" "HEAD"})
AND (http.request.uri.path matches "^/(?!wp-admin/|wp-login\.php|wp-json/).*$")
AND (not http.cookie contains "wordpress_logged_in")
THEN
  Cache: Eligible
  Edge TTL: Use cache-control header if present, default otherwise

4. 防御の要：WAFマネージド＋カスタムルール＆レート制限

まずはWAFマネージド・ルールセットを有効化し、wordpress関連のルールを含むスタックをオンにします。
新規脆弱性に追随しやすく、誤検知の改善も継続されます。

4.1 管理・ログイン面のカスタムルール例
# 管理とログインは許可IPのみ（他はManaged Challenge）
(http.request.uri.path contains "/wp-admin/" or http.request.uri.path contains "/wp-login.php")
and not ip.src in {203.0.113.10 198.51.100.2}
-> Managed Challenge
4.2 XML-RPCの悪用対策
# xmlrpc.php へのPOSTは原則ブロック（Jetpack等を使わない前提）
(http.request.uri.path eq "/xmlrpc.php" and http.request.method eq "POST")
-> Block
4.3 レート制限（Rulesets API想定）
{
  "description": "wp-login brute-force limit",
  "expression": "(http.request.uri.path contains \"/wp-login.php\" and http.request.method eq \"POST\")",
  "action": "block",
  "ratelimit": {
    "characteristics": ["ip.src"],
    "period": 60,
    "requests_per_period": 20,
    "mitigation_timeout": 600
  },
  "enabled": true
}

5. ボット対策：Bot Fight Mode／Super Bot Fight ModeとTurnstile

Bot Fight Modeは無償で有効化でき、既知の悪質ボットに対し演算チャレンジ等でコストを課します。
上位プランのSuper Bot Fight Modeでは制御粒度が上がり、分析も充実します。

Turnstileは従来のCAPTCHA代替で、WordPressのログインや問い合わせフォームに軽量に統合できます。

5.1 Turnstile最小実装例（手動設置）
<!-- head等に Turnstile スクリプト -->
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>

<!-- ログインフォーム内の適切な位置に設置 -->
<div class="cf-turnstile" data-sitekey="YOUR_SITE_KEY"></div>

<!-- サーバー側: トークン検証（疑似例） -->
POST https://challenges.cloudflare.com/turnstile/v0/siteverify
  secret=YOUR_SECRET_KEY
  response=<token from client>

6. 「絶対にキャッシュしない」領域の明確化（管理・ログイン・動的）

APOやCache Rulesを使っても、管理画面・ログイン・カート/チェックアウト・会員ページなどは
キャッシュ対象から除外するのが原則です。Cookieやパスで除外条件を管理します。 

# 代表例：Cache Rulesの考え方（GUI相当）
IF (
  http.request.uri.path contains "/wp-admin/" or
  http.request.uri.path contains "/wp-login.php" or
  http.request.uri.path starts_with "/cart" or
  http.request.uri.path starts_with "/checkout" or
  http.request.uri.path starts_with "/my-account" or
  http.cookie contains "wordpress_logged_in" or
  http.cookie contains "woocommerce_items_in_cart"
)
THEN Cache: Bypass

7. 運用と監視：ヘッダー確認・切り分け・落とし穴
7.1 配信確認の基本
# キャッシュ状態とエッジ通過を確認
curl -I https://example.com/ | sed -n 's/^\(cf-cache-status\|cf-ray\|age\|server\):.*/\1: &/ip'
7.2 よくある落とし穴
  • Page Rulesへの過度な依存：現行はCache Rules中心の設計が推奨です。
  • 古いRate Limiting APIのまま：最新のルール体系で再構成しましょう。
  • TLSモードの誤設定：Full（strict）未満は避けます。
  • APOと重複するキャッシュ指定：衝突を避け、無効化やTTLは一元管理します。

8. まとめ：速度・安全・可用性を同時に上げる配列

設計の順番は次の通りです。
① DNSプロキシ＋TLS Full（strict） →
② WAFマネージド有効化 →
③ 管理・ログインのカスタムルールとレート制限 →
④ APOで公開HTMLをエッジ配信 →
⑤ Cache Rulesで除外とTTL整備 →
⑥ Turnstile／Bot対策で入口の雑音を除去。
この配列なら、WordPressの体感速度と安全性を現行水準で底上げできます。

XでシェアFacebookでシェアThreadsでシェア