Dashlet + cpolar：自建轻量仪表盘，告别书签混乱

1. 为什么我受够了浏览器书签才决定做一个轻量仪表盘我浏览器收藏夹里的链接数量终于在某个下午突破了心理阈值400 多条。里面有公司内网系统的后台、在线文档、技术手册、素材站、报表平台、云服务控制台……收藏的时候都觉得以后肯定用得上真到用的时候一个也搜不着。找一个链接的平均路径是点开收藏夹、翻到对应的文件夹、再碰运气看记忆里的分类是否靠谱。时间隔得久一点还得同时开两个浏览器互相对照整个过程非常浪费时间。后来我花了一个晚上搭了个 Dashlet 轻量仪表盘把最高频的网址按用途直接铺成卡片一次点击就能打开目标页面。再用 cpolar 做内网穿透把这个原本只能在本机访问的页面变成了在家、在公司、在路上都能打开的统一入口。这件事被我记进了自己的cpolar 内网穿透实验室操作记录编号正是第 757 个成功挑战。如果你也有一堆永远找不到的网址或者家里跑着自建服务但出门就连不上这篇文章可以给你一套能直接落地的完整方案。从 Dashlet 的部署细节、cpolar 隧道配置到我在实测过程中踩过的几个坑全部捋一遍。1.1 书签越攒越乱根源不是收藏而是找回浏览器书签的问题从来不是收录困难而是找回路径太长。收藏时只需要一秒但找回时往往要花半分钟甚至更久。更麻烦的是很多网址长得几乎一模一样后台系统、开发环境、测试环境、生产环境URL 只差一个数字或一个单词。我见过不少同事把类似这样的网址记在本地文档里结果换了电脑就完全找不到。我之前也尝试过用浏览器自带的文件夹分类给书签建了工作学习工具素材几大类大类下再分小类。整理的那天确实舒服但新收藏一个链接时还是会偷懒丢进其他几个月后又乱了。问题的核心在于书签栏适合放偶尔用的东西不适合放每天都在用的东西。高频网址需要的是看得见、点得着的入口而不是藏在层层菜单里的文字链接。所以问题的解法不应该是更好地整理书签而是把高频网址变成一打开就能看到的面板。这其实就是仪表盘工具的定位把散落在收藏夹、文档、聊天记录里的链接统一集中到一个界面上按场景分组视觉上扫一眼就能找到目标。1.2 为什么选 Dashlet而不是自己写一个导航页最早我确实想过自己写个导航站一个 HTML 页面放几个分类、一堆链接不外乎就是一个静态页面的事。但进一步想静态页面的维护成本低是低它解决不了几个实际问题第一我没有停在外面的服务器页面部署在家里就得想办法让外面能访问这一步终究绕不开内网穿透第二导航页需要改链接、加分类每次都得编辑文件再重新部署不够灵活第三我想要的不只是一堆链接还希望有一些小部件比如天气、RSS 订阅摘要、服务状态显示静态页面做这些就要开始写 JavaScript 了。Dashlet 是当时搜索到的一个很合适的开源项目。它主打轻量一个 Docker 容器就能跑界面默认就长成卡片面板的样子。官方定位是自托管的个人仪表盘核心功能就是把链接、书签、小部件混在一起展示。和同类的 Heimdall、Homarr 相比Dashlet 给我的第一印象是干净——没有一大堆用不上的功能也没有特别复杂的前端配置。它的默认界面就是一个全屏的网格靠类别区分区域视觉负担很小。再一个原因就是维护维度。Dashlet 支持通过 Docker Compose 部署数据目录可以随容器保留升级镜像也简单。对个人使用来说这已经足够。我现在自己维护的各类自建服务基本都是这个套路Dashlet 的加入不会带来额外的运维复杂度。1.3 第 757 个成功挑战是怎么一回事这里稍微解释一下标题里的编号。我在本地做了个内网穿透实验室系列的实验记录每期给自己定一个目标比如把一个没有公网 IP 的应用通过隧道发布出去、给家里的 NAS 打通远程访问、给开发中的 Webhook 回调提供临时回连地址。每完成一期就按顺序记一条Dashlet 这期正好排到第 757 个。编号本身没什么玄学只是想给自己一个持续实践的动力。这个系列的核心结论其实很朴素很多应用卡在只能本机访问这一关一旦把内网穿透的链路跑通生活质量能明显上一个台阶。这一期的验收标准我在动手前就列了四条Dashlet 容器正常启动数据目录可持久化在局域网内能正常访问仪表盘页面通过 cpolar 隧道在手机 4G/5G 网络下能打开同一页面移动端显示不破版点开链接能正常跳转。四条全过才算成功挑战。下面就从部署开始一步步说清楚。2. Dashlet 部署网址卡片是怎么跑起来的2.1 前置准备一台能跑 Docker 的设备就够了Dashlet 官方推荐用 Docker 部署所以准备一台能跑 Docker 的设备是唯一硬性要求。我用的是家里一台常年开机的迷你主机配置不高但跑几个轻量服务绰绰有余。树莓派、旧笔记本、云主机都可以只要系统是 Linux 或者能运行 Docker 的环境就行。在开始之前建议先规划好数据目录。我习惯在宿主机上建一个统一的服务目录比如/opt/docker下面每个服务一个子目录。Dashlet 的数据目录我放在/opt/docker/dashlet/data这样后续备份、迁移、升级都很方便不需要钻进容器里找数据。还需要确认 Docker 和 Docker Compose 已经装好。如果设备上还没有建议先把这两个装到位。我用的机器是 Ubuntu装 Docker 的命令就是常规的几条这里不再展开。2.2 通过 Docker Compose 启动 Dashlet我习惯用 Compose 文件管理所有自建服务Dashlet 也不例外。下面是我这期实际使用的docker-compose.yml你复制后按自己的端口和目录调整即可version: 3 services: dashlet: image: ntilley/dashlet:latest container_name: dashlet restart: unless-stopped ports: - 8080:3000 volumes: - ./data:/data environment: - TZAsia/Shanghai几个值得说明的地方容器内部端口是 3000我映射到宿主机 8080。如果你的 8080 已被占用改成 8081、9000 之类都可以但后面 cpolar 隧道也要指向同一个端口别记混。/data是容器内存储配置文件、数据库的目录必须挂载到宿主机否则容器一删你辛苦配置的卡片就全没了。restart: unless-stopped保证机器重启后服务自动拉起。这个参数对常驻服务来说几乎是标配。写好后在docker-compose.yml所在目录运行docker compose up -d。第一次会拉取镜像时间取决于网络状况。容器起来后在浏览器访问http://localhost:8080如果能打开 Dashlet 的默认欢迎页部署这关就算过了。2.3 添加卡片把高频网址从收藏夹里挑出来Dashlet 的交互逻辑不复杂核心是三类东西类别、链接和应用。类别相当于导航页里的分区比如工作后台日常工具学习资源链接就是具体的网址应用则是它内置的一些快速入口填写名称、URL、图标就能生成卡片。我建议第一步先做减法别把全部收藏夹都搬进去。只挑那些至少一周会打开一次的高频地址控制在 20 到 30 个以内。搬得太多仪表盘又会变成第二个收藏夹。我当时选了这几类工作高频运维后台、日志平台、工单系统、文档协作页开发常用Git 仓库、CI/CD 面板、接口调试工具日常素材设计素材站、图标库、压缩工具订阅内容几个常看的 RSS 源网页版。在 Dashlet 界面上添加链接时可以给每个链接配图标和颜色。图标可以选择用外部图标的 URL也可以让它自动抓取网站的 favicon。我后来是让 Dashlet 自动拉取 favicon效果普遍还行个别站点抓不到的就手动指定一个图标地址。2.4 页面布局和第一印象调整所有链接添加完成之后Dashlet 的默认布局已经能用了但我又花了几分钟做了两处调整一是把类别的顺序理顺。仪表盘的展示顺序是按类别来的把每天必用的类别往前放点击率低的往后放。二是改掉默认标题让它显示成我自己认识的名称而不是默认的 Dashlet。Dashlet 整体风格走极简路线默认背景、卡片阴影都比较克制。不过它不是那种能高度定制视觉主题的工具如果你想做渐变背景、圆角调超大、字体花哨的方案它可能满足不了你。它的定位就是清爽、少干扰这一点在我使用两周之后体会更深——仪表盘是拿来快速跳转的不是拿来欣赏的。3. 用 cpolar 把 Dashlet 变成随身入口3.1 先想清楚什么场景才需要内网穿透如果 Dashlet 只在局域网里用其实做到第 2 章就结束了。但我对它的要求是随身可用白天在公司打开晚上在家用手机打开出差时也能从平板上直接访问。这就要说到内网穿透了。家用宽带、公司网络绝大多数情况下没有单独的固定公网 IP路由器在公网侧是不可直接寻址的外面想主动连接到家内网的服务非常困难。内网穿透工具做的事情是在你的设备和一个有公网地址的服务端之间建立一条隧道把本地的某个端口映射到服务端分配的公网地址上。这样外部设备访问公网地址时流量沿着隧道到本地服务实际上访问的就是你家里的那台设备。这类技术本身是中性工具正当用途非常广远程访问自建的 NAS 和文件服务、开发调试时接收外部 Webhook 回调、临时把本地页面分享给不在同一局域网的人、在外访问家里的智能家居面板等等。我这一期做的就是把自建仪表盘安全地发布出去属于很典型的个人自建服务远程访问场景。3.2 安装 cpolar 并完成基础接入cpolar 是我这期用的穿透工具它的客户端支持 Linux、macOS、Windows。因为 Dashlet 跑在 Linux 迷你主机上我直接在宿主机上装了 cpolar 客户端。安装方式很简单官网提供了安装脚本curl -L https://www.cpolar.cn/static/downloads/install-release-cpolar.sh | sudo bash装完先确认版本号能正常显示再执行自动化管理命令。cpolar 客户端需要登录账号后才能正常使用隧道服务它会分配一个 token执行cpolar authtoken 你的token完成认证。之后启动服务隧道有两种方式临时使用可以直接用命令需要长久稳定运行则建议把隧道配置写进 crontab 或配置文件让客户端后台常驻。我这期是先临时跑通确认没问题后再做成配置避免一开机就要手动敲命令。3.3 创建第一条 HTTP 隧道指向 Dashlet 的 8080 端口因为 Dashlet 是网页服务且本地已经通过 HTTP 提供服务所以需要创建一条 HTTP 隧道命令形如cpolar http 8080执行后cpolar 会为这条隧道分配一个临时的公网访问地址。客户端同时会在本地启动一个 Web 管理面板默认地址是http://localhost:9200可以在面板里看到隧道状态、公网地址、请求统计等信息。我在这个环节有一个习惯性的自检动作拿到临时地址后先用手机浏览器打开一次确认页面能正常渲染、点链接能跳转而不是只在 PC 上试。手机端能通基本说明隧道链路是好的如果手机端有问题可以直接在管理面板里看请求是否到达了本地端口以此判断是隧道问题还是本地服务问题。临时地址的缺点是它会变化重启 cpolar 隧道之后地址可能就换了。对长期使用来说这不能忍所以下一步要固定域名。3.4 固定域名为什么必须给隧道一个不变的联系方式临时地址就相当于一个每次开机都会变的号码你不可能天天把新号码发给同事、存在自己手机里。固定的域名才能成为真正稳定的入口。cpolar 后台提供固定域名能力你可以在管理面板里申请一个保留的二级域名然后把本地隧道绑定到这个域名上。固定之后通过https://你的固定域名就能稳定访问 Dashlet不管隧道怎么重启、机器怎么重启入口地址不变。这一步对实际使用体验的提升是决定性的我强烈建议不是用来做一两次临时分享的话都去申请固定域名。绑定方式也很直观在 cpolar 管理面板创建隧道时指定本地端口为 8080隧道类型选 HTTP然后绑定你申请的保留域名。保存之后回到命令行重启隧道让新配置生效。3.5 安全底线仪表盘暴露在公网之前先想好这几件事把服务发布到公网不等于什么都不管。Dashlet 忘记设密码、隧道没有访问控制、页面里暴露了内网敏感信息这些都是实际风险。我给自己定了三条安全底线第一Dashlet 的登录必须启用。Dashlet 支持设置管理员账号部署后第一时间创建管理员用户。不要图省事跳过这步这就是最后一道门。第二cpolar 的隧道不随意开放。如果只需要自己用在管理面板里对公网访问做好限制或者至少在发现有异常请求时能通过访问日志看到来源。第三不在仪表盘里放任何含敏感凭据的信息。仪表盘只放链接入口密码、密钥、内网管理凭据一律不进页面。这条建议来自我的一次教训早期我把一些内部工具的 URL 带参数地写在仪表盘卡片上有一次分享页面截图时差点把带 token 的链接截进去。后来我明确规定仪表盘卡片一律只放干净的登录页地址需要带认证信息的操作走专门的密码管理工具。4. 实测中踩过的坑五个让跑通变成跑顺的问题这一章是全文最想说清楚的部分。第 2、3 章的步骤是顺的但如果你像我一样边做边踩大概率会碰到下面几个问题。我把每一次的排查过程都记录下来希望能帮你省下几个小时。4.1 端口没通容器起来了页面就是白屏第一次启动 Dashlet 后我在宿主机的浏览器里访问http://localhost:8080一直白屏。第一反应是镜像没跑起来但docker ps一看容器明明在运行日志也正常Dashlet 已经监听 3000 端口了。检查了很久才发现问题出在端口映射和防火墙两层机器上原本有一个旧服务占用了 8080Docker Compose 在启动时虽然报错失败了但因为我用的是up -d没细看启动输出容器根本没起来。另一个原因是系统防火墙没有放行 8080后来我在防火墙规则里加了端口放行才恢复正常。这里有个经验容器部署完以后别只盯着docker ps要习惯看docker logs和启动时的输出。docker ps显示在运行不代表端口映射成功更不代表服务真的对外可访问。4.2 临时隧道通了公网却返回 502cpolar 隧道启动后管理面板显示隧道 Online但用手机访问公网地址时浏览器返回 502 Bad Gateway。这个问题的排查链路我认为非常典型第一步确认本地是不是真的能访问。我在宿主机上执行curl http://localhost:8080返回正常说明 Dashlet 本身没问题。第二步看 cpolar 隧道是不是指向了正确的端口。我检查了隧道配置发现它指向了 3000而不是我映射到宿主机的 8080。我前面强调过别把容器端口和宿主机端口记混这里就踩了个正着容器内部监听 3000但宿主机上对外提供服务的端口是 8080隧道应该指向宿主机视角的 8080。改过来之后公网地址立刻通了。这类问题很隐蔽因为 cpolar 面板不会自动检测目标端口到底有没有服务它只管把流量送过去目标端口不通就反馈 502。4.3 公网地址是 HTTPS页面里却混着 HTTP 资源cpolar 分配的隧道地址默认支持 HTTPS。Dashlet 页面本身是纯前端渲染的这个问题一开始并不明显直到我发现手机浏览器上有些图标加载不出来、个别链接跳转时候浏览器地址栏出现不安全提示。排查方式是打开浏览器的开发者工具看 Console 和 Network 里的报错发现页面上部分静态资源仍然通过 HTTP 协议加载。浏览器处于 HTTPS 页面时默认会阻止 HTTP 子资源请求。这个问题的解决办法有两类一是检查 Dashlet 的配置看是否有设置项能强制资源走 HTTPS二是确认 cpolar 隧道配置里本地端口和协议设置正确让上游协议头的传递正常。我当时主要是调整了 cpolar 隧道的协议设置并把 Dashlet 前端资源地址改成相对路径或 HTTPS 形式问题就消停了。这个坑提醒我发布到公网的服务一定要在真实公网地址下完整测试一遍光在局域网里测是测不出混合内容问题的。4.4 移动端点开链接在新窗口还是原窗口的问题刚开始使用手机访问 Dashlet 时点卡片链接经常直接在当前标签页跳走想回到仪表盘还得再输一次网址或后退体验跟浏览器后退到收藏夹差不多。后来在 Dashlet 的链接配置里设置成新标签页打开跳转之后仪表盘标签还在切回去直接点下一个效率高了很多。虽然只是一个小设置但它对仪表盘能不能真正替代收藏夹影响很大。仪表盘的使用习惯是高频连续跳转先看 A 系统再开 B 平台再查 C 文档。如果每次跳走都要返回那跟手动输网址也没区别。Dashlet 支持对链接的打开方式做配置这一点建议拿到手就先改掉。4.5 没有访问告警我差点忘了它暴露在公网这是我最想强调的一个教训。Dashlet 和 cpolar 都跑通后我把入口域名存到手机上心满意足地用了两周。直到有一天我无意间打开 cpolar 管理面板看到里面有来自陌生 IP 的访问记录虽然都被登录页挡住了但那种原来我一直开着门的感觉很不好。后来我在管理面板养成了一个习惯每隔几天看一眼访问日志关注有没有异常来源。同时在 Dashlet 侧把管理员密码换成了高强度的随机密码开启两步验证或者在可能的情况下做访问白名单。内网穿透是一个入口工具入口后面是你家庭网络里的服务对这种入口保持一点谨慎不亏。5. Dashlet 到底好不好用同类方案对比与扩展方向5.1 和 Heimdall、Homarr、Flame 放一起比做了几期自托管仪表盘实验后我把常见方案都大概试了一圈。这里用表格整理一下它们之间的差异给正在选型的读者一个参考方案部署复杂度界面风格小部件生态适合人群Dashlet低单容器极简卡片网格基础但够用只想要干净导航入口的个人用户Heimdall中图标网格偏传统支持较多内置应用习惯传统导航页、需要大量预置图标Homarr中高高度可定制丰富可做监控卡片喜欢折腾界面、服务较多的用户Flame低极简单栏较弱追求极简、只需要链接的用户最终我留下 Dashlet 的原因是它足够简单配置完基本不用管界面也不像 Homarr 那样需要花时间调样式。仪表盘这种东西一旦开始追求美观你就会在上面花大量时间而它最初的价值其实是让你少花时间。另外提一句内网穿透工具这一层可选的不止 cpolar 一个。ngrok、frp 也是常见方案各有各的部署方式和适用场景。我个人选 cpolar 主要是因为客户端管理面板直观、固定域名的流程简单适合个人用户快速上手。选择哪个都可以关键是隧道配置思路是一致的本地端口、隧道类型、公网地址这三个要素理清楚就行。5.2 下一步这个仪表盘还能加什么Dashlet 跑顺之后我又给它加了几样东西让它的价值从网址导航延伸到内部服务总入口第一把家里其他自建服务的入口也汇总进来。NAS 管理页、下载工具、监控面板只要这些服务本身有网页界面都可以在 Dashlet 里加一张卡片。这样手机里不需要记住五六个 IP 地址和端口所有入口统一走一个面板。第二利用 Dashlet 的小部件把常看的 RSS 摘要放进来。我加了一个技术资讯源在仪表盘首页就能扫到更新标题。看着刷新频率还不错的 RSS 摘要比打开微信刷来刷去更克制。第三把容器的状态监控放到仪表盘之外做一些跳转。Dashlet 本身不擅长做复杂的监控图表但它可以放一个链接指向单独的监控页面做一个入口 详情的分层。我还有一个设想后续可以把 cpolar 隧道的健康状态也做一个简单的小组件直接在 Dashlet 上看到隧道是不是在线。这样即使在公司如果家里服务挂了也能一眼发现。5.3 重新来过我会先做哪几件事如果让我把这一期的过程重走一遍我会把三件事提到最前面一是先在纸上把需求写清楚。哪些网址是真正高频的、哪些只是说不定哪天用得上。第一次搬链接的时候我还是没忍住多塞了一些后来发现不少卡片从添加那天起就没点过。二是先把登录账号和访问控制配置好再让隧道上线。不应该先暴露再补救。三是留出一个小时专门做公网视角的完整测试。用手机流量而不是 WiFi 测访问速度用 HTTPS 地址测有没有混合内容用不同浏览器测兼容性。这些问题如果在部署当天就发现后面根本不用多花一个晚上。这次做完 Dashlet 加 cpolar 的方案之后我自己最大的感受是很多感觉不值得折腾的小事恰恰是每天最消耗注意力的事。网址入口看似微小但它嵌在每个工作日里反复打开收藏夹找链接这种动作累积起来的时间成本远超一个晚上的搭建成本。如果你也打算动手建议先拿一个晚上把 Dashlet 跑起来再用 cpolar 打开一条稳定的隧道。真正用上一周之后你可能就再也不想回到那个 400 条书签的收藏夹了。