时间： 2026-02-10（寒假回家第一天） 坐标： Home Server 状态： 修复完成 ✅
🏠 碎碎念
昨晚上刚放寒假回家，本来兴致勃勃地把吃灰的显示器支架搭好，拿出了我的 K380 和新买的小键盘，准备远程连上我的 Home Server 大干一场。
结果刚给服务器重启了一下，发现我的网盘服务 OpenList 居然挂了。网页打不开，Nginx 直接甩给我一个 502 Bad Gateway。
作为一个成熟的“折腾党”，第一反应当然是：修！ 但这个看似简单的故障，排查过程却挺有意思，甚至有点“离奇”。
🔍 故障现象：沉默的报错
服务器重启后，OpenList 服务没有正常拉起。我习惯性地先看 Systemd 状态：
Bash
sudo systemctl status openlist
yanchang@yanchang-Home-Server:/opt/openlist$ sudo systemctl status openlist.service
× openlist.service - OpenList service
Loaded: loaded (/etc/systemd/system/openlist.service; enabled; preset: enabled)
Active: failed (Result: exit-code) since Tue 2026-02-10 11:17:48 CST; 6min ago
Duration: 86ms
Process: 5637 ExecStart=/opt/openlist/openlist server (code=exited, status=1/FAILURE)
Main PID: 5637 (code=exited, status=1/FAILURE)
CPU: 56ms
2月 10 11:17:48 yanchang-Home-Server systemd[1]: Started openlist.service - OpenList service.
2月 10 11:17:48 yanchang-Home-Server openlist[5637]: INFO[2026-02-10 11:17:48] reading config file: /opt/openlist/data/config.json
2月 10 11:17:48 yanchang-Home-Server openlist[5637]: INFO[2026-02-10 11:17:48] load config from env with prefix: OPENLIST_
2月 10 11:17:48 yanchang-Home-Server openlist[5637]: INFO[2026-02-10 11:17:48] init logrus...
2月 10 11:17:48 yanchang-Home-Server openlist[5637]: start HTTP server @ 0.0.0.0:5244
2月 10 11:17:48 yanchang-Home-Server systemd[1]: openlist.service: Main process exited, code=exited, status=1/FAILURE
2月 10 11:17:48 yanchang-Home-Server systemd[1]: openlist.service: Failed with result 'exit-code'.结果显示状态是 failed，退出码是 1。
但最坑爹的是，Systemd 的日志里只有一句轻飘飘的： start HTTP server @ 0.0.0.0:5244
然后就戛然而止了。没有任何 Error，也没有 Panic，程序就像断电一样直接消失了。这就很难受了。
🕵️♂️ 排查过程：抽丝剥茧
1. 第一嫌疑人：端口冲突
OpenList 默认监听 5244 端口。因为我之前折腾过 Docker 版的 AList，第一反应是不是 Docker 没关干净，端口打架了？
我敲了命令：sudo netstat -tulpn | grep 5244
结果是空的。没有任何进程占用该端口。看来不是端口的问题，事情没那么简单。
2. 关键一步：脱离 Systemd 手动运行
经验告诉我，Systemd 有时候会吞掉程序的标准输出（stdout），导致我看不到核心报错。我决定直接进目录，手动运行二进制文件，看看它到底怎么死的。
Bash
cd /opt/openlist
sudo ./openlist server
神奇的一幕发生了：程序打印完初始化信息后，直接**“闪退”**回了命令行。控制台依然没有任何报错红字。
这说明一个问题：报错信息被重定向到了文件日志里。
3. 真相大白：日志里的秘密
我翻出了 OpenList 的配置文件 config.json，找到了日志路径，然后查看最后几行：
Bash
tail -n 10 /opt/openlist/data/log/log.log
终于，凶手找到了！日志最后一行赫然写着：
FATA[2026-02-10 11:27:37] given FTP public host is invalid ... lookup home.yanchang.xyz ... no such host
💡 根因分析：蝴蝶效应
看到 no such host，我瞬间反应过来了，逻辑链条完美闭环：
配置埋雷：我的 OpenList 配置文件里一直开着 FTP 功能，并且为了支持被动模式，我以前配置了一个外部域名
home.yanchang.xyz让它去自动解析公网 IP。环境变迁：重点来了，
yanchang.xyz这个域名我几天前刚让它彻底过期因为赎回期过了彻底停止解析（因为我现在全面换用了十年的yanchang.cc）。触发崩溃：服务器重启后，OpenList 启动时尝试去 DNS 解析这个旧域名。因为域名已注销，DNS 解析失败。程序判断这是致命配置错误 (Fatal Error)，直接“自杀”退出。
一个 Web 网盘服务，竟然因为 FTP 的域名解析失败，导致整个 HTTP 服务都起不来。 😂
✅ 解决与反思
既然 FTP 功能我几乎不用（主要是为了兼容旧设备），最直接的方案就是关掉它。
修改 /opt/openlist/data/config.json，把 ftp 下面的 enable 从 true 改成 false。
保存，重启服务：
Bash
sudo systemctl restart openlist
搞定！网页秒开，一切恢复正常。
📝 这事儿给我的教训：
Systemd 不是万能的：看不到报错时，一定要去翻应用原本的日志文件，或者手动运行试试。
定期清理“技术债务”：更换域名后，不仅要改 Nginx，还得地毯式搜索一下服务器里的旧配置文件。这次就是漏网之鱼导致的“惨案”。
最小权限原则：不用的功能（比如 FTP），最好在配置里显式关闭，少一个功能就少一个故障点。