Dashy 导航页：家庭服务总入口长这样

摘要

服务越上越多，地址越记越乱：博客是哪个域名、图床端口多少、PVE 面板走哪个隧道？Dashy 导航页就是全家的"服务黄页"：CT702 上 Docker 部署（:3002），一个页面按分组列出所有服务的内外网入口和用途说明，公网地址 nav.028000.xyz（basic auth + HTTPS）。这篇记录它的部署、信息架构（分组逻辑）、conf.yml 的结构，以及 Dashy 3.x 那个"配置挂载位置变了"的大坑。

一、为什么需要导航页

这套家庭数据中心现在的入口数量：5 个公网域名、十几个 nps 隧道端口、若干内网 IP:端口。没有导航页的日常是这样的：想进 PVE 面板，先翻聊天记录找隧道端口；想给朋友分享文件，翻半天才想起 file 的域名；图床地址换了公网，旧书签还指着内网。

导航页解决的是"寻址"问题：所有服务的入口，一个页面全找到。它不跑业务，只解决"去哪"的问题。之前整理过一份 Word 版的服务地址手册（归档用），日常查地址看导航页，分工明确。

二、部署：CT702 上的 Docker

Dashy 跑在 CT702（docker-lab）上，和 Stirling PDF、Uptime Kuma 共用 /root/lab-compose.yml（在容器内）：

# /root/lab-compose.yml（dashy 片段，结构示意）
services:
  dashy:
    image: lissy93/dashy:latest
    ports:
      - "3002:3002"
    volumes:
      # Dashy 3.x 真正读取的是 /app/user-data/conf.yml
      # 两个都挂，避免踩坑（见第七节）
      - /opt/dashy/conf.yml:/app/user-data/conf.yml
      - /opt/dashy/conf.yml:/app/public/conf.yml

配置文件在容器内的 /opt/dashy/conf.yml，改完重启容器生效（注意 bind 挂载单文件的 inode 问题，见踩坑）。

三、信息架构：分组逻辑

导航页的页面名叫「028000 · 家庭数据中心」，分组按"使用场景"而不是"技术类型"划分——因为看导航页的不只我自己，家人也要能看懂：

分组	内容举例	面向
常用服务	博客、图床、文件站、密码库	全家
PVE 虚拟化	PVE 面板、DSM、办公虚机 RDP	管理员
应用服务	Stirling PDF、Uptime Kuma、qBittorrent	管理员
VPS	nps 面板、s-ui、宝塔（注：走 VPN）	管理员

每个条目包含：名称、内外网地址、用途一句话说明。地址写全：公网写域名，内网写 IP:端口，隧道写 VPS 端口。目标是"看到条目就知道怎么连"，不用再翻别的文档。

分组逻辑有个原则：常用服务的放前面，管理入口放后面。家人打开导航页，第一眼看到的是博客、图床、文件站，不会被 PVE 面板这种他们用不上的东西干扰。管理员才往下翻。

四、conf.yml 的结构速览

Dashy 的配置就是一份 YAML，结构很直白：

# /opt/dashy/conf.yml（结构示意）
pageInfo:
  title: 028000 · 家庭数据中心
  description: 家庭服务总入口

sections:
  - name: 常用服务
    items:
      - title: 博客
        description: 技术博客（Halo）
        url: https://blog.028000.xyz
        icon: favicon  # Dashy 可自动抓取站点图标
      - title: 图床
        description: EasyImage 自建图床
        url: https://img.028000.xyz

  - name: PVE 虚拟化
    items:
      - title: PVE 面板
        description: 经 nps 隧道 28006
        url: https://192.168.0.100:8006  # 内网直连地址

维护就是增删改 items。图标用 Dashy 的自动抓取（favicon），不用手动找图。description 写"用途 + 关键信息"（比如隧道端口），一眼能用。

五、公网化：nav.028000.xyz

Dashy 是唯一保留公网入口的"默认内网"应用，因为它本身就是"从外面查家里服务地址"的入口。链路：

