实战 Internal 指令：实现“后端接口授权鉴权、网关层文件直接透传”的安全模式-Nginx-PHP中文网

internal 是 Nginx 强制禁止客户端直连的访问控制开关，必须配合子请求（如 auth_request）使用，单独配置会导致 404；正确用法是外层普通 location 处理鉴权，再通过子请求跳转至带 internal 的真实资源 location，且后者应直接读文件或安全 proxy_pass，并辅以后端 IP 白名单等加固措施。

实战 internal 指令：实现“后端接口授权鉴权、网关层文件直接透传”的安全模式

Internal 指令不是“让 Nginx 内部跳转”这么简单，它本质是强制切断客户端直连能力的访问控制开关——用错就等于把受保护文件直接裸奔暴露在公网。

Internal 指令必须配合子请求（subrequest）使用，否则 404 是必然结果

很多人写完 location /download { internal; proxy_pass http://backend; } 就以为万事大吉，结果一访问立刻 404。这是因为 internal 的语义是：该 location 只允许被 Nginx 自身发起的子请求命中，不允许任何来自客户端的原始请求进入。

正确路径必须是两段式：

对外暴露一个普通 location /api/download，处理鉴权逻辑（比如调用 auth_service）
鉴权成功后，用 auth_request 或手动 rewrite ... last 触发内部子请求，跳转到带 internal 的真实资源 location
那个真实 location 必须明确指定 internal;，且不能有 proxy_pass 到外部服务——它应该直接读文件或转发给后端静态资源服务

auth_request + internal 是最常用、最可控的组合

auth_request 是 Nginx 官方模块提供的子请求鉴权机制，它会在主请求到达目标 location 前，先发一个子请求去校验权限。只有子请求返回 2xx，主请求才继续；否则直接返回子请求的响应码（如 401/403）。

典型配置要点：

auth_request /auth; 必须写在带 internal 的 location 外层，不能写在内部 location 里
location = /auth 要明确设置 internal;，防止被绕过直接访问
鉴权服务返回的响应体可以为空，但响应头中必须包含 X-Accel-Redirect（如果走文件透传）或靠 proxy_pass 转发
若用 X-Accel-Redirect，后端需返回类似 X-Accel-Redirect: /internal/files/report.pdf，Nginx 才会跳转到对应 location ~ ^/internal/ 并触发 internal 校验

proxy_pass 到带 internal 的 location 时，路径重写极易出错

常见错误是：在 location /api/download 里写 proxy_pass http://backend，而后端又返回 302 跳转到 /files/xxx.pdf ——这会绕过所有 internal 限制，因为跳转是客户端行为。

Bertha.ai

一款专为WordPress内容创作设计的AI工具，可在网站编辑环境中辅助生成文章、文案和图片内容，提高站点内容生产效率。

下载

更安全的做法是后端不返回跳转，而是返回完整文件内容或由 Nginx 接管透传：

后端鉴权通过后，返回 HTTP 200 + 文件二进制流，并设置 Content-Disposition: attachment，Nginx 直接透传（无需 internal）
或后端返回 X-Accel-Redirect: /protected/xxx.pdf，Nginx 匹配到 location ^~ /protected/ 后，检查该 location 是否含 internal;，再用 alias 或 root 读取本地文件
注意 alias 和 root 对路径拼接规则不同：alias /var/data/; + 请求 /protected/a.pdf → 实际读 /var/data/a.pdf；而 root /var/data; → 读 /var/data/protected/a.pdf

internal location 中用 proxy_pass 仍需额外防护

即使加了 internal，如果后端服务本身没做 IP 白名单或 token 校验，攻击者仍可能伪造请求头直连后端，绕过 Nginx 鉴权。

建议加固点：

后端只监听 127.0.0.1，拒绝外部网络连接
Nginx 在 proxy_pass 前添加唯一标识头，如 proxy_set_header X-Nginx-Internal "1";，后端据此拒绝非该头的请求
避免在 internal location 中使用 proxy_pass 到可公网访问的地址——这是典型的“用 internal 假装安全，实则形同虚设”

真正容易被忽略的是：internal 不提供加密、不校验 token、不记录审计日志。它只是访问路径层面的一道门栓，门后还得有锁、有监控、有后端二次校验。