家庭服务器实战手册

主题

暴露公网之前，先做一次「体检」 ​

起因很平常：我在应用中心装了一个文件列表程序（OpenList），用来把云盘挂到 NAS 上。装完能用，然后我就忘了。

几周后我偶然翻它的日志，看到这么一行：

2026-xx-xx 21:40:10  Web UI: login success  from 42.49.109.18

一个陌生的公网 IP，一分钟前，登录成功。

我赶紧去试默认口令 admin/admin——能进。多盘挂载、云盘账号密码明文躺在配置里，全都在这个页面后面。

这个应用从装好那天起就暴露在公网，口令是出厂默认，我忘了它存在，而扫描器没忘。

这篇是那次事故之后固定下来的检查清单。新装任何对外可访问的服务之前、以及每隔一段时间复查，都过一遍。

第一步：它到底开了哪个端口 ​

bash
# 看一个应用监听了什么
ss -ltnp | grep -i <应用名>

# 或者不知道进程名，直接看所有对外监听
ss -ltnp | grep -v 127.0.0.1

判断标准很简单：监听地址是 0.0.0.0 还是 127.0.0.1。

  • 0.0.0.0:5525 —— 所有网卡都听，局域网能访问，做了端口映射就是公网能访问
  • 127.0.0.1:8080 —— 只有本机能连，外面要用就得走反向代理（这是好的默认姿势）

很多"一键安装"的应用默认是第一种。

第二步：公网上真有人访问得到吗 ​

端口监听是内因，端口映射是外因。两个都成立才真的暴露。

内网地址上出现公网来源的访问记录，就说明映射已经通了：

bash
# 应用自己的访问日志，找非内网来源
grep -Eo '([0-9]{1,3}\.){3}[0-9]{1,3}' /var/log/apps/<应用>.log | sort | uniq -c | sort -rn | head

内网段（192.168.、10.、172.16-31.）之外的都是外网。家用宽带下出现外网 IP 访问一个"我自己用的"服务，只有两种可能：端口映射开了，或者有台设备把它转发出来了（隧道、DDNS、UPnP）。

⚠️ 注意：日志里出现自己 NAS 的局域网 IP不一定可疑。我一开始就误判过一次——那些来自 192.168.0.36（本机）的 WebDAV 请求，其实是 NAS 自带的文件管理器在挂载本地服务，是好事，不是入侵。

第三步：口令是不是出厂的 ​

这一步最容易被跳过，也最容易出事。

bash
# 直接试默认口令，能进就是问题
curl -s -X POST http://127.0.0.1:5525/api/auth/login \
  -H 'Content-Type: application/json' \
  -d '{"username":"admin","password":"admin"}'

不要相信"我装的时候设过密码"。 有的应用第一次启动会生成随机密码写在日志里，你从没看过；有的升级会重置成默认值；有的"默认管理员"和"你自己建的账号"是两套。

第四步：谁在依赖它 ​

决定能不能直接卸载/关掉之前，先确认没有别的东西指着它：

bash
grep -rl "5525" /etc/nginx /etc/systemd /etc/cron* 2>/dev/null
docker ps -a | grep -i <应用>
crontab -l 2>/dev/null | grep -i <应用>

还要看隧道/反代那边有没有一条 ingress 指向它。这一步的目的不是留住它，而是避免关掉之后连带弄坏别的服务。

我那次排查的结论是：没有任何东西依赖它。那些云盘挂载点（/vol02/1000-1-xxxx）走的是 NAS 系统自带的云存储服务，和这个应用无关——这个区分很关键，否则会以为"卸了云盘就掉了"。

第五步：卸载 ≠ 清理干净 ​

应用卸载了，残留通常分三类，处理方式完全不同：

1. 应用自己的数据目录

/vol1/@appdata/<应用>、@appconf、@apphome、@appmeta 这几个目录的属主是那个应用自己的用户，普通账号没有权限删。会看到：

drwx------ 3 OpenList OpenList 4096 ...

如果 NAS 提供了"以管理员身份操作文件"的服务（很多系统有，比如带 root 文件服务的 CLI），可以借它删；否则只能进系统界面删。

2. 云存储挂载的残留目录

这类目录删不掉是正常的——不是权限问题，是云存储管理器还持有这条挂载记录。表现是删的时候报一个奇怪的 errno（我这边是 65280），目录还在。正确做法是先去系统的「远程挂载 / 云存储」里删条目，目录才会消失。

3. 系统日志

/var/log/apps/<应用>.log 及其 .gz 轮转文件通常属主是 root，普通账号删不动。这个影响不大，但要知道它在。

第六步：查一下它在背后做过什么 ​

这一步是我事后才学会的，很有用。很多 NAS 系统有一个全局事件日志库，普通用户就能读，记录所有文件操作：

bash
# 通用做法：找一个 sqlite 格式的事件日志
find /usr -name "*.db3" 2>/dev/null | head
sqlite3 /path/to/logger_data.db3 ".tables"

我用它查到了那几周的实际情况：有几次通过挂载点拷贝照片的操作，对应的应用日志里 PUT 返回 403 / 405（写入被拒），而 DELETE 成功了。

也就是说：我以为传上去的照片可能没传成功，而云盘里的示例文件确实被删了。 没有这个日志库，我只会看到"操作完成了"。

这份清单，一行版 ​

对外暴露一个服务之前：

  1. ss -ltnp 看它监听 0.0.0.0 还是 127.0.0.1
  2. 看日志里有没有外网来源
  3. 试一次出厂默认口令
  4. grep 一遍谁依赖它
  5. 记住卸载后有三类残留
  6. 事后查事件日志，确认它真正做过什么

教训 ​

不是"不要装应用中心的应用"——那些应用确实好用。真正的教训是：

装东西的成本不只是安装那几分钟，还有"你以后得记得它存在"。

我忘了它存在，扫描器没忘。它能被公网访问、口令是 admin/admin、身后是明文云盘凭据——这三件事任意一件单独出现都还好，叠在一起就是"谁扫到谁能进"。

所以现在的默认姿势改成：

  • 能只监听 127.0.0.1 就只监听，对外统一走隧道/反代（只开一个入口好审计）
  • 装完立刻改口令，或者干脆只保留一个自己建的账号
  • 每季度翻一次应用列表，问一句"这个我还在用吗"

一句话版本：暴露公网的代价不是带宽，是"你必须记得它还活着"。不记得的，就下线。