公网用户 → https://nav.028000.xyz
  → VPS 443（nginx：basic auth + LE 证书）
  → 127.0.0.1:28503（nps 隧道）
  → 192.168.0.127:3002（CT702）

安全措施：basic auth（账号密码在 NAS 私密配置归档）、HTTPS（LE 证书，2026-12-30 到期，自动续期）、HTTP 301 跳转。验收：无认证返回 401，有认证返回真实页面。

basic auth 是有意选的"笨办法"：导航页不需要复杂的用户体系，一道密码门就够了。简单、可靠、无维护成本。

六、维护习惯：新服务上线必录入

导航页的价值在于"全"，漏一个就打折。所以定了个习惯：新服务上线，Dashy 录入是验收清单里的一项。Halo 博客、EasyImage 图床上线时，都第一时间录进了导航页。

录入检查项：

[ ] 名称、内外网地址、用途说明写全
[ ] 分组放对（常用/管理）
[ ] 图标正常显示
[ ] 内网地址从家里点得通，公网地址从外面点得通
[ ] 下线服务及时删除（比如已删的 pdf/status 公网入口）

导航页本身也要进监控（Uptime Kuma P1 级），它是"找服务的服务"，它挂了，别的服务再正常也找不到。

七、踩坑记录

坑 1：Dashy 3.x 的配置挂载位置变了

带 Node 后端的 Dashy 3.x，配置实际从容器内的 /app/user-data/conf.yml 读取并服务，挂载到 /app/public/conf.yml 会被无视。表象：配置改了，页面还是英文默认，误以为"配置写错了"。解法：compose 里两个路径都挂。详见《PVE 里跑 Docker：LXC 容器 CT702 实战》。

坑 2：bind 挂载单文件，宿主重写后容器内还是旧的

bind 挂载单个文件后，如果在宿主侧重写文件（换了 inode），容器内看到的还是旧内容。表象：conf.yml 明明改了，重启容器也不生效。解法：重启或重建容器。更稳的习惯：改配置后 docker compose restart dashy，不行就 up -d --force-recreate。

坑 3：basic auth 密码别太简单

导航页在公网，basic auth 是唯一的门。密码要够强，存在 NAS 私密配置里。basic auth 没有防爆破机制（不像登录接口有 fail2ban），所以密码强度是唯一的防线。

进阶玩法：状态小组件与搜索框

Dashy 除了导航，还支持小组件（widget）和顶部搜索框，配好了导航页就从"黄页"升级成"工作台"。

玩法	说明
状态 widget	接 Uptime Kuma 或服务探针，导航页上直接看到各服务在线/离线，不用跳过去看
搜索框	顶部一键搜索，可配成搜书签、搜服务，家人找东西更快
天气/时钟 widget	门面装饰，打开导航页先看到时间和天气，体验加分

这些属于"有了更好"的进阶项，核心导航先稳，再慢慢加。加 widget 的原则：只加"看一眼就有用"的，不加纯装饰吃性能的。

导航页的设计哲学：家庭数字生活的玄关

导航页看起来只是个"链接集合"，但它的设计藏着一套哲学：它是家庭数字生活的玄关。玄关的作用是什么？进门换鞋、挂钥匙、放雨伞——把外面的世界整理成"家的秩序"。导航页干的正是这件事：把散落在各处的服务（博客、图床、文件站、面板、隧道），整理成一家人都看得懂的秩序。

设计导航页时，有三个问题要先想清楚。第一，谁在看？家人和管理员看到的应该是不同的东西。家人要的是"博客在哪点、照片在哪看"，管理员要的是"PVE 面板走哪个端口、隧道通没通"。所以分组不是按技术类型（虚拟化/网络/应用），而是按使用场景（常用服务/管理入口）。技术分类是工程师的语言，场景分类才是人的语言。第二，点进去之后呢？每个条目除了地址，还要有一句用途说明。"PVE 面板"四个字，家人看了不知道是干嘛的；"PVE 面板（经隧道 28006，管理员用）"，一看就懂，还顺手把"别乱点"的意思传达到了。第三，旧的怎么办？服务下线了，导航页的条目要同步删。导航页最怕"僵尸链接"：点进去 404，比没有导航页还让人恼火。所以"新服务上线必录入、下线必删除"不是洁癖，是导航页的生命线。

