您可以在下方找到有关 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 中的位置没有影响。
但是，如果他们在活动排队期间关闭选项卡然后尝试再次访问应用程序，他们将失去其位置并必须回到队列的末尾。
当用户加入队列时，他们会被放入一个表示其在队列中大致位置的存储桶中。当用户离开队列（关闭浏览器或选项卡）时，他们的排队位置将在最后一次刷新后保留五分钟。这个宽限期允许用户在遇到短暂断开连接时保持其在队列中的位置。五分钟后，宽限期到期，他们将不再被计为在队列中等待。
由于架构设计，在您的 Waiting Room 达到其限制之前，某些用户可能会被排队。有关该行为以及如何解决该行为的更多详细信息，请参阅排队激活。
如果您注意到用户没有在您的 Waiting Room 中排队，请确保您定义的路径与您网站的路径完全匹配。
路径区分大小写，因此如果您为 /Black-Friday-Sale 设置了 Waiting Room，而用户转到 /black-friday-sale，他们将绕过您的 Waiting Room。
有关更多详细信息，请参阅最佳实践。
如果您有速率限制，请检查您的速率限制规则。
Waiting Room 队列页面通过填充刷新标头每 20 秒刷新一次。如果您设置了在 20 秒内阻止来自特定 IP 的请求的规则，则 Waiting Room 中的用户将被阻止。请确保您的规则允许至少每 20 秒一个请求。
您的用户可能也没有启用 cookie。如果他们不启用 cookie 并且您的 Waiting Room 正在主动对流量进行排队，他们将无法到达您的端点，直到排队停止。
如果用户离开您网站的速率降低，预计等待时间可能会增加。预计等待时间会在每次页面刷新时更新，基于有关您网站上开放插槽速率的最新可用信息以及队列中该用户前面的用户数量。为了降低这种增加的可能性，您可以通过禁用会话续订来限制允许用户在您网站上花费的时间。请注意，如果您更改流量设置，预计等待时间也会随之改变。
new users per minute 指标跟踪在上一分钟内被接纳到源站的用户数。仅当排队用户刷新并被接纳到源站时，该指标才会增加。如果 Waiting Room 排队方法设置为 fifo，我们将等待直到基于分钟的存储桶中的所有排队用户被接纳，然后才移动到下一个存储桶。如果存储桶中的许多用户已经放弃了排队，那么 Waiting Room 必须等到他们的排队位置过期，才能继续处理下一个存储桶。当只有很小比例的排队用户实际还在等待时，这会导致 new users per minute 变低。
如果存在大量未能正确处理 cookie 的自动化流量，经常会注意到这种情况。由于机器人通常不会将 cookie 从一个请求持久化到下一个请求，因此它们最终会在队列中计为多个非活动用户，并阻止完全利用可用插槽。因此，我们建议利用 Bot Management 产品将机器人排除在队列之外。Waiting Room Advanced 客户可以尝试我们的 Turnstile 集成，这会通过将机器人放入无限队列来防止它们阻塞队列。
Waiting Room 依靠会话 cookie 来计算和跟踪活跃用户。用户被视为处于活跃状态的持续时间取决于 Waiting Room 配置。此计算中涉及的关键设置是会话持续时间。默认情况下，Waiting Room 认为用户从其使用会话 cookie 发出的最后一次请求起，直到配置的会话持续时间过去，一直处于活跃状态。拥有高级 Waiting Room 设置的客户可以通过禁用会话续订和/或使用源站命令明确撤销会话来修改此行为。
如果会话持续时间设置为较高的值，仅发出一个请求的用户将被认为其活跃时间比实际时间更长。这可能导致 Total Active Users 指标似乎高于 Google Analytics 针对同一时间段报告的活跃用户指标，因为 Google Analytics 仅计算在特定时间段内发出请求的用户。
例如，如果会话持续时间设置为 30 分钟，而您在 Google Analytics 中查看过去 10 分钟内的活跃用户，则 Waiting Room 报告的活跃用户数将更高，因为它包括过去 30 分钟内的用户。
另一个主要区别是，Waiting Room 根据对源站发出的请求运行，而 Google Analytics 要求 user-agent 运行 JavaScript（通过 Google Tag）。Waiting Room 基于 HTTP 请求路径创建新会话并跟踪用户指标，不需要 user-agent 执行任何额外的 JavaScript。相反，Google Analytics 要求 user-agent 执行 JavaScript 并发出辅助请求以向 Google Analytics 报告详细信息。如果流量中有很大一部分是自动化的，Google Analytics 可能无法捕获。然而，Waiting Room 分析会将此类流量计为新用户，并在配置的会话持续时间内将其视为活跃用户。
Waiting Room 是一个分布式系统，由于全球数据中心之间的状态传播需要时间，因此难以在实时中实现完美的全局计数。预算逻辑围绕特定于数据中心的预算和全局预算构成。数据中心预算是根据每个数据中心收到的历史流量分配的，而维护全局预算（总可用预算的一部分）是为了允许全球任何数据中心的新用户进入。
如果出现快速激增（在一分钟内增加到数千名用户），全局状态传播过程大约需要两分钟，这会导致在所有数据中心都意识到激增之前出现延迟。如果这些信息没有足够快地传播到其他位置，就可能会出现暂时的超量，特别是在实施了较低限制的情况下。
发生这种情况是因为预留给进入某个数据中心的新用户的预算部分对于所有数据中心同等可用。在该预算的使用在所有数据中心同步之前，每个数据中心可能会消耗一部分，这些部分加起来就超过了分配给新用户的全局预算的 100%。