局域网联机：1.0.0 做什么
当前状态
四关都已经发布，但还没在真实环境里验证过：代码写了、有测试，打洞在模拟的 NAT 里测过， 安卓模拟器经官方服务器真的连通过；还没在两台真的电脑之间拿真的游戏试过。进度见路线图。
1.0.0 只做一件事
让不在一处的朋友，像插在同一台交换机上一样联机打游戏。
很多游戏只支持局域网联机 —— 尤其是老游戏，还有一些新游戏的"局域网"模式。 朋友不在同一个屋檐下，就只剩两条路：自己配端口转发（CGNAT 下根本配不了），或者装一个虚拟局域网工具。
Meshora 1.0.0 就是后者，而且只做这一件事。通用组网、网络出口、按应用分流这些方向都排到了 1.0 之后， 见路线图 · 1.0 之后。客户端有 Windows 和安卓。
联机要过的四关
1. 每台电脑都得有一个"局域网地址"
已发布。 每个节点从 100.64.0.0/10（运营商级 NAT 的保留段，几乎不会和家用网段撞车） 拿到一个 overlay 地址，经虚拟网卡（Windows 上是 wintun）收发。游戏看到的就是一块多出来的网卡、 一个和朋友同网段的 IP。
建网络、凭网络码加入： 在客户端里点"建网络"（默认放在官方服务器上），把网络码发给朋友， 朋友贴进客户端就能加入，服务器自动给他分最小的空闲地址，重启也不变。
2. 房间列表里要能看见对方 —— 真正的难点
已发布，还没拿真的游戏验证过。 这一关决定了"虚拟局域网"这个说法名不副实还是名副其实。
大多数局域网游戏找房间靠的不是你输入的 IP，而是广播或组播：主机往整个网段喊一声"我在这开了房间"， 其他人的游戏听到了才会列出来。几个查得到的例子：
| 游戏 | 怎么找房间 |
|---|---|
| Minecraft（Java 版）「对局域网开放」 | 往组播地址 224.0.2.60:4445 定期发公告 |
| 魔兽争霸 III 的局域网游戏 | UDP 6112 上的广播 |
| CS 1.6 的局域网服务器列表 | UDP 广播 |
如果虚拟局域网只转发单播，结果就是一个很让人困惑的状态：互相 ping 得通，房间列表里却看不见对方。 这不是罕见情况 —— 在 Tailscale 的官方仓库里，这正是一个长期开着的功能请求 （#11134）里描述的场景。
所以 1.0.0 必须把虚拟网卡上收到的广播和组播帧真正送到网里其他节点。代价是广播会在整张网里扩散， 节点一多就是负担 —— 所以转发要有边界：只在同一个联机网络里扩散，不出网。
现在做到哪了：
- 已经写了：发往
255.255.255.255、组播地址（224.0.0.0/4）和本网段广播地址的 UDP 报文， 会给网里每个已经有路径的节点各加密发一份；对方照常解密、写进自己的虚拟网卡 - 有边界：只转发 UDP；系统自己的发现协议（NetBIOS、SSDP、mDNS、LLMNR）不转发 —— 它们会把你电脑的名字和服务广播给整张网，游戏又用不上；每秒最多转发 200 个广播，防止一台机器刷爆全网
- Windows 那一头：游戏发广播时系统只挑一张网卡发出去，挑的是接口跃点数最小的那张 —— 装了加速器、VPN 这类软件的电脑上，它们的虚拟网卡可能抢在 Meshora 前面。桌面客户端 默认把虚拟网卡的跃点数设为 1 来解决，设置里可以关。代价是 Meshora 连着时，本机别的程序发往局域网广播地址的报文 也会交给虚拟网卡
- 验证到哪了：在一台 Windows 11 上实测过，往
255.255.255.255、224.0.2.60、网段广播地址发的 UDP 报文 都进了 Meshora、转发给了网里的另一个节点（见桌面客户端 · 实测）。 还没拿真的游戏在两台 Windows 电脑之间试过
3. 能直连就直连，打不通就走中继
已发布。 这部分就是建连流水线：
- 两边都在普通家用路由器后面：打洞直连，游戏流量不经过任何第三方
- 有一边在对称型 NAT 后面，打不通：经中继，中继转发的是已经加密的报文，看不到内容
- 直连断了：回落中继；恢复后切回直连。换了网络、路由器换了公网地址：重新探测、重新打洞
- 协调服务可以给好几个中继：每个都探测，正在用的那个挂了，两三秒内换到别的
这些都在 Linux 上用模拟的 NAT 测过，场景和结果见路线图 · M1。 安卓模拟器每次打包都经官方服务器的中继真的连一次。还没在真实网络、两台真的电脑之间验证过。
4. 延迟要稳，不只是要低
已发布，还没在真实网络里量过。 联机游戏要的不只是"通"：
- 抖动比平均延迟更要命。 稳定的 60ms 比在 20~90ms 之间跳的体验好得多。现在每条直连都记着平滑后的往返时间和抖动 （算法同 TCP 估算重传超时），选路按"往返时间 + 4 × 抖动 + 丢包罚分"打分（每丢 1% 的包算慢 5ms）：一条平均 20ms 但在 5~35ms 之间跳的路， 输给一条稳稳 30ms 的路。正在用的直连，别的路要明显更好（至少好 10ms 和四分之一）才换，免得来回跳
- 倾向直连，容忍更激进的打洞重试 —— 经中继多绕一段，延迟就上去了
- 不为省带宽做缓冲和聚合，游戏的小包要来一个发一个
直连断了要尽快发现。 M1 里要 6.5 秒没有回应才判定、切到中继，对正在打的一局游戏就是卡住 6 秒。 现在正在用的直连每 2 秒探测一次，连丢两次（每次等 1 秒）就切到中继：从断开到切走大约 3~4 秒。 本机换了网络（Wi-Fi 换成手机热点之类）时不等超时，旧的直连一律立刻作废、先走中继，重新打通了再切回来。
中继那条路也探测（经中继发 Ping），和直连放在一起比：直连丢包严重、中继连续半分钟都明显更好时会走中继； 差不多的时候仍然走直连 —— 中继占着别人的带宽，还多绕一段。走中继时界面上也显示延迟。
1.0.0 不做什么
把话说在前面：
- 不做加速器。 不优化你到官方游戏服务器的线路 —— 那是网游加速器的事。Meshora 只连你和朋友的电脑
- 不做网络出口、不做按应用分流、不做通用组网。 都在路线图 · 1.0 之后
- 不保证每款游戏都能用。 有的游戏局域网模式还依赖别的东西（比如特定的网卡顺序、别的发现协议）， 只能一款款试。1.0.0 之前没有兼容列表，写了就是编的
现在就想联机？
Meshora 刚发布不久，真实网络里验证得还很少，想要稳的话先别指望它。如果你现在就需要，同类对比里列了几个已经能用的工具， 以及各自的限制。
下一步：架构 讲这些是怎么落到控制面和数据面上的。