还有一个容易被忽略的点：导航页是"文档"的一种。之前整理过 Word 版的服务地址手册，归档用；导航页是活的手册，天天在用。文档有两种命运：一种是写完就死，一种是天天被用。导航页属于后者，因为它长在每天的动线上。做运维文档有个经验：凡是需要"专门去翻"的文档，都会慢慢过时；凡是长在动线上的信息，都会自我更新。导航页就是后者——每次点开都在验证它的正确性，错了立刻能发现。

最后说说颜值。导航页是全家桶的门面，家人对它的第一印象，决定了他们对整套自建服务的信任度。一个排版精美、图标齐全、分组清晰的导航页，家人会觉得"这东西靠谱"；一个默认英文、链接堆砌的页面，家人会觉得"这又是什么野路子"。Dashy 的图标自动抓取、分组、搜索框，都是为这个服务的。技术人容易忽视"好看"的价值，但在家庭场景里，好看就是可用性的一部分。

导航页的另一面：书签管理的终结

导航页上线前，全家的服务地址散在三个地方：浏览器书签、聊天记录、备忘录。书签的问题是"只在自己的浏览器里"：手机书签和电脑书签不同步，换浏览器全丢；聊天记录的问题是"越久越难找"：半年前的地址，翻半小时；备忘录的问题是"没人更新"：地址换了，备忘录还是旧的。

导航页终结了这种混乱，因为它是"单一可信源"：地址换了，改导航页一个地方，全家生效。不用通知每个人"书签换一下"，不用在群里发"新地址"。单一可信源是运维的基本功，导航页是它在"服务寻址"上的落地。

书签还有个隐性问题：它记的是"你常去的地方"，不是"全家的地方"。家人的书签里没有 PVE 面板（他们不用），但有一天他们需要找"家里的照片在哪"，书签帮不上忙。导航页是"全家的地图"，不只是"你常去的几个点"。地图和书签的区别：书签是私人的、静态的；地图是公共的、活的。家庭数字生活，需要的是一张地图。

移动端：导航页的手机版

导航页在手机上也要好用，因为"出门在外查地址"是高频场景。Dashy 默认是响应式的，手机上自动变单列。两个优化点：一是把"常用服务"分组置顶，手机上第一屏就是博客、图床、文件站，不用翻；二是大按钮， tile 别太小，手指点得准。手机浏览器的"添加到主屏幕"，把导航页变成一个 App 图标，点开就是全家服务。这才是导航页的完全体：手机主屏幕上的"家"。导航页做完，最大的感受是：家庭数字生活需要的不是更多服务，而是更少的心智负担。一个入口，全家不迷路，这就是导航页的全部意义。把这句话贴在显示器上，下次加服务时，先问"导航页怎么放"。服务可以越来越多，入口永远只有一个。入口一多，就不是导航页，是第二个书签堆。守住"一个入口"，就是守住导航页的价值。价值守住了，导航页才有存在的意义。导航页的另一个价值是" onboarding"：新设备、新家人，打开导航页，全家的数字家当一目了然。不用一个个解释"照片在哪""文件在哪""博客地址是啥"，一个链接解决。这种"自解释"的能力，是导航页超越书签的本质：书签是给自己看的，导航页是给全家看的。给全家看的东西，标准要更高：名字要直白，图标要清晰，分区要合理。多花 10 分钟排版，省的是全家人未来无数次的"这个在哪"。

八、总结

Dashy 导航页是家庭数据中心的"服务黄页"：Docker 部署、conf.yml 管分组、按使用场景分组（家人能看懂）、新服务上线必录入、公网入口加 basic auth。最大的坑是 Dashy 3.x 配置挂载位置变了，两个路径都挂一劳永逸。导航页本身也要进监控——"找服务的服务"不能挂。之前 Word 版的手册归档留底，日常查地址只看导航页，一个入口就够了。

摘要

目录