2026-10-09 · 运维部署与运维

一个域名下，怎么把公开内容和要密码的内容分开

这个需求很常见

一台服务器、一个域名，一部分页面是给所有人看的，另一部分只想自己看。最省事的办法当然是不分开——但那等于把不该公开的东西也摆到了外面。所以边界要自己划。

第一，公开的文件和私密的文件物理上就放在不同目录。不要靠"同一个目录里靠命名约定区分"，那种边界迟早会被一次手滑打破。

第二，在 web 服务器这一层用白名单：默认全站都要密码，然后逐条显式放行公开的那些——首页、公开栏目路径前缀、样式表、几个静态文件，每条都单独写一句"这里不要密码"。

location = /public-file.txt {
    auth_basic off;
    root /srv/site/public;
}

为什么用白名单而不是黑名单？因为两种写法的失效方向是相反的：白名单写漏一条，结果是"本该公开的看不到"，你会立刻发现；黑名单写漏一条，结果是"本该保密的泄了"，你可能永远发现不了。

有时候你会需要"只放行某一个文件"——比如放一个图片、一个校验文件，或者任何第三方要求"任何人都能访问到"的东西。这时最顺手的写法是把整个目录放开。

那就是这类事故的常见起点：为了放行一个文件，把一整个目录连同里面不该公开的东西一起敞开了。正确的写法是只放行那一个精确路径，多一个字都不要。

改完别登录着看，要以未登录的身份去拉。至少三条：

第三条才是最关键的一条回归检查。做"公开化"这个动作时，最容易伤到的就是它——前两条你会不自觉地反复验，第三条常常被默认"应该没动吧"。

如果默认规则是"全站要密码"，那么匿名访问一个根下并不存在的路径，会先撞上密码验证、返回 401，而不是你精心写的自定义 404 页。自定义 404 通常只在公开命名空间内部（比如公开栏目的子路径下）才生效。

这不是 bug，是白名单结构的必然结果：根命名空间属于私密区，不在白名单上的路径属于私密那一侧。