SiteOps
トップメディアダッシュボード更新履歴
記事一覧

Cloudflare WAFでStripe webhookが届かないとき、最初の30分でやること

Stripe webhookが届かない/再試行が続くときに、Cloudflare側のブロックとStripe側の失敗理由を最短で切り分けて復旧する手順です。

著者: 川原更新: 2026-05-15収益改善RSS
Xで共有FacebookLinkedIn
料金相談

Cloudflare WAFでStripe webhookが届かないとき、最初の30分でやることは、まず「Stripe側で“送っている”のか」「Cloudflareで“弾いている”のか」「アプリ側で“受けて落としている”のか」を切り分けることです。Webhookは“外から必ず叩かれる入口”なので、ここが詰まると売上・提供・請求が連鎖で止まります。

最初に結論

  • まずStripe DashboardのWebhookログで、イベントが発生しているか／どのEndpointに送っているか／最新レスポンス(HTTPステータス) を確認します。
  • 失敗が 403 / 401 / 1020（Cloudflare系）/ block に寄っているなら、最優先は CloudflareのSecurity Events（Firewall/WAF）で該当リクエストを探すことです。
  • 次にアプリ側で、受信URL（ルーティング）/署名検証/レスポンス(2xxを速く返す) の3点が壊れていないかを確認します。
  • 最後に直近の変更（Cloudflareルール/デプロイ/環境変数/ルーティング/ドメイン）を“時刻で”当てます。

最初の30分でやること

1) 症状を固定する（Stripe Dashboard）

  • どのイベントが失敗しているか（例: checkout.session.completed / invoice.paid など）
  • いつから失敗しているか（直近のデプロイ時刻と照合）
  • エラーの型（配信できない/タイムアウト/4xx/5xx/署名検証失敗 等）
  • どのEndpoint（本番/ステージング/古いURL）に送っているか
  • 直近のレスポンスのステータスが何か（特に 403/401/1020/429/5xx）

2) “Stripeは送れているか”を確認する（ログの見方）

  • 送信自体がない → そもそもイベントが起きてない（決済フロー/テスト環境/モード違い）可能性
  • 送信していて 4xx → アプリが拒否している（署名検証/ルーティング/メソッド/ボディ処理）
  • 送信していて 5xx → アプリが落ちている（例外/DB/外部API）
  • タイムアウト → 受信処理が遅い（同期処理しすぎ/リトライ設計不足）

3) Cloudflare側で弾いていないか確認する（Security Events）

  • Cloudflareの Security Events / Firewall events で、Webhookの パス（例: /api/stripe/webhook）をキーに該当ログを探す
  • アクションが block / managed challenge / JS challenge / rate limit になっていないか確認する
  • 原因ルール（Managed WAF / Custom rules / Bot Fight Mode / Rate limiting / Geo制限 など）を特定する

復旧の最短手は、IP allowlist ではなく 「Webhookのパスにだけセキュリティを適用しない（skip/bypass）」 を作ることです（Stripe側の送信元は変動し得るため）。

4) 受信URL（ルーティング）を確認する

  • WebhookのURLが“今の本番URL”か（www有無/サブドメ/パス）
  • 直近の移行でパスが変わってないか（例: /api/webhook/stripe → /api/stripe/webhook など）
  • ルーティングがミドルウェアで弾かれていないか（認証/CSRF/リダイレクト）

5) 署名検証（Signing secret）を確認する

  • 本番EndpointのSigning secretと、アプリの環境変数が一致しているか
  • テスト/本番モードを取り違えていないか
  • 生のリクエストボディを改変していないか（検証前にJSONパースしている等）

6) “2xxで速く返す”設計になっているか

  • Webhookハンドラが同期で重い処理をしていないか（外部API、重いDB集計など）
  • Stripeの再送（retries）を前提に 冪等性 を満たしているか（イベントIDで重複排除）
  • 失敗時に、どこで落ちたかがログで分かるか（署名/DB/外部API）

7) 切り分けを確定させる（再送/テスト送信）

  • Stripe Dashboardから Resend / Send test webhook を実行し、直後に
    • StripeのWebhookログ（最新レスポンス）
    • CloudflareのSecurity Events（block/challengeが消えたか）
    • アプリのログ（受信→署名検証→2xxまで到達したか） を同じ時刻で突き合わせます。

SiteOpsで最短にする

複数サービス運営では、同じ「Webhook失敗」でも原因が違うことが多いです。SiteOpsは「どの環境で」「どのイベントで」「いつから」「どの変更の直後か」を並べて、最初の30分の切り分けを短縮します。

相談する（SiteOps）

  • いま起きている症状を整理して、切り分けの最短ルートを作りたい場合は、SiteOpsで「いつから/どの環境/どのイベント/直前の変更」を並べて確認できます。
  • 料金: /#pricing
  • 相談: /contact

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

AdSenseのCPC（単価）が急落したとき、最初の30分でやること収益改善更新: 2026-05-17CSP強化でAdSenseが出なくなったとき、最初の30分でやること収益改善更新: 2026-05-17Stripeの支払いが突然0件になったとき、最初の30分でやること収益改善更新: 2026-05-17
前の記事Stripeの支払いが突然0件になったとき、最初の30分でやること次の記事サイト運営「最初の30分」チェックリスト集（ハブ）

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