非常感谢您发布此消息，因为我遇到了完全相同的问题，即 http://DOMAIN 将 直接 重定向到 https://www.DOMAIN，结合 重定向到 HTTPS 和www子域的那个。
我知道这将是“简单”的解决方案。
请注意，reasons 可以使用像 www 这样的子域，discussed 已经多次使用过，因此这种选择是完全可以理解的。
然而，HSTS 没有办法（至少目前还没有）将这两种重定向结合起来：它只能直接 转发到 HTTPS。我想如果 HSTS 预加载站点检测到这不是普通 HTTP 服务器本身所做的，那么将“307 内部重定向”强制执行到 HTTPS 是不可接受的。 （据我所知，hstspreload.org 上并未明确说明此要求，但只能通过实际尝试设置 HSTS 预加载来发现。）
我对你的问题没有完整的答案，但我可以就你提出的几点提供更多信息：
如果您提供重定向服务，则该重定向必须具有 HSTS 标头，而不是它重定向到的页面。
请注意hstspreload.org的准确（当前）报价：
如果您从 HTTPS 站点 提供 附加 重定向，则该重定向必须仍具有 HSTS 标头（而不是重定向到的页面）。
这与以下几点有关：
据我所知，在进行重定向时没有办法提供 HSTS 标头之类的东西......
HTTP 重定向响应也完全有可能具有 HSTS 标头。这仅意味着 HTTP 重定向响应还包含带有合适参数的 Strict-Transport-Security 标头字段。例如，使用 SWI-Prolog 作为 HTTP 服务器，您可以发出这样的响应：
?- http_status_reply(moved('https://stackoverflow.com'), current_output,
[strict_transport_security('max-age=63072000; includeSubdomains')]，代码）。
屈服：
HTTP/1.1 301 永久移动
日期：2017 年 2 月 12 日星期日 10:04:55 GMT
位置：https://stackoverflow.com
严格的传输安全性：max-age=63072000；包括子域
内容长度：366
内容类型：文本/html；字符集=UTF-8
等等
请注意，只有在 已经 使用 TLS 时才允许使用此标头字段（否则，攻击者可能会通过未经身份验证的连接将流量强制到不同的端口！）。事实上，标头不得出现在 HTTP→HTTPS 重定向中，因为它使用未经身份验证的连接，并且如果它（错误地）确实通过普通 HTTP 出现，客户端必须忽略它。
现在到您问题的实际要点：
这造成了巨大的重定向稀释SEO问题（更不用说链式重定向并不理想）。
我完全同意链式重定向远非理想，而且对于我们这样的（常见的！）设置似乎没有办法解决这个问题，至少目前没有。
但是，我个人希望额外重定向的影响不会对您网站的排名产生太大影响：理论上，一旦搜索引擎发现您的网站在 HSTS 预加载列表中，它应该关心的只是 HTTPS它的版本（因为这也是支持 HSTS 预加载的浏览器的功能！）。因此，您最终只有一个重定向，即https://DOMAIN→https://www.DOMAIN 一个，这应该与您当前的情况相当。至少这是我有些天真的希望。在此重定向中，请确保包含 HSTS 标头，因为这是进入预加载列表的要求。当然，具体的配置细节取决于您的具体 Web 服务器。
另外，请注意，即使 您已将其加入 HSTS 预加载列表，您也无法恢复原始重定向链。这是因为继续要求部分指出：
您必须确保您的网站始终满足提交要求。