很多人问过我：到底是继续用浏览器书签，还是自己搭一个导航页？实话说，如果你只有三五个常用网站，书签完全够用；但当你手上有 NAS、监控面板、下载工具、代码仓库、在线笔记、路由后台等十多个服务时，每次打开浏览器都要在书签栏里翻半天，机器一换账号一多，收藏夹乱到想删库重来。我选择自托管导航页，并把“随时随地能打开”作为硬性条件。

最近我完成了一次还算完整的落地：用开源导航页 Fenrus 做了一个高颜值首页，又通过 cpolar 把本机 3000 端口映射到公网地址，手机用流量、公司网络、出差酒店 Wi-Fi 都能直接打开。算下来，这也是我内网穿透实验记录里第 789 个成功跑通的案例。这篇就把整个从选型到排错的过程完整写出来，适合想在 NAS 或家用服务器上搭导航页，又想从外网访问的读者。

1. 先想清楚：导航页到底替你解决什么问题

1.1 书签栏为什么不够用

书签栏的最大问题是“只收藏，不易用”。浏览器书签本质上是一个扁平列表，加上文件夹之后虽然能分类，但每层都要手动点开，视觉上密密麻麻，没有任何信息层级。更麻烦的是多设备同步：电脑上收藏了一堆链接，平板和手机上还要重新整理一遍；内网地址、开发调试用的临时端口、只有家里路由器才认识的局域网 IP，在不同的网络环境下打开结果还不一样。这些问题不是书签功能的问题，而是“静态列表”这种形态已经撑不住日常高频访问了。

导航页实际上是一个“活的入口”：把高频链接以卡片、图标、分组的方式陈列在一个页面里，一眼看到，点一下就能进去。它还能直接设为浏览器主页、新标签页，手机上也能通过 PWA 形式放到桌面。相对于书签栏，导航页是“把选择前置”：你不需要记住 URL，不需要层层展开文件夹，只要页面在，入口就在。对于自托管玩家来说，导航页还有一个普通书签完全比不了的优势：所有数据掌握在自己手里，不怕浏览器厂商改版、不怕同步服务抽风。

1.2 一个可私有部署导航页的理想形态

在动手之前，我先把需求列了一遍，免得装完发现不对又要推倒重来：

• 部署简单。最好一个容器就能跑，能放在已有的服务器或 NAS 上，不占用额外资源。
• 外观能自定义。支持背景图、主题色、卡片样式，能配合自己的桌面审美。
• 支持分组和多个页面。高频、低频、工作、娱乐分开，不要一页堆满几百个链接。
• 支持用户隔离。家里多个人用，或者自己和朋友共用一个导航页，大家的布局不能互相踩踏。
• 能通过公网访问，且访问要稳定，最好地址固定。这一点决定了我后续要不要引入内网穿透。
• 最好有扩展能力。天气、时钟、书签、二维码这些小部件能顺手带上。

拿这个清单去筛选，市面上常见的自托管导航页其实不少，但我最后选了 Fenrus。后面的章节我会讲讲对比过程，以及为什么它对我这种“既想要好看、又不想要太复杂”的需求最合适。

2. 工具选型：Fenrus 和同类方案横向对比

2.1 同类导航页工具速览

自托管导航页这个品类已经非常热闹，随便一搜就有四五个耳熟能详的项目。我把它们放在一起做了个对比，侧重点都在“部署难度、颜值、可扩展性、多用户能力”这四方面：

从表格可以看出，Fenrus 在“部署难度”和“默认颜值”上占优。它的默认长相不是那种后台管理系统的简陋列表，而是自带现代卡片、毛玻璃配色和完整的图标体系，新手也能很快得到一个看得过去的页面。

2.2 我选了 Fenrus 的四个理由

对比完一圈，我选 Fenrus 的原因非常具体：

第一点是部署成本足够低。Fenrus 本身是一个单容器应用，不需要外部数据库，不需要 Redis，所有配置都落在本地目录里。对只想快速跑起来的人来说，这种“零依赖”设计最省心。第二点是颜值默认就很高。它的界面不是那种一眼就是后台管理系统风格的简陋列表，而是自带现代卡片、透明质感和精致的图标体系，新用户不用做太多装饰就能得到一个“看起来像产品”的导航页。第三点是多用户和页面隔离机制。Fenrus 允许多个登录用户各自维护自己的页面布局，家长和孩子、我和朋友都能各玩各的，互不乱。第四点是它对“个性化”的支持不设限，背景、链接图标、页面列数、自定义搜索引擎、小部件全部开放，意味着我可以一直折腾下去。

