起因：服务一多，书签就不够用了
我在极空间上陆陆续续跑了不少容器。最开始只有两三个，记 IP 加端口就行。后来变成七八个，再后来连我自己都要翻 Docker 列表才能想起来某个服务到底在哪个端口上。
问题的核心不是"记不住端口"，而是入口分散。每个服务都有自己的登录页、自己的图标、自己的地址。家里人想用某个服务，我得截图发过去，或者口头念一遍192.168.x.x:xxxx。这种体验在服务数量超过五个之后基本就崩了。
我先试过几种办法：
- 浏览器书签：只能解决我自己的问题，别人用不了，换设备就没了。
- 极空间自带的应用入口：能聚合一部分，但对第三方 Docker 容器的支持有限，自定义程度不高。
- 手写一个 HTML 页面：可行，但每加一个服务就要改一次 HTML，图标和分组全靠手写，维护成本高。
后来我想找现成的导航面板。这类工具其实不少，我最终选了 Dashlet，原因是它足够轻，配置是 YAML，容器镜像体积小，而且支持分组和内外网地址切换——这几点正好对上我的需求。
需要说明的是，导航面板这个领域选择很多，我选择 Dashlet 不代表它是唯一解或者最优解，只是它符合我"配置简单、部署轻量"的偏好。下文所有内容都基于我实际部署的这一套，没有验证过的部分我会明确标出来。
部署：用 Docker Compose 跑起来
极空间支持通过 Docker 界面或者 Compose 文件部署容器。我习惯用 Compose，因为配置可以版本化，迁移和重建都方便。
Dashlet 的镜像和配置方式，我参考的是它项目仓库里的说明。下面是我实际用的 compose 配置，路径部分需要按自己的存储结构改：
version:"3"services:dashlet:image:ghcr.io/dashlet/dashlet:latestcontainer_name:dashletrestart:unless-stoppedports:-"8088:8080"volumes:-/volume1/docker/dashlet/config:/app/configenvironment:-TZ=Asia/Shanghai几个点解释一下为什么这么写：
restart: unless-stopped是必须的。NAS 会不定时重启，如果不加这个，每次重启后导航页就没了，得手动去拉起来，那就失去意义了。
ports左边我用了8088，是因为8080在我的环境里已经被别的服务占了。这个端口你可以随便换，只要不冲突。
volumes映射的是配置文件目录。Dashlet 的配置以文件形式存在，挂出来之后，改配置不用进容器，直接编辑宿主机上的文件即可，也方便备份。
【踩坑提醒】极空间的存储路径命名和群晖不太一样，我这边是/volume1/...这种结构，但不同型号、不同存储池的挂载点可能不同。部署前先用docker inspect或者文件管理器确认一下真实路径，别直接照抄。
TZ这个环境变量，我是习惯性加的。至于 Dashlet 本身是否读取这个变量来调整时间显示，这一点我没有专门验证——加着不影响，但不要以为它一定生效。
配置目录里通常需要一个主配置文件，我这边叫config.yaml（具体文件名以项目文档为准，我没有逐一核对所有版本）。结构大致是这样：
title:"家庭服务导航"groups:-name:"媒体"items:-name:"Jellyfin"url:"http://192.168.1.10:8096"icon:"jellyfin"-name:"工具"items:-name:"Vaultwarden"url:"http://192.168.1.10:8080"icon:"vaultwarden"groups是分组，每个分组下面是items，每个 item 有name、url、icon。这套结构是导航面板里比较通用的写法，Dashlet 大体上也是这个思路，但字段名和层级是否完全一致，需要以你拉取的那个版本的项目文档为准。我写的是我这边能跑通的形态，不保证跨版本通用。
【注意】改完配置后，有的实现是热加载，有的需要重启容器。我这边是重启容器生效的，所以每次改完配置我会docker restart dashlet一下。你可以先改一个条目试试，看刷新页面有没有变化，再决定要不要重启。
分组：按使用场景而不是按技术栈
分组这件事，我一开始想按技术类型分——数据库一类、媒体一类、工具一类。后来发现这个分法对我没用。
真正用导航页的人不只是我。家里人只关心"我要看电影"、“我要传文件”、“我要记密码”。他们不关心这个服务是 Python 写的还是 Go 写的，也不关心它跑在哪个端口。
所以我改成了按使用场景分组：
| 分组 | 放什么 | 谁会用 |
|---|---|---|
| 媒体 | 影视、音乐、照片 | 全家 |
| 文件 | 网盘、同步、备份 | 全家 |
| 工具 | 密码管理、笔记、RSS | 主要是我 |
| 运维 | 监控、日志、容器管理 | 只有我 |
| 测试 | 临时跑的服务 | 只有我 |
这么分之后，家里人打开导航页，第一眼看媒体和文件就够了，不用在十几个图标里找。运维和测试这两个分组相当于给我自己留的，其他人基本不会点进去。
分组名不用太花哨，叫什么不重要，重要的是别让不同角色的人在同一个列表里翻找。
图标：能用官方图标就别自己画
导航页好不好用是一回事，好不好看是另一回事。图标这块我踩过一次弯路。
一开始我是自己找 PNG 图片，一个个上传。问题是大小不统一、风格不统一，深色模式下有的图标直接看不见。后来我发现 Dashlet 支持用图标名（比如上面配置里的jellyfin、vaultwarden），它会去匹配内置的图标库。
-name:"Jellyfin"url:"http://192.168.1.10:8096"icon:"jellyfin"用名字匹配的好处是，图标风格统一，而且不用自己维护图片文件。坏处是不是所有服务都有对应的图标。冷门的自建服务大概率匹配不到，这时候它会显示一个默认图标或者首字母。
我试过用icon字段填一个图片 URL，指向我自己托管的一张图。这个做法在部分版本里可行，但我没有在所有版本上验证，如果你的版本不支持，最稳的办法还是看官方文档里对icon字段的说明。
【关键结论】图标这件事，优先用内置图标名，匹配不到就接受默认图标，别为了几个冷门服务去搞一堆自维护图片，维护成本划不来。
内外网地址：一个容易忽略但很实用的点
我最初没在意这个功能，直到有一次在外面用手机流量打开导航页，发现所有链接都点不开——因为它们全是192.168.x.x的内网地址，出了局域网就是死链。
Dashlet 这类导航面板一般支持给同一个服务配多个地址，比如一个内网地址、一个外网地址，访问时根据当前环境自动选。配置形态大概是这样：
-name:"Jellyfin"url:"http://192.168.1.10:8096"url_public:"https://jellyfin.example.com"icon:"jellyfin"url是内网地址，url_public是外网地址。
这里我要非常明确地说：url_public这个字段名是我按照常见实现推测的写法，我没有逐字核对 Dashlet 官方文档里这个字段到底叫什么。不同版本可能用external_url、public_url或者别的名字。你在用之前，一定要去项目文档里确认字段名，别直接抄。
至于它怎么判断"当前是内网还是外网"，我这边观察到的行为是：如果页面是从内网地址打开的，就走内网链接；从外网域名打开的，就走外网链接。但这个判断逻辑的具体实现我没有看源码，属于观察到的现象，不是确认过的机制。
外网地址能不能通，还取决于你有没有做内网穿透或者反向代理。这部分和 Dashlet 本身无关，是网络层的事。
反向代理下的几个注意点
如果你像我一样，把导航页放在反向代理后面，有几个地方要留意。
第一是路径前缀。有些服务被挂在子路径下，比如https://example.com/dashlet/，这时候页面里的静态资源路径可能会错。我遇到的情况是图标加载不出来，最后是给 Dashlet 单独分配了一个子域名（dash.example.com）才绕过去。子路径部署能不能配好，取决于服务本身对 base path 的支持，这一点我没有深究。
第二是实际访问地址。如果 Dashlet 自己是通过https://dash.example.com访问的，但配置里服务地址写的是内网 IP，那么从外网打开导航页时，点内网链接依然不通。这正是上面内外网地址要分开配的原因。
第三是WebSocket 或者长连接。Dashlet 作为纯静态导航页，我这边没有观察到需要 WebSocket 的场景，所以反向代理配置里没做特殊处理。如果你的版本有实时更新之类的功能，可能需要额外配置，这一点我没有验证。
一个最简的反向代理配置思路（以通用 Nginx 为例）：
server { listen 443 ssl; server_name dash.example.com; location / { proxy_pass http://192.168.1.10:8088; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }X-Forwarded-Proto这行别省。如果后端需要根据协议判断生成绝对 URL，少了这行可能会生成http://的链接，导致混合内容问题。
配置备份：别把导航页当成可以随时重建的东西
导航页本身是"配置即数据"。容器删了可以重跑，但配置丢了就得一个个重新填。所以配置目录一定要纳入备份。
我的做法是把/volume1/docker/dashlet/config这个目录一起放进极空间的备份任务里，和其他重要数据一样定期同步。这样即使容器出问题，重建之后挂上同一个配置目录，服务立刻恢复。
顺带说一句，配置文件我建议直接放进 Git 仓库管理。导航页配置不涉及敏感数据（地址、图标名而已），版本化之后，改了什么一目了然，改错了也能回滚。这比"改完忘了改了啥"强太多。
这套方案解决了什么，没解决什么
用下来一段时间，我觉得它确实解决了最初的问题：入口集中，家里人不用再问我地址，我自己换设备也不用重新找书签。
但它没解决的事情也得说清楚：
- 它不管服务的可用性。导航页只是链接集合，某个服务挂了，图标还是亮的，点进去才发现打不开。真正的可用性监控得靠 Uptime Kuma 这类工具。
- 它不管权限。所有能打开导航页的人，都能看到所有链接。如果某个服务不想让家里人看到，导航页层面是拦不住的，得在服务本身做认证，或者干脆不放上去。
- 它不替代反向代理。外网访问、HTTPS、统一域名，这些还是得靠 Nginx、Caddy 或者内网穿透工具。
所以我的定位很明确：Dashlet 是入口层，不是管理层，也不是安全层。把它当成一个更好用的书签页，期望就不会错位。
关于 Dashlet 本身的一些说明
写到这里，我得诚实地说明几点：
Dashlet 这个项目，我使用的时间还不算特别长，配置项也没有全部试过。文章里出现的url_public字段、配置文件的准确名称、图标 URL 是否支持，这些我都标注了"未验证"或"以文档为准"。我不想把不确定的东西写成确定的事实，那样对你没有帮助。
如果你打算部署，我建议的顺序是：
- 先用最小配置（一个分组、一个服务）跑通，确认容器能起来、页面能打开。
- 再逐步加分组和服务，每加几个就刷新看看有没有问题。
- 最后再折腾图标、内外网地址、反向代理这些细节。
一步到位容易出错，而且出错之后不好定位是哪一步的问题。
如果你也在极空间或者类似 NAS 上自建服务，导航页这件事值得花半天时间整理一次。服务数量少的时候感觉不到，一旦超过十个，一个清晰的入口页能省下不少来回找端口的时间。至于用哪个工具，Dashlet、Homepage、Heimdall 这类都能干这个活，选一个配置方式顺手的就行，没必要在选型上纠结太久。
