Nginx的merge_slashes指令默认开启（on），在http块中将请求URI中连续多斜杠（如//、///）自动合并为单斜杠（/），用于路径标准化，影响location匹配及$uri变量取值，$request_uri始终保留原始URI。
默认就已处理，无需额外操作——Nginx 的 merge_slashes 指令默认开启（on），会自动把请求路径中连续多个斜杠（如 //、///）合并为单个斜杠（/），这是安全且符合 HTTP 路径语义的标准行为。
它在哪起作用？
该指令只能写在 http 块中，全局生效，影响所有 server 和 location 的路径解析过程：
- 路径标准化发生在 location 匹配之前，确保
location /api/能匹配到GET //api//v1/ - 变量
$uri取值是合并后的路径（如/api/v1/users） - 变量
$request_uri始终保留原始请求（如/api//v1///users?x=1）
什么时候需要关掉它？
绝大多数场景应保持默认 on；仅在极少数明确依赖原始多斜杠结构时才考虑关闭：
- 后端服务用
//做特殊分隔符（如某些老旧 CGI 或自定义协议） - 需在日志或 rewrite 中严格记录/区分原始路径格式（但更推荐用
$request_uri记录） - 配合正则 location 精确匹配含多斜杠的特定路径（不推荐，易出错）
若关闭，必须同步检查所有 location 定义、rewrite 条件和 proxy_pass 拼接逻辑，否则极易出现 404 或路径错误。
怎么配置和验证？
正确写法（仅限 http 块）：
http {
merge_slashes on; # 或 off，二选一
server {
location /test/ {
return 200 "URI: [$uri]\nRequest-URI: [$request_uri]\n";
}
}
}验证方式：
- 运行
nginx -t确保语法无误 - 用 curl 发送含多斜杠请求：
curl -I http://example.com//test//abc - 观察响应内容或查看 access_log，对比
$uri与$request_uri是否不同
别混淆：它不是重定向，也不改响应地址
merge_slashes 是内部路径规范化，不产生 301/308 重定向，也不修改响应头中的 Location。如果你看到大量 301，问题大概率出在其他地方——比如 CDN 配置、前端拼接 URL 错误，或你自己写的 rewrite ... permanent 规则。
