Komari 开启私有模式后报错 HTTP 401？这几步排查帮你搞定

最近在折腾自己的小工具时，遇到一个挺让人头秃的问题，估计不少朋友在部署 Komari 这类服务时也踩过坑。

事情是这样的：本来 Komari 跑得好好的，为了安全起见（或者纯粹想藏起来自己用），我顺手开启了“私有站点”模式。结果这一开不要紧，刷新页面直接一个大大的 Error: HTTP 401: Unauthorized 给整懵了。

既然是 401 错误，核心肯定出在**身份认证（Authorization）**这一环。结合我之前的排雷经验，咱们分几步把这个 Bug 给揪出来。

一、 检查账号与密码是否录入正确

这是最基础但也最容易忽略的地方。开启私有模式后，通常系统会要求你设置或确认管理员账号和密码。

• 排雷点：有些部署方式（比如 Docker 环境变量或配置文件）里，密码可能有特殊字符转义的要求。如果你密码里包含 @、# 或者 $ 等符号，一定要确认它们是否被正确解析了。建议先用简单的纯数字/字母密码测试一下，如果能登录，再换回复杂密码并注意转义。

二、 Token 与 Headers 配置问题

私有化部署很多时候是为了配合 API 调用或者反向代理使用。如果你是通过接口访问或者挂了反代，401 往往意味着 Token 没传对。

• 排雷点：查看你的请求头（Headers）中是否正确包含了 Authorization 字段。Komari 这类工具通常依赖 Bearer Token 或特定的鉴权头。
• 本地排查：如果你是浏览器直接访问，尝试打开浏览器的开发者工具（F12），切换到 Network 标签页，刷新网页，点击对那个 401 的请求，看看 Request Headers 里有没有带上认证信息。如果是空的，那大概率就是 Cookie 丢失或者 Session 过期了。

三、 清除浏览器缓存与 Cookie

有时候不是服务器配置错了，而是浏览器“记性太好”或者记错了。

• 操作建议：在开启私有模式前，你可能已经以游客身份访问过站点，浏览器缓存了旧的登录态。开启私有化后，旧的 Cookie 导致服务端拒绝请求。
• 解决：无痕模式打开试试。如果无痕模式能正常访问，那就果断清除该域名下的所有缓存和 Cookie。

四、 Docker 日志大法

如果是用 Docker 部落的一键脚本或者 Docker-compose 起来的服务，别光盯着网页看，去终端里捞日志。

• 命令：docker logs -f [容器名] 或 docker compose logs -f。
• 分析：网页上只会给一个冷冰冰的 401，但日志里往往会告诉你为什么。比如是“密码错误”、“用户不存在”还是“鉴权中间件拦截”。看到真实报错，问题就解决了一半。

五、 配置文件的权限校验

Komari 开启私有模式后，后台通常会有一个配置文件（如 config.json 或 .env）发生变化。

• 排雷点：检查挂载的配置文件路径是否正确。有时候容器重启后，挂载目录权限发生变更（比如变成了 root 只读），导致程序无法读取正确的管理员配置，进而判定所有请求为非法。

总结

遇到 HTTP 401 别慌，核心就是围绕“我是谁”这个问题展开：

1. 密码对不对？
2. 鉴权信息有没有带？
3. 客户端缓存有没有捣乱？
4. 服务日志怎么说？

按这个顺序查下来，基本都能定位问题。如果全试了一遍还是不行，建议暂时关掉私有模式，确认服务本身没挂，再逐步开启功能排查。希望这篇笔记能帮你省点折腾的时间！