当然它也有短板，比如第三方插件生态不如某些类似工具丰富，偶尔会有冷门小 Bug。但对我这个“导航页只追求稳定打开、颜值在线、随时访问”的目标来说，缺点可以接受。选型这件事没有绝对正确，关键是你愿意为哪种取舍买单。

3. 从 0 到 1 部署：初始化与容器落地

3.1 准备运行环境和目录

我建议准备一台常开的机器，最好是有公网出口的家用服务器或 NAS，配置不用高，2 核 CPU、2GB 内存跑 Fenrus 绰绰有余。操作系统方面，Debian/Ubuntu 系以及群晖这类带 Docker 的 NAS 都验证过，后面所有步骤都以 Docker 容器作为载体。

部署前先把目录结构理好。我习惯在服务器上建一个 /data/fenrus 目录，专门存放 Fenrus 的配置文件、用户数据、备份文件。这样做的好处是以后迁移或备份只要压缩这一个目录即可，不用东找西找。如果你用的是 NAS，直接在共享文件夹下建一个 fenrus 目录也可以。目录权限注意给当前用户可读写，避免容器启动后没有权限写入数据。

3.2 Docker Compose 启动与首次页面验证

我用的是 Docker Compose 来管理，因为比 Docker run 命令更好维护配置，改端口、加环境变量都直观。写一个 docker-compose.yml，内容大概是这个结构：

services: fenrus: image: your-fenrus-image:latest # 换成你实际拉取的 Fenrus 镜像地址 container_name: fenrus restart: unless-stopped ports: - "3000:3000" environment: - TZ=Asia/Shanghai volumes: - ./data:/app/data

这里给的是标准写法，镜像地址请以 Fenrus 官方仓库 README 里的指引为准，不同版本 tag 可能不同。启动命令：

docker compose up -d

第一次启动后，等待几秒，浏览器打开 http://服务器IP:3000 ，就能看到默认的初始页面。第一次进入时系统会让你设置一个管理员账号，这一步别跳过，后面所有配置和用户管理都要用它登录。我踩过的教训是：如果随便起个名字，后面会忘记，建议一并记录在服务器的密码管理器里。

3.3 数据持久化与日常维护

Fenrus 的数据都写在挂载目录里，这意味着容器删了重建，只要目录还在，配置就不会丢。平时我基本不碰容器，最多每周手动备份一下 data 目录，压缩成 tar.gz 扔到另外一块盘或者云存储里。这份备份成本非常低，但真到需要迁移的时候，比重新配置一遍省太多时间。

日常维护还有一个小点：Fenrus 版本更新不算频繁，但 Docker 镜像不会自动升级。我一般一个月检查一次，看到新版本就先拉镜像再重启容器：

docker compose pull && docker compose up -d

注意先备份再做，避免新版本数据结构变化导致配置异常。我在一次版本升级后就遇到过 UI 变了但旧数据没完全兼容的情况，还好备份完整，十分钟就回滚了。

4. 高颜值定制：让首页既好看又能快速跳转

4.1 链接分组与图标配置

导航页好不好用，第一印象是“打开之后能不能 3 秒内找到目标链接”。Fenrus 的配置逻辑是这样的：最外层叫“页面”，页面由若干“分组”，分组里面是具体“链接”。我按工作、媒体、工具、家庭网络四个方向建了四个页面，每个页面下面再分若干组。

添加链接时，Fenrus 会自动尝试抓取网站的图标，但这个功能依赖外网连通性，如果抓不到，就会显示一个默认图标。我的建议是对于常用站点直接把图标地址手动填成固定 URL，这样做出来的页面最整齐。图标尺寸统一、风格统一后，整体颜值立刻上一个台阶，这比调半天背景色都管用。比如我习惯把所有图标都用纯色背景加白色符号的写法，视觉上非常统一，强迫症表示很舒服。

4.2 主题背景与版式调整

