internal 是 nginx 强制切断客户端直连的访问控制开关，仅响应 auth_request、rewrite last 或 x-accel-redirect 等内部子请求，直接访问一律返回 404；必须与外层鉴权 location 配合使用，不可单独配置。
internal 指令不是“隐藏路径”，而是强制切断客户端直连能力的访问控制开关。它让某个 location 只响应 Nginx 自身发起的内部跳转（比如 auth_request 子请求、rewrite last、X-Accel-Redirect），任何浏览器、curl 或 Postman 的直接访问都会被立即返回 404。用错就等于把后端接口裸奔暴露在公网。
必须配合子请求，单独配置必然失败
很多人写完 location /api/internal { internal; proxy_pass http://backend; } 就以为安全了，结果一访问就是 404——这恰恰说明 internal 生效了，但你没走对路。
- internal 的语义是：该 location 不接受任何原始 HTTP 请求，只认 Nginx 内部发起的子请求
- 不能把它放在对外暴露的入口 location 里；也不能单独使用，否则永远无法命中
- 正确结构一定是两段式：外层普通 location 做鉴权，内层带 internal 的 location 做资源交付
典型安全组合：auth_request + internal
这是最常用、最可控的防护模式，适用于 API 接口授权后透传场景。
- 对外提供
location ^~ /api/，里面配置auth_request /auth; - 单独定义
location = /auth { internal; proxy_pass http://auth-service; }，防止被绕过直调 - 真实接口放在
location /internal/api/ { internal; proxy_pass http://backend; }，只允许 auth_request 成功后跳转进来 - 后端鉴权服务返回 2xx 才放行，返回 401/403 则主请求直接终止
文件类资源透传：X-Accel-Redirect + internal
适合私有下载、报告生成等需后端动态授权再流式下发文件的场景。
- 后端不读文件、不输出 body，只设置三个关键响应头：
X-Accel-Redirect: /dl/report.pdf（路径必须匹配 Nginx 中定义的 internal location）
Content-Type: application/pdf
Content-Disposition: attachment; filename="report.pdf" - Nginx 配置
location /dl/ { internal; alias /data/files/; }，注意 alias 末尾斜杠要与 location 一致 - 用户即使知道 /dl/report.pdf 这个 URL，直接访问也会 404；只有后端触发 X-Accel-Redirect，Nginx 才内部跳转并读取文件
常见错误与加固要点
很多看似“已加 internal”的配置仍被绕过，问题往往出在路径设计或配套措施上。
- 避免在 internal location 中使用
proxy_pass到外部不可信服务；应直连可信后端或用 alias 读本地文件 - 禁止外部直接访问 .php/.py 等脚本：可在 server 块加
location ~ \.php$ { deny all; }，再用 rewrite + internal 显式放行合法路径 - internal location 若用 root，请确认路径拼接逻辑是否符合预期；alias 更推荐，语义更清晰
- 所有对外入口 location 应做基础校验（如检查 Token、Referer、IP 白名单），internal 只负责守最后一道门
