在.htaccess文件中使用以下代码自动将访问者重定向到站点的HTTPS版本:

RewriteEngine On

RewriteCond %{HTTPS} off

RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

如果你有一个现有的。htaccess文件:

不要重复“重写引擎”。

确保以RewriteCond和RewriteRule开头的行立即跟随已经存在的RewriteEngine On。

最佳解决方案取决于您的需求。这是对之前发布的答案的总结，并添加了一些上下文。

如果你使用Apache web服务器并且可以更改其配置，请参考Apache文档:

<VirtualHost *:80>
    ServerName www.example.com
    Redirect "/" "https://www.example.com/"
</VirtualHost>

<VirtualHost *:443>
    ServerName www.example.com
    # ... SSL configuration goes here
</VirtualHost>

但你还问是否可以在.htaccess文件中进行。在这种情况下，你可以使用Apache的RewriteEngine:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [L]

如果一切正常，你想让浏览器记住这个重定向，你可以将最后一行更改为:

RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

但如果你在这个方向上改变了主意，要小心。浏览器会记住它很长一段时间，不会检查它是否改变了。

根据web服务器配置，您可能不需要第一行RewriteEngine On。

如果你在寻找一个PHP解决方案，看看$_SERVER数组和header函数:

if (!$_SERVER['HTTPS']) {
    header("Location: https://" . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI']); 
} 

在.htaccess文件中添加以下代码:

Options +SymLinksIfOwnerMatch
RewriteEngine On
RewriteCond %{SERVER_PORT} !=443
RewriteRule ^ https://[your domain name]%{REQUEST_URI} [R,L]

其中[您的域名]是您网站的域名。

你也可以重定向特定的文件夹从你的域名通过替换上面的最后一行代码:

RewriteRule ^ https://[your domain name]/[directory name]%{REQUEST_URI} [R,L]

这将重定向所有的url到https和www

RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTPS_HOST} !^www.example.com$ [NC,OR]
RewriteCond %{HTTP_HOST} !^www.example.com$ [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [L,R=301]

这个问题的另一个优势是当负载均衡器开始发挥作用时。

情况如下: -从浏览器到负载均衡器的流量，以及返回，是(应该)HTTPS —负载均衡器与实际WebServer之间的流量为HTTP协议。

因此，PHP或Apache中的所有服务器请求变量都显示连接只是HTTP。服务器上的HTTP和HTTPS目录是相同的。

已批准答案中的重写条件不工作。 它要么是循环，要么就是不起作用。

问题是:如何让它在负载均衡器上工作。

(或者负载均衡器配置错误。这就是我所希望的，因为这样我就可以把问题转移到网络托管公司:-))

正如我在这个问题中所说的，我建议您避免盲目地将所有HTTP请求重定向到其HTTPS对等物，因为这可能会使您对安全性产生错误的印象。相反，您应该将HTTP站点的“根”重定向到HTTPS站点的根，并从那里链接到HTTPS。

问题是，如果HTTPS站点上的某些链接或表单使客户端向HTTP站点发送请求，那么在重定向之前，其内容将是可见的。

例如，如果一个通过HTTPS提供服务的页面有一个<form action="http://example.com/doSomething">的表单，并且发送了一些不应该明确发送的数据，浏览器将首先将完整的请求(包括实体，如果它是POST)首先发送到HTTP站点。重定向将立即发送到浏览器，由于大量用户禁用或忽略警告，它很可能被忽略。

Of course, the mistake of providing the links that should be to the HTTPS site but that end up being for the HTTP site may cause problems as soon as you get something listening on the HTTP port on the same IP address as your HTTPS site. However, I think keeping the two sites as a "mirror" only increases the chances of making mistakes, as you may tend to make the assumption that it will auto-correct itself by redirecting the user to HTTPS, whereas it's often too late. (There were similar discussions in this question.)