1. 为什么我的个人服务器选了 Docker先说说我这几年折腾个人服务器的感受。最早我在一台旧电脑上装了服务一个应用一套环境今天装 Redis 要编译明天跑 Python 脚本要配依赖后来换机器迁移更是噩梦配置文件散落各处几个月前能跑的服务突然就起不来了。直到我把所有应用切到 Docker 之后这套流程才彻底变清爽。这篇文章想分享的就是我个人服务器上真正在用的、适合家庭环境和自托管场景的 Docker 项目集。如果你有一台小主机、旧笔记本、NAS 甚至云服务器想把它变成下载机、媒体中心、监控看板、密码管理器或者自动化任务平台这篇文章可以直接当清单用。适合的人包括刚入手 NAS 的新手、厌倦了在裸机上折腾环境的开发者、以及想把家里那些零散服务统一管理起来的实用派玩家。Docker 对个人服务器最大的价值不是“跑得多快”而是“换环境不慌”。一个容器打包了应用本身和它依赖的所有东西在 A 机器上跑起来什么样搬到 B 机器上还是什么样。这意味着你可以在电脑上先试跑觉得稳定了再部署到服务器也可以放心折腾系统坏了重装系统后一条命令把服务全部拉回来。1.1 个人服务器选 Docker 的三个决定性理由第一个理由是隔离。以前我一个服务中毒或者配置写错可能会拖垮整个系统。容器化之后每个应用跑在自己的独立空间里就算某个容器崩了日志打满了也不会影响其他服务。对于个人服务器这种“平时没人盯着”的场景这是非常大的安全感来源。第二个理由是回滚简单。我经常升级镜像版本升完发现新版本有毛病在 Docker 里只需要重新指向旧镜像再启动一次几十秒就回去了。裸机上做版本回退可能要翻备份、改配置、重新编译搞不好就是半天。第三个理由是迁移方便。后来我把服务从一台旧主机搬到 N100 小主机整个迁移过程就是旧机器上docker ps看跑着什么新机器上执行几条docker compose up -d再把数据目录同步过去完工。没有路径依赖没有环境适配问题。对个人用户来说这种“可复制性”太珍贵了。1.2 环境选型先想清楚你的服务器是什么平台Docker 虽好但先要确认你的硬件平台。绝大多数 Docker 镜像都提供linux/amd64和linux/arm64两种架构。x86 的小主机、老台式机跑 amd64 没问题ARM 平台的树莓派、部分 NAS 和国产小主机应该优先选 arm64 镜像。如果你不太确定直接运行docker info看Architecture那行心里就有数了。还有一类特殊平台比如龙芯的 LoongArch 架构这类 CPU 目前 Docker 生态的兼容性比较有限很多官方镜像没有对应架构。网上也有一些热心开发者做了适配但你要有“遇到问题自己改 Dockerfile 重新构建”的心理准备。普通用户我建议优先选 x86 或 ARM 平台生态成熟度差距很大。另外要区分一下场景。像 Docker Desktop 是给开发者在本机 Windows 或 macOS 上做开发调试用的它自带虚拟机层适合搞开发但不适合做长期跑服务的个人服务器。个人服务器上我更推荐用纯 Docker Engine配合 Portainer 或 1Panel 这类 Web 管理面板轻量、直观、不占太多内存。2. 第一梯队先把这些“刚需级”项目装起来个人服务器上最怕“装机两小时吃灰一辈子”。所以我推荐项目有一个原则不搞那些花里胡哨但用不上几次的东西先装那些每天都在后台运行、又不会给你添麻烦的“基建型服务”。把它们跑稳了再考虑进一步玩法。2.1 Uptime Kuma给服务器装了双眼睛Uptime Kuma 是一个开源监控探针我会为每个核心服务配置 HTTP、Ping 或者 TCP 检查比如路由器、DDNS、家里跑的几个容器、甚至公网服务都在一个面板上盯着。它有很好看的 Web 界面报警渠道支持邮件、Telegram、钉钉、企业微信机器人等多种通知方式。为什么个人服务器也需要监控因为很多服务平时不出声一坏就是默默坏了很久你才发现。比如 DDNS 掉了、某个容器内存泄漏Uptime Kuma 会在服务不可达的几十秒内把报警推给你省得你等发现问题时已经故障了几个小时。它的部署极其简单暴露 3001 端口映射一个数据目录完事。我自己的配置习惯是每分钟检查一次通知方式选 Telegram 的 bot这样手机能第一时间收到。如果你没有 Telegram用邮件也行。注意千万别把所有服务都挂在“本机 IP”上检查因为你得监控的是公网视角的可用性至少要有一个检查用公网域名确认经过路由器、反代不丢包。2.2 Nginx Proxy Manager反向代理没有想象中复杂反向代理对个人服务器来说真正的意义是“把 80 和 443 收拢到一个入口”。以前我要在 Nginx 里手写 server 块改一个站点就要 reload 一次配置错一个分号整个站点打不开。Nginx Proxy Manager简称 NPM把这件事拖到了图形界面里给每个域名或子域名填上转发的内部端口它就自动生成配置、自动签发和续期 SSL 证书。一个非常推荐的搭配是路由器把 80、443 端口转发到服务器然后 NPM 负责按域名把流量分发给各个容器。这样一来你只需要开放这两个端口其他容器的端口全部禁止外部访问。安全性直接高了一个档次管理体验也清爽很多。NPM 本身也是 Docker 部署依赖一个数据库容器。第一次进去填一下管理员账号之后所有“绑定域名 证书申请”的操作都能在 Web 上完成。实测下来很稳我跑了十来个映射一直没有出过问题。唯一的坑是升级版本时数据库结构可能变化所以升级前一定备份数据库目录。2.3 Watchtower自动更新这件事其实是双刃剑Watchtower 的作用是定时检查容器使用的镜像有没有新版本有就自动拉取并重新创建容器。把它配好后你的服务会一直保持比较新的状态不用隔三差五记着去docker pull。但我对自动更新的态度是挑容器用。像 Nginx Proxy Manager、Uptime Kuma 这类更新频率低、更新风险小的项目可以放进自动更新名单。而像数据库、密码管理器这种数据敏感型的应用我建议要么不启用自动更新设置只更新指定容器要么用一个通知机制在更新前通知你。Watchtower 启动时可以通过--label-enable配合容器标签来控制哪些镜像参与更新。也可以给每个容器加com.centurylinklabs.watchtower.enablefalse这个 label 跳过更新。我个人的策略是默认全部开启但关于数据库和密码库的项目会单独排除。别小看这一步数据库大版本升级带来的坑踩一次就明白了。2.4 Portainer 还是 1Panel管理面板怎么选个人服务器不装任何管理面板也能活但装了面板后很多操作会舒服很多。Portainer 是纯 Docker 管理工具它把容器、镜像、卷、网络、日志都整合在一个界面中。特别适合习惯原生 Docker 概念的人查看容器资源占用、进容器里敲命令、查看日志都很方便。国产的 1Panel 则是更全面的服务器运维面板不仅管理 Docker还带防火墙、文件管理、应用商店、计划任务等功能。它内置的应用商店里有不少常见应用比如 Nginx、MySQL、Redis、青龙面板等点一下就能部署对新手特别友好。我个人的建议是如果你只是冲着“管理容器”来的选 Portainer如果你想面板尽可能把整台服务器都管起来而且喜欢中文界面可以试试 1Panel。两个可以共存但内存小的情况下别装太多毕竟管理面板本身也在吃资源。3. 第二梯队让服务器从“有用”变成“好用”服务器只跑着监控和反代确实很稳但缺少“呀这玩意真实用”的时刻。这个梯队里的项目都是能让你每天主动打开服务器去用一下的东西也是我向朋友安利个人服务器时最常展示的部分。3.1 Alist把散落各处的网盘拢到一个页面Alist 是一个文件列表和网盘聚合工具它可以把本地目录、各种网盘和对象存储挂载到一个网页里统一访问支持 WebDAV 协议。也就是说你可以在浏览器里一个界面翻遍所有文件也可以在电脑上通过 WebDAV 挂载成一个本地磁盘。这个项目对国内用户特别实用的地方在于很多网盘的客户端既臃肿又限速而 Alist 可以帮你把文件统一管理起来配合下载工具还能实现“网盘文件直传到本地服务器”的自动流程。我自己就经常把一些临时文件传到某个网盘的特定目录然后在服务器上通过 Alist 抓取处理。部署 Alist 时需要挂载本地数据目录和你要访问的存储目录启动后默认 5244 端口首次启动用命令行设置管理员密码。要注意的是第三方网盘接口属于“民间适配”接口失效时需要及时更新容器版本所以建议开启 Watchtower 的自动更新。3.2 Navidrome自托管音乐库比想象中香如果你家里攒了不少无损音乐或 CD 抓轨文件Navidrome 可以把这些文件变成一个私人音乐平台。它支持多用户、多格式包括 MP3、FLAC、AAC 等手机端用第三方客户端比如音流、SubMusic连上去体验非常接近主流音乐 App。我为什么推荐它的原因其实是一个很具体的场景孩子睡前要听儿歌我很久以前存的那些音频文件放在硬盘里吃灰自从用 Navidrome 建了音乐库后手机打开就能放没有广告没有推荐算法没有“会员才能听”。这种彻底掌控自己数据的感觉很舒服。部署 Navidrome 时注意要把音乐目录挂载进容器它会扫描并建立索引所以第一次启动后耐心等一会儿。如果有大量中文歌曲的曲目信息比较乱可以在 Web 后台手动编辑它会把关联信息保存到自己的数据库里不会动你的原始文件。3.3 Stirling PDF一个容器解决所有 PDF 操作这年头几乎每个家庭都免不了跟 PDF 打交道扫描件转文字、合并几个文件、压缩体积、签字、拆分页面。Stirling PDF 是一个基于 Web 的工具集合把这些功能全部做成了网页版不需要安装任何桌面软件。它的优势是所有处理都在你自己的服务器上完成敏感的合同、证件材料不用上传到第三方网站。我们经常在搜索引擎里找“PDF 在线合并”之类的工具那些网站上传后数据去向不明放在个人服务器上就没这个担忧了。部署时比较吃内存JVM 应用大概要吃 300 到 500MB如果你的服务器只有 1GB 内存建议在docker-compose.yml里限制一下内存大小。界面默认英文但支持多语言在设置里可以切换成中文。有些高级功能需要额外的 Python 或 OpenCV 支持但常规操作开箱可用这个项目的更新频率很高同理建议开着自动更新。3.4 Vaultwarden密码管理器可以自托管密码管理器是我认为“越早部署越安心”的项目。Vaultwarden 是一个用 Rust 写的轻量级密码管理器服务端API 兼容 Bitwarden 客户端。简单说你可以在官方 App、浏览器插件里直接用自己的服务器地址所有密码数据都存放在自己手里。它不是官方 Bitwarden 服务器的替代品而是为自托管场景设计的轻量实现内存占用小、部署简单。官方版的 Bitwarden 对个人和小团队来说资源要求偏重Vaultwarden 一个容器就能跑实测 256MB 内存也能正常运行。部署时需要挂载一个数据目录并且强烈建议你在 NPM 里配好 HTTPS。密码库这种数据明文走 HTTP 是绝对不能接受的。Vaultwarden 的管理后台可以设置是否开放注册个人用建议关闭注册并开启两步验证。升级前务必备份数据目录里的db.sqlite3文件这玩意丢了就是所有密码一起没。4. 进阶玩法青龙面板和自动化不只是“定时任务”到这里你的服务器已经跑了不少服务管理也有面板了接下来就可以玩点更有意思的东西。个人服务器到后期真正的乐趣其实在于“把重复的事交给机器去做”定时任务、网页变化检测、智能家居联动这些都属于这一类。4.1 青龙面板定时任务这件事它可以做得优雅青龙面板是一个定时任务管理平台支持 Python、JavaScript、Shell 等脚本提供 Web 界面有任务执行日志、依赖管理和并发控制等功能。很多自托管玩家用它来做定时提醒、数据备份、签到提醒、接口巡检和自动化脚本调度。网络热词里经常提到“青龙 依赖管理”其实就是在说青龙面板里给脚本安装 Python 包或 Node 模块。你可以在后台可视化管理这些依赖而不必进入容器敲命令行。它的任务调度用标准的 cron 表达式比如每天凌晨 3 点跑一次备份脚本写成0 3 * * *保存即可。青龙的部署文件比较长因为它内部有多个服务和数据库可以用官方提供的 docker-compose 文件一键起也支持通过 1Panel 的应用商店安装。启动后会进入初始化界面设置好账号和密码后就能在 Web 端新建脚本、设置定时规则、查看日志。要强调的是用它管理自动化任务没问题但一定要用合规合法的脚本涉及破解、恶意采集、绕过商业系统限制之类的脚本不要碰。自己写脚本跑数据备份、家人共用资源的监控、定时提醒这些才是真正妥当的用法。4.2 Changedetection.io网页一有变化马上通知你这个工具的原理很简单定时抓取你指定的网页内容和目标快照对比有变化就发通知。你可以用它监测商品价格、监控某个页面公告、追踪文档更新、盯某个朋友的博客有没有新文章。它比 RSS 更广因为有些网页根本没有 RSS 订阅。我在实际使用中最常用的场景是监控某个产品页面的“有货”状态和一些部门网站的公示更新。以前都是隔几天手动刷一次现在它一有变化就推消息到手机。它的界面比较简洁填上 URL 和选择器就能用支持中文。部署时比较吃资源的是它会用浏览器渲染页面如果目标网站是 JavaScript 渲染的动态页面需要启用 Playwright 浏览器支持那样内存占用会明显上升。普通静态页面用默认的文本提取即可资源不足时不要开太多监控任务。4.3 Home Assistant让容器和家里设备联动如果你家里的智能设备比较杂不同品牌有不同 AppHome Assistant 可以把它们合并到一个控制台中。它可以接入各种协议包括 WiFi、蓝牙、Zigbee 等通过不同的插件把设备状态拉进来然后做自动化。比如“晚上 7 点灯自动打开”这种场景就是它的拿手好戏。Home Assistant 在 Docker 里跑的版本叫 Home Assistant Container不带官方操作系统只跑核心服务。如果你只想把它当作“智能家居中枢”这种方式够用。如果你想要更加完整的插件生态可以考虑 Home Assistant Supervised但那需要更系统级的权限一般个人服务器建议直接跑容器版。部署后记得访问8123端口完成初始化然后勾选你手头的设备类型。它对新手来说有一个陡峭但值得爬的学习曲线因为玩到后面你写自动化脚本时其实是在写 YAML 配置一份配置就能控制全家设备。对容器玩家来说还有一个额外福利Home Assistant 可以监控 Docker 容器运行状态比如某个容器挂了之后自动拉起或者跑一个自动化脚本重启它。5. 从零部署示例用 docker compose 一次跑起三件套前面推荐的项目有点多我来给你走一遍完整部署流程保证你照着做就能把服务跑起来。这里选三个组合来演示Uptime Kuma Nginx Proxy Manager Alist三者配合基本就是一个“看得见、进得来、翻得动”的个人服务中心。5.1 准备工作建目录和设置环境先在我的服务器上建好统一的配置目录我习惯把数据放在/srv/docker下每个应用一个子目录这样备份直接打包整个目录就行。mkdir -p /srv/docker/uptime-kuma mkdir -p /srv/docker/nginx-proxy-manager/{data,letsencrypt} mkdir -p /srv/docker/alist同时确认 Docker Engine 和 docker compose 插件是正常安装的。查看版本docker --version docker compose version如果你的 Docker 版本比较老希望后续部署顺畅建议先升级 Docker Engine。个人服务器只要不是跑生产环境用官方安装脚本升级是省事的选择。需要强调不要用docker run去裸跑所有服务虽然它也能跑但服务一多参数混乱、重启策略不一致的问题都会冒出来。docker compose 才是个人服务器管理容器的正确姿势。5.2 编写 docker-compose.yml在/srv/docker下建一个docker-compose.yml把三个服务写在一起version: 3.8 services: uptime-kuma: image: louislam/uptime-kuma:latest container_name: uptime-kuma restart: unless-stopped ports: - 3001:3001 volumes: - /srv/docker/uptime-kuma:/app/data npm: image: jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - 80:80 - 443:443 - 81:81 environment: - TZAsia/Shanghai volumes: - /srv/docker/nginx-proxy-manager/data:/data - /srv/docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt alist: image: xhofe/alist:latest container_name: alist restart: unless-stopped ports: - 5244:5244 volumes: - /srv/docker/alist:/opt/alist/data这几个参数值得展开说说。restart: unless-stopped意味着容器异常退出时会自动重启除非你手动停掉它这是个人服务器上所有常驻服务都应该设置的核心参数。ports是宿主机端口和容器端口的映射写在前面的3001、80、81是从外面访问用的端口在服务器上可能已经被占用需要注意调整。TZAsia/Shanghai这个环境变量很关键不设的话容器默认是 UTC 时区定时任务和日志时间都会对不上。5.3 启动、验证和常用命令在docker-compose.yml所在目录执行docker compose up -d docker compose ps如果一切正常你会看到三个服务都处于 running 状态。然后分别访问Uptime Kumahttp://服务器IP:3001Nginx Proxy Managerhttp://服务器IP:81Alisthttp://服务器IP:5244首次进入 NPM 要用默认账号adminexample.com和密码changeme登录然后立即修改。Alist 管理员密码要在容器里执行命令生成docker exec -it alist ./alist admin set 你的密码日常维护最常用的三条命令记在心里docker compose logs -f 服务名查看某服务日志docker compose restart 服务名重启某服务docker compose pull docker compose up -d更新所有镜像并重建容器。这基本覆盖了我 90% 的运维操作。5.4 部署完成后的第一件事把所有端口收起来三个服务跑起来后路由器上有 80、443、81、3001、5244 五个端口是开放的。其中 81、3001、5244 是管理界面和服务端口直接暴露到外网并不安全。第一件事就是在 NPM 里给它们配上子域名进行反代并对 81、3001 这类管理面板加上访问密码或 IP 白名单。这样做的核心思路是外网只需要开放 80 和 443 两个端口其他端口一律不映射。就算 Alist 的 WebDAV 也要通过 NPM 转发而不是直接暴露原生端口。端口暴露得越少攻击面越小对个人服务器来说这比装任何安全软件都管用。6. 常见问题与排查技巧实录Docker 跑久了总会碰到一些奇怪问题。我把自己踩过的坑整理成一份速查你遇到类似情况可以直接对应排查。6.1 容器反复重启但看不到明显错误如果容器一直处于 restarting 状态先看退出码再配合日志判断。命令是docker ps -a docker logs --tail 50 容器名比较常见的退出码含义1一般表示应用启动时出错需要看应用日志137表示被强制结束通常是内存不够被系统 OOM 杀掉了139是段错误多见于架构不匹配或者镜像本身有兼容问题。遇到反复重启别急着删除重装先看日志日志时间戳会告诉你崩溃前发生了什么。内存不足导致的 OOM 很隐蔽docker ps可能看不到任何提示。可以执行dmesg | grep -i oom查内核日志确认是不是内存被杀。解决方法是给容器加mem_limit或者干脆减少同机运行的服务数量。个人服务器 2GB 内存以下时别同时跑太多重型容器尤其是带 Java、Chromium 的应用。6.2 端口冲突和防火墙问题端口占用是另一个频繁踩坑点。启动容器时提示address already in use说明宿主机上已经有程序占用这个端口了。先查谁占用了端口ss -lntp | grep 3001如果是服务之间的端口设计冲突改 compose 文件里左边宿主机端口即可。比如 Uptime Kuma 已经用了 3001NPM 就换81如果 81 也被占了换成8081。需要提醒的是云服务器上除了容器本身还需要在安全组和系统防火墙里放行端口很多时候容器起来了但访问不了就是防火墙规则没放开。Debian/Ubuntu 系的 UFW 常用命令是ufw allow 3001/tcp。6.3 镜像拉取慢或超时在国内个人服务器上镜像拉取速度慢、超时是常见现象。我建议的做法是给 Docker 配置国内镜像加速器在/etc/docker/daemon.json中写入镜像源地址再执行systemctl restart docker注意熔断和安全问题导致镜像源更换很频繁网上搜索到的加速地址可能过一段时间就失效。找不到可用地址时另一个可行办法是找一台海外 VPS 在那边docker pull后docker save成 tar 包再传到目标服务器docker load。虽然没有直接加速来得优雅但确定性强。6.4 青龙面板依赖报错青龙新手最容易在“运行脚本时提示缺模块”上卡住。这个问题其实分两种情况一种是在 Web 后台“依赖管理”里装错了模块比如把 Python 包装到 Node 依赖中另一种是模块已经装了但版本不对。排查建议先确认脚本类型。Python 脚本要在“依赖管理”的 Python 列里填包名Node 脚本要选 Node 列不要混装。装完依赖后重启一下青龙让环境变量重新加载。很多脚本还会依赖系统级工具比如wget、curl、ffmpeg这些通过“系统依赖”安装。如果还是报错去容器里手动验证docker exec -it qinglong bash pip list | grep 包名然后看缺少的是不是脚本有一句import对应顶层模块名和 pip 包名不一致。这种坑经常出现需要耐心对照。6.5 容器数据备份与恢复最后聊一个每个人迟早都会面对的环节备份。备份这个事方案不重要先备份起来最重要。我是用宿主机 crontab 定时打包整个/srv/docker目录再配上 rclone 传到异地存储。restic 也是很好的方案能确保备份不会被误删。恢复的过程比想象中简单把备份目录解压回去再docker compose up -d几乎都能原样恢复。唯一要小心的是数据库类容器如果它正在写入时你强行覆盖数据文件可能损坏数据库。所以备份前最好先停掉数据库容器或至少对数据目录做一次一致性快照。Vaultwarden 这种密码库应当采取“备份后验证一下能正常打开”的原则别只备份不恢复。7. 我的个人实践经验与几个扩展方向写了这么多最后再分享一点我的实际感受。折腾个人服务器玩了两年多之后我越来越觉得挑 Docker 项目的核心标准不是“功能多不多”而是“更新勤不勤、维护活不活跃、数据是否会因升级丢失”。踩过太多次停更项目的坑了功能再全、社区凉了就是凉了最终只能被迫放弃。所以选项目时我会先去 GitHub 看看仓库 star 数和最近 release 时间再决定要不要上生产。当前这组组合我跑了两三个月没有出过任何大问题。日常打开最多的是 Uptime Kuma 看整体健康状态Alist 每天用来抓文件、传文件NPM 几乎是无感存在。青龙面板上的备份和提醒任务也一直正常执行。整个系统的维护成本基本就是偶尔docker compose pull一下其余时间根本不用管。文章最后如果你刚入坑我建议按这个顺序来先装 Uptime Kuma 和 NPM把基础设施立住再装 Portainer 或 1Panel管理界面会让你舒服很多然后选一个“会天天用”的应用比如 Alist 或 Navidrome让服务器进入日常使用状态最后再考虑青龙面板和自动化。别一口气全装那样既是负担也会很快失去兴趣。个人服务器的乐趣从来不在于“什么都跑”而在于“跑什么都能随心所欲地掌控”。希望这份清单能让你少走一些弯路也能给你一些新的折腾灵感。
个人服务器Docker项目推荐：从监控到自动化的实用清单
1. 为什么我的个人服务器选了 Docker先说说我这几年折腾个人服务器的感受。最早我在一台旧电脑上装了服务一个应用一套环境今天装 Redis 要编译明天跑 Python 脚本要配依赖后来换机器迁移更是噩梦配置文件散落各处几个月前能跑的服务突然就起不来了。直到我把所有应用切到 Docker 之后这套流程才彻底变清爽。这篇文章想分享的就是我个人服务器上真正在用的、适合家庭环境和自托管场景的 Docker 项目集。如果你有一台小主机、旧笔记本、NAS 甚至云服务器想把它变成下载机、媒体中心、监控看板、密码管理器或者自动化任务平台这篇文章可以直接当清单用。适合的人包括刚入手 NAS 的新手、厌倦了在裸机上折腾环境的开发者、以及想把家里那些零散服务统一管理起来的实用派玩家。Docker 对个人服务器最大的价值不是“跑得多快”而是“换环境不慌”。一个容器打包了应用本身和它依赖的所有东西在 A 机器上跑起来什么样搬到 B 机器上还是什么样。这意味着你可以在电脑上先试跑觉得稳定了再部署到服务器也可以放心折腾系统坏了重装系统后一条命令把服务全部拉回来。1.1 个人服务器选 Docker 的三个决定性理由第一个理由是隔离。以前我一个服务中毒或者配置写错可能会拖垮整个系统。容器化之后每个应用跑在自己的独立空间里就算某个容器崩了日志打满了也不会影响其他服务。对于个人服务器这种“平时没人盯着”的场景这是非常大的安全感来源。第二个理由是回滚简单。我经常升级镜像版本升完发现新版本有毛病在 Docker 里只需要重新指向旧镜像再启动一次几十秒就回去了。裸机上做版本回退可能要翻备份、改配置、重新编译搞不好就是半天。第三个理由是迁移方便。后来我把服务从一台旧主机搬到 N100 小主机整个迁移过程就是旧机器上docker ps看跑着什么新机器上执行几条docker compose up -d再把数据目录同步过去完工。没有路径依赖没有环境适配问题。对个人用户来说这种“可复制性”太珍贵了。1.2 环境选型先想清楚你的服务器是什么平台Docker 虽好但先要确认你的硬件平台。绝大多数 Docker 镜像都提供linux/amd64和linux/arm64两种架构。x86 的小主机、老台式机跑 amd64 没问题ARM 平台的树莓派、部分 NAS 和国产小主机应该优先选 arm64 镜像。如果你不太确定直接运行docker info看Architecture那行心里就有数了。还有一类特殊平台比如龙芯的 LoongArch 架构这类 CPU 目前 Docker 生态的兼容性比较有限很多官方镜像没有对应架构。网上也有一些热心开发者做了适配但你要有“遇到问题自己改 Dockerfile 重新构建”的心理准备。普通用户我建议优先选 x86 或 ARM 平台生态成熟度差距很大。另外要区分一下场景。像 Docker Desktop 是给开发者在本机 Windows 或 macOS 上做开发调试用的它自带虚拟机层适合搞开发但不适合做长期跑服务的个人服务器。个人服务器上我更推荐用纯 Docker Engine配合 Portainer 或 1Panel 这类 Web 管理面板轻量、直观、不占太多内存。2. 第一梯队先把这些“刚需级”项目装起来个人服务器上最怕“装机两小时吃灰一辈子”。所以我推荐项目有一个原则不搞那些花里胡哨但用不上几次的东西先装那些每天都在后台运行、又不会给你添麻烦的“基建型服务”。把它们跑稳了再考虑进一步玩法。2.1 Uptime Kuma给服务器装了双眼睛Uptime Kuma 是一个开源监控探针我会为每个核心服务配置 HTTP、Ping 或者 TCP 检查比如路由器、DDNS、家里跑的几个容器、甚至公网服务都在一个面板上盯着。它有很好看的 Web 界面报警渠道支持邮件、Telegram、钉钉、企业微信机器人等多种通知方式。为什么个人服务器也需要监控因为很多服务平时不出声一坏就是默默坏了很久你才发现。比如 DDNS 掉了、某个容器内存泄漏Uptime Kuma 会在服务不可达的几十秒内把报警推给你省得你等发现问题时已经故障了几个小时。它的部署极其简单暴露 3001 端口映射一个数据目录完事。我自己的配置习惯是每分钟检查一次通知方式选 Telegram 的 bot这样手机能第一时间收到。如果你没有 Telegram用邮件也行。注意千万别把所有服务都挂在“本机 IP”上检查因为你得监控的是公网视角的可用性至少要有一个检查用公网域名确认经过路由器、反代不丢包。2.2 Nginx Proxy Manager反向代理没有想象中复杂反向代理对个人服务器来说真正的意义是“把 80 和 443 收拢到一个入口”。以前我要在 Nginx 里手写 server 块改一个站点就要 reload 一次配置错一个分号整个站点打不开。Nginx Proxy Manager简称 NPM把这件事拖到了图形界面里给每个域名或子域名填上转发的内部端口它就自动生成配置、自动签发和续期 SSL 证书。一个非常推荐的搭配是路由器把 80、443 端口转发到服务器然后 NPM 负责按域名把流量分发给各个容器。这样一来你只需要开放这两个端口其他容器的端口全部禁止外部访问。安全性直接高了一个档次管理体验也清爽很多。NPM 本身也是 Docker 部署依赖一个数据库容器。第一次进去填一下管理员账号之后所有“绑定域名 证书申请”的操作都能在 Web 上完成。实测下来很稳我跑了十来个映射一直没有出过问题。唯一的坑是升级版本时数据库结构可能变化所以升级前一定备份数据库目录。2.3 Watchtower自动更新这件事其实是双刃剑Watchtower 的作用是定时检查容器使用的镜像有没有新版本有就自动拉取并重新创建容器。把它配好后你的服务会一直保持比较新的状态不用隔三差五记着去docker pull。但我对自动更新的态度是挑容器用。像 Nginx Proxy Manager、Uptime Kuma 这类更新频率低、更新风险小的项目可以放进自动更新名单。而像数据库、密码管理器这种数据敏感型的应用我建议要么不启用自动更新设置只更新指定容器要么用一个通知机制在更新前通知你。Watchtower 启动时可以通过--label-enable配合容器标签来控制哪些镜像参与更新。也可以给每个容器加com.centurylinklabs.watchtower.enablefalse这个 label 跳过更新。我个人的策略是默认全部开启但关于数据库和密码库的项目会单独排除。别小看这一步数据库大版本升级带来的坑踩一次就明白了。2.4 Portainer 还是 1Panel管理面板怎么选个人服务器不装任何管理面板也能活但装了面板后很多操作会舒服很多。Portainer 是纯 Docker 管理工具它把容器、镜像、卷、网络、日志都整合在一个界面中。特别适合习惯原生 Docker 概念的人查看容器资源占用、进容器里敲命令、查看日志都很方便。国产的 1Panel 则是更全面的服务器运维面板不仅管理 Docker还带防火墙、文件管理、应用商店、计划任务等功能。它内置的应用商店里有不少常见应用比如 Nginx、MySQL、Redis、青龙面板等点一下就能部署对新手特别友好。我个人的建议是如果你只是冲着“管理容器”来的选 Portainer如果你想面板尽可能把整台服务器都管起来而且喜欢中文界面可以试试 1Panel。两个可以共存但内存小的情况下别装太多毕竟管理面板本身也在吃资源。3. 第二梯队让服务器从“有用”变成“好用”服务器只跑着监控和反代确实很稳但缺少“呀这玩意真实用”的时刻。这个梯队里的项目都是能让你每天主动打开服务器去用一下的东西也是我向朋友安利个人服务器时最常展示的部分。3.1 Alist把散落各处的网盘拢到一个页面Alist 是一个文件列表和网盘聚合工具它可以把本地目录、各种网盘和对象存储挂载到一个网页里统一访问支持 WebDAV 协议。也就是说你可以在浏览器里一个界面翻遍所有文件也可以在电脑上通过 WebDAV 挂载成一个本地磁盘。这个项目对国内用户特别实用的地方在于很多网盘的客户端既臃肿又限速而 Alist 可以帮你把文件统一管理起来配合下载工具还能实现“网盘文件直传到本地服务器”的自动流程。我自己就经常把一些临时文件传到某个网盘的特定目录然后在服务器上通过 Alist 抓取处理。部署 Alist 时需要挂载本地数据目录和你要访问的存储目录启动后默认 5244 端口首次启动用命令行设置管理员密码。要注意的是第三方网盘接口属于“民间适配”接口失效时需要及时更新容器版本所以建议开启 Watchtower 的自动更新。3.2 Navidrome自托管音乐库比想象中香如果你家里攒了不少无损音乐或 CD 抓轨文件Navidrome 可以把这些文件变成一个私人音乐平台。它支持多用户、多格式包括 MP3、FLAC、AAC 等手机端用第三方客户端比如音流、SubMusic连上去体验非常接近主流音乐 App。我为什么推荐它的原因其实是一个很具体的场景孩子睡前要听儿歌我很久以前存的那些音频文件放在硬盘里吃灰自从用 Navidrome 建了音乐库后手机打开就能放没有广告没有推荐算法没有“会员才能听”。这种彻底掌控自己数据的感觉很舒服。部署 Navidrome 时注意要把音乐目录挂载进容器它会扫描并建立索引所以第一次启动后耐心等一会儿。如果有大量中文歌曲的曲目信息比较乱可以在 Web 后台手动编辑它会把关联信息保存到自己的数据库里不会动你的原始文件。3.3 Stirling PDF一个容器解决所有 PDF 操作这年头几乎每个家庭都免不了跟 PDF 打交道扫描件转文字、合并几个文件、压缩体积、签字、拆分页面。Stirling PDF 是一个基于 Web 的工具集合把这些功能全部做成了网页版不需要安装任何桌面软件。它的优势是所有处理都在你自己的服务器上完成敏感的合同、证件材料不用上传到第三方网站。我们经常在搜索引擎里找“PDF 在线合并”之类的工具那些网站上传后数据去向不明放在个人服务器上就没这个担忧了。部署时比较吃内存JVM 应用大概要吃 300 到 500MB如果你的服务器只有 1GB 内存建议在docker-compose.yml里限制一下内存大小。界面默认英文但支持多语言在设置里可以切换成中文。有些高级功能需要额外的 Python 或 OpenCV 支持但常规操作开箱可用这个项目的更新频率很高同理建议开着自动更新。3.4 Vaultwarden密码管理器可以自托管密码管理器是我认为“越早部署越安心”的项目。Vaultwarden 是一个用 Rust 写的轻量级密码管理器服务端API 兼容 Bitwarden 客户端。简单说你可以在官方 App、浏览器插件里直接用自己的服务器地址所有密码数据都存放在自己手里。它不是官方 Bitwarden 服务器的替代品而是为自托管场景设计的轻量实现内存占用小、部署简单。官方版的 Bitwarden 对个人和小团队来说资源要求偏重Vaultwarden 一个容器就能跑实测 256MB 内存也能正常运行。部署时需要挂载一个数据目录并且强烈建议你在 NPM 里配好 HTTPS。密码库这种数据明文走 HTTP 是绝对不能接受的。Vaultwarden 的管理后台可以设置是否开放注册个人用建议关闭注册并开启两步验证。升级前务必备份数据目录里的db.sqlite3文件这玩意丢了就是所有密码一起没。4. 进阶玩法青龙面板和自动化不只是“定时任务”到这里你的服务器已经跑了不少服务管理也有面板了接下来就可以玩点更有意思的东西。个人服务器到后期真正的乐趣其实在于“把重复的事交给机器去做”定时任务、网页变化检测、智能家居联动这些都属于这一类。4.1 青龙面板定时任务这件事它可以做得优雅青龙面板是一个定时任务管理平台支持 Python、JavaScript、Shell 等脚本提供 Web 界面有任务执行日志、依赖管理和并发控制等功能。很多自托管玩家用它来做定时提醒、数据备份、签到提醒、接口巡检和自动化脚本调度。网络热词里经常提到“青龙 依赖管理”其实就是在说青龙面板里给脚本安装 Python 包或 Node 模块。你可以在后台可视化管理这些依赖而不必进入容器敲命令行。它的任务调度用标准的 cron 表达式比如每天凌晨 3 点跑一次备份脚本写成0 3 * * *保存即可。青龙的部署文件比较长因为它内部有多个服务和数据库可以用官方提供的 docker-compose 文件一键起也支持通过 1Panel 的应用商店安装。启动后会进入初始化界面设置好账号和密码后就能在 Web 端新建脚本、设置定时规则、查看日志。要强调的是用它管理自动化任务没问题但一定要用合规合法的脚本涉及破解、恶意采集、绕过商业系统限制之类的脚本不要碰。自己写脚本跑数据备份、家人共用资源的监控、定时提醒这些才是真正妥当的用法。4.2 Changedetection.io网页一有变化马上通知你这个工具的原理很简单定时抓取你指定的网页内容和目标快照对比有变化就发通知。你可以用它监测商品价格、监控某个页面公告、追踪文档更新、盯某个朋友的博客有没有新文章。它比 RSS 更广因为有些网页根本没有 RSS 订阅。我在实际使用中最常用的场景是监控某个产品页面的“有货”状态和一些部门网站的公示更新。以前都是隔几天手动刷一次现在它一有变化就推消息到手机。它的界面比较简洁填上 URL 和选择器就能用支持中文。部署时比较吃资源的是它会用浏览器渲染页面如果目标网站是 JavaScript 渲染的动态页面需要启用 Playwright 浏览器支持那样内存占用会明显上升。普通静态页面用默认的文本提取即可资源不足时不要开太多监控任务。4.3 Home Assistant让容器和家里设备联动如果你家里的智能设备比较杂不同品牌有不同 AppHome Assistant 可以把它们合并到一个控制台中。它可以接入各种协议包括 WiFi、蓝牙、Zigbee 等通过不同的插件把设备状态拉进来然后做自动化。比如“晚上 7 点灯自动打开”这种场景就是它的拿手好戏。Home Assistant 在 Docker 里跑的版本叫 Home Assistant Container不带官方操作系统只跑核心服务。如果你只想把它当作“智能家居中枢”这种方式够用。如果你想要更加完整的插件生态可以考虑 Home Assistant Supervised但那需要更系统级的权限一般个人服务器建议直接跑容器版。部署后记得访问8123端口完成初始化然后勾选你手头的设备类型。它对新手来说有一个陡峭但值得爬的学习曲线因为玩到后面你写自动化脚本时其实是在写 YAML 配置一份配置就能控制全家设备。对容器玩家来说还有一个额外福利Home Assistant 可以监控 Docker 容器运行状态比如某个容器挂了之后自动拉起或者跑一个自动化脚本重启它。5. 从零部署示例用 docker compose 一次跑起三件套前面推荐的项目有点多我来给你走一遍完整部署流程保证你照着做就能把服务跑起来。这里选三个组合来演示Uptime Kuma Nginx Proxy Manager Alist三者配合基本就是一个“看得见、进得来、翻得动”的个人服务中心。5.1 准备工作建目录和设置环境先在我的服务器上建好统一的配置目录我习惯把数据放在/srv/docker下每个应用一个子目录这样备份直接打包整个目录就行。mkdir -p /srv/docker/uptime-kuma mkdir -p /srv/docker/nginx-proxy-manager/{data,letsencrypt} mkdir -p /srv/docker/alist同时确认 Docker Engine 和 docker compose 插件是正常安装的。查看版本docker --version docker compose version如果你的 Docker 版本比较老希望后续部署顺畅建议先升级 Docker Engine。个人服务器只要不是跑生产环境用官方安装脚本升级是省事的选择。需要强调不要用docker run去裸跑所有服务虽然它也能跑但服务一多参数混乱、重启策略不一致的问题都会冒出来。docker compose 才是个人服务器管理容器的正确姿势。5.2 编写 docker-compose.yml在/srv/docker下建一个docker-compose.yml把三个服务写在一起version: 3.8 services: uptime-kuma: image: louislam/uptime-kuma:latest container_name: uptime-kuma restart: unless-stopped ports: - 3001:3001 volumes: - /srv/docker/uptime-kuma:/app/data npm: image: jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - 80:80 - 443:443 - 81:81 environment: - TZAsia/Shanghai volumes: - /srv/docker/nginx-proxy-manager/data:/data - /srv/docker/nginx-proxy-manager/letsencrypt:/etc/letsencrypt alist: image: xhofe/alist:latest container_name: alist restart: unless-stopped ports: - 5244:5244 volumes: - /srv/docker/alist:/opt/alist/data这几个参数值得展开说说。restart: unless-stopped意味着容器异常退出时会自动重启除非你手动停掉它这是个人服务器上所有常驻服务都应该设置的核心参数。ports是宿主机端口和容器端口的映射写在前面的3001、80、81是从外面访问用的端口在服务器上可能已经被占用需要注意调整。TZAsia/Shanghai这个环境变量很关键不设的话容器默认是 UTC 时区定时任务和日志时间都会对不上。5.3 启动、验证和常用命令在docker-compose.yml所在目录执行docker compose up -d docker compose ps如果一切正常你会看到三个服务都处于 running 状态。然后分别访问Uptime Kumahttp://服务器IP:3001Nginx Proxy Managerhttp://服务器IP:81Alisthttp://服务器IP:5244首次进入 NPM 要用默认账号adminexample.com和密码changeme登录然后立即修改。Alist 管理员密码要在容器里执行命令生成docker exec -it alist ./alist admin set 你的密码日常维护最常用的三条命令记在心里docker compose logs -f 服务名查看某服务日志docker compose restart 服务名重启某服务docker compose pull docker compose up -d更新所有镜像并重建容器。这基本覆盖了我 90% 的运维操作。5.4 部署完成后的第一件事把所有端口收起来三个服务跑起来后路由器上有 80、443、81、3001、5244 五个端口是开放的。其中 81、3001、5244 是管理界面和服务端口直接暴露到外网并不安全。第一件事就是在 NPM 里给它们配上子域名进行反代并对 81、3001 这类管理面板加上访问密码或 IP 白名单。这样做的核心思路是外网只需要开放 80 和 443 两个端口其他端口一律不映射。就算 Alist 的 WebDAV 也要通过 NPM 转发而不是直接暴露原生端口。端口暴露得越少攻击面越小对个人服务器来说这比装任何安全软件都管用。6. 常见问题与排查技巧实录Docker 跑久了总会碰到一些奇怪问题。我把自己踩过的坑整理成一份速查你遇到类似情况可以直接对应排查。6.1 容器反复重启但看不到明显错误如果容器一直处于 restarting 状态先看退出码再配合日志判断。命令是docker ps -a docker logs --tail 50 容器名比较常见的退出码含义1一般表示应用启动时出错需要看应用日志137表示被强制结束通常是内存不够被系统 OOM 杀掉了139是段错误多见于架构不匹配或者镜像本身有兼容问题。遇到反复重启别急着删除重装先看日志日志时间戳会告诉你崩溃前发生了什么。内存不足导致的 OOM 很隐蔽docker ps可能看不到任何提示。可以执行dmesg | grep -i oom查内核日志确认是不是内存被杀。解决方法是给容器加mem_limit或者干脆减少同机运行的服务数量。个人服务器 2GB 内存以下时别同时跑太多重型容器尤其是带 Java、Chromium 的应用。6.2 端口冲突和防火墙问题端口占用是另一个频繁踩坑点。启动容器时提示address already in use说明宿主机上已经有程序占用这个端口了。先查谁占用了端口ss -lntp | grep 3001如果是服务之间的端口设计冲突改 compose 文件里左边宿主机端口即可。比如 Uptime Kuma 已经用了 3001NPM 就换81如果 81 也被占了换成8081。需要提醒的是云服务器上除了容器本身还需要在安全组和系统防火墙里放行端口很多时候容器起来了但访问不了就是防火墙规则没放开。Debian/Ubuntu 系的 UFW 常用命令是ufw allow 3001/tcp。6.3 镜像拉取慢或超时在国内个人服务器上镜像拉取速度慢、超时是常见现象。我建议的做法是给 Docker 配置国内镜像加速器在/etc/docker/daemon.json中写入镜像源地址再执行systemctl restart docker注意熔断和安全问题导致镜像源更换很频繁网上搜索到的加速地址可能过一段时间就失效。找不到可用地址时另一个可行办法是找一台海外 VPS 在那边docker pull后docker save成 tar 包再传到目标服务器docker load。虽然没有直接加速来得优雅但确定性强。6.4 青龙面板依赖报错青龙新手最容易在“运行脚本时提示缺模块”上卡住。这个问题其实分两种情况一种是在 Web 后台“依赖管理”里装错了模块比如把 Python 包装到 Node 依赖中另一种是模块已经装了但版本不对。排查建议先确认脚本类型。Python 脚本要在“依赖管理”的 Python 列里填包名Node 脚本要选 Node 列不要混装。装完依赖后重启一下青龙让环境变量重新加载。很多脚本还会依赖系统级工具比如wget、curl、ffmpeg这些通过“系统依赖”安装。如果还是报错去容器里手动验证docker exec -it qinglong bash pip list | grep 包名然后看缺少的是不是脚本有一句import对应顶层模块名和 pip 包名不一致。这种坑经常出现需要耐心对照。6.5 容器数据备份与恢复最后聊一个每个人迟早都会面对的环节备份。备份这个事方案不重要先备份起来最重要。我是用宿主机 crontab 定时打包整个/srv/docker目录再配上 rclone 传到异地存储。restic 也是很好的方案能确保备份不会被误删。恢复的过程比想象中简单把备份目录解压回去再docker compose up -d几乎都能原样恢复。唯一要小心的是数据库类容器如果它正在写入时你强行覆盖数据文件可能损坏数据库。所以备份前最好先停掉数据库容器或至少对数据目录做一次一致性快照。Vaultwarden 这种密码库应当采取“备份后验证一下能正常打开”的原则别只备份不恢复。7. 我的个人实践经验与几个扩展方向写了这么多最后再分享一点我的实际感受。折腾个人服务器玩了两年多之后我越来越觉得挑 Docker 项目的核心标准不是“功能多不多”而是“更新勤不勤、维护活不活跃、数据是否会因升级丢失”。踩过太多次停更项目的坑了功能再全、社区凉了就是凉了最终只能被迫放弃。所以选项目时我会先去 GitHub 看看仓库 star 数和最近 release 时间再决定要不要上生产。当前这组组合我跑了两三个月没有出过任何大问题。日常打开最多的是 Uptime Kuma 看整体健康状态Alist 每天用来抓文件、传文件NPM 几乎是无感存在。青龙面板上的备份和提醒任务也一直正常执行。整个系统的维护成本基本就是偶尔docker compose pull一下其余时间根本不用管。文章最后如果你刚入坑我建议按这个顺序来先装 Uptime Kuma 和 NPM把基础设施立住再装 Portainer 或 1Panel管理界面会让你舒服很多然后选一个“会天天用”的应用比如 Alist 或 Navidrome让服务器进入日常使用状态最后再考虑青龙面板和自动化。别一口气全装那样既是负担也会很快失去兴趣。个人服务器的乐趣从来不在于“什么都跑”而在于“跑什么都能随心所欲地掌控”。希望这份清单能让你少走一些弯路也能给你一些新的折腾灵感。
