把一个经典老 MMO 重新跑起来，第一步不是写新代码，而是弄清它原本的服务器拓扑。这套 2003 年的架构是标准三层：客户端永远只连 GCC（网关集群控制器，GacPort 6000），场景逻辑全部在 GAS（区域服务器，6010）上跑，落库走 DBS（数据库服务器，6023）。三层各自是独立进程，互不引用，靠一套自定义 TCP 协议串起来。
一次性 Key 认证
客户端登录 GCC 拿到的不是会话 cookie，而是一个一次性 Key：拿 Key 去和 GAS 换场景入场资格。这意味着认证必须经过 GCC——你没法绕过网关直连区域服务器，因为 Key 只在 GCC 与 GAS 之间流转有效。这套设计今天看也不过时。
AllowedClients 白名单
每一层的配置里都有 AllowedClients：GAS 只接受 GCC 的连接，DBS 只接受本机的 GCC/GAS。本机化部署时所有白名单保持 127.0.0.1，只有 GCC 的监听口对外。端口矩阵一目了然：
客户端 ──► GCC :6000 （唯一对外端口）
GCC ──► GAS :6010 （本机环回）
GCC/GAS ─► DBS :6023 （本机环回）InnerAddress / OutterAddress 分离
每层配置里有两个地址字段，语义极易混淆：InnerAddress 是 bind 地址，OutterAddress 是对外通告地址。云上部署的正确姿势是 Inner 设 0.0.0.0 监听全部网卡、Outter 设公网 IP——客户端拿到的转发目标永远是通告地址。把这两个当成同一个东西，是部署翻车的头号来源。
经验：架构梳理阶段先画出「谁监听哪个端口、谁允许谁连进来」的矩阵，再动任何配置。后面所有的 IP 迁移、域名化，都只是改这张矩阵。