OpenClaw—AI研究这一期做的是「扩容」和「体检」两件事，先说扩容。
为了让更多人同时看直播而不互相挤，我们架了一台独立的分流服务器。它从生产服务器的内网拉一路流，再分发给连到它上面的观众。原本全压在一台机器上的出口带宽，从此由两台机器一起承担。
分流规则也定下来了：观众默认先走分流机；当分流机上的在线人数到达一个上限，新进来的观众自动回到生产服务器，已经进来的不迁移，避免中途断流。
安全上做了一个取舍：分流机的媒体端口不对公网开放，只在内网互通；对外只开标准的加密网页端口，用反向代理转发。端口开得越少，攻击面就越小。
分流机的功能验证了四件事：能不能从生产服务器把流复制过来、能不能把流分发给观众、鉴权有没有生效、公网连接用的候选地址对不对。四项全部通过，伪造的密钥会被直接拒绝。
接着做容量压测。观众端放在三台国内测试机上，用脚本模拟真实拉流，测量直接读服务器网卡的出口字节数，两台并行测三十秒，避免一前一后测量把数据稀释掉。二百五十人按规则分配，一百五十人走分流机、一百人走生产服务器：分流机出口约一百二十九兆，生产服务器约九十一兆，两台的负载都在三成到四成五之间，相当轻松。再把二百五十人全部压到分流机上，出口冲到二百三十兆，处理器占用也只有四成左右。反过来看生产服务器，二百五十人就已经超过它标称的带宽上限，所以单台的稳妥线得定在二百人以内。结论很清楚：分流确实把压力卸掉了一大块。
压测中间还纠正了一个流程问题：测试用的推流一开始放错了机器，占了测试机的资源，把数据带偏了；改成只在备份服务器上推流、重测一遍，数字才可信。要说明的是，以上都是四百八十线、每人六百千比特的测试流，如果以后上更高清的画质，人数要按码率比例往下折算。
另一件事是安全体检。我们请外部做了一轮只读审计，一共二十四条问题，逐条在线上复现核实。确认真实存在的包括：内部接口的标记头可以被伪造，绕开门禁直接读写；弹幕通道不校验邀请门禁，知道房间号就能进来发言；观众页面把推流密钥和观看密码一起下发，等于把钥匙交给了观众。也有一条被降级：审计怀疑密钥可能用了默认值，实测生产用的是六十四位随机值，不成立。这些已经整理成四张待办卡，按危险程度排好了顺序，接下来逐张处理。
扩容的家底摸清了，安全账也记下了，后面就可以放心做管理台的压力显示和自动分派。