论坛

Hi Chris,

我们检查了您的服务器，好消息是：文件系统没有损坏，您的数据完整无缺，不需要进入救援模式。

实际发生的情况是：操作系统因内存耗尽而死机（内核在上次开机时记录了一连串的 OOM kills）。您进行的重启以及仪表板上的重启指令都有被接收，但关机程序本身卡住了——机器直到 09:45 UTC 才完成关机，并于 09:46 UTC（即您发文后）重新启动。自那时起 SSH 已可连接，我们可以看到从 09:47 UTC 开始有来自您网络的活动连接，因此您应该已经可以访问了——请趁现在一切正常时，将那 9 个项目文件夹中的工作内容推送到远程。磁盘状态健康（150G 中使用了 26G，根文件系统挂载正常，没有错误）。“Transport endpoint is not connected”的错误信息并未出现在上次开机的系统日志中，因此这很可能是来自您某个工具中的 FUSE 挂载，而非磁盘损坏。

服务器上有两件事仍会导致 Zeabur 仪表板异常，需要您进行调整：

1. 防火墙阻挡了 Kubernetes API。 ufw 已启用且默认拒绝所有传入连接，而 6443 端口未在允许列表中。Zeabur 的控制平面需要该端口来读取服务器状态并列出您的项目——这就是为什么尽管 VM 显示为运行中，但“状态”选项卡仍无法使用的原因。解决方法：sudo ufw allow 6443/tcp
2. nginx 占用了 80/443 端口。 如您所提，您的主机 nginx 占用了这些端口，导致 Zeabur 的 ingress controller 已经崩溃重启（crash-looping）数周。任何绑定到 Zeabur 的域名在 80/443 被释放前都无法正常路由。

如果服务器再次发生类似死机，请优先检查内存——该机器拥有 8GB 内存且没有 swap，因此一个高负载的进程就可能锁死整台机器。增加 swap 或限制高负载进程可以防止此类问题再次发生。