01 27015 报错能说明什么
第二个实例出现 CreateBoundSocket: ::bind couldn't find an open port between 27015 and 27015 时，先排查本地端口绑定冲突。同一网络命名空间内可能已有进程占用该端口；增加路由器映射不能释放第一个进程占用的套接字。
这段报错见于 January 2024 report / 2024 年玩家报告 ↗，只能证明历史上存在该现象，不能证明所有 1.0 构建都使用相同查询端口机制。记录完整错误、构建号、启动器和两个实例的启动命令，面板与容器本身也可能造成映射不一致。
02 先证明两个实例都能单独启动
- A、B 使用独立安装或数据目录、存档目录与服务名称，不能让两个进程同时写同一世界。
- 正常关闭两者，单独启动 A，记录监听端口和进程 ID。
- 关闭 A，单独启动 B 并记录相同信息。
- B 单独也失败时，先修复 B 本身的配置。
- 两者单独正常、同时运行才失败时，比较所有已启用监听端口，包括可选管理接口。
在实际主机做只读检查，不要只看路由器面板：
# Linux：UDP 监听与所属进程
ss -lunp
# Windows PowerShell：检查相关 UDP 端口的进程
Get-NetUDPEndpoint | Where-Object { $_.LocalPort -in 8211,8212,27015,27016 } |
Select-Object LocalAddress,LocalPort,OwningProcess
Get-Process -Id <OwningProcess>这些端口只是诊断示例，还要加入实际日志和配置中出现的端口。
03 更改真正的监听端口，而不只是 PublicPort
官方通过 -port= 设置实际监听端口。原生 Linux 下，分别进入两个独立工作目录：
# 在 A 的目录执行
./PalServer.sh -port=8211
# 在 B 的目录执行
./PalServer.sh -port=8212这里只分离了游戏监听，不能保证所有可选服务都无冲突。Official launch arguments / 官方启动参数 ↗ 明确区分监听端口与对外公告的 -publicport。只公告 8212、实际仍监听 8211，并没有解决问题。
桥接容器应分别记录“外部 UDP 端口 → 容器 UDP 端口”。隔离容器内部可以使用相同端口，但外部映射须不同；host 网络容器共享主机空间，需要不冲突的监听。若是同一路由器后的两台电脑，本地套接字并不冲突，但同一个公网 IP 与外部端口不能同时转发给两台电脑。
04 -queryport=27016 是否有效？
历史 Reddit 回复建议第二个实例使用 -queryport=27016，但我们核对的当前官方参数表未列出此开关。它只能作为与版本有关的待验证线索，不能写成官方保证有效的 1.0 修复方法。
若具体启动器或服务商有文档化的查询端口设置，在对应位置更改，重启 B 后验证进程确实占用了新端口。命令行接受字符串不代表游戏采用该参数。仍报相同错误或监听未变化时，不要继续猜参数；提交两个命令、监听清单、版本与网络模式。无法独立配置的监听，可能需要独立虚拟机、网络命名空间或公网地址。
05 先验证共存，再调整外网访问
两者同时运行后，核对进程、世界与实际监听，再让外网玩家逐一测试。只允许实际配置需要的入站端口；通用 TCP 端口检测不能证明 UDP 游戏连接正常。
不要为了修复列表显示而开启 REST 或 RCON，也不要公开管理凭据或接口。两个游戏连接均正常后，再按 Community diagnostic guide / 社区列表排障 单独处理发现问题。保留监听清单，便于更新后对照。