局域网联机最熟悉的画面，是一人建房，其他人的列表里便出现了同一个名字。可换一个 Wi-Fi，或让朋友从外地加入，房间就可能消失。问题往往出在两个不同环节：游戏怎样发现房间，以及发现之后能否连接。把这两步分开看，比反复重开游戏更容易找到原因。
一、房间发现：广播与组播各有分工
房主刚建好房时，通常不知道还有哪些玩家在找房。部分游戏会发送 UDP 广播，让同一广播域内的设备收到房间通告；另一些使用 UDP 组播，由监听指定组地址的客户端接收。不同游戏、版本的发现协议和端口并不相同，不能只因使用了 UDP 就都叫广播。
以 IPv4 广播为例：
- 目标 IP 地址：
255.255.255.255是受限广播地址；192.168.1.255只有在对应的子网划分下才是定向广播地址，例如192.168.1.0/24。 - 目标 MAC 地址：以太网广播帧使用
FF:FF:FF:FF:FF:FF，组播则有自己的地址映射。 - 发现端口与游戏端口：通告里可以包含真正用于加入的端口。能收到通告，不代表这个连接端口也已经放行。
交换机会把广播帧转发到同一 VLAN 内符合转发条件的其他端口。无线接入点的访客隔离、客户端隔离或组播策略也可能影响发现。因此，“连着同一台路由器”并不一定意味着设备能够互相发现。
二、为什么跨网以后看不见房间？
房间发现通常以本地网络为范围，而互联网路由主要负责把数据送往明确的目的地址。
1. 路由边界与发现范围
二层广播不会通过普通的三层路由自动传播；IPv4 受限广播也不会被路由器转发到远端网络。这是 RFC 919 广播规则 中明确的边界。组播需要相应的网络支持，不能假定家用网络或公网会替游戏转发。
所以，朋友知道房主的公网 IP，也未必能在局域网大厅里“搜到”房间。如果游戏支持输入地址直连，可以绕过发现步骤，再单独验证连接是否可达。
2. NAT 与防火墙是另一道检查
家用路由器通常用 NAT 让多个设备共享公网 IPv4。来自外网的新连接，需要有对应的映射或穿透路径，还要通过防火墙。路由器后面如果还有运营商级 NAT，仅在自家路由器设置端口转发通常不够。
能 ping 通只说明某类探测报文有响应，不能证明游戏的 TCP 或 UDP 端口也已连通。
三、虚拟组网怎样把远方玩家接进来？
LanGame OS Orbit 等工具提供的异地虚拟组网，可以在现有网络之上建立覆盖网络（Overlay）。它与交换机上划分广播域的 VLAN 不是同一个概念。
下面是支持二层转发的一种示意，具体实现并不都使用同一种驱动或穿透协议：
[ 游戏发出房间通告 ]
↓
[ 本机虚拟网卡或发现代理 ]
↓
[ 组网引擎封装，按连接协议传输 ]
↓
[ 互联网直连路径或中继路径 ]
↓
[ 远端解包并交给对应网卡或应用 ]
↓
[ 好友游戏接收通告，再连接房主的游戏端口 ]
1. 虚拟网卡承载什么？
TAP 类型接口处理以太网帧，TUN 类型接口处理 IP 数据包。支持 IP 直连的网络，不一定会把老游戏的广播或组播一并送过去。选工具时，要看游戏需要的是地址可达，还是完整的房间发现能力。
2. 穿透与中继解决什么？
组网引擎尝试为两端建立可用路径；具体方案可能使用 NAT 穿透，也可能在直连受限时走中继。加密保护的是传输内容，无法消除物理距离、带宽拥堵或无线干扰带来的延迟与丢包。
3. 连入房间后仍要核对什么？
先确认双方游戏版本和 Mod 一致，再检查服务器监听地址、游戏端口及防火墙规则。如果能按虚拟地址加入、却看不到大厅列表，应重点检查发现报文走哪张网卡、组网是否支持该类报文，而不是继续更换服务器存档。
四、按游戏的加入方式选择方案
- 依赖大厅发现的老游戏：先确认它使用的广播或组播是否受支持；必要时按游戏说明调整网卡或使用兼容的发现代理。
- 支持专服地址直连的游戏：优先核对
IP:Port和监听状态。直接加入能减少对大厅发现的依赖，但服务器负载、线路质量和游戏自身的同步机制仍会影响体验。
房间列表只是入口。把发现、连接和游戏运行三个环节分别查清楚，才能知道下一步该改网络、配置，还是服务器本身。