internal 指令仅限具名 location 块中使用，通过 rewrite last、auth_request 或 X-Accel-Redirect 触发内部跳转才能生效，正则 location 和 server 块中无效；关键路径均需加 internal 防绕过，并应叠加鉴权与 IP 透传等加固措施。

用 internal 指令保护内部 API，核心是让该路径“只认 Nginx 自己”，不接受任何浏览器、curl 或扫描器的直接请求——直连一律 404，连存在性都不暴露。

必须放在具名 location 块中

internal 不是全局开关，也不能写在 server 或 http 块里。它只能出现在明确命名、可被跳转匹配的 location 中：

• ✅ 正确： location /_internal/ { internal; proxy_pass http://backend; }
• ❌ 错误： location ~ ^/_internal/ { internal; ... }（正则 location 不支持 internal）
• ❌ 错误：把 internal; 写在 server { ... } 里（语法报错）

必须由内部跳转触发才生效

internal 本身不提供入口，只是守门员。你需要先定义一个对外的入口 location，并用 Nginx 原生内部机制把它“送进去”：

• 用 rewrite ... last;：外部请求 /api/user → 重写为 /_internal/user → 匹配带 internal 的块
• 用 auth_request：先调鉴权子服务，成功后自动以内部子请求方式进入 /_internal/
• 用 X-Accel-Redirect：后端响应头中返回 X-Accel-Redirect: /_internal/data.json，Nginx 自动内部跳转

注意：rewrite ... redirect（302）或 proxy_pass 到外部地址，都不算内部跳转，不会触发 internal 放行。

要防绕过，关键位置都加 internal

攻击者可能跳过主入口，直接打你的鉴权地址或资源路径。所以：

• 鉴权子 location（如 location = /auth）也必须加 internal
• 资源 location（如 location ^~ /_internal/）必须加 internal
• 避免把 internal 放在 location / { ... } 这类宽泛匹配里，否则整个站点可能不可访问

搭配基础加固更稳妥

internal 解决的是“能否命中”，不是“是否合法”。建议叠加：

• 在对外入口 location 中加 auth_request 或 token 校验
• 用 proxy_set_header X-Real-IP $remote_addr; 透传真实 IP 给后端做风控
• 静态资源用 alias 而非 root，且注意末尾斜杠一致性（如 location ^~ /_private/ { alias /data/private/; }）