自架一臺能在網頁裡打開的遠端 Chrome，選項一直不多。noVNC 那套把 VNC framebuffer 一格一格丟進 Canvas，字型永遠糊一層、鍵盤延遲穩定超過半秒；Apache Guacamole 走 RDP/VNC 再翻譯成自家的 Guacamole Protocol，每張畫面重新壓 JPEG，多人共用時控制切換靠伺服器排隊處理。真正把「虛擬瀏覽器」當基礎建設在做的，過去多年剩下 Kasm Workspaces 這類商用方案，Community Edition 撐得很勉強、真正好用的功能全收在訂閱裡。
Neko 是 m1k1o 從 2020 年寫到現在的自架虛擬瀏覽器，用 Go 加 pion WebRTC 加 GStreamer 三支開源專案，把 X11 桌面、PulseAudio 音訊、瀏覽器行程一起收進 Docker 容器，畫面走 WebRTC 而非 HTTP polling。2026 年 9 月上架的 v3.1.5 補上 H.265（HEVC）編碼、對 NVIDIA 590+ 驅動改用 nvautogpuh264enc 硬體加速、XInput 觸控裝置支援，同時把 v3.0 引入的 REST API、OpenAPI 3.0 文件、Prometheus 指標整套穩定下來。Apache 2.0 授權，GitHub 上兩萬兩千顆星，一臺 VPS 加 Docker Compose 就能開起來。
VNC 那層 framebuffer 為什麼永遠追不上網頁
VNC 協定當年設計來遠端 X 桌面，資料模型是「畫面上這塊矩形變了、重畫一次」。這種思路在畫 Emacs、xterm 這類低更新頻率的視窗很合理，但現代網頁 60fps 的動畫、CSS transform、Canvas 動態渲染，全部都是全屏局部同時更新。VNC framebuffer 每秒得重繪整個桌面的一半，走 TCP 又不允許 packet loss，於是延遲堆疊、頻寬爆炸。
Guacamole 的方案是把 VNC/RDP 反向轉譯成 Guacamole Protocol，前端用 HTML5 Canvas 依指令繪圖，畫面資料靠 JPEG 或 PNG 傳輸。畫質比 noVNC 好但仍然重壓 JPEG、輸入事件走 WebSocket 排隊處理，兩人以上同時操作就會出現互卡的情況。這條路徑的本質限制是 TCP 底層的 head-of-line blocking，網頁 60fps 撐不住。
Neko 走完全不同的路：桌面畫面就是視訊串流，走 WebRTC 的 RTP over UDP，容忍 packet loss、支援 SVC 分層。這正是 Google Meet、Discord 語音、雲端遊戲平臺都選 WebRTC 的原因。同一顆決策套在虛擬瀏覽器上，就是三倍畫質、五分之一延遲。
GStreamer 把桌面推進 WebRTC 這條 pipeline
Neko 的資料流其實不複雜：容器內起一個 Xorg server 加 PulseAudio，把瀏覽器（Chromium、Firefox、Brave、Tor Browser、Vivaldi 等各有一支 Docker image）放進這個 X 桌面，Go 寫的主程式呼叫 GStreamer 讀 X 視訊訊號跟 PulseAudio 音訊，經過編碼後透過 pion 打包成 RTP，走瀏覽器原生的 WebRTC PeerConnection 送給客戶端。
編碼選項在 v3.1.5 完整了：VP8、VP9、H.264、H.265 四選一，其中 H.264 與 H.265 都支援 CPU 軟編以及 NVENC 硬體編碼。單卡 T4 或 A2000 級別的 GPU 能同時開四到六個 1080p 60fps 的瀏覽器會話。文件標示的 <300ms 是這條 pipeline 的理論值，實測情境下大多落在 50 到 120 毫秒之間。
v3.0 引入的 simulcast 更關鍵：同一個桌面同時編出高中低三種畫質串流，客戶端根據頻寬拉不同的層，中間 WebRTC bandwidth estimation 動態切換。這條設計消除了 Guacamole「一次崩潰全部凍住」的體驗，行動網路使用者也能拿到合理的畫面。
共用一臺瀏覽器：host、admin、user 三層角色
Neko 的多人模式並不是每個人各開一個 tab，而是所有人共同看同一臺桌面、同一顆游標。這個設計對觀影派對、遠端教學、共同除錯這幾個情境很合適：
- host 手上有滑鼠鍵盤控制權，其他人跟著看
- admin 能強制轉移控制權、踢人、鎖房、關麥
- user 可以請求控制，host 同意後接管
管理員介面走 REST，v3.0 起有 OpenAPI 3.0 文件，可以從 CI、Bot、外部服務觸發開房、送 URL、抓螢幕截圖。搭配 v3.1 的麥克風 passthrough 與剪貼簿自動同步，遠端桌面能當一臺真的協作工作站用，而不只是「一起看網頁」。
Neko 跟 Steel Browser 不是同一種東西
近兩年 AI Agent 起飛，Browserbase、Steel Browser 這類「無頭瀏覽器即服務」很紅。這兩者跟 Neko 面向的問題不同：Steel 是給 AI Agent 用的 CDP 端點，沒有人盯著螢幕看，重點在 stealth 與 session 管理；Neko 是給人用的，重點在畫面推流跟輸入延遲。
實務上兩者常常一起部署。Steel 服務生產環境的自動化任務，Neko 提供人類介入的介面。當 Agent 撞到 Cloudflare Turnstile、CAPTCHA 或需要 SSO 二次驗證的時候，把 Chromium session 從 Steel 遷到 Neko、丟連結給人接手，這條 handoff 就成立。同一個 Chromium profile 目錄互相掛載即可，兩邊都吃 CDP。
上機該注意的幾件事
最小可行配置是 4 vCPU、8 GB RAM 的 VPS 加 Docker Compose，H.264 軟編會吃掉兩顆 CPU 核心，剩下的算力給瀏覽器本身。想開多人並發或跑 4K，加一顆 T4 或 A2000 把編碼扔進 NVENC，同一臺機器能開到六到八個並發會話。
WebRTC 需要 UDP 加公開 IP，這是很多自架失敗的第一坑。Neko 預設會用 3478 起算 200 個 UDP port 做 media 傳輸，這批 port 要在防火牆放行；VPS 若在 NAT 後面（家用場景常見），還得掛一支 coturn 當 TURN server 幫忙打洞，或收斂到 v3 的 screencast TCP fallback，代價是延遲會被拉到 500ms 以上。
多房間需求要靠上層 orchestration。官方的 neko-rooms 幫忙生 docker-compose、管房間生命週期，是實質的多實例管理平面，用來搭內部工具站或小規模服務綽綽有餘。要走到雲端規模，把 neko-rooms 換成一支 Kubernetes operator 更好維護。
選型建議
自架虛擬瀏覽器這件事終於有一條不用付訂閱、不用忍受畫質糊掉的路。Neko 3.1 把 WebRTC pipeline、硬體編碼、清楚的角色模型、開放的 REST API 湊齊，Docker Compose 一份就能上線。想給海外辦公室開一臺被審計、cookie 不會外流的瀏覽器工作站，選它；想給 AI Agent 加人類 fallback、想要一臺共享觀影用的雲端 Chrome，也選它。真正該考慮商用 Kasm 的場景，剩下 Windows-based application streaming 或大企業級 IdP 深度整合這兩塊——Neko 的路線圖上並沒有。
NCSE Network 的臺灣是方電訊機房 VPS 提供獨立公開 IPv4 與充足 UDP 埠位配置，Intel Gold CPU 加 NVMe SSD 是把 Neko 跑順的基本盤；要 NVENC 硬體編碼的場景，機房代管方案能把 GPU 卡直接掛進機器裡。細節可以到 ncse.tw 查看。
