NAS 这玩意,折腾到最后往往就变成"买前生产力,买后爱奇艺"。但最近我在绿联 DX4600 上部署了个像素风宝可梦同人游戏 pokerogue,家里的使用率一下就上来了——不用装客户端、不用改手机配置,浏览器一开就能玩,存档还能由我自己掌控。这篇文章就把完整的部署思路和实操过程写下来,包括我在绿联 NAS 上踩过的坑、存档备份的关键点、以及外网访问的调优细节。如果你是第一次碰 NAS 部署,或者只是想让家里的 NAS 多一个"游戏机"身份,这篇可以直接照着做。
先说清楚一个前提:pokerogue 本质上是纯前端的 Web 应用,也就是说它的"运行"并不需要高性能算力,一台 NAS 甚至比普通云服务器更合适——数据在本地,随时可迁移,断网也不影响局域网内的使用。这也是我为什么坚持把它放在绿联上而不是扔到某个免费托管平台的原因。
1. 被低估的 NAS 新玩法:浏览器即点即玩的 pokerogue
1.1 为什么在 NAS 上跑一个网页游戏
可能有人会问:既然是网页游戏,我直接打开官网玩不就完了吗?当然可以,但你自己部署和在官网玩完全是两回事。pokerogue 的存档机制默认是存在浏览器本地(localStorage),如果你今天在公司电脑玩、晚上回家用 NAS 局域网玩、周末又换台笔记本,存档是分开的,随时可能丢。自己部署之后,虽然存档还是在浏览器里,但你可以把导出存档当作一个日常备份任务,真正落到 NAS 的硬盘上。
更实际的一点是:自托管意味着不受官方服务器状态影响。官方服务器偶尔维护、升级、或者某个版本有 Bug,你这边完全不受牵连。我自己就遇到过官网版本更新后存档读不出来的情况,自部署版本因为锁定版本号,反而一直稳定运行。
另外还有一个容易忽略的点:NAS 本身就是一台 7x24 小时开机的 Linux 机器。部署一个纯静态 Web 应用,对 CPU、内存的占用几乎可以忽略不计。绿联 DX4600 这种 N100 级别的 CPU,跑 pokerogue 时 Docker 容器内存占用通常只有几十 MB,完全不影响同一台机器上的下载、相册、影音这些常规服务。一个低成本、高可玩性、还能锻炼部署能力的项目,放在 NAS 上非常合适。
1.2 这个游戏到底是个啥
pokerogue 是 GitHub 上一个开源项目,简单概括就是"像素风宝可梦 + Roguelike 爬塔"。你开局选一只宝可梦,然后一层一层往上打,每一层都有随机野生宝可梦、随机道具、随机事件,输了就从头再来,但过程中获得的"成就点"和"图鉴数据"会保留下来。数值系统、特性、招式、进化链这些都做得相当完整,不是那种粗制滥造的模仿品,很多细节能看出作者是真懂宝可梦的老玩家。
从部署角度看,它的优点很突出:项目是标准的前端工程,产出物是一堆静态文件(HTML、JS、CSS),任何能托管静态文件的 HTTP 服务器都能跑。这意味着部署选项非常灵活——既可以用 Docker 跑一个 Nginx 容器包一层,也可以丢进绿联自带的 Web 服务目录里,甚至你电脑上装个 Python 自带的 http.server 都能启动。当然,在 NAS 上最正规、最好维护的方式还是 Docker,下面我展开讲。
2. 绿联 NAS 的基础准备:Docker、SSH 与目录规划
2.1 确认 Docker 环境和 SSH 权限
绿联目前的 UGOS Pro 系统自带 Docker 应用,这是最基础的前提。如果你用的是老款机型或者系统版本特别旧,先去应用中心把 Docker 装好。装好之后打开 Docker 界面,正常情况下你能看到容器、镜像、网络这几个 Tab。如果你打算全程用图形界面操作,理论上可行,但我强烈建议顺手打开 SSH 权限——后面处理文件权限、执行命令、看容器日志都靠它。
开启方法不复杂:进入绿联的控制面板,找到终端/SSH 选项,打开 SSH 服务,设置一个端口(默认 22 就行),然后用你 NAS 的管理员账号密码通过终端连接。Windows 用户可以直接用 PowerShell 里的ssh 用户名@NAS的IP登录,Mac 用户更是原生支持。登录成功后会看到 UGOS 的 shell 环境,这说明你已经有完整的命令行掌控权了。
这里有个我当初自己踩过的小坑:绿联的管理员账号和 Linux 的 root 账号不完全是同一个概念。用管理员 SSH 登录后,部分系统目录你可能只有只读权限,需要使用sudo -i切换到 root 再操作 Docker 命令。如果你习惯直接用docker ps排查容器状态,却提示权限不足,先切 root 再试。
2.2 目录规划与镜像加速
部署前先把目录结构想清楚,不然以后版本更新、备份存档的时候会手忙脚乱。我建议在 NAS 的 Docker 数据根目录下建一个专属文件夹,比如/volume1/docker/pokerogue,里面再分两个子目录:一个放游戏静态文件,一个放备份。整体结构大概是这样的:
| 路径 | 用途 |
|---|---|
/volume1/docker/pokerogue/dist | 游戏前端静态文件,容器挂载这里 |
/volume1/docker/pokerogue/backup | 存档导出备份、版本升级前的老包备份 |
/volume1/docker/pokerogue/logs | 容器日志映射,方便排查问题 |
之所以单独划一个 backup 目录,是因为我在实际使用中吃过亏:升级游戏版本时直接把旧文件覆盖了,结果新版没跑起来,想回滚却发现手里没有旧压缩包。从那以后我养成了"每次升级前先打包备份 dist 目录"的习惯,成本极低,但关键时刻能救命。
然后是 Docker 镜像加速的问题。绿联自带的应用商店里虽然能直接拉镜像,但国内网络环境拉 GitHub 上的镜像源或者 Docker Hub 都偶尔会卡住。我用的办法是修改 Docker 的 daemon.json 配置,加入国内可用的镜像加速地址。在 SSH 里执行:
sudo mkdir -p /etc/docker sudo tee /etc/docker/daemon.json << 'EOF' { "registry-mirrors": [ "https://docker.1ms.run", "https://docker.m.daocloud.io" ] } EOF sudo systemctl restart docker注意不同加速源的可用性会变化,如果你遇到重启后仍然拉不动镜像的情况,换一批当前可用的域名就行,配置格式完全一样。这一步做好之后,后面拉nginx:alpine这种基础镜像会快很多。如果你不想折腾 Docker 加速,也有替代方案:直接在绿联套件中心找一个支持静态网站的套件,把 dist 目录塞进去一样能跑。但我个人不推荐,因为容器化的隔离性和可迁移性是裸套件给不了的。
3. 部署实操:静态资源托管是最省心的路线
3.1 方案一:直接用 Nginx 容器托管 release 静态包
先确认一下你从哪拿到 pokerogue 的静态文件。开源项目的发布方式通常有两种:一是给 release 页面附带打包好的 zip,二是让你自己用源码构建。作为使用者,优先找 release 的现成产物,省时省力。
拿到 zip 之后,通过绿联的文件管理器或者 SFTP 把它解压到/volume1/docker/pokerogue/dist。解压后确认目录里应该有index.html、assets之类的典型前端文件结构,这一步很关键——很多人解压之后发现多了一层嵌套目录,比如dist/pokerogue/index.html,导致后面容器挂载路径没对应上。
路径确认无误后,创建一个 docker-compose 文件来跑容器。在/volume1/docker/pokerogue下新建docker-compose.yml:
services: pokerogue: image: nginx:alpine container_name: pokerogue restart: unless-stopped ports: - "8001:80" volumes: - /volume1/docker/pokerogue/dist:/usr/share/nginx/html:ro - /volume1/docker/pokerogue/logs:/var/log/nginx environment: - TZ=Asia/Shanghai为什么选 Nginx 而不是别的 Web 服务器?原因很简单:pokerogue 的所有交互都在浏览器端完成,不需要后端动态处理,Nginx 专职做静态文件服务,稳定性和性能都是经过无数次生产环境验证的,而且nginx:alpine镜像够小,几 MB 的体积,内存占用可以忽略。挂载时我特意加了:ro,也就是只读挂载,防止容器内意外修改宿主机文件。
然后执行:
cd /volume1/docker/pokerogue docker compose up -d启动完成后,浏览器访问http://你的NAS局域网IP:8001,如果能看到游戏加载界面,基本就成功了。
3.2 方案二:源码构建再打包(可选进阶路线)
如果你对前端构建流程比较熟,或者手头想跑一个新功能但 release 还没出包,可以选择源码构建。流程不算复杂,但对国内网络环境不太友好,因为npm install需要拉不少依赖包。大致步骤如下:
git clone https://github.com/pagefaultgames/pokerogue.git cd pokerogue npm install npm run build构建成功后,产物同样在dist目录下。需要注意构建时 Node 版本要求比较高,一般 18 以上都行,我在绿联上是直接跑在 SSH 里的,但 NAS 自带系统环境未必有 Node,我建议在 Docker 里开一个node:20-alpine容器做构建,构建完退出容器,保持宿主机环境干净。
方案二适合对"自己从源码构建出不带任何官方改动痕迹的版本"有执念的人,或者官方 release 缺失时应急。日常使用,我还是会选方案一,简单直接。
3.3 启动参数与访问验证
不管用哪种方式,部署完成后第一步不是急着开始玩,而是验证容器是否正常运行。建议跑一遍这个命令看状态:
docker ps | grep pokerogue docker logs -f pokerogue如果容器状态是Up,日志里没有任何 nginx 报错,接着在浏览器里访问测试。我遇到过一个奇怪的情况:容器起来了、文件也在,但页面空白,打开开发者工具发现 HTTP 500。最后排查到原因是文件挂载路径错了——我把解压后的子目录挂到了根上,导致 nginx 找不到index.html。这类问题在静态部署里很常见,检查思路就一条:进容器里看看挂载点下到底是什么。
docker exec -it pokerogue ls -la /usr/share/nginx/html如果index.html没有直接出现在这个目录,而是还在某个子文件夹里,就调整 compose 文件的挂载路径,把宿主机路径指向包含index.html的那一层即可。
4. 最容易忽略的存档问题:localStorage 与备份策略
4.1 存档到底存在哪里
pokerogue 的存档默认存在浏览器的 localStorage 里,这可能是整个游戏体验中最大的坑。因为 localStorage 的特点是"跟着浏览器走",不是跟着设备走,更不是跟着你的 NAS 走。你在 Safari 上玩了一天,换成 Chrome 打开,之前的进度就"消失"了——实际上当然没消失,只是每个浏览器各存各的。
数据存储量也不大,但足够记录完整的游戏进度、图鉴、成就、每日挑战排名这些内容。理论上你可以直接手动修改 localStorage 来"作弊",但更实际的问题是:如果不做备份,一次误清浏览器缓存,或者浏览器崩溃后重置,几十小时的游戏进度就全没了。
我刚开始部署的时候没太在意这件事,直到有一次为了测试外网访问,用手机浏览器登录玩了一个多小时,第二天想换回电脑发现进度不通用,才老老实实研究了一套自己的备份流程。这里也建议大家不要被"NAS 部署了游戏"这个表象迷惑,部署本身只是第一步,存档管理才是长期体验的核心。
4.2 跨设备存档迁移的实操方法
把存档从手机浏览器迁移到电脑浏览器,或者从旧电脑迁到新电脑,核心操作就是导出和导入。pokerogue 设置里专门提供了存档导出功能,通常在设置(Settings)页面里的 Data 或者 Save 相关分类下。点击导出后会下载一个 JSON 文件,这个文件就是你的完整存档。
导入的时候,先在目标浏览器打开游戏,进入设置,选择导入 JSON 文件,确认覆盖即可。整个过程我实测下来比较顺畅,但有几个细节需要注意:
- 游戏版本不同可能导致存档格式不兼容,尽量在相同或接近的版本之间迁移。
- 导入操作会覆盖当前浏览器里的存档,如果原浏览器还有新的进度,先导出留底再导入。
- 导出的 JSON 文件名通常带时间戳,建议不要改名,方便日后分辨版本和日期。
4.3 基于 NAS 的存档备份方案
既然 NAS 就在你手边,把存档备份做成一个"顺手就做"的习惯并不难。我的做法是:每周至少导出一次存档 JSON,通过绿联文件管理器上传到/volume1/docker/pokerogue/backup目录,按日期命名。进一步的自动化方案,可以在绿联的任务计划里加一个定时提醒(比如每周日晚弹窗/推送提醒我导出存档),或者干脆写一个脚本,定期把 backup 目录同步到另一块硬盘甚至网盘上。
如果你愿意稍微折腾一下,可以用 Docker 挂载一个常用网盘同步容器(比如 alist 管理网盘,然后用 rclone 定时上传),把 backup 目录自动同步到远端。这样即使 NAS 硬盘整体损坏,云上还有一份。很多人部署 NAS 应用时只关心"能跑",不考虑"数据安全",但游戏进度这东西,丢一次就会有切肤之痛——不是花多少钱的问题,是你几十小时的投入瞬间归零的那种挫败感。
5. 版本更新与服务维护:让游戏长期稳定运行
5.1 版本更新流程
pokerogue 的更新频率不算低,隔一两周就会出新版本,加新宝可梦、调平衡、修 Bug。如果你是官网玩家,这可能是利好;但自部署的话,意味着你需要维护自己的版本。我推荐的更新流程非常简单,但每一步都要做:先去项目 release 页面看最新版本号,下载最新的 zip;然后在 backup 目录里把当前 dist 打包一份:tar -czf pokerogue_old_日期.tar.gz dist;接着用新文件替换 dist 目录内容,注意先删掉旧文件再解压,不要混着装;最后在浏览器里强制刷新页面(Ctrl+F5 / Cmd+Shift+R),清掉浏览器缓存,避免旧 JS 文件残留。
整个过程不需要重启容器,因为 Nginx 是每秒钟直接从磁盘读文件,你替换完文件刷新页面就能生效。如果出现更新后页面白屏、样式错乱,优先怀疑是浏览器缓存了旧版本资源,强制刷新一次基本都能解决。
还有一点:升级前最好看一眼 release notes,有些版本会变更存档字段,旧存档可能不兼容。我的习惯是升级后先不急着玩,先导入一份测试存档跑一局,确认没问题再把主存档导回去。
5.2 容器自启动与资源占用
绿联 Docker 在系统重启后默认会拉起设置了restart: unless-stopped的容器,我用 docker-compose 部署时已经加了这个参数,所以 NAS 意外断电、重启后游戏服务会自动恢复,不需要手动点启动。这个配置看似细节,但实际用起来非常关键——家用 NAS 的稳定性再怎么说也和专业服务器有差距,指不定哪次手滑重启了机器,如果你还要手动去 Docker 界面一个个拉起容器,麻烦是一方面,忘掉的话服务就断掉了。
资源占用方面我实测给你一个参考:nginx:alpine容器跑 pokerogue 静态文件,内存占用大约 20-50MB,CPU 平时几乎为 0,只有在首次加载大包资源时会有短暂上升。绿联 DX4600 这种机器日常挂着下载、相册、Docker 全家桶,再加一个 pokerogue 完全没压力。你可以用docker stats查看实时占用,我观察下来基本是恒定在一个很低的水平。
版本更新和容器维护之外,还有一类隐蔽问题是日志膨胀。Nginx 容器默认会记录访问日志,时间久了/var/log/nginx里的日志文件会越来越大。我虽然映射了 logs 目录,但如果不做轮转,日志还是可能撑爆小容量启动盘。临时解决办法是定期清理,更优雅的方式是在容器内配置 logrotate,或者干脆在 compose 文件里加一行配置禁用访问日志。对这种个人娱乐型的服务,我建议直接在 nginx 配置里关掉 access.log,省心。
6. 局域网与外网访问:从内网到手机随时打开
6.1 绿联自带的远程访问能力
绿联 UGOS Pro 自带的远程访问功能对外网访问是最省心的方案——你只需要在手机或者外部电脑上通过绿联的官方 App 或者网页端登录自己的 NAS 账号,就能在"应用"列表里找到你 Docker 里跑的服务入口。这种方式不需要你懂端口转发、不需要公网 IP,理论上打开即用。
但实际体验下来有个明显的短板:绿联远程访问是通过它的中转服务器实现的,访问速度取决于绿联服务器的线路质量和你本地网络的上行带宽。你如果只是偶尔在外打开看一眼状态,完全够用;但如果你想在地铁上流畅玩一把 pokerogue,中转链路的延迟可能让你的操作"慢半拍"。而且这种玩法依赖绿联账号体系,和"纯局域网直连"的体验差距明显。所以它适合保底,不适合作为唯一途径。
6.2 IPv6 直连与外网速度的坑
如果你家的宽带有 IPv6 地址(现在大多数运营商默认开通了),外网直连其实可以做到"点对点打通"。绿联网络设置里能看到你 NAS 获取到的 IPv6 地址,同时确保你的家庭路由器防火墙放行了对应端口。手机在 4G/5G 网络下访问http://[IPv6地址]:8001,如果能打开,说明直连已经打通,这时候延迟和带宽理论上只受你家里宽带的上行速度限制。
但这里有一个非常典型的坑:很多场景下"手机外网连接 NAS 还是很慢",并不是带宽不够,而是你的域名解析或者客户端访问方式出了问题。比如你用了一个带端口的面板地址,DNS 解析走的还是 IPv4 或中转节点,IPv6 根本没有被使用;另外,部分手机系统在 Wi-Fi 和蜂窝网络之间切换时,IPv6 链路重建需要时间,首次访问会明显卡一下。排查思路很直接:先用手机流量浏览器直接访问 NAS 的 IPv6 原始地址,排除一切中间层。能直连且速度正常,说明问题在自己的域名/反代配置上;如果直连也慢,再检查路由器 IPv6 的 MTU 设置和防火墙状态检测机制。
我自己调完之后,外网用手机流量访问 pokerogue 基本能做到秒开,游戏操作也没有明显延迟。这一步做完,你才算真正实现了"随时随地打开浏览器就能玩"的目标。
6.3 安全配置建议
最后简单说下安全。pokerogue 本身是无鉴权的纯静态服务,任何能访达你的端口的人都能打开玩——这其实不是坏事,毕竟游戏存档各自存在各人的浏览器里,互不影响。但如果你的 NAS 暴露在外网,注意以下几点:
- 不要把容器端口直接映射到 DMZ 主机,尽量通过绿联的防火墙只放行必要的端口;
- 如果路由器支持,可以只对已知的访问来源 IP(比如你手机流量所在的运营商网段)放行;
- 我个人的偏好是给 pokerogue 套一层 Caddy 或 Nginx 反代,加一个简单的 Basic Auth,这样外部访问必须先输密码,内网直连则自动跳过验证,兼顾方便和安全。
你可能会觉得给一个游戏加密码很麻烦,但换位思考一下:NAS 上不只跑着 pokerogue,还有你的相册、文件、备份数据库。端口暴露越多,其他服务被扫描到的概率越大。给这个"对外可访问"的游戏服务加一道薄薄的认证,代价极低,换来的是整个 NAS 安全边界的收窄。这属于那种"用了才知道值"的配置。
回顾一下整个部署过程,pokerogue 搬到绿联 NAS 这件事,技术难度其实不高,真正有价值的是后续的存档管理、版本更新习惯和安全边界的把控。我自己实际操作下来的体会是:别嫌麻烦,存档备份要养成肌肉记忆,版本升级前留一手旧包,外网访问优先走 IPv6 直连——这三点做到位,这个游戏服务基本就长期稳如老狗了。如果你家里也有闲置的 NAS,不妨按这个流程把它变成一台"游戏服务器台",你会发现 NAS 除了存数据,还能给全家提供一个随时能开一局的娱乐入口。