1. 问题现象

在小程序 WebView 或 H5 访问中，访问不带末尾斜杠的目录（如 https://domain.com/orderfood）时，会出现以下异常：

微信小程序 ：报错"不支持打开非业务域名"，并显示一个 http 开头的链接。

浏览器 ：地址栏短暂闪烁后恢复 https，但通过 Network 面板可见明显的 301 或 307 跳转。

2. 核心原因分析

这是由 SSL 卸载（SSL Termination） 架构下的 Nginx 默认重定向逻辑引发的。

A. Nginx 的"自动补全"逻辑

当访问 /orderfood 且该路径在服务器上是一个目录时，Nginx 为了符合 HTTP 标准，会自动发起 301 重定向，引导客户端访问真正的目录地址 /orderfood/。

B. 协议降级（罪魁祸首）

由于运维在负载均衡（LB）上做了 SSL 卸载，外部请求是 HTTPS，但 LB 转发到后端 Nginx 的是 HTTP (80端口)。

Nginx 在发起重定向时，默认会感知当前的 HTTP 环境。

它生成的 Location 头部会包含完整的绝对路径：Location: http://domain.com/orderfood/。

C. 微信小程序的"零容忍"安检

普通浏览器具有"协议纠偏"能力（如通过 HSTS 或 LB 的强制跳转绕回 HTTPS），但微信小程序 WebView 的安全机制非常严格：

只要重定向链条中出现一次 http://，即便它是中间状态，微信也会立刻拦截并报错。

3. 解决方案验证

通过对现场 curl 结果和 Network 面板的分析，验证了以下两种有效方案：

方案一：运维侧配置 absolute_redirect off; (已生效)

在 Nginx 配置中关闭绝对重定向：

Nginx

复制代码

server {

listen 80;

absolute_redirect off; # 将绝对路径跳转改为相对路径跳转

...

}

原理 ：Nginx 返回 Location: /orderfood/（相对路径），不再包含协议头。

结果 ：浏览器/小程序收到后，自动沿用当前的 https 协议拼接，避开了 http 的出现。

方案二：前端规范化 URL

规范 ：所有访问目录的链接，手动在末尾补全 /。

原理 ：直接命中目录资源，不触发 Nginx 的"补全斜杠"重定向逻辑，从根源上消除产生 http 的机会。

总结与建议

运维建议 ：除了配置 absolute_redirect off;，建议在 LB 层面开启 HTTP 强制跳转 HTTPS，作为全局安全补丁。

开发建议 ：在小程序 web-view 的 src 路径中，养成目录必带 / 的习惯，减少不必要的网络跳转开销。