OpenFront 大厅池（Pool）：当你点进上架大厅却被送到姊妹大厅时

直接答案

大厅池（pool）是房主一次性创建的一组 2 到 8 个完全相同的大厅；公开列表里只显示第一个（入口）。当你点进这张上架卡片时，服务器用你的持久身份做哈希，确定性地把你分到某一个姊妹厅，并发送一条重定向，客户端会自动跟随。只有“全新加入者”会被路由：重连玩家、观战者、白名单玩家和管理员都保持原地。该功能在 v0.34.19（2026-09-25）公告，从 v0.34.20（2026-09-26）起才真正可用。如果你落在一个没有朋友的姊妹厅，说明重定向已经发生了一次——重新进原上架大厅再试一次即可。

答案背后的实际顺序值得展开说明，因为正是它解释了本指南里的每个症状。你点击那张列表卡片，客户端向入口房间建立连接，服务器在答复”有空位”或”已满”之前，先做一次分类：这个玩家属于哪一个池？如果它属于池，服务器计算哈希桶，挑出那个桶对应的姊妹房间，然后把你直接送到那里，你全程看不到那个入口房间的完整名单。这个顺序很重要，因为它说明池路由不是一个”进入之后”的额外关卡，而是你这次加入的第一次分类。这也解释了几件反直觉的事：你被”重定向”时并没有先连上入口房间再被踢走；你最终落地的姊妹房间就是服务器替你选定的那个；而”重定向”这个词其实不准确——你从未进入你看到的那张卡片对应的房间，你直接进了它的姊妹房间。理解这一点之后，“我怎么会被丢到别的房间”这个问题的答案就从”出了 bug”变成了”池路由按设计工作”，而你接下来要做的只是确认这个房间确实是那个池的姊妹房间（模式、地图、倒计时一致），而不是去追查一次不存在的连接失败。这也是本指南后面每个排查步骤的出发点：先确认你看到的是池路由而不是断线重连或反作弊拦截，再决定要不要处理。

为什么一张上架卡片可能对应多个大厅

在 v0.34.19 之前的每个版本里，公开浏览器里的一张大厅卡片就是且仅是一个大厅：一份花名册、一个开始计时器、一个房间。房间满了或还没开门，服务器就告诉你，你留在浏览器里。从 v0.34.19 起，通过管理员池路由创建上架大厅的房主可以在同一时刻额外创建最多 7 个姊妹厅，全部共享入口的配置。公开列表仍然只显示一张卡片——入口——因为姊妹厅的标识符被视为加入密钥，服务器会从它发出的每一个 lobby_info 帧中把它们剥掉。真正变化的是你点击“加入”的那一瞬间：服务器不再针对单个房间回答“满了”或“可进”，而是问“这一小组房间里的哪一个该收你”。

这个设计回应了玩家在上池之前反复抱怨的真实问题。公开大厅列表很薄；社区帖子反复要求可筛选的列表，或抱怨等一个上架游戏要花二十分钟以上。一张上架卡片把一群人吸收进八个房间，就是一个不改动浏览器的容量修复：卡片看起来一样，模式和修饰符胶囊一样，开始倒计时也一样，但有效房间数被成倍放大。这就是大厅池一句话的目的，也是为什么这个功能在你发现自己加载的大厅和朋友加载的不是同一个之前完全不可见。想要理解公开卡片本身承诺了什么——模式、房主自选的 1 到 5 分钟开始、10 到 100 人上限、以及托管的订阅门槛——去读公开大厅指南。如果你要上架的卡片在付费计划之后，公开特殊大厅指南讲的就是那道决定你能否创建上架大厅的门槛。

机制是刻意单向的。服务器可以把加入者从入口路由到姊妹厅，也可以把直接到达某个姊妹厅的加入者重新路由回池内做负载均衡，但它从不移走已经在大厅里的玩家，也从不把姊妹厅集合暴露给客户端。游戏内没有姊妹厅列表，卡片上没有“8 人池”徽标，你也无法浏览姊妹厅。唯一可观察的效果是你出生在哪里、落入哪份玩家花名册。

