IIS 8 HTTPS请求被重定向到HTTP怎么办？

IIS 8 HTTPS请求被重定向到HTTP怎么办？

IIS 8网站正常情况下不应该将 HTTPS 请求主动重定向到 HTTP。如果浏览器访问 https://example.com 后收到 http://example.com 的 301 或 302 跳转，说明服务器端或应用程序返回了 HTTP 地址。

常见原因包括 IIS URL Rewrite 规则配置错误、ASP.NET 应用生成了错误的绝对URL、反向代理没有正确传递 HTTPS 状态，以及站点代码中的固定跳转地址。

排查时应先查看 HTTP 响应中的 Location 头，再确定究竟是 IIS、应用程序还是前端代理生成了跳转。

IIS为什么会把HTTPS重定向到HTTP？

HTTPS → HTTP 重定向本身并不是 IIS 的默认行为。

IIS 接收到 HTTPS 请求后，如果站点绑定和证书配置正确，会继续按照 HTTPS 请求处理。只有某个组件主动返回类似下面的响应时，浏览器才会跳转到 HTTP：

HTTP/1.1 301 Moved Permanently
Location: http://example.com/

因此，排查这类问题时，第一步不是重新安装SSL证书，而是确认：

到底是谁生成了 Location: http://...。

常见来源包括：

• IIS URL Rewrite；
• ASP.NET / ASP.NET MVC 应用程序；
• Global.asax；
• 登录、退出登录等认证模块；
• 负载均衡器；
• Nginx、F5等反向代理；
• CDN或WAF；
• 应用程序生成绝对URL时错误判断当前协议。

先检查浏览器收到的Location地址

可以打开浏览器开发者工具，进入 ​**Network（网络）**​，重新访问HTTPS地址。

如果看到：

Status Code: 301
Location: http://example.com/

就可以确定这是服务器端返回的重定向。

也可以直接使用 curl：

curl -I https://example.com

如果返回：

HTTP/1.1 301 Moved Permanently
Location: http://example.com/

说明HTTPS请求确实被服务器端重定向到了HTTP。

如果第一次响应没有 Location，而是页面加载后又跳转，则需要继续检查HTML、JavaScript和应用程序代码。

检查IIS URL Rewrite规则

如果服务器安装了 ​IIS URL Rewrite Module​，首先检查网站根目录下的 web.config。

重点寻找：

<rewrite>
    <rules>
        ...
    </rules>
</rewrite>

尤其检查是否存在把HTTPS请求重定向到HTTP的规则。

例如下面这种配置就属于错误示例：

<rule name="Force HTTP" stopProcessing="true">
    <match url="(.*)" />
    <conditions>
        <add input="{HTTPS}" pattern="on" />
    </conditions>
    <action type="Redirect"
            url="http://{HTTP_HOST}/{R:1}"
            redirectType="Permanent" />
</rule>

其中：

url="http://{HTTP_HOST}/{R:1}"

明确指定了HTTP地址。

如果该规则作用于HTTPS请求，就会产生：

HTTPS
 ↓
301/302
 ↓
HTTP

这种配置应当删除或修改。

IIS正确的HTTP→HTTPS重定向怎么配置？

如果网站的目标是强制使用HTTPS，URL Rewrite规则应该反过来：

HTTP
 ↓
301
 ↓
HTTPS

例如：

<configuration>
    <system.webServer>
        <rewrite>
            <rules>
                <rule name="Redirect to HTTPS" stopProcessing="true">
                    <match url="(.*)" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect"
                            url="https://{HTTP_HOST}/{R:1}"
                            redirectType="Permanent" />
                </rule>
            </rules>
        </rewrite>
    </system.webServer>
</configuration>

核心判断条件是：

<add input="{HTTPS}" pattern="off" />

只有当前请求不是HTTPS时才执行跳转。

目标地址则必须使用：

https://

而不是：

http://

如果网站已经安装并绑定SSL证书，这种方式可以将HTTP访问统一转到HTTPS。

检查ASP.NET应用程序代码

如果 web.config 没有问题，下一步应该检查应用程序。

例如下面的代码就可能造成HTTPS降级：

Response.Redirect("http://example.com/login");

或者：

Response.Redirect("http://" + Request.Url.Host + "/");

这类代码会直接生成HTTP地址。

更隐蔽的情况是应用程序根据请求协议生成绝对URL：

Request.Url.Scheme

如果应用程序认为当前请求是HTTP，就可能生成：

http://example.com/

因此，如果网站使用ASP.NET，并且前面还有负载均衡器或反向代理，需要特别检查代理传递的协议状态。

IIS前面有反向代理时要检查什么？

如果网站架构是：

用户
 ↓
CDN / WAF / F5 / Nginx
 ↓
IIS
 ↓
ASP.NET

HTTPS可能已经在前端设备完成：

客户端 → HTTPS → 代理
代理 → HTTP → IIS

这种情况下，IIS后端看到的请求可能是HTTP，但用户实际访问的是HTTPS。

如果代理没有正确传递原始协议，应用程序就可能错误地认为：

用户访问的是HTTP

然后生成：

Location: http://example.com/

常见做法是通过代理传递：

X-Forwarded-Proto: https

或者使用具体代理产品提供的等效协议头。

但需要注意：

IIS不会因为存在 X-Forwarded-Proto 就自动理解所有应用程序逻辑。

ASP.NET、ASP.NET Core以及不同版本的代理组件，对转发头的处理方式并不完全相同。因此这类环境应该同时检查：

1. 前端代理是否发送协议头；
2. IIS是否正确接收；
3. 应用程序是否信任并处理该协议头；
4. 应用程序生成绝对URL时使用的协议是否正确。

HTTPS证书错误会导致自动跳转到HTTP吗？

一般不会。

如果SSL证书存在以下问题：

• 证书过期；
• 域名不匹配；
• 证书链不完整；
• 证书不受信任；
• 证书已经吊销；

浏览器一般会显示相应的证书安全错误，而不是由IIS自动把HTTPS降级成HTTP。

因此：

“HTTPS访问后变成HTTP”和“HTTPS证书错误”应该分开排查。

如果是证书问题，可以进一步使用 SSL证书工具 检查证书有效期、域名匹配和证书链。

如果确认是证书本身的问题，再按照 修复SSL证书错误 的排查流程处理。

混合内容和HTTPS跳转有什么区别？

这两个问题很容易被混淆。

例如网页本身通过：

https://example.com

访问，但HTML里面存在：

<img src="http://example.com/image.jpg">

这属于​**混合内容（Mixed Content）**​。

它不会等同于：

https://example.com
        ↓ 301
http://example.com

后者是HTTP重定向。

所以排查时应该分别看：

IIS 8 HTTPS重定向循环怎么排查？

如果访问网站出现：

ERR_TOO_MANY_REDIRECTS

并且HTTP和HTTPS之间不断跳转，需要重点检查重定向条件。

例如前端代理已经完成HTTPS终止：

用户
 ↓ HTTPS
Nginx
 ↓ HTTP
IIS

如果IIS不知道用户原始请求是HTTPS，就可能认为：

当前请求 = HTTP

于是执行：

HTTP → HTTPS

但代理再次将HTTPS请求以HTTP形式转发给IIS，最终形成循环。

这种情况下，单纯修改SSL证书通常无法解决问题，必须检查：

代理层 → IIS → 应用程序

这一整条请求链路。

IIS 8配置HTTPS时还需要检查哪些项目？

除了重定向规则，还建议检查以下配置：

IIS服务器证书部署完成后，可以参考 怎么安装SSL证书 检查证书安装、PFX导入和站点绑定。

IIS 8需要开启HSTS吗？

HSTS可以进一步要求浏览器以后只能通过HTTPS访问网站。

例如：

Strict-Transport-Security: max-age=31536000

但HSTS不是解决“HTTPS → HTTP重定向”的根本方法。

应该先保证：

HTTP → HTTPS
HTTPS → 正常访问

全部工作正常，再根据网站架构和业务需求配置HSTS。

特别是：

includeSubDomains
preload

这类配置具有更强的约束性，启用之前应确认所有相关子域都已经支持HTTPS。

IIS 8 HTTPS重定向排查流程

遇到“HTTPS访问后跳HTTP”，可以按照下面的顺序排查：

访问 https://example.com
        ↓
检查响应状态码
        ↓
是否存在 Location: http://？
        ↓
    ┌── 是 ──→ 检查URL Rewrite
    │              ↓
    │          检查ASP.NET代码
    │              ↓
    │          检查反向代理/CDN
    │
    └── 否 ──→ 检查页面JavaScript和资源链接

如果使用代理或负载均衡，则增加：

检查 X-Forwarded-Proto / 等效协议头
        ↓
确认应用程序正确识别原始HTTPS

这个流程比直接重新安装证书更加有效，因为它首先定位了​是谁产生HTTP跳转​。

常见问题 FAQ

Q：IIS会自动把HTTPS跳转到HTTP吗？

A：不会。IIS本身不会因为安装了SSL证书就自动将HTTPS降级到HTTP。如果出现这种情况，应重点检查URL Rewrite、应用程序代码、反向代理、CDN或负载均衡器。

Q：HTTPS访问后跳到HTTP，是SSL证书配置错误吗？

A：不一定。证书过期、域名不匹配或证书链错误一般会产生证书验证错误，而不是主动返回HTTP重定向。首先检查HTTP响应中的 Location 头，确定跳转来源。

Q：IIS怎么强制HTTP跳转HTTPS？

A：可以使用 IIS URL Rewrite Module，在 web.config 中判断 {HTTPS} 是否为 off，然后将请求永久重定向到 https:// 地址。

Q：IIS前面有Nginx，为什么HTTPS会一直跳转？

A：常见原因是Nginx与IIS之间使用HTTP通信，但应用程序没有正确识别用户最初使用的是HTTPS。需要检查反向代理传递的协议头，以及应用程序对该协议头的处理方式。

IIS 8出现“HTTPS被重定向到HTTP”，核心不是SSL证书本身，而是​HTTP重定向逻辑出现了错误​。

排查时首先查看 301/302 响应中的 Location 头，然后依次检查 IIS URL Rewrite、ASP.NET应用代码、CDN/负载均衡和反向代理协议识别。正确的HTTPS部署逻辑应该是 ​HTTP → HTTPS​，

而不是HTTPS → HTTP。对于前置代理架构，还需要保证应用程序能够正确识别客户端最初使用的HTTPS协议，避免出现降级或重定向循环。