internal 指令本质是路径身份闸门，仅允许Nginx内部跳转（如auth_request、rewrite last、try_files、error_page、X-Accel-Redirect）访问，外部直连返回404；必须配合规范location定义（具名前缀、独占块、正确alias斜杠）与安全结构（对外入口+对内透传）使用，否则失效。

配置 internal 指令的关键，是把它当作一道“路径身份闸门”——它不鉴权、不校验，只认请求来源：必须是 Nginx 自己发起的内部跳转，外部直连一律返回 404。单独加 internal; 到某个 location，却不提供合法跳转入口，结果必然是不可访问。

必须配合内部跳转机制才生效

internal 不是独立安全策略，它依赖 Nginx 内部指令触发才能被命中。以下方式可成功抵达该 location：

• auth_request 子请求验证通过后，主请求自动转入
• rewrite ... last;（注意是 last，不是 redirect 或 break）
• try_files 匹配失败后跳转到该 location
• error_page 指向该 location
• 后端响应含 X-Accel-Redirect: /_protected/xxx 头，且前缀精确匹配

location 定义要规范、隔离

不能写在根上下文或与 proxy_pass 混用于无明确匹配的块中。正确写法需满足：

• 使用具名、明确前缀的 location，例如 location ^~ /_serve/ 或 location = /auth
• internal; 必须独占该 location 块，不与其他出口逻辑（如公开 proxy_pass）共存
• 若用 alias，末尾斜杠必须与 location 一致：location /_serve/ { internal; alias /data/files/; }
• 避免 location / { internal; } —— 这会让整个站点 404

典型安全结构：对外入口 + 对内透传

一个可用的下载链路由两个分离部分组成，缺一不可：

• 对外入口：比如 location ^~ /download/，承载鉴权（auth_request /auth）、参数解析、签名校验等逻辑
• 对内透传：比如 location ^~ /_serve/，仅含 internal; 和 alias（或 root），不做任何判断，专注读文件
• 二者之间靠 rewrite ^/download/(.*)$ /_serve/$1 last; 或 X-Accel-Redirect 衔接，确保跳转为内部行为

常见误配与规避要点

很多配置看似合理却失效，问题常出在细节：

• 用了 rewrite ... break;：break 不触发内部重匹配，无法进入 internal location
• X-Accel-Redirect 值带协议或相对路径，如 http://xxx/_serve/a.pdf 或 ../etc/passwd，Nginx 直接忽略
• 鉴权子 location（如 /auth）没加 internal，攻击者可绕过主入口直调，导致鉴权形同虚设
• 在 internal location 中 proxy_pass 到不可信后端，等于把闸门开在了代理层，失去保护意义