服务器如何挑选你的姊妹厅

路由函数很小且完全确定性：用你的持久身份做哈希，混入池自身的标识符，再对姊妹厅数量取模。写出来就是 index = hash(poolId + ":" + 你的持久ID) % 姊妹数，然后在该池有序列表中查下标 index 处的姊妹厅。如果这个下标恰好就是你已经指到的大厅，重定向会被整体跳过，你直接加入你点的那个房间——所以池并不是对每个人强制重定向，只对大多数加入者重定向。

这个公式的两个性质决定了功能的手感。第一，池标识符在取模之前混入，意味着同一个玩家指向两个不同池时，即使池大小相同，也可能落在不同序号上：你不会被钉死在“每个同规模池里都是 3 号厅”。第二，哈希按玩家稳定，所以在同一个池内只要池大小不变，你永远被送进同一个姊妹厅。你无法通过反复加入来“摇”出别的大厅，因为哈希输入在你再次进入时并不改变。真正改变输入的是池大小：房主不能在创建后增删姊妹厅，但两个规模不同的池会把同一个玩家分到不同位置。

由于哈希基于稳定的玩家身份，路由在团队大厅上还有另一种重要的一致性：服务器不会故意拆散队友，也永远不会打散已有的花名册，因为重连被豁免（见下一节）。它做的是分散新加入者。一个 8 人池因此表现得像一张有八份花名册的卡片：最早的加入者各自落到不同姊妹厅，第一轮之后分布就取决于哈希说什么。不存在“先填满 1 号厅再填 2 号厅”的顺序——取模不偏好第一个空房间，它偏好确定性的桶。这就是为什么池里可能一个姊妹厅快满而另一个几乎空着，同时发生；也为什么你不应该把姊妹厅上的人数当作整个池有多满的信号。

重定向本身是一条控制帧，不是大厅消息。服务器发送一条类型为 redirect 的消息，携带目标大厅 id，并且它先于任何“满员/已开始”的回答发出。服务器代码里对这个顺序的注释写得很明确：被路由不是被拒绝。这是解读“弹回”时最重要的事实，因为它意味着“你被送去别处”和“这个大厅满了”是两种不同的服务器决策，重定向尝试之后出现的玩家侧错误必须对着重定向路径诊断，而不是对着满员大厅路径。

谁会被告路由，谁不会

准入路径按固定顺序跑池检查，这个顺序定义了豁免项。第一，服务器检查加入客户端是否已经作为玩家存在于目标花名册中：如果是，这次加入就是重连，池逻辑被跳过。第二，服务器检查角色与名单：管理员加入大厅、玩家在该大厅白名单上、客户端角色为观战者，这三类都绕过重定向。第三，对所有确实全新的人，服务器计算哈希目标，若与你指到的是不同大厅，就发出重定向。

值得记住的实际后果：

• 重连从不重新路由。 你在对局中掉线再回到同一大厅，你会落回原处。服务器在池检查之前就在现有花名册里认出你，池检查被跳过。所以“我被踢回菜单再重进”的体验永远不是池重定向；踢人/掉线是另一类故障，与池路由无关。
• 观战者被钉住。 在池入口打开观战模式时，如果哈希目标是另一个成员，切换会被拒绝：你不能观战你作为玩家会被路由进去的那个厅。你只能观战你正指到的那个厅。
• 白名单优先于池。 白名单玩家直接进入口，不管哈希说什么。如果你想和朋友在池环境里同室，唯一受支持的机制就是白名单。
• 管理员被钉住。 工作人员加入池入口时留在入口，这是运营盯入口卡片而不被撒到全池的方式。
• 新加入者被分散。 其余所有人——通常情况——被哈希进某个姊妹厅。

还有一个不对称：重定向对新加入者只发生在进入池的方向。服务器从不随着花名册变满把一个玩家从一个姊妹厅移到另一个，所以不存在“顶格补位”行为把你从已经站着的大厅里拽出来。池在门口分配加入者；一旦你在里面，你就在里面。