Fenrus 在美观方面给的自由度很大。背景图可以填一个网络图片地址，也可以本地上传；背景之上还有一层半透明遮罩，能调整明暗，让卡片上的文字始终可读。我实际调下来，比较耐看的组合是：一张低饱和度的渐变或者风景图打底，遮罩开到 30% 左右，卡片保持半透明毛玻璃效果。

版式上，Fenrus 允许设置页面的列数、卡片间距、是否显示分组标题等细节。不要贪多，我自己的导航页把列数控制在 3 到 4，每个分组链接不超过 8 个，这样视觉重心不会散。给背景和主题调成一个套系，整个页面会很像产品官网而不是个人工具页。这个阶段最容易陷入“过度美化”的坑，我见过有人把背景设成高饱和动漫图，结果文字完全看不清。记住一点：导航页的第一任务是可用性，颜值是排在可用性之后的。

4.3 多用户登录与隐私保护

如果只是自己用，可以完全开放浏览；但如果你打算通过公网访问，我还是建议开启登录功能。Fenrus 的登录体系不依赖第三方数据库，管理员在后台可创建多个用户，每个用户登录后看到的是自己配置的页面。

这里有一个容易被忽略的隐私点：导航页的链接本身可能暴露你的服务列表，比如 192.168.x.x、内网 NAS 名称、路由后台地址。所以做公网访问前，我强烈建议至少给它加一道用户认证，哪怕密码简单一点，也比你直接裸奔在公网上好得多。Fenrus 的登录页默认会生成一个二维码，方便手机扫码登录，这个功能实测在公网场景下很顺手，不用每次手动敲密码。

5. 随时随地访问：cpolar 内网穿透接入

5.1 内网穿透的原理与 cpolar 的定位

自托管服务跑在家里或公司局域网时，外网无法直接访问，因为出口 IP 不固定，而且路由器背后的服务通常没有公网端口映射。内网穿透解决的就是这个问题：在本地跑一个客户端，主动向外网服务器建立一条安全通道，外网用户访问服务器分配的地址时，请求会通过这条通道被转发到本地服务端口。

cpolar 就是这类工具中我比较常用的一款。它的优势是配置简单、有免费额度、支持固定二级域名，不用自己租一台公网服务器做中转，也不用去理解复杂的隧道协议。对自托管玩家来说，它的学习成本几乎等于零：本地装客户端，创建一条隧道，把公网地址复制出来，完事。

5.2 安装、认证与创建固定隧道

第一步安装客户端，到 cpolar 官网按自己系统下载对应二进制，解压后放到 /usr/local/bin，然后执行认证命令，把浏览器控制台里拿到的 token 填进去：

cpolar authtoken <你的认证token>

接着创建隧道。对于导航页这种 Web 服务，协议选 http，本地地址填 127.0.0.1:3000，域名类型建议选固定二级域名。这里的关键是“固定”两个字：如果选临时域名，每次重启隧道地址都会变，你手机里存的快捷方式就废了。选了固定域名之后，它会给你分配一个形如 你的前缀.cpolar.xxx 的地址，这个地址长期不变，适合拿来做书签和桌面快捷方式。

创建完隧道后，客户端会保持后台连接，控制台可以看到隧道状态、请求数、流量记录。免费套餐的请求量对个人导航页来说绰绰有余，哪怕天天远程打开，也用不了多少配额。

5.3 远程访问验证与端口细节

配置完成后，我把手机 Wi-Fi 关掉，用 4G/5G 访问分配的公网地址，能直接看到 Fenrus 登录页，说明穿透链路已经打通。这里有个细节：cpolar 给的是 https 地址还是 http 地址，取决于你在创建隧道时的选择，一般建议用 https，浏览器不会报警，Chrome 也不会在地址栏显示“不安全”。

端口上要注意：隧道映射的是 127.0.0.1:3000，公网访问只能到达 Fenrus，不会把宿主机其他端口暴露出去。这个机制帮我省了很多安全上的担心，相当于只开了一道门，进来的流量全部指向 3000 端口。我在第一次实验时还担心过“会不会被扫到其他端口”，实测下来完全没有这个风险，因为隧道是点对点转发，没有做端口全映射。

6. 进阶安全与稳定性优化

6.1 给隧道再加一层访问认证

