在 nginx 中，`internal` 指令用于限制对特定 uri 的访问，使其只能由内部重定向（如 `return`、`rewrite ... last` 或 `proxy_pass`）触发，而不能直接通过客户端请求访问。该指令的作用域限定在 `location` 块内，配置后该路径下的资源将返回 404 错误给外部请求。
如何配置 location 以启用 internal
只需在需要保护的 `location` 块中添加 `internal` 指令即可生效。例如，保护 `/private/` 目录时，直接在对应位置添加指令，Nginx 会检查请求来源是否为内部处理流程。
server {
listen 80;
# 正常公开的资源
location /public {
root /var/www/html;
}
# 受保护的内部资源
location /private {
internal;
root /var/www/html;
}
}
上述配置中，访问 `/public/` 下的文件会正常返回内容，而访问 `/private/` 下的文件，若请求来自浏览器等外部客户端，Nginx 将直接返回 404 Not Found。只有当服务器内部逻辑（如 PHP-FPM 后端或 Lua 脚本）发起对该路径的请求时，才会成功获取资源。
internal 在不同作用域下的行为差异
`internal` 指令仅在当前 `location` 块及其子 `location` 块中有效。如果父级 `location` 设置了 `internal`，子级默认继承；但若子级未显式声明，则保持内部访问限制。若子级希望开放访问，需移除 `internal` 或重新定义规则。
server {
listen 80;
# 父级 location 设置 internal
location /api {
internal;
proxy_pass http://backend;
}
# 子级 location 继承 internal
location /api/v1 {
# 此处仍为 internal，外部无法直接访问
proxy_pass http://backend;
}
# 若需开放某个子路径，需单独处理
location /api/public {
# 不设置 internal，允许外部访问
proxy_pass http://backend;
}
}
在实际应用中，这种层级结构常用于 API 网关场景。主路径 `/api` 被标记为内部访问，防止外部直接调用底层接口，而特定的公开端点 `/api/public` 则不受限制。注意，`internal` 不影响 `try_files` 或 `alias` 等其他指令的行为，它仅控制请求的最终准入判断。
使用 return 指令测试 internal 效果
为了验证 `internal` 是否生效，可以使用 `return` 指令模拟内部重定向。例如，在另一个 `location` 中使用 `return 302 /private/test.html`，虽然状态码是 302，但 Nginx 内部会再次处理 `/private/test.html`，此时因 `internal` 存在，最终返回 404。若改为 `rewrite ^/test$ /private/test.html last;`，同样会触发内部查找并返回 404。这表明 `internal` 对所有内部重定向机制均生效。