版本边界：v0.34.19 公告，v0.34.20 才可用

这个功能的历史跨两个版本，边界很重要，因为两个版本做的声明不同。v0.34.19 的 release notes（发布于 2026-09-25）公告该功能：上架大厅可以把加入者分散到姊妹厅池。v0.34.20 的 release notes（发布于 2026-09-26）给出修复：生产环境从未成池的大厅池现在能成池了，上架大厅现在确实可以把加入者分散到姊妹厅。第二条存在的原因是第一个版本上线的代码在真实环境里没产出可用的池；两个版本之间，路由代码在服务器上存在，但池实际上没有被创建。

由此有三条推论。第一，v0.34.19 窗口内任何说“池不工作”的社区报告或直播都与版本记录一致，不是针对 v0.34.20 的 bug 报告。第二，你在本指南读到的线上行为是 v0.34.20 及以后的行为；如果你读旧指南或看旧视频描述池行为，先核对它的版本行再信。第三，2 到 8 的池大小边界、仅入口上架、创建时锁死配置都来自 v0.34.20 上线的同一份代码，所以本指南里每个数字都是 v0.34.20 的数字。

配置本身还有第二种更安静的版本锁定：池块只在创建时存在。大厅补丁路由不复制 pool 字段，意味着房主无法给已有上架大厅加姊妹厅，也无法在创建后改池大小。想要池就得在开头创建；没有从“单个上架大厅”升级到“带七个姊妹厅的上架大厅”的游戏内路径。这是设计决定而非缺失功能：共享的开始截止时间和共享配置使池成为一个原子对象，且截至本文记录的版本边界，版本记录中没有后续版本把池块扩展进补丁路由。

决策框架：点“加入”之前做什么

对公开浏览器里任何上架卡片按此顺序操作：

1. 先决定同室是否要紧。 如果你为和特定朋友同室而加入，池默认与你的目标敌对：你们各自独立哈希，两个独立哈希落进同一姊妹厅只能靠巧合（N 人池的概率是 1/N）。受支持的变通是入口大厅白名单；房主不给你白名单，就接受可能被拆。
2. 再决定具体花名册是否要紧。 对竞技或影响排名的对局，开局队伍构成是变量时，池成员的花名册在你加载前未知。若你在意成队，把池当作八份花名册上的随机抽取，按最坏情况规划；若不在意，池严格优于单个满房，因为卡片始终可加入。
3. 核对卡片上的开始计时器。 全池共享一个开始截止时间（池创建时入口的截止时间被复制到每个姊妹厅），所以卡片上的倒计时就是每个成员的倒计时。你永远不会被送进一个比卡片承诺更早或更晚开始的姊妹厅；你读到的计时器就是你拿到的计时器。
4. 假设姊妹厅集合是封闭的。 你看不到其他成员、不能在其中选择、也看不到它们的人数。任何需要这些信息（例如“加最空的姊妹厅”）的策略都不被支持；唯一可控变量是你的持久身份，而你不应该轮换它来骗过哈希。
5. 若你是房主，创建前就定池大小。 两个姊妹厅把有效房间翻倍；八个让卡片几乎永不显示“满”。按预期人群定大小，而不是按最小可用定，因为池之后不能变大。

场景 A：你点了上架卡片，却落在了没有朋友的大厅

设定：你和一位朋友都打开同一个四姊妹池的上架 FFA 卡片。你点加入，朋友点加入，你加载进了不同的大厅。这是预期结果，不是 bug：你的两个持久身份产生两个独立哈希值，四个姊妹厅下你们落在一起的概率是 1/4。什么都没坏，服务器侧也没有“把我们留在同一厅”的选项给新加入者。

按优先级该做的事：

