在遠端伺服器上開一個 tmux session，離線之後還能回來，這件事幾乎是每個 Linux 管理員的肌肉記憶。但 tmux 從 2007 年推出到現在，內部結構跟操作邏輯沒動過幾次——Ctrl+b 當 prefix、.tmux.conf 用自己的迷你語言寫、外掛全靠 shell script 跟 tpm 這個第三方工具湊起來。Zellij 從 2021 年出現就在挑戰這套設計，2026 年 3 月釋出的 0.44 版把終端分享、Windows 支援、CLI 自動化補齊之後，第一次讓「用它取代 tmux」在遠端 VPS 環境變成一個真的選項。
Zellij 用 Rust 寫，走 MIT/Apache 雙授權，主打「工作區」而不是「多工器」。多出來的一層抽象讓它同時處理 pane 排版、外掛、佈局檔、遠端 session，變成一個像 tmux 加 tmate 加 vim script 集合的東西。這篇拆解它跟 tmux 幾個關鍵的斷層——狀態列取代 prefix 記憶、KDL 佈局檔取代 shell script、HTTPS 遠端 session 取代 tmate——以及在臺灣的 VPS 情境下該不該換過去。
tmux 學習曲線的問題不是「難」，是「不可見」
新手第一次用 tmux 幾乎沒有例外會遇到同一件事：按什麼都沒反應。Prefix key 這個設計來自 GNU Screen 時代，那時候終端沒辦法區分 Ctrl+a 跟 shell 內建 Ctrl+a（跳到行首）的意圖，所以只能設計成兩鍵組合。到 2026 年，這個限制早就不存在，但 tmux 保留了 Ctrl+b，然後每個教學都建議改成 Ctrl+a，接著新使用者去 stackoverflow 抄一份幾百行的 .tmux.conf，複製貼上直到能用。
真正的問題不是 prefix key 本身，而是這套模型完全沒有可見性。按 Ctrl+b 之後可以做什麼？答案不會出現在螢幕上，只在 man tmux 的第 200 頁跟散在網路上的教學裡。新使用者背了三十個組合鍵才勉強能日常使用，這條學習曲線把很多本來可以用 tmux 的人擋在門外。
Zellij 的做法直接把這個問題拆掉——狀態列在螢幕最下方一直顯示當前模式的所有可用按鍵。預設處於「Normal」模式，按 Ctrl+p 進 pane 模式，狀態列會即時列出所有 pane 相關操作：n（新開 pane）、x（關掉）、h/j/k/l（切換方向）、r（換分割方向）、f（切換浮動）。按 Esc 回到 Normal，再按 Ctrl+t 進 tab 模式，狀態列再變一次。整套操作邏輯不用背，看著螢幕就能用。
代價是狀態列吃掉一行螢幕空間，重度使用者可以在設定裡調成 compact 或完全隱藏。但預設值是為了讓新使用者不用抄別人的 .conf 就能上手，這個取捨對推廣新工具來說是對的。
KDL 佈局檔把「開機腳本」變成純資料
tmux 使用者要在開機時自動開好三個 pane 分別跑 htop、logs、shell，通常靠一支 shell script 呼叫 tmux new-window、tmux split-window、tmux send-keys 這一連串指令，寫完自己都不想維護。這件事在 Zellij 是純資料——寫一個 KDL 檔就好：
1 | layout { |
KDL 是 Zellij 從 0.32 版開始改用的設定語言，取代原本的 YAML。選擇 KDL 而不是 YAML 或 TOML 有幾個明確理由：KDL 的縮排是選用而不是語意，這件事對描述樹狀結構（像 pane 巢狀分割）比 YAML 好用；KDL 原生支援節點屬性跟子節點的組合，寫出來的 layout 讀起來像 XML 但沒有結束標籤的雜訊。實務上維運起來的差異是，一個複雜的多 pane 佈局在 tmux 是一支 100 行的 shell script，在 Zellij 是 30 行的 KDL 檔——後者能放進 git、能給團隊共用、也能在啟動時傳給 zellij --layout 直接載入。
值得一提的是 command pane 這個機制。指定 command="htop" 之後，那個 pane 不是 shell 也不是 htop——它是一個可以按 Ctrl+c 中斷、按 Enter 重跑的容器。這解決了 tmux 使用者常見的痛點：跑起來的服務中斷之後，那個 pane 就變成一個空的 shell，要手動重新輸入指令。Zellij 的 command pane 記得原本的指令，重跑一次不用打字。
0.44 把 tmate 那條路走完
跨過機房或跨過 NAT 分享終端 session 這件事，tmux 使用者過去只有 tmate 一條路——它是一個 tmux 的分支，接上一個中央伺服器做中介，其他人 SSH 到 wss.tmate.io 就能連進來看。這套流程能動，但架構上有兩個明顯缺點：所有流量都經過第三方伺服器，即便是自架的 tmate-server 也要另外維護一個中央節點；再者授權限制讓自架版本不能拿來做商業服務。
Zellij 0.44 把這一整套用另一個模型解掉。啟動時多下一個 zellij web 指令，它會在指定 port 起一個內建 HTTP 伺服器，接受 HTTPS 連線，透過 token 認證讓別人從瀏覽器或另一個 zellij 客戶端連進來。整個機制不需要第三方中介伺服器，全部跑在同一個 VPS 上——瀏覽器連上 https://server.example.com:8082/my-session 就直接進到 session 裡，加上正確的 token 就能操作。
Read-only token 是 0.44 另一個重點。同一個 session 可以同時發出可讀寫的 token 給協作者、只能觀看的 token 給示範對象。這在教學、支援、Pair programming 情境有明確用處——把 read-only 網址丟給客戶或學員，他們能看終端狀態但改不到任何東西。tmate 早就有類似機制，Zellij 的差別是這件事整合在同一個 binary 裡，不需要額外元件。
HTTPS 遠端 session 預設不會開，需要在設定檔加 web_server = true 明確啟用。這個保守預設避免使用者在不知情下開放外部連線，憑證走 Let’s Encrypt 或自訂 CA 都可以。
Attach 到另一臺機器不用再開 SSH
過去 tmux 使用者連到遠端 session 的標準流程是：ssh user@host 進到伺服器，tmux attach -t work 接上去。這條路徑要求本地機器有 SSH 存取、金鑰設定完整、目標主機的 sshd 正常運作。Zellij 0.44 加了一個更直接的做法：zellij attach https://server.example.com:8082/work 直接從本地終端接上遠端 session，走 HTTPS 底層、token 認證，中間完全不經過 SSH。
這個設計在幾個場景有實用價值：共用終端環境不用每個人都發 SSH 帳號，管理員發 token 就能授權；穿透只放行 443 port 的企業 firewall；平板或手機瀏覽器直接開網址就能接進去，不用裝 SSH 客戶端。
當然這條路徑取代不了 SSH——金鑰驗證的信任模型、port forwarding、SFTP，Zellij 都沒有。它的定位是「SSH 之外多一條路徑」。實務建議是把 zellij web server 綁在 localhost，配合 Caddy 或 Nginx 反向代理，讓 HTTPS 憑證跟認證邏輯集中在 web server 那一層。
WASM 外掛把生態系從 shell script 拉出來
tmux 外掛的實作方式歷史包袱很重——本質上是一堆 shell script 加上 tpm（tmux plugin manager）這個第三方工具湊起來。要寫一個顯示 CPU 用量的 status bar 元件，作者要用 tmux 特定的 shell 語法呼叫外部指令、解析輸出、格式化字串，然後每個外掛都是獨立的 script 跟設定檔混在使用者的 .tmux.conf 裡。這套模型能動，但外掛之間常常互相衝突、效能不好、也沒有沙箱。
Zellij 從一開始就用 WASM 當外掛執行環境。0.44 版的 runtime 從 wasmtime 換成 wasmi，binary size 減少、跨平臺移植性提升。外掛用 Rust 寫是第一級公民，但任何能編譯到 WASM 的語言——Go、TinyGo、Zig、AssemblyScript——都能寫 Zellij 外掛。這件事對維運工具生態的影響不小：一個用 Go 寫的 Kubernetes pane（顯示叢集狀態）可以編譯成 wasm 檔，丟到 Zellij 就能跑，不需要重寫。
技術面上 WASM 帶來三個 tmux 外掛做不到的能力：沙箱隔離讓外掛跑錯不會弄爛整個 session；跨平臺分發只需要一個 wasm binary 就能在 Linux、macOS、Windows 跑；API 是型別安全的介面，外掛開發者能拿到明確定義的 event、state、command。實務上寫外掛的體驗更像寫 VS Code extension 或 Neovim 外掛，而不是寫 shell script。
0.44 擴充了外掛能做的事：讀取 pane 的 scrollback、標記 viewport 的文字、查詢環境變數、改 pane 顏色。這打開了新的整合方式——例如掃描 pane 輸出裡的錯誤訊息、把檔案路徑高亮成可點擊、按下直接在編輯器打開對應行號。
換過去的實際成本
Zellij 有明顯優勢，但實務決策要考慮幾個現實。
伺服器上不會預裝是最直接的問題。Debian 主線倉庫到 2026 年還沒收 Zellij，Ubuntu 24.04 之後才有 snap 版本。VPS 剛開機要用就得自己抓 tarball 或用 cargo install，tmux 幾乎所有發行版都預裝或一行 apt 裝好。可行的做法是把 Zellij 安裝好放進系統映像檔，或用 Ansible/Nix 自動化。
資源使用是另一個現實。實測閒置狀態下 Zellij 用 30 MB RAM，tmux 用 5 MB。對 512 MB 的最低階 VPS 值得留意，同時開好幾個 session 會吃掉幾百 MB。
既有 tmux 設定的遷移成本也不小。花了幾年調 .tmux.conf、記熟一整套鍵位，全部丟掉重學不是每個人都想付。Zellij 從 0.35 版之後才穩定可以日常用，0.44 才是第一次能認真考慮取代 tmux 的版本。
什麼場景該換、什麼場景不用
Zellij 適合幾個明確情境：日常工作有跨作業系統需求（Linux 伺服器加 Windows 工作站，0.44 之後 Windows 有原生支援）、常要跟他人分享 session（讀寫或只讀）、想寫自訂外掛整合工作流、或是新手還沒被 tmux 綁住的情況。這幾種場景 Zellij 都能提供 tmux 需要多個工具才能拼起來的體驗。
tmux 適合的情境還在：主要工作是 SSH 到不同的舊 Linux 伺服器（很多還在跑 CentOS 7 或 Debian 10，Zellij 靜態 binary 要靠 glibc 版本，老系統上不一定能跑）；已經有一整套 tmux 設定跟外掛熟到不用想；需要極低的資源開銷；或者純粹沒有換的動機。tmux 不會消失，跟 Zellij 是共存關係。
臺灣的 VPS 使用者社群偏好穩定跟低開銷，這點對 tmux 有利。但 Zellij 0.44 的遠端 session 對維運團隊跟跨地協作場景有明確吸引力。剛開始建立自己的伺服器工作流、或想把終端分享納入日常維運的話，Zellij 值得試——2026 年這個時間點已經跨過「拿來玩玩」跟「認真取代 tmux」的分界。
用 Zellij 或 tmux 之前，先有一臺穩定的 VPS 才是重點。NCSE Network 提供臺灣是方電訊機房的 VPS 服務，Intel Gold CPU 加 NVMe SSD，適合跑長時間的終端 session 跟自架服務。有興趣可以到 ncse.tw 了解方案細節。
