为何加载manifest.json需发起新SSL握手？HTTPS站点该问题如何解决

安全阿岳

2026-5-14

解决HTTPS站点manifest.json触发新SSL握手的问题

这问题确实挺反常的——全站都部署了HTTPS，同域名的manifest.json居然还要发起新的SSL握手，换谁碰到都会疑惑。我之前排查过类似的场景，给你梳理几个实用的排查方向和修复方案：

先确认manifest的请求域名是否和主站完全一致
有时候看起来是同域名，但可能藏着细微差别：比如主站是https://www.yoursite.com，但manifest的链接写的是https://yoursite.com（不带www），或者用了某个子域名。这种情况下浏览器会认为是不同的域名，自然会触发新的SSL握手。
你可以打开Chrome DevTools的Network面板，筛选“manifest”类型，查看请求的完整域名，和当前页面的域名做对比（包括www、子域名、端口，HTTPS默认443端口如果没写但实际一致就没问题）。
修复起来很简单：把<link rel="manifest">标签里的href改成相对路径（比如/manifest.json），或者和主站完全一致的完整域名，避免硬编码时出错。
检查HSTS配置是否覆盖了manifest的域名
如果你的站点开启了HTTP严格传输安全（HSTS），但manifest所在的域名不在HSTS的覆盖范围内（比如子域名没加includeSubDomains参数），浏览器可能会重新发起SSL握手来确认安全性。
你可以在Chrome DevTools的Security面板里，查看当前页面的HSTS状态，再对比manifest域名的HSTS响应头（可以用curl命令：curl -I https://yoursite.com/manifest.json，看是否有Strict-Transport-Security头）。
修复方法：确保HSTS的响应头包含includeSubDomains（如果需要覆盖子域名），或者把manifest放在主域名下，保证被HSTS规则覆盖。
排查CDN或服务器的SSL配置差异
有些CDN会对不同资源路径设置不同的SSL终端或证书，比如manifest.json所在的路径被分配了和主站其他资源不一样的SSL配置，导致浏览器识别为不同的连接。
你可以用openssl命令对比主站和manifest路径的SSL握手信息：
```
# 测试主站根路径的SSL信息
openssl s_client -connect yoursite.com:443
# 测试manifest路径的SSL信息
openssl s_client -connect yoursite.com:443 -path /manifest.json
```
看返回的证书、会话ID等是否一致。如果不一致，就需要调整CDN的路由规则，确保manifest和主站其他资源使用同一套SSL配置；如果是服务器配置，检查是否有针对特定路径的特殊SSL设置，统一成相同的证书和配置即可。
检查manifest标签的错误配置
有时候误加的属性会导致浏览器处理异常，比如给同域的manifest标签加了crossorigin="anonymous"属性，或者rel属性写错了（比如写成manifesto）。
确认你的manifest标签是标准格式：
```
<link rel="manifest" href="/manifest.json">
```
去掉不必要的crossorigin属性（同域资源不需要跨域配置），确保rel属性准确为manifest。
临时排查：清除SSL会话缓存
偶尔浏览器的SSL会话缓存会出现异常，导致对同一域名的资源重新握手。你可以在Chrome地址栏输入chrome://net-internals/#ssl，点击“Clear session cache”，然后重新测试。不过GTMetrix的测试是模拟全新会话，所以如果这里解决了但GTMetrix还是有问题，说明还是配置层面的问题，但可以作为快速排查的步骤。

内容的提问来源于stack exchange，提问作者somuch72