n.eko：用 WebRTC 把整个浏览器搬进 Docker，然后多人一起用

它解决的是「多人共用同一个浏览器」的问题

普通远程桌面工具一次只服务一个人，屏幕共享则只能看不能碰。n.eko 的定位是让多个用户同时看到一个虚拟桌面，并且都能控制它。这源于作者想和朋友一起看动画片的经历，rabb.it 关停后，他找到 Turtus 项目，然后 fork 出了 n.eko。核心场景是看片聚会、交互式演示、结对调试，或者让客户在一个受控环境里操作你的应用。它不限于浏览器，实际上可以跑任何 Linux 程序，甚至安装完整的 XFCE 或 KDE 桌面。关键区别是：它把整个桌面当作一个共享对象，而不是把单个窗口推给每个人。

WebRTC 串流，不是 VNC 也不是 RDP

n.eko 的机制是：Docker 容器里运行一个 X server，浏览器或应用跑在其中，然后 neko 的服务端定期抓取 X 画面，编码后用 WebRTC 推给客户端。用户的操作事件通过 WebRTC 数据通道回传，实现双向交互。这与 Apache Guacamole 那种客户端渲染的方式完全不同，Guacamole 把图像编码成网页可显示的流，但 n.eko 是直接的视频流。WebRTC 带来的好处是低延迟和点对点传输，但代价是 NAT 穿透问题，需要 STUN/TURN 服务器配合。文档里也提到理论上可以实现 RDP 或 VNC 协议，让 neko 只做 WebRTC 中继，但目前这只是未来计划，不是现成功能。

部署：一条 docker run 命令起步

README 给出的启动方式是 Docker 容器，官方镜像在 Docker Hub 上。基本命令类似 docker run -p 8080:8080 m1k1o/neko，但实际需要指定一些环境变量，比如 NEKO_PASSWORD 和 NEKO_PASSWORD_ADMIN，用来区分普通用户和管理员权限。默认情况下容器里跑的是 Firefox 或 Chromium，具体取决于你拉取的镜像标签。如果你需要持久化浏览器配置，比如保存 cookies，得挂载数据卷。更复杂的部署可以使用 neko-rooms 项目，它提供 API 来动态创建和销毁房间，适合嵌入到自己的 web 应用里。注意，n.eko 依赖 WebRTC，所以你的服务器需要开放 UDP 端口，并且最好配置 TURN 服务器，否则某些网络环境下客户端无法连接。

多个用户同时操作，但权限粒度有限

n.eko 允许多个用户同时进入同一个房间，但控制权的分配并不像协同编辑那样精细。文档提到用户可以共享屏幕并实时交互，但并没有说明如何精确控制谁有鼠标键盘权限。管理员密码和普通用户密码的区分暗示了基本的权限层级，但具体到每个用户的输入隔离，文档没有详细描述。实际使用时，很可能出现两个人同时拖动鼠标的情况，这需要外部约定或者自己写逻辑来协调。如果你需要严格的角色控制，比如只让一个人操作、其他人只能看，你可能得依赖 n.eko 的 API 自己实现，或者等待未来版本完善。

适用场景：从看片到嵌入你的产品

n.eko 的用例列表很长：看片聚会、交互式演示、协作工具、技术支持、嵌入式虚拟浏览器。其中嵌入场景最有意思，你可以用 neko-rooms 的 API 动态创建房间，然后把虚拟浏览器嵌入到自己的 web 应用里，让用户直接在网页上操作一个远程浏览器，而不用安装任何插件。这类似于 Hyperbeam 的服务，但 n.eko 是开源的，你可以自己托管。另一个独特用例是 VR Chat 里看片，通过一个第三方项目 jameskitt616/vrchat_streaming 实现。还有会话广播，可以用 RTMP 把房间内容推送到 Twitch 或 YouTube，这需要额外配置 nginx-rtmp。这些场景都依赖同一个核心：把桌面当作可共享的视频源。

资源消耗与安全边界，需要自己掂量

运行一个完整的浏览器加 X server 在容器里，意味着每个房间都要消耗相当多的 CPU 和内存。这不是一个轻量级的方案，尤其是同时开多个房间时，服务器配置要跟得上。文档提到可以安装完整桌面环境，但那会更重。安全方面，n.eko 的卖点之一是“不传输 cookies”，只传视频流，所以宿主机浏览器不会留下状态。但容器本身如果暴露在公网，就需要考虑 WebRTC 的端口开放和密码强度。项目使用 Apache-2.0 许可证，这意味着你可以自由使用和修改，但要注意如果你分发修改后的版本，需要保留版权声明。维护方面，项目仍在活跃更新，v3.x 系列持续发布，但升级可能涉及配置格式变化，需要查看 release notes。

对比 Guacamole：客户端渲染 vs 视频流

文档中提到了 Apache Guacamole 和 websockify 这类“无客户端远程桌面网关”。它们走的是客户端渲染路线：服务器把屏幕编码成图像，浏览器端解码显示，交互事件通过 WebSocket 回传。这种方式延迟通常高于 WebRTC，但好处是不需要客户端安装任何东西，而且对带宽要求更可控。n.eko 走的是 WebRTC 视频流，延迟更低，但要求网络能穿透 NAT，而且视频编码会消耗服务器 CPU。如果你的用户都在同一局域网，WebRTC 直连很快；如果跨公网，TURN 中继会增加延迟。选择哪个取决于你的网络拓扑和延迟敏感度。n.eko 的优势在于多人实时同步，而 Guacamole 更适合单人远程访问内部应用。

谁该用，谁不该用，以及先验证什么

如果你的核心需求是多人实时共享一个浏览器，比如远程一起看视频、协作调试、或者给客户做交互式演示，n.eko 值得尝试。但如果你只是偶尔需要从外部访问家里的浏览器，那可能太重了，一个简单的 VNC 或 Guacamole 更省事。在正式采用前，先验证三件事：第一，你的服务器能否开放 WebRTC 所需的 UDP 端口，或者你能否配置 TURN 服务器；第二，容器里跑的浏览器是否满足你的插件和性能需求，比如硬件加速可能不可用；第三，多用户同时操作时，你的团队能否接受没有细粒度权限控制的现状。项目本身在持续迭代，v3.1.5 是最新版本，但未来功能方向并不保证。

编辑结论

n.eko 适合那些需要多人实时共享一个浏览器或桌面的团队，比如远程协作、在线教学、看片聚会，或者想把自己的 web 应用嵌入虚拟浏览器的开发者。不适合只想一个人偶尔远程开个浏览器的用户，因为要维护 Docker 容器、处理 WebRTC 的 NAT 穿透，还要承担虚拟桌面带来的 CPU 和内存开销。在采用之前，先确认你的网络环境能否让 WebRTC 直连，或者准备好 TURN 服务器；再检查容器内运行的浏览器或应用是否支持你需要的音频输入输出。若只是单人远程桌面，Apache Guacamole 走客户端渲染可能更轻；但若要多人实时同步操作，n.eko 的 WebRTC 方案是更直接的选择。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes