在群晖NAS上用Docker部署Squoosh：打造全家可用的图片压缩工具

做NAS这些年，我发现一个特别尴尬的场景：手机拍照动辄几MB到几十MB，群晖Photo里存了上万个文件，电视端、手机端浏览时缩略图加载慢得要命。想压缩，但每次把文件导出来、用PS批处理一遍再传回去，实在太蠢。后来我把Google实验室出品的Squoosh图片压缩工具部署到了群晖上，直接在浏览器里拖进去就压，几秒出结果，全家设备都能打开用。这篇文章把我这次部署的全过程记录下来，包括选型思路、Docker配置、踩坑记录和提升效率的小技巧。手里有群晖、又经常被图片体积困扰的朋友，这篇能帮你少走不少弯路。

1. Squoosh是什么，为什么值得部署在群晖上

1.1 Google实验室的开源图片压缩神器

Squoosh是Google Chrome实验室团队开源的一款图片压缩Web工具。它最核心的特点，是整个压缩过程完全在浏览器本地完成，基于WebAssembly技术，把C++和Rust编写的压缩库直接编译成浏览器可执行的模块，图片从头到尾不会上传到任何服务器。也就是说，它既是一个在线工具，又具备离线工具的隐私安全感。

功能层面它支持JPEG、PNG、WebP、AVIF等多种格式之间的互转，每种格式都提供了精细的算法选择。比如JPEG可以选MozJPEG编码器，WebP支持Lossy、Lossless、Near-lossless三种压缩模式，AVIF甚至能选多种编码器。这种颗粒度，主流在线压缩网站基本给不了。

界面方面，Squoosh采用左右对比式布局：左侧是原始图片，右侧是压缩后的实时预览。中间面板调整参数时，右侧效果同步变化，压缩率、文件大小、实际像素尺寸都直接显示，所见即所得。操作门槛几乎为零，拖拽图片进浏览器窗口就能用。

1.2 在群晖上部署的四大核心价值

第一个理由是隐私安全。我不会把生活照片上传到第三方压缩平台，那些网站不仅要等上传下载，照片还可能被存储、被分析。自部署Squoosh，所有计算都在NAS本地，图片不出家门。

第二个理由是全家设备共享。部署在群晖上之后，家里任何设备只要有浏览器就能访问。手机、平板、Mac、Windows电脑都行，不用每台机器装一个客户端，也不存在跨平台兼容问题。家人要压缩几张图片，手机浏览器打开直接拖进去，几秒钟解决。

第三个理由是性能优势。NAS的CPU比手机强得多，压缩几十张4K照片时桌面浏览器的WebAssembly执行效率相当可观。我实测中，一张48MB的无人机航拍图，转换到WebP格式，大概三四秒出结果。在手机上压这么大的图，基本会卡到怀疑人生。

第四个理由是配合NAS的文件管理能力。群晖的共享文件夹、Cloud Sync、Syncthing这些生态都用得上。把待压缩图片放到固定目录，浏览器里处理完直接存回NAS指定位置，整个工作流自然顺畅，不用再走"下载-处理-上传"的弯路。

选择在群晖上部署Squoosh，本质上就是把图片处理能力内嵌到已有的存储基础设施里，让"存储"和"处理"不再脱节。这也是我强烈推荐给NAS玩家的原因。

2. 部署前的准备：思路与选型

2.1 确认群晖Docker环境

部署Squoosh最干净利落的路径是Docker容器。群晖从DSM 7.2开始，套件中心的Docker应用改名为Container Manager，底层还是那套Docker引擎。DSM 6.x时代的老版本用Docker套件同样可行，但建议优先升级到7.x以上，Container Manager的界面和稳定性都好不少。

确认方法很简单：打开群晖套件中心，搜索Container Manager或者Docker，如果没安装就点安装。安装完成后打开，能看到容器、镜像、项目、注册表等菜单，说明Docker环境就绪。群晖的Container Manager本质上就是把命令行Docker管理操作图形化，你后续可以在里面完成拉镜像、建容器、看日志这些核心操作。

硬件架构也值得提前确认。群晖的NAS分为x86架构和ARM架构两类，DS220+、DS920+这类是x86，DS423、DS223j这类偏入门的是ARM。Squoosh镜像通常同时提供多架构版本，但在老旧的ARM机型上跑WebAssembly编译出来的前端，性能可能不太理想。部署前看一眼自己NAS的CPU架构，有助于预判实际体验。

2.2 镜像选择与研判

Squoosh官方仓库主要提供源代码和开发环境，Docker Hub上并没有一个所谓的"官方稳定镜像"。所以社区方案就成了主流选择。我调研了一圈，常见的有两类。

第一类是社区维护的现成镜像，使用度比较高的是ascoderu/squoosh。这个镜像在Squoosh原版基础上做了增强：支持点选上传多张图片、支持批量压缩、部分界面上做了中文适配。它的GitHub仓库更新还算活跃，遇到问题也能去提Issue。对普通用户来说，这是最省心的方案。

第二类是自建镜像，从Squoosh的GitHub仓库拉源码，自己写Dockerfile构建。好处是可以深度定制界面和功能，坏处是需要Node.js构建环境，而且每次上游更新都要重新拉代码打包。如果不是有特殊的二次开发需求，我不建议普通用户走这条路，纯粹是给自己找事。

我在实际部署中选择了ascoderu/squoosh，理由是省事、功能比原版全、更新活跃度够。版本标签方面，直接用latest简单粗暴，也可以选一个明确的版本号，更利于环境稳定复现。

2.3 端口、目录与资源规划

Squoosh容器默认监听80端口，在群晖上需要映射到一个不会冲突的宿主端口。我选了8088，这个端口在群晖上通常没有被占。端口规划时注意避开群晖的一些系统端口：5000和5001是DSM管理界面，80和443是Web Station，如果这些端口被容器抢走，群晖自己的服务可能出问题。

目录方面，ascoderu版本支持两种方式：一种是把图片直接上传到容器内处理，另一种是把宿主机目录挂载进容器，方便直接处理NAS本地文件。我建议在容器配置里设置存储空间映射，比如把/volume1/docker/squoosh/input映射到容器内的/input，这样群晖里的图片可以拷贝进去，批量处理完再从容器内拷贝出来。虽然多一步拷贝操作，但胜在路径清晰。

资源限制我也强烈建议提前规划。镜像默认没设内存上限，压缩超大图片时浏览器和WebAssembly模块可能会消耗好几GB内存。我在创建容器时就设置了2GB的内存上限，避免压缩过程把NAS拖垮，影响了其他容器和文件服务。CPU方面不用特别限制，Squoosh的压缩任务短则几秒长则几十秒，不会持续霸占CPU。

3. 实操部署：从拉取镜像到第一次压缩

3.1 通过Container Manager拉取镜像

打开群晖的Container Manager，左侧菜单栏找到"注册表"，在搜索框输入squoosh。搜索结果里会出现好几个相关镜像，选择ascoderu/squoosh，注意不要选错，有些镜像名字很像其实是别人做的二次修改版。

选中之后点击"下载"，会弹出标签选择窗口，选latest即可。如果希望环境更稳定可复现，也可以选一个具体的版本号。下载时间取决于网络情况和镜像体积，一般几分钟内能完成。下载完成后，在"镜像"列表里就能看到这个镜像，状态是"已完成"。

喜欢用命令行的朋友也可以在群晖上开启SSH功能，然后用docker pull ascoderu/squoosh拉镜像。两种方式本质一样，Container Manager只是把Docker命令封装成了图形界面。我平时习惯用图形界面操作，因为直观，不用记参数。

3.2 创建容器并完成关键配置

镜像下载完成后，在"镜像"列表里选中它，点击"运行"，进入容器创建向导。配置项比较多，我一个个说：

第一项是常规设置。给容器起一个容易识别的名字，比如Squoosh，其他保持默认。

第二项是端口设置，这步最关键。点击"新增"添加一条端口映射规则：容器端口填80，本地端口填8088。含义是群晖的8088端口收到的请求，全部转发到容器内的80端口。如果8088被占用了，就换8089或者8090，只要确保不和其他服务冲突。

第三项是存储空间设置，可选配。把群晖上的一个目录映射到容器内，建议路径像/volume1/docker/squoosh这样的固定位置，方便管理。容器内路径可以填/output，后续压缩导出文件时就可以直接写到这个目录。注意挂载目录如果不存在，需要先在File Station里手动创建。

第四项是环境变量和高级设置。ascoderu/squoosh镜像一般不需要额外配置环境变量。但资源限制建议在高级设置里加上：勾选内存限制，填入2048（单位是MB，也就是2GB）。如果NAS本身内存不大，可以设成1024。

全部配置完成后点击"完成"或"应用"，Container Manager会自动创建并启动容器。启动后可以在"容器"列表里看到它的状态变成"运行中"。

为了方便习惯用命令行方式的朋友，这里附上对应的docker run命令写法，参数含义和上面的界面配置一一对应：

bash复制docker run -d \
  --name squoosh \
  -p 8088:80 \
  --memory 2g \
  -v /volume1/docker/squoosh/output:/output \
  ascoderu/squoosh:latest

3.3 启动容器并验证访问

容器启动成功后，在浏览器里输入群晖的IP和映射端口即可访问。比如我的NAS IP是192.168.1.100，访问地址就是http://192.168.1.100:8088。页面上如果出现Squoosh的拖拽界面，说明部署成功了。

如果打不开，先别急着重建容器，到Container Manager的"容器"列表里选中Squoosh，点击"日志"按钮查看输出。正常的日志里会出现监听80端口之类的字样。如果日志空白或者报错，多半是配置问题。我后文会专门讲排查思路。

浏览器兼容性也值得注意。Squoosh依赖WebAssembly，太老版本的浏览器直接白屏或提示不支持。建议用Chrome、Edge或者新版本的Safari，Firefox也能跑，但某些编码参数下的性能不如Chromium内核浏览器。

3.4 第一次完整压缩体验

部署完成，我拿一批最近旅行拍的JPEG试了试。操作非常直观：打开页面，把图片文件直接拖进浏览器窗口，界面自动分成左右两栏，左栏显示原图信息和大小，右栏显示压缩后的实时预览。

中间的区域是参数调整面板。格式选择、压缩质量、编码算法都能调。我选了WebP格式，质量参数拉到75左右，一张原本4.8MB的JPEG照片，立刻压到了1.2MB，肉眼看不出明显差别。切换到AVIF格式更猛，压到了600多KB，但编码时间稍微长了一点，大概多花了2秒。

这里把各格式的适用场景和参数建议整理成一个表格，是我多次使用后的经验值：

批量处理方面，ascoderu版本支持一次上传多张图片，逐张调整参数后分别保存。我实测批量压缩30张照片，输出到挂载目录，全程不到2分钟。和手动用PS一张张批处理相比，效率提升是数量级的。

4. 常见问题与排查技巧实录

4.1 端口冲突导致容器启动失败

这是新手最容易遇到的问题。如果设置的本地端口已经被其他容器或者群晖系统服务占用，容器会启动后立即退出。排查方法很简单：在Container Manager的容器列表里，如果状态是"已退出"，点击日志查看，里面大概率有端口绑定失败的报错信息。

解决方案就是换一个本地端口，重启容器即可。我建议在设置端口前先用SSH执行netstat -tlnp | grep加上端口号，提前确认端口没有被占用。另外，端口映射里"本地端口"和"容器端口"别搞反了，前者是外部访问用的，后者是容器内部固定的监听端口。

4.2 容器运行中但浏览器访问不了

容器状态是"运行中"，但浏览器死活打不开，这种情况我从三个方向排查。

第一步，确认访问地址正确。Squoosh的端口映射后，访问地址是http://NAS的IP:本地映射端口。把8088误写成容器端口80会导致失败，因为容器端口只在Docker内部网络有效。

第二步，排查群晖防火墙。群晖的防火墙默认可能拦掉非标准端口的访问。去控制面板的"安全性"里检查防火墙规则，如果启用了防火墙，需要加一条规则放行8088端口的入站TCP流量。

第三步，看反向代理和HTTPS跳转的问题。有些群晖用户配置了全局HTTPS强制跳转，导致访问HTTP端口时被跳到一个不存在的HTTPS地址。如果遇到这种场景，要么给Squoosh配一条不强制走HTTPS的规则，要么在反向代理里把HTTPS证书绑定好。

4.3 大图处理卡顿或内存占用过高

压缩几十MB的RAW文件或者超大PNG时，浏览器和WebAssembly模块会吃掉大量内存。如果NAS本身内存不大，或者同时跑着其他容器，压缩过程可能明显卡顿甚至浏览器崩溃。

我的经验是，容器设置里一定要限制内存上限。设成NAS总内存的四分之一比较稳妥，比如NAS有8GB内存，容器限制2GB。浏览器端也不要一次性拖入太多大图，处理完一组再拖下一组。真遇到卡顿，等图像编码完成再调整参数，别同时开多个标签页，避免不必要的内存开销。

4.4 界面显示异常或按钮缺失

访问到的界面是英文的，或者找不到某些功能按钮，先不要怀疑镜像装错了，大概率是浏览器缓存问题。用Ctrl+F5强制刷新页面、清掉缓存再试。

如果确定是ascoderu版本但界面还是原版风格，检查一下镜像名称和标签。有时候latest标签拉的确实是原版或者旧版本，建议去看一下镜像的GitHub仓库说明，看它推荐的标签是哪个。还有一点，WebAssembly需要浏览器支持，老版本浏览器会导致界面白屏或交互失灵，升级浏览器版本基本能解决。

4.5 外网访问的安全配置

Squoosh本身没有用户认证机制，部署在局域网内问题不大，但一旦通过端口转发暴露到公网，等于给全世界开了一扇门。任何知道地址的人都能用你的NAS带宽压缩图片，这既浪费流量也有隐私风险。

我建议的外网访问方式是：群晖QuickConnect配合反向代理，或者在反向代理层加一层Basic Auth认证。具体操作是在群晖的反向代理规则里，为Squoosh域名启用HTTP访问认证，设置用户名和密码。这样即使地址暴露，没有凭证也进不来。还有一条红线——不要图省事把8088端口直接映射到路由器公网，除非你有完整的防火墙规则和访问控制，否则风险极大。

5. 进阶玩法与个人心得

5.1 与群晖生态的联动实践

Squoosh部署完成后，我很快把它融进了现有的群晖工作流。手机相册自动同步到群晖Photos，周末整理相册时，把准备分享的照片拷贝到一个固定的共享文件夹，然后用Squoosh批量压缩到合适体积，再发到家庭群。整个过程只涉及浏览器和File Station两个界面，逻辑特别清晰。

如果你用了群晖Drive或者Syncthing，还可以更自动化。比如设置一个单向同步任务，把手机里的照片自动同步到NAS上的一个"待压缩"目录。定期打开Squoosh，从这个目录拖图进去处理，压缩完输出到"已压缩"目录，再让Drive把这些小体积文件同步回需要的地方。这套组合拳下来，图片处理环节基本不需要跨设备搬运了。

5.2 批量处理的工程化思路

日常100张以内的图片，用Squoosh逐个调参完全够用。但如果你一次要压几百上千张，比如做电商商品图、整理活动照片，逐个操作就太慢了。

工程化的思路有两个方向。一个是用Squoosh自身支持的批量上传功能，一次拖入几十张图，逐张确认参数后统一输出，这适合几百张的中等批量。另一个是写脚本调用前端压缩能力，比如用Node.js配合Sharp库处理批量图片。Sharp底层是libvips，压缩速度和内存表现都不错，但和Squoosh的算法细节不完全一样，输出体积会有些差异。对大多数NAS玩家来说，Squoosh自带功能已经足够，脚本化反而是过度设计。

5.3 使用Squoosh的几点个人体会

把Squoosh部署到NAS之后，它成了我分享照片整个链路里最顺手的环节。让我最放心的是它的隐私特性——图片从头到尾不出本地，我不用纠结第三方平台会不会拿照片做额外的事情。其次是它的轻量，不像桌面应用那样开机自启、弹窗更新、占用常驻内存，它是个容器，需要时打开页面，不需要时安静地待在后台。

从NAS运维的角度看，Squoosh的运行非常稳定。我部署到现在差不多半年，没有出现过容器崩溃或数据丢失的情况。Docker隔离机制带来的好处很直接：就算界面出问题，也不会影响群晖系统本身，删掉容器重建一个就是，无痛恢复。

最后再分享一个小经验：压缩WebP格式时，把质量参数拉到70到80之间是最佳性价比区间。再往上提，肉眼几乎分辨不出画面变化，文件体积却会明显增加。AVIF格式的性价比也不错，但编码时间偏长，处理大量图片时总耗时会更久。另外，定期在Container Manager里检查镜像更新信息，新版本通常会优化压缩算法和界面交互，值得跟进。

Squoosh这种"手边工具"型应用，折腾的成本很低，收益却实实在在。拿它处理完第一批照片后，你大概也会和我一样，把PS批量压缩脚本彻底丢进回收站。