internal 指令用于定义仅限 Nginx 内部跳转的 location，必须置于具名 location 块中，仅响应 rewrite last、try_files 命名位置或 auth_request 子请求，直连返回 404，需与外层入口配合构成安全闭环。
在 Nginx 中，用 internal 保护受限路由，本质不是“加个指令就安全”，而是构建一套内外分离的访问路径：外部请求只能打到有业务逻辑的入口 location，再由它通过内部机制跳转到真正干活的 internal location。这个过程不经过浏览器重发，全程在 Nginx 内部完成。
必须写在具名 location 块里
internal 指令不能单独存在，也不能放在 server 或 http 块中。它只对带明确路径前缀的 location 生效：
- ✅ 正确：
location /_proxy/ { internal; proxy_pass http://backend; } - ❌ 错误：
location / { internal; ... }（整站变 404） - ❌ 错误：
internal;单独一行，或放在if块里
必须靠内部指令触发，不能靠用户直连
声明了 internal 的 location，对外永远返回 404。它只响应三类 Nginx 自身发起的跳转：
-
rewrite last：例如
rewrite ^/api/(.*)$ /_proxy/$1 last;（注意是last，不是redirect） -
try_files + 命名 location：例如
try_files $uri @fallback;，再配location @fallback { internal; proxy_pass ... } -
auth_request 成功后的子请求：外层做鉴权，
/auth子服务也需加internal防绕过
任何 curl 直接请求 /_proxy/xxx 都会失败——这是设计目标，不是配置错误。
搭配外层入口，形成完整闭环
单独一个 internal location 没有意义。典型结构是两段式：
-
外层入口：处理鉴权、参数校验、友好路径映射，比如
location /api/v1/ -
内层透传：只含
internal、proxy_pass或alias，不做业务判断，比如location /_int/
二者之间必须用 rewrite last 或 auth_request 衔接，禁止用 302、proxy_pass 直连或 if + proxy_pass 这类不可靠组合。
安全增强建议
internal 只管“是不是内部来”，不管“该不该访问”。如需权限控制，得在外层加：
- 用
auth_request调用后端鉴权服务 - 在入口 location 中限制 method：
limit_except GET POST { deny all; } - 配合
X-Accel-Redirect实现动态文件路径授权（后端返回头，Nginx 自动跳转） - 避免 alias 路径拼接出错：location 和 alias 末尾斜杠保持一致，推荐用
alias而非root处理静态资源
