internal指令是访问来源守门人，只放行Nginx内部跳转（如rewrite last、error_page、auth_request），外部直连一律返回404；不校验Cookie、Token、IP或Header，必须置于具名location块内。
internal 指令不是“权限开关”，而是“访问来源守门人”——它只放行由 Nginx 自身触发的内部跳转请求，直接来自浏览器或 curl 的公网访问一律拒之门外，返回 404（不是 403）。
internal 的真实作用机制
它不看 Cookie、不验 Token、不查 IP、也不管 Header 是否合法。只要请求是客户端主动发起的（哪怕带了正确 Authorization 头），Nginx 就认定为“外部请求”，直接拦截。真正起效的前提只有一个：该请求必须由 Nginx 内部指令驱动过来。
- 有效触发方式包括：
rewrite ... last、error_page 404 = @internal、auth_request成功后的隐式跳转 - 无效触发方式包括：
rewrite ... redirect（302 跳转，属于浏览器重发）、proxy_pass直连、curl 手动请求路径 - 必须写在具名
location块内，不能放在server或http根上下文中
典型安全配置结构
单纯加 internal 不够，需配合路径映射与访问控制形成闭环：
- 对外暴露友好路径（如
/api/v1/user），内部通过rewrite映射到受保护位置 - 受保护 location 显式声明
internal，并限制 HTTP 方法（如仅允许 POST/GET） - 若需进一步校验身份，应在跳转前完成（如用
auth_request调用鉴权服务）
示例配置：
location /api/v1/ {
# 先鉴权（可选）
auth_request /auth;
<pre class='brush:php;toolbar:false;'># 再内部重写到 protected 区域
rewrite ^/api/v1/(.*)$ /_internal/$1 last;}
location /_internal/ { internal; # 外部直连全部 404 limit_except GET POST { deny all; } proxy_pass https://www.php.cn/link/9fae7572ff8bae93fc21468e873cb4ac; proxy_set_header X-Real-IP $remote_addr; }
调试与验证要点
上线前务必做两组对比测试，确认逻辑生效：
- 模拟公网直连：
curl -v https://example.com/_internal/user→ 应返回404 Not Found - 走内部流程调用：
curl -v https://example.com/api/v1/user→ 应正常返回后端响应 - 检查 Nginx 错误日志，确认被拒请求是否出现
client denied by server configuration类提示
常见误配与规避建议
- 避免对根路径使用 internal：
location / { internal; ... }会导致整个站点不可访问 - 不要和 IP 白名单混用：
allow/deny与internal逻辑冲突，后者优先级更高且无视 IP - 文件透传场景中，
alias或root必须与internal同处一个 location，否则路径解析失败 - 若需记录被拒请求，可用
log_not_found off;避免刷爆 error.log