cpolar 支持在隧道层面设置访问认证，也就是在访问公网地址时，先弹出一个浏览器基础认证框，输入正确的用户名密码之后，才会把流量转发到 Fenrus。这一步的价值在于：即使 Fenrus 本身没开登录，外面的人拿到地址也打不开你的页面，算是在网络层先挡一道。

我的建议是双重保护都打开：隧道认证用一组独立的账号，Fenrus 登录再设一组账号。这样即便某一层口令泄露，也不会直接暴露内网服务。密码不要和服务器 root 密码一样，相信我，这种低级错误在折腾的时候最容易犯。基础认证的密码保存在 cpolar 管理端，如果放到公网又碰上暴力破解，控制台后台也能看到失败次数，我会定期翻一眼日志，有异常就换密码。

6.2 容器重启与 IP 变动后的处理

家用服务器最常见的不稳定因素是断电。容器虽然设置了 restart: unless-stopped，会跟着 Docker 自动起来，但因为内网 IP 变化，Fenrus 里配置的某些服务地址可能会失效。我的解决办法是：给服务器设静态 IP，或者在路由器里做 DHCP 地址绑定；cpolar 隧道目标地址都填 127.0.0.1，不依赖局域网 IP 分配，这样即使重启也不会影响公网通道。

还有一个小实践：我写了一个非常简单的健康检查脚本，每分钟访问一次本机 3000 端口，如果返回异常就重启容器并推送通知。这个脚本不复杂，但对“人在外面、服务挂了”的场景非常管用。导航页本身很小，重启成本极低，自动化反而比人工干预更快。

6.3 还可以继续扩展的玩法

导航页跑通后，我把其他本地服务也陆续接了进来。比如下载工具的 Web 界面、监控面板，都通过 cpolar 做了类似映射。Fenrus 这个页面本身是一个很好的“服务目录”，把内网所有 Web 服务入口集中起来，配合隧道访问，等于把家用小服务器变成一个小型私有云。

另一个我觉得值得尝试的方向是把 Fenrus 设置成浏览器默认主页和新标签页。Chrome 和 Edge 都支持自定义新标签页地址，直接把 cpolar 的公网地址填进去，每次打开浏览器看到的都是自己搭的导航页。这样不仅在家里能用，在外面的网吧或临时电脑上也能保持统一的入口。唯一要注意的是，公共电脑上别勾选自动保存登录状态，免得别人顺着你的会话摸进 Fenrus 后台。

7. 实操中的常见问题与排查实录

7.1 问题速查表

这次做完之后，我把容易踩的坑整理成了一个速查表，方便以后再遇到类似问题直接对照：

这个问题表看起来简单，但每一条背后都是我实打实踩过坑的。尤其是背景图过大导致手机访问慢的问题，一开始根本没意识到，后来用开发者工具看到一次请求要加载好几 MB 图片才反应过来，压缩之后速度立刻回到秒开。

7.2 几个容易忽略的小细节

结合这次第 789 次实验，我把最后几个小知识点单独拎出来讲一讲，别看它们不起眼，往往决定体验成败。

第一个是时区问题。Fenrus 容器默认可能用的不是本地时区，导致时钟小组件显示的时间差 8 小时。我在 compose 里加了 TZ=Asia/Shanghai 才解决，如果你在别的时区就设成对应的值。第二个是“图标抓取失败”的替代方案。如果内网环境没有外网连通性，Fenrus 抓不到任何图标，页面会非常难看。我后来把常用的几个图标文件直接放到服务器目录里，用相对路径引用，彻底摆脱外网依赖。第三个是注意保护 cpolar 的认证 token。token 泄露等于别人也能把你的端口映射出去，甚至可能把你的免费隧道额度用完，所以这个值一定要当成敏感信息对待，不要写进公开的配置仓库里。

最后再分享一个个人感受：真正让 Fenrus 页面变“高颜值”的，未必是复杂的背景图或花哨的配色，而是统一、克制、有层级。图标风格统一，分组数量精简，链接命名简洁，页面自然就好看。cpolar 这种内网穿透工具也是如此，它最大的价值不是技术上的炫酷，而是让我在外出时也能像坐在家里一样，打开同一个导航页，点同一个入口，访问自己的服务。如果你也有一台小服务器或者 NAS，不妨按这条路线折腾一下，从部署到穿透，每完成一个环节都能收获一点“自己动手”的成就感。