• 请房主把你们俩都加白名单。 白名单豁免先于哈希触发，所以你们俩都直接进入口。这是池环境里唯一受支持的同室机制，且需要房主配合，所以在下一次池活动前而不是对局中给房主发消息。
• 一起从入口重进。 如果房主不能加白名单，重进入口大厅（上架卡片）而不是你最终落到的姊妹厅。你的哈希目标稳定，所以重进只会把你放回同一个姊妹厅——这意味着重进并不能帮你找到朋友；只有当他重进入口且他的哈希恰好命中你的姊妹厅（仍是 1/4）时才有用。不要指望反复刷新能解决；哈希输入在重进时不改变。
• 接受拆分并聊天协调。 FFA 里拆分常常无关紧要；团队模式里它会改变你的队伍，所以队伍构成对你要紧时，把池当作抛硬币，选那些队伍不依赖预设组合的模式或大厅。

不要做的事：不要把拆分解读为踢人或反爬失败，也不要在没有“存在池”这一上下文的情况下把它报成“被大厅弹回”——否则支持者和社区线程会把它和下面故障节里的拒绝类问题混为一谈。

场景 B：你托管一个上架大厅，卡片快满了而姊妹厅还空着

设定：你托管一个八姊妹池的上架团队大厅，公开卡片显示入口接近人数上限，而你知道池里还有六个空姊妹厅。你以为卡片会继续吸人，但新加入者不断落在入口，卡片数字一路逼近上限。

两件事同时在发生。第一，哈希把新加入者分散到八个姊妹厅，所以入口不会线性填满：每个新加入者有 1/8 概率落在入口本身。卡片数字是入口的花名册，不是池总数，服务器从不向你显示池总数。第二，卡片的“满”状态是入口的满状态：当入口花名册达到上限，服务器对入口回答“满”——而重定向逻辑跑在满员回答之前，所以指向满员入口的加入者仍可能被路由到未满的姊妹厅。因此卡片可能显示一个看着像满的数字而池里仍有空位，这是功能按设计工作，不是卡死的大厅。

作为房主的操作规程：

• 不要把卡片数字当池的健康度。 你能从卡片可靠作出的唯一陈述是关于入口的。需要池级占用率，来源是管理工具，不是公开卡片。
• 按峰值定池大小，然后接受尾部。 池在创建时固定，定小了（四十人的场面只开两个姊妹厅）只会短暂出现“入口快满而池仍有位”；定大了（十人的场面开八个姊妹厅）会让六个姊妹厅几乎空着，把你的社区撒到各个厅。周期性上架活动，8 是安全默认；随意的双加朋友局，2 即可。
• 把你的核心圈加白名单。 你的常客可以白名单到入口，让他们总与你同室，而公开人群分散到池。核心稳定，池的容量收益也不丢。

故障与反制

重定向路径很短，但故障形态有四种，各有不同原因和反制。诊断出你看到的是哪一种是全部关键，因为至少两种的玩家侧症状都是“我尝试加入然后报错”。

1. 重定向跟随后连接错误。 客户端的重定向处理在跟随池重定向时会在 sessionStorage 里设一个闩，并把第二次重定向当作连接拒绝，防止客户端在两个姊妹厅之间循环。如果你点进上架卡片后立即得到“connection refused”，可能原因是：目标姊妹厅在重定向决策与连接尝试之间被移除或关闭（罕见、服务器侧），或者同一标签页里之前失败的尝试已设闩，第二次重定向被当作循环。反制：彻底关闭标签页（清掉 sessionStorage），从上架卡片重进。同一标签页不要重试超过一次。
2. 重定向跟随后落到的不是你预期的池成员。 如果你落进的大厅模式或地图与卡片不符，那不是池：池的所有姊妹厅按构造共享入口配置（姊妹厅由同一配置铸造，补丁路由无法让它们分叉）。模式或地图不符意味着你加错了卡片，不是池路由错。反制：把你加载的大厅与卡片的模式、地图胶囊对照；不符就点错了列表，重进正确的那张。
3. 看似池弹回的拒绝实为反爬拒绝。 “Connection refused: Unauthorized: Turnstile token rejected” 是 Cloudflare 反爬检测拒绝加入，与池路由无关。社区 2026 年帖子把它报成最常见的“被大厅弹回”抱怨，且早于池。反制：标准反爬手段（重启、换大厅、换网络）适用，没有一条涉及池。如果你被这个错误从一个大厅弹回而另一个没事，原因是 token，不是大厅。
4. 对局中被踢回菜单。 突然回到开始画面是掉线或踢人，而重连被豁免池路由，所以踢人永远不是池重定向。被踢后重进，你会落回原大厅而不是姊妹厅。反制：先检查常规成因（服务器重启、无活动、会话过期），再考虑是否把对局中被踢归因于池。

