——从零构建 Traefik + Authentik 方案之前，先把问题想清楚
1. 家庭 NAS 的一个常见误区
很多人在折腾家庭 NAS 时，第一关注点往往是：
装了多少 Docker 服务
能不能公网访问
UI 好不好看
而认证和访问控制，通常是最后才考虑，甚至不考虑。
最常见的状态是：
每个服务一个端口
每个服务一套账号密码
有的服务甚至完全没登录机制
当服务数量从 3 个变成 10 个、20 个之后，这种模式几乎必然失控。
2. 典型问题：不是“能不能用”，而是“还能不能管”
在一个真实的家庭 NAS 场景中，常见问题包括：
2.1 账号体系碎片化
A 服务一套账号
B 服务另一套账号
有的支持 LDAP，有的不支持
有的干脆只能匿名访问
结果就是：
账号管理成本指数级上升。
2.2 内网服务“默认安全”的错觉
很多服务部署在内网，就会默认认为：
“反正是 192.168.x.x，问题不大。”
但现实是：
内网设备越来越多
浏览器插件 / IoT / 访客设备并不可信
一旦接入远程访问（VPN / 穿透），风险瞬间放大
“内网 ≠ 安全”，这是家庭环境里最容易被忽略的一点。
2.3 端口暴露失控
当没有统一入口时，往往会变成：
http://nas:8080
http://nas:3000
http://nas:9000
http://nas:9443
端口即权限，
端口越多，风险越大，也越难维护。
3. 两种思路：把认证放在哪里？
从工程角度看，认证只有两种放置方式：
方案一：每个应用自己负责认证
优点：
看起来“最直接”
不需要额外组件
问题：
应用质量参差不齐
很多开源项目根本没认证
账号无法统一
一旦应用下线，账号体系也跟着消失
👉 不具备可持续性
方案二：在入口层统一做认证（推荐）
核心思路只有一句话：
所有流量先到统一入口，认证通过后才允许访问应用
应用本身：
不知道“谁登录了”
只接收“已经被允许”的请求
这是一个典型的网关层设计，在生产环境中非常常见，只是被完整搬到了家庭 NAS 场景中。
4. 为什么选择 Traefik 作为统一入口
在家庭 NAS 场景中，引入反向代理几乎是必然的，而 Traefik 的优势非常明确：
4.1 动态发现，非常适合 Docker
基于 Docker labels
不需要频繁改主配置
新服务接入成本低
4.2 天然适合“统一入口”模型
Traefik 的设计本身就区分了：
路由（Router）
服务（Service）
中间件（Middleware）
这为后续“统一认证”留下了非常干净的扩展点。
5. 为什么不直接把认证写进应用？
这是一个必须提前想清楚的问题。
在家庭 NAS 环境中，很多服务具有以下特点：
开源、第三方
不可控、不想改代码
升级频繁
如果认证逻辑写进应用本身，意味着：
每个应用一套方案
每次升级都可能破坏认证
无法做到统一策略
而把认证放在 Traefik 这一层，可以做到：
应用完全无感
认证策略集中管理
接入成本只剩“配置”
6. 为什么选 Authentik，而不是“简单 Basic Auth”
很多人会在 Traefik 上直接加 Basic Auth，但在实际使用中问题很快暴露：
账号静态写在配置里
无法分组、授权
无法扩展到 OAuth / SSO
不适合长期使用
Authentik 在家庭 NAS 场景中的优势是：
自托管
支持 ForwardAuth
支持统一账号体系
后续可扩展 OAuth2 / 权限控制
它并不是“多此一举”，而是为规模化预留空间。
7. 本系列将解决什么问题
在后续文章中，将围绕一个明确目标展开：
在家庭 NAS 环境中，实现：
一个入口（Traefik） + 一个身份系统（Authentik） + N 个业务应用
并重点解决以下问题：
Traefik 如何作为唯一入口
Authentik 如何参与认证决策
ForwardAuth 的真实工作方式
新 Docker 应用如何“零侵入”接入
哪些配置是必须的，哪些是坑
8. 下一篇预告
第 2 篇：
《从零搭建家庭 NAS 的统一入口：Traefik 基础架构设计》
将从 Traefik 的静态 / 动态配置、Docker Provider、网络结构 开始，
一步一步搭出后续所有认证能力的地基。
