加 internal 指令可使 location 仅响应 Nginx 内部跳转，须置于具名路径 location 块中；仅 rewrite last、auth_request 成功跳转、X-Accel-Redirect 三类内部行为可访问，外部请求一律 404。
直接在目标 location 块中加 internal;，就能让该路径拒绝所有客户端直连请求，只响应 Nginx 自身发起的内部跳转——这是最核心、最简洁的保护方式。
必须写在具名 location 块里
internal 不能单独出现在 http 或 server 块中，也不能放在泛匹配的 location / { } 里。它必须包裹在一个明确路径前缀的 location 中：
- ✅ 正确：
location /_proxy/ { internal; proxy_pass http://backend; } - ❌ 错误：
internal;单独一行；或location / { internal; ... }
必须靠内部指令触发才能访问
加了 internal 的 location 不会自动生效。外部请求哪怕带完整 Token 或合法 Cookie，也会立刻返回 404 Not Found。只有以下三类 Nginx 原生内部行为能抵达它：
-
rewrite ... last;：重写后重新匹配 location，例如rewrite ^/api/(.*)$ /_proxy/$1 last; -
auth_request成功后的隐式跳转：如鉴权通过后自动进入后端代理 -
X-Accel-Redirect响应头驱动：后端返回头X-Accel-Redirect: /_proxy/file.zip，Nginx 自动内部跳转读取
避免常见绕过和失效点
很多配置看似合理却不起作用，问题常出在细节：
- 不要用
rewrite ... redirect（302），那是浏览器重发，已跳出 Nginx 内部流程 -
proxy_pass的 URI 处理要与location路径一致：若写location /_proxy/，则proxy_pass http://svc/末尾需带斜杠，否则可能重复拼接 - 如果用
alias提供静态文件，location和alias路径末尾斜杠必须统一，否则文件路径错位 - 禁止同时暴露
/_proxy/和另一个指向相同后端的公开路径，否则internal形同虚设
典型安全结构：入口 + 内部透传
真正可用的保护永远是两段式：
- 外层入口：
location /api/，负责接收请求、做鉴权（auth_request）、参数校验、签名验证 - 内层透传：
location /_internal/ { internal; proxy_pass http://real_backend; }，不处理逻辑，只专注转发 - 两者之间用
rewrite ... last或auth_request衔接，绝不走 302 或手动 curl
