路径穿越源于Nginx解析URI时被利用配置漏洞，防护需从root/alias规范、rewrite变量过滤、map拦截非法路径、禁用autoindex及启用URI规范化入手。
路径穿越不是 Nginx 主动“做错”，而是它按规则解析 URI 时，被攻击者利用了配置漏洞或信任缺陷，让请求绕出预期目录范围。防护关键不在堵某个字符，而在控制解析逻辑本身——从 root/alias 的使用、rewrite 的变量处理，到 URI 规范化时机，每一步都可能成为突破口。
别让 alias 成为穿越入口
alias 指令天然容易引发路径解析歧义，尤其当 location 和 alias 值末尾斜杠不一致时。例如：
-
危险写法：
location /static { alias /var/www/static_files; }（location 无尾斜杠，alias 也无尾斜杠）
访问/static../../etc/passwd可能被拼接为/var/www/static_files../etc/passwd，最终解析出站。 -
安全写法：统一加尾斜杠：
location /static/ { alias /var/www/static_files/; }，或更推荐用root：location /static/ { root /var/www/; }。root 是追加匹配路径，天然抗 ../ 跳转。
rewrite 中的变量必须“消毒”
如果 rewrite 目标直接引用用户可控变量（如 $arg_path），就等于把文件系统路径的构造权交给了攻击者。
- 像
rewrite ^/file$ $arg_path last;这类配置，攻击者传参?path=../../../etc/shadow就可触发穿越。 - 正确做法是：先用
map对变量做白名单过滤或路径规范化，再用于 rewrite；或改用try_files+ 固定前缀方式，避免动态拼接。
主动拦截非法路径模式
不能只靠配置“不出错”，还要加一层兜底识别。但注意：if 在 server 级使用有性能和逻辑风险，优先用 map。
- 推荐方式（高效且安全）：
map $request_uri $bad_path {<br> ~"(\.\./|\.\%2e/|\.%2e\%2e/)" 1;<br> default 0;<br>}
然后在 server 或 location 中：if ($bad_path) { return 403; } - 禁用 autoindex：除非明确需要目录列表，否则全局关闭
autoindex off;，防止通过索引暴露结构或诱导猜测路径。
启用 URI 规范化与严格匹配
Nginx 默认会对 URI 做标准化（如解码、合并重复斜杠、消除 . 和 ..），但某些场景（如 proxy_pass 后端、或使用 rewrite break）可能跳过这步。
- 确保
merge_slashes on;（默认开启，勿关）； - 对敏感 location，显式用
try_files $uri =404;，强制只响应真实存在的文件，不尝试向上回溯或 fallback； - 避免在 location 正则中过度宽松，比如
location ~ \.php应收紧为location ~ ^/api/.*\.php$，缩小匹配范围。
