Waiting Room について、よくある質問への回答をまとめます。
はい。詳細は Waiting Room をカスタマイズする を参照してください。
Waiting Room のテンプレートをカスタマイズ している場合:
- 本番へデプロイする前に、テンプレートをプレビューします。
- 問題が起きた場合は、構文と閉じのバックスラッシュ（/）を確認します。
Waiting Room のテンプレート は更新でき、変更はほぼリアルタイムでユーザーに反映されます。ユーザーと対話し、最新情報や見込みを伝える手段として、この更新を推奨します。
Waiting Room の 設定 も更新できますが、必要なときだけ変更してください。表示される推定待ち時間が変わり、ユーザーが混乱することがあります。
プラン種類ごとの機能は プラン を参照してください。
一部の Cloudflare 製品は、Waiting Room がトラフィックを処理する前に実行されます。
- DDoS Mitigation
- Web Application Firewall（WAF）
- Bot Management
- Page Rules
ほかの Cloudflare 製品は、Waiting Room がトラフィックを処理したあとに実行されます。
- Workers
タブを手動で更新しても、Waiting Room 内のユーザーの位置は変わりません。
ただし、タブを閉じてから、キュー処理中に再度アプリケーションへアクセスすると、順番を失い、列の末尾に回されます。
ユーザーがキューに入ると、列内の大まかな位置を表すバケットに入ります。ユーザーがキューを離れた（ブラウザーまたはタブを閉じた）場合、最後の更新から 5 分間は順番が保持されます。この猶予期間により、短い切断でも列の位置を保てます。5 分が過ぎると猶予期間は切れ、待機中の人数として数えられなくなります。
アーキテクチャ上の理由で、Waiting Room が上限に達する前に、一部のユーザーがキューに入ることがあります。動作と対処の詳細は キューの有効化 を参照してください。
ユーザーが Waiting Room のキューに入らない場合は、定義した path がサイトの path と完全に一致しているかを確認してください。
path は大文字と小文字を区別します。/Black-Friday-Sale 向けに Waiting Room を設定していても、ユーザーが /black-friday-sale にアクセスすると、Waiting Room を迂回します。
詳細は ベストプラクティス を参照してください。
Rate Limiting を使っている場合は、レート制限ルール を確認してください。
Waiting Room のキューページは、Refresh ヘッダーを入れて 20 秒ごとに更新されます。特定の IP からのリクエストを 20 秒以内にブロックするルールがあると、Waiting Room 内のユーザーがブロックされます。ルールは 20 秒に少なくとも 1 リクエストを許可してください。
ユーザーが Cookie を有効にしていない場合もあります。Cookie が無効で、Waiting Room がトラフィックをキュー処理しているときは、キューが終わるまでエンドポイントに到達できません。
サイトを離れるユーザーの速度が下がると、推定待ち時間が増えることがあります。推定待ち時間は、ページ更新のたびに、サイトで空き枠が開く速度と、そのユーザーより前に並んでいる人数の最新情報で更新されます。増えにくくするには、セッション更新を無効にして、ユーザーがサイトに滞在できる時間を制限できます。トラフィック設定を変えると、推定待ち時間も変わる点に注意してください。
new users per minute 指標は、直近 1 分間にオリジンへ受け入れたユーザー数を追跡します。キュー内のユーザーが更新し、オリジンへ受け入れられたときだけ増加します。Waiting Room のキュー方式が fifo の場合、1 分単位のバケット内のキューユーザーが全員受け入れられるまで待ってから、次のバケットへ進みます。バケット内の多くのユーザーが列を放棄していると、その順番が期限切れになるまで Waiting Room は次のバケットへ進めません。実際に待っているキューユーザーが少数だと、new users per minute が低くなることがあります。
Cookie を正しく扱わない自動トラフィックが多いと、よくこの状態になります。ボットは通常、リクエスト間で Cookie を保持しないため、キュー内の複数の非アクティブユーザーとして数えられ、空き枠を使い切れなくなります。そのため、キューからボットを排除するには Bot Management 製品の利用を推奨します。Waiting Room Advanced のお客様は Turnstile 連携を試せます。ボットを無限キューに入れ、列を詰まらせないようにします。
Waiting Room はセッション Cookie でアクティブユーザーを数え、追跡します。ユーザーをアクティブとみなす期間は、Waiting Room の設定によって異なります。この計算に関わる主な設定は session duration です。デフォルトでは、Waiting Room はセッション Cookie 付きの最後のリクエストから、設定した session duration が経過するまで、そのユーザーをアクティブとみなします。Advanced Waiting Room を使っているお客様は、セッション更新を無効にする か、オリジンコマンドで セッションを明示的に取り消す ことで、この動作を変えられます。
session duration を長くすると、リクエストが 1 回だけのユーザーも、実際より長くアクティブとみなされます。そのため、同じ期間の Google Analytics のアクティブユーザー指標より、Total Active Users が高く見えることがあります。Google Analytics は、その期間にリクエストしたユーザーだけを数えます。
たとえば、session duration が 30 分で、Google Analytics で直近 10 分のアクティブユーザーを見ると、Waiting Room が報告するアクティブユーザー数の方が高くなります。直近 30 分のユーザーを含むためです。
もう 1 つの違いは、Waiting Room はオリジンへのリクエストで動き、Google Analytics はユーザーエージェントが JavaScript（Google Tag 経由）を実行する必要がある点です。Waiting Room は HTTP リクエストの path に基づいて新しいセッションを作り、ユーザー指標を追跡します。ユーザーエージェントによる追加の JavaScript 実行は不要です。一方、Google Analytics はユーザーエージェントが JavaScript を実行し、詳細を報告する 2 回目のリクエストを行う必要があります。トラフィックの多くが自動処理の場合、Google Analytics には含まれないことがあります。ただし Waiting Room の分析は、そのようなトラフィックを新規ユーザーとして数え、設定した session duration のあいだアクティブとみなします。
Waiting Room は分散システムです。世界中のデータセンターへ状態を伝播する時間がかかるため、リアルタイムで完全なグローバル集計を行うのは難しいです。予算のロジックは、データセンター固有の予算とグローバル予算の両方で構成されます。データセンター予算は、各データセンターが受け取ってきた過去のトラフィックに基づいて割り当てます。グローバル予算（利用可能予算の一部）は、どのデータセンターからでも新規ユーザーが入ってこられるように維持します。
急増（1 分以内に数千ユーザーまで上昇）の場合、グローバル状態の伝播にはおよそ 2 分かかり、すべてのデータセンターが急増を認識するまでに遅れが出ます。この情報がほかの拠点へ十分速く伝わらないと、特にしきい値が低いときに、一時的な超過が起きることがあります。
これは、新規ユーザーがデータセンターへ入るために予約されている予算の一部が、すべてのデータセンターに等しく使えるためです。この予算の使用量がすべてのデータセンターで同期されるまで、各データセンターが一部を消費し、合計が新規ユーザー向けグローバル予算の 100% を超えることがあります。