我的网站使用CloudFlare的通用SSL，我希望浏览器自动redirect到HTTPS。 但是，由于并非所有浏览器都支持SSL cloudflare使用的types ，我不想直接强制使用SSL。 所以HSTS似乎是一个不错的select。 但是，当我在浏览器中testing它时，它并不像我预期的那样工作。
在我的网站configuration文件中，我有这样的一行：
server { ... listen 443 ssl; add_header Strict-Transport-Security max-age=63072000; ... } 它显示在响应标题中：
Strict-Transport-Security: max-age=63072000
但是，Windows 10和OS X 10.10.3上的Firefox 35和Chrome 41仍然会在HTTP上导航站点，而不会redirect到HTTPS。
我正在使用在CentOS 7上运行的NGINX版本1.7.3。
STS响应头只对安全scheme有效。 客户端必须至less访问一次https页面才能在HSTScaching中获得STS条目。
该规范build议服务器应该redirect到HTTP的HTTP，但这并不总是可行的。 因此，您可以尝试在后端嗅探不受支持的用户代理，并且只在UA未列入黑名单时才发出redirect。
有关更多背景信息，请参阅RFC 6797的第7.2节 ：
7.2。 HTTP请求types
如果HSTS主机通过非安全传输接收到一个HTTP请求消息，它应该发送一个HTTP响应消息，其中包含一个状态代码，指示一个永久的redirect，例如状态代码301（[RFC2616]的第10.3.2节）包含HTTP请求的原始有效请求URI（请参见第9节“构build有效的请求URI”）的位置标头字段值，根据需要更改为具有“https”的URIscheme或根据本地策略生成的URI “https”的URIscheme。注：上述行为是“应该”，而不是“必须”，因为：
- 服务器端的非安全到安全redirect风险[OWASP-TLSGuide]。
- 网站部署特点。 例如，包含第三方组件的站点在通过非安全传输进行访问的情况下执行服务器端的非安全至安全redirect时可能无法正确运行，但在通过安全传输进行统一访问时运行正常。 后者就是一个HSTS-capable UA的情况，该UA已经将该站点指定为已知的HSTS主机（无论如何，例如，先前的交互或UAconfiguration）。 HSTS主机不得在通过非安全传输传送的HTTP响应中包含STS头域。
本身并不是一个答案，但不允许在不安全的连接上设置严格传输安全的原因是，这样做会允许一个MITM攻击者–HSTSdevise的威胁 – 阻止访问任何实际上不支持SSL的网站。