四种形态的快速诊断表：

症状	原因	反制
点进上架卡片后立即“connection refused”	重定向防循环闩，或目标在决策与连接之间关闭	关闭标签页，从上架卡片重进
加载大厅的模式/地图与卡片不符	点错卡片，不是池路由错（姊妹厅共享配置）	对照卡片胶囊；重进正确列表
“Turnstile token rejected”	Cloudflare 反爬拒绝，与池无关	标准反爬手段；按 token 问题报，不是池问题
对局中被踢回菜单，重进落回原大厅	掉线/踢人；重连被豁免路由	看被踢出排查指南

模式与地图调整

池不改变模式、地图或修饰符胶囊：所有姊妹厅继承入口配置，服务器从配置帧中只剥掉姊妹厅标识符。池改变的是模式内的玩家构成，下面是每个模式对开局决策意味着什么的备注。

• FFA。 池是净收益。你的开局位置来自你自己的选择，不来自花名册，唯一变化的是卡片可获得的人群规模。对上架卡片打 FFA 时，把卡片当作“池真正满之前都可加入”，不要因为入口数字看着高就退。
• 团队模式。 池是关键的变量。你的队伍是姊妹厅现有花名册加你产生的结果，而姊妹厅在你加载前未知。若你是想掌控队伍的准队长，白名单是你的工具；若你是灵活位玩家，池是特性：你落到最需要你角色的那份花名册。按队伍构成的最坏抽取规划开局，而不是按期望。
• 核武/高利害大厅。 若你的模式有很长的前置（核武准备、SAM 网络），跨姊妹厅拆分代价高：你对特定对手基地的预设反制可能在一个你永远看不到的姊妹厅里。要对指定玩家反制时，白名单或私人厅优于池；开放式公开对局，接受拆分。
• 地图特定判断。 池不改变加载哪张地图，所以地图知识在姊妹厅间原样迁移。不迁移的是地图的状态：两个姊妹厅在同一开始时间跑同一张地图，但玩家不同、早期扩张也不同。不要假设入口的队友就在你加载的姊妹厅；前 30 秒重新识别你的花名册。

速览表：池一览

属性	值	来源
池大小	2 到 8 个姊妹厅	create_pool 路由以 min(2).max(MAX_POOL_MEMBERS) 校验 count，MAX_POOL_MEMBERS = 8
上架	仅入口上架	池创建时 applyListing 只应用于 lobbies[0]
配置	共享，创建时锁死	姊妹厅由入口配置铸造；补丁路由不复制 pool
开始时间	全池共享同一截止时间	入口自动开始截止时间复制到每个姊妹厅（setPoolAutoStartAt）
路由输入	hash(poolId + ":" + 持久ID) % 大小	PoolRouting.ts 的 poolIndexFor / poolTargetFor
重定向目标	哈希下标处的姊妹厅；若等于你指的入口则跳过	poolTargetFor 在目标等于入口时返回 null
豁免	重连、管理员角色、白名单 publicId、观战者	GameServer.ts 的准入路径
观战切换	哈希目标为另一成员时拒绝	setSpectator 池检查
客户端行为	以整页跳转跟随重定向；sessionStorage 闩阻止第二次重定向（按拒绝处理）	Transport.ts 重定向处理
姊妹厅标识符	从每个 lobby_info 帧中剥掉（加入密钥）	GameServer.ts 的 configWithoutPool
队伍 pin	池不支持（teams_unsupported_for_pool）	create_pool 校验
版本边界	v0.34.19 公告（2026-09-25）；v0.34.20 起可用（2026-09-26）	v0.34.19 与 v0.34.20 release notes

如何读这张表，因为行不是自上而下勾选的清单，而是关于同一个功能的一组事实，排序是为了让每一行回答前一行引出的问题。前三行是”是什么”（池是什么、重定向做什么、谁被豁免），刚接触这个功能时先读这几行。中间几行是”何时”（版本边界和自动开始倒计时），想弄懂某个版本上池到底成没成时读这几行。底部几行是”怎么做”（管理员命令、客户端重定向、只重定向一次的保证），当你作为房主或管理员需要创建或检查池时读这几行。表刻意简短——它是参考而不是教程——所以对你最重要的行是回答你带着来的那个问题的那一行，其余行是你需要核对某个细节时用的。如果你是玩家，在意的行是”谁被豁免”和”重定向是单向的”；如果你是房主，在意的行是”create_pool”和”自动开始倒计时”；如果你是管理员，在意的行是”池配置在姊妹房间间共享”。最常用的实际用法是：当某个行为让你意外时打开表，找到匹配症状的那一行——落在意外房间的玩家可以看”重定向是单向的”那一行，提醒自己无法”回到”入口房间；池没开始的房主看自动开始倒计时那一行，检查倒计时是不是太短；检查池的管理员看共享配置那一行，记住每个姊妹房间都继承入口房间的模式和地图。所以这张表是个快速锚点：当某个具体细节你一时想不起来时，不用重读整篇指南，直接找到承载该细节的那一行并回到它，比在全文里搜索更省时间。

一个可验证的工具：管理员池路由

你能看见池而不只是体验它的唯一位置是管理员 bot API。路由 POST /api/adminbot/create_pool 是池诞生的唯一途径，其请求形状以机器可读形式记录了功能的约束：

POST /api/adminbot/create_pool
{
  "count": 4,                    // 2..8，姊妹厅数量（含入口）
  "lobby": { ...config... }      // 入口的完整大厅配置；姊妹厅复制它
}

请求的三个属性让约束具体化。count 字段是唯一的尺寸旋钮，被校验在 min(2).max(8) 内——请求一个姊妹厅会被拒绝，请求九个也被拒绝，所以速览表里的大小边界不是文档声明，而是你可以触发的校验错误。lobby 配置是每个姊妹厅的唯一来源：请求里没有逐姊妹厅字段，这就是姊妹厅无法在模式、地图或修饰符胶囊上分叉的原因。响应返回铸造出的大厅标识符，其中只有第一个上架——响应本身就展示池的形状（N 个标识符、一个公开上架），这正是玩家侧从客户端永远看不到的形状。

你通常不会自己调用这个路由：它是管理员 bot 端点，公开玩家路径只是“加入上架卡片，让服务器路由你”。它对本文重要，因为它是上表每个数字的事实源——大小边界、仅入口上架、共享配置、仅创建时存在——若未来版本改变其中任何数字，这个路由的校验与响应形状会是变化最先可见的地方。

从房主的角度看，管理员路由做什么。create_pool 命令是池如何诞生的方式：房主（或拥有权限的管理员）给池起个名字，指定要多少个姊妹房间，服务器据此建立一组配置完全相同的房间，只有第一间出现在公开列表里。理解了这条命令，你就能看懂后面表格里”池配置在姊妹房间间共享”那行是什么意思——共享不是巧合，而是 create_pool 一次性把同一份配置写进每个姊妹房间的结果。对房主来说，这条命令的实际含义是：你创建的池的大小（两到八个姊妹房间）决定了你一次能”摊”多少玩家，也决定了入口房间在列表里看起来”满员”的可能性——因为列表只显示入口房间，玩家不知道背后还有几个姊妹房间在承接。所以如果你创建池是为了分流拥挤的 FFA 房间，你要权衡的是：池越大，单个姊妹房间越空、越容易进入，但入口房间在列表里的”热度”信号也越弱（因为人数被摊薄了）；池越小，入口房间显得越热闹，但每个姊妹房间越快填满。这个权衡没有唯一正确答案，取决于你要的是”快速开局”还是”列表吸引力”。

