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