internal指令语义明确：仅允许Nginx内部重定向访问，外部直连必返404；日志中若出现非404的成功访问记录，即表明配置失效或被绕过。
直接检查 Nginx 访问日志中是否出现对 internal 位置的客户端直连请求，是判断其是否外泄的最有效方式。因为 internal 指令的语义非常明确：该 location 只允许被 Nginx 自身发起的子请求（如 auth_request、X-Accel-Redirect）命中，任何来自真实客户端的原始 HTTP 请求都会被直接拒绝并返回 404。所以只要日志里有非 404 的成功访问记录，就说明 internal 已被绕过；而频繁出现 404 本身也值得深挖——它可能暴露了攻击者正在试探内部路径。
确认日志是否记录 internal location 的真实访问行为
Nginx 默认不会在 access_log 中记录被 internal 拦截的请求，但一旦配置不当（比如 location 写错、rewrite 逻辑错误、或后端返回了 302 跳转），就可能让请求“漏进”目标 location 并完成处理，此时就会留下日志。需确保：
- access_log 配置未被局部关闭（例如在 server 或 location 块中误加
access_log off;） - 使用的是标准 combined 日志格式，能体现请求路径、状态码、响应体大小、上游地址等关键字段
- 日志中包含
$request_uri和$status，便于筛选和比对
筛查高风险访问模式
在日志中重点搜索以下特征，它们往往指向 internal 接口已被暴露或可被探测：
-
匹配 internal 路径但返回 2xx 状态码：例如
grep '/internal/files/' /var/log/nginx/access.log | grep ' 200 '，若存在结果，说明该 location 被客户端直连成功，配置已失效 -
大量 404 针对 internal 路径：如
grep '/internal/' /var/log/nginx/access.log | grep ' 404 '出现高频请求，可能是扫描器或攻击者在枚举内部接口 -
请求来源异常：检查这些请求的
$remote_addr是否来自公网 IP，而非后端服务或本地回环（127.0.0.1、::1），后者才符合 internal 的合理调用场景 -
User-Agent 异常：如出现
sqlmap、nuclei、curl/7.89等工具标识，或为空、极简字符串，属于典型自动化探测行为
验证 auth_request + internal 组合是否闭环
如果使用了 auth_request 鉴权链路，需确认两个环节的日志一致性：
- 外层鉴权 location（如
/api/download）应有正常 2xx 记录，且其$upstream_http_x_accel_redirect或类似 header 应携带合法 internal 路径 - 内层
location = /auth必须声明internal;，且其自身不能出现在 access_log 的成功请求中；若发现该路径有 200 记录，说明它被直接访问，鉴权层已失守 - 对比同一时间戳的两条日志：主请求与子请求的
$request_id（需启用log_format包含该变量）应一致，否则说明子请求未触发或被跳过
补充审计建议
仅靠日志还不够，需配合配置检查与主动验证：
- 检查所有声明
internal;的 location 是否都位于非公开路径下（如以/internal/、/_private/开头），且无proxy_pass指向外部不可信服务 - 禁用 Nginx UI 等第三方管理界面（尤其 CVE-2026-27944 影响版本），避免其后台接口意外暴露 internal 资源路径
- 用 curl 模拟客户端直连测试：如
curl -v http://yourdomain.com/internal/config.conf，预期必须返回 404；若返回 200 或文件内容，立即整改
