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路径中，养成目录必带/的习惯，减少不必要的网络跳转开销。
