项目链接#

Demo

为什么会有 simpleUI#

前面其实已经写过 hy2、Trojan，还有 Clash 聚合分流之类的东西。最开始折腾这些的时候，我的想法很简单：一台服务器，一个脚本，能跑就行。

但节点一多，事情就开始变得不太优雅了。

今天 SSH 到这台机器看一下服务状态，明天去另一台机器改端口，过两天又要查日志、封 IP、重启服务、同步配置。每次都不是很难，但每次都要重新开终端、找命令、回忆这台机器上到底装了什么。次数多了之后，就有一种很强烈的感觉：

这些操作本来就应该有个面板。

于是 simpleUI 就这么长出来了。它不是那种一开始就设计得很宏大的项目，更像是我在日常维护节点时一点点攒出来的工具箱：哪里重复，哪里烦，哪里容易忘，就把它收进面板里。

它大概是什么#

SimpleUI 是一个面向多服务器代理节点运维的轻量 WebUI。它目前主要围绕 Hysteria2、Trojan 和一些 sing-box 常见协议做管理，把服务器接入、节点部署、状态同步、客户端封禁、远程工具、终端维护这些东西放到同一套控制面板里。

简单说，它不是 Clash/Mihomo 的替代品。Clash 负责本地怎么分流、怎么选节点；simpleUI 更偏向上游一点，负责这些节点在服务器上怎么部署、怎么维护、怎么发现、怎么恢复。

现在项目大致由几块组成：

• Vue 3 前端，负责面板和交互。
• Node.js / Express 控制面，负责 API、任务流、认证和调度。
• 远程 hook agent，负责在被管理服务器上执行维护动作。
• Electron 桌面壳，可选，想当本地桌面工具用也可以。

听起来有点像“控制台”，但我更愿意把它理解成一个比较清醒的运维工作台：它不替你假装服务器没有复杂性，只是把复杂性摆到更容易看见、更容易处理的位置。

我最在意的点#

做这个项目的时候，我其实不太想只做一个“按钮很多的面板”。按钮当然可以堆，但如果底层流程不稳，最后只会变成一个更漂亮的危险开关。

所以 simpleUI 里面有几个我比较在意的设计。

它适合谁#

如果你只有一个节点，而且一年也不怎么改，那直接 SSH 进去维护完全够用，甚至更简单。

但如果你有多台服务器，节点协议也不止一种，还经常需要查状态、重启、换配置、做封禁、跑诊断脚本，那 simpleUI 就会变得很顺手。它特别适合个人或小团队自用，不太像那种面向商业用户系统的“机场面板”。

我写它的出发点也不是做一套完整的用户计费系统，而是解决我自己的一个真实问题：我想更轻松地管理自己的节点，而且希望这个过程可看、可控、可恢复。

一些折腾痕迹#

simpleUI 这个项目其实不是一次写完的。中间经历过不少“看起来差不多了，结果一上真实场景就露馅”的时刻。

比如 Electron 打包之后，开发环境能跑，发行包里却缺运行依赖；比如节点同步逻辑一开始没处理好远端身份，导致同一个节点重复出现；再比如远程 hook、终端、命令执行这些功能做起来很爽，但安全边界也必须跟着补上。

这些问题修起来不一定浪漫，但它们让项目慢慢从“能跑”变成“比较能放心地跑”。我现在越来越觉得，真正有用的工具不是第一次 demo 的时候最亮眼，而是过几天、过几周，你还愿意继续用它。

后面想继续做什么#

目前 simpleUI 还只是一个早期项目，很多地方仍然可以继续打磨：

• 支持更多协议和更稳定的配置识别。
• 做更清楚的批量操作和服务器分组。
• 把备份、导入、迁移流程做得更舒服。
• 继续加强远程 hook 的升级、回滚和诊断能力。
• 让桌面端和 Web 端的使用体验更统一。

这些东西不一定会一下子全做完，毕竟项目最好还是跟着真实需求走。哪里真的痛，就先修哪里。

结语#

simpleUI 对我来说不是一个“炫技项目”，更像是把自己日常折腾代理节点时积累的麻烦，慢慢整理成一个能复用的工具。

它没有试图把运维变成魔法，也不假装服务器管理可以完全无脑。它只是把那些反复出现的 SSH、脚本、日志、状态刷新和服务操作，放进一个更直观的界面里。

如果说以前是手动挡，那 simpleUI 至少让我不用每次都在终端里重新摸方向盘。

照例，相关技术请用于合法学习、研究和自用维护场景。工具本身只是工具，怎么用还是得自己负责。