在你自己的会话里验证什么

因为池从客户端不可见，你能做的唯一诚实验证是行为性的，且只需要一次加入：

1. 加入一个你相信是池的上架卡片（活动期间房主创建的上架大厅是典型情况），记下你加载进哪个大厅。
2. 问一位同一时刻加入同一卡片的朋友加载进了哪个大厅。若他在不同的大厅而模式、地图、开始时间相同，卡片就是池，路由按文档工作。
3. 若你们在同一大厅，要么池大小为一（无池），要么你的两个哈希撞车；八人池下撞车概率是 1/8，所以一次同室结果对两个方向都是弱证据——多拉几位朋友重复以得到更强判断。
4. 如果你被“Turnstile token rejected”或对局中被踢回菜单顶替，那不是池结果：先套用上面故障反制，再考虑归因于路由。

负例和正例同样重要：如果一张上架卡片在多次独立加入中从不把你和朋友拆开，卡片就不是池（或池大小为一）。“这张卡片每次都让我和朋友落同厅”在池环境里就是池不存在的信号。

验证清单按从便宜到昂贵排序，因为前三个检查只需几秒就能排除大多数情况。版本检查（你的客户端是否在 v0.34.20 或之后）是最先做的，因为它能立刻把”池根本不存在”和”池按设计工作”区分开。接下来是模式与地图检查（你落地的房间是否和入口房间同模式、同地图），这一步确认你看到的是池路由而不是进了另一个完全不同的房间。第三步是倒计时检查（自动开始倒计时是否在合理范围内），这一步区分”池按设计开始”和”倒计时设置过短导致提前开始”。这三个检查都通过之后，才轮到较重的检查：核对姊妹房间是否真的共享配置（需要管理员视角），以及确认重定向是单向的（你无法回到入口房间）。清单的关键不是”按顺序全做一遍”，而是”遇到症状先做最便宜的那个”——如果你怀疑自己进了错房间，先做模式与地图检查；如果你怀疑池没按设计开始，先做倒计时检查；如果你怀疑自己客户端太旧，先做版本检查。这样做的实际好处是，绝大多数”我被重定向了”的报告，在前三个检查里就能找到答案，不需要走到最重的管理员核对那一步。

结论

大厅池是容量装置，不是目的地选择：一张上架卡片、最多八个房间、一个共享开始、一份锁死配置，以及一个把新加入者分散到各房间的确定性哈希。你不能选择姊妹厅、看不到姊妹厅、也看不到池的总占用率——卡片是你得到的一切，而卡片的模式、地图、计时器仍然与承诺一致。变化的决定是社交性的：同室需要白名单，团队需要最坏抽取计划，“被弹回”症状需要先过四形态诊断再归咎于路由。v0.34.20 起，机制按 release notes 描述工作；在那之前，它只被公告而并未上线。

给不想读完的玩家的短版本。池是由房主用 create_pool 创建的两到八个配置相同的房间，背后的那张列表卡片就是入口房间；你点卡片时，服务器按你的身份哈希挑一个姊妹房间直接把你送进去，所以你”重定向”其实是”落到了姊妹房间”，而不是”被踢出入口房间”。三件你要记住的事：第一，重定向是单向的，你没法回到那张卡片对应的入口房间；第二，你落地的姊妹房间和入口房间同模式、同地图，变的只是房间里的玩家构成；第三，这个功能在 v0.34.20 起完整可用，如果你的客户端更早，池对你根本不存在，你看到的就是普通加入。遇到”我怎么进了别的房间”时，先确认客户端版本、再确认模式和地图一致、最后确认倒计时合理——大多数情况到此就有答案。如果你是房主，池的大小决定了你一次摊多少玩家，也决定了入口房间在列表里的热度信号，按你要”快速开局”还是”列表吸引力”来选；如果你是管理员，记住每个姊妹房间都继承入口房间的配置，所以改一处就改全组。