☰

URL 重写未正确触发

tag-icon • tag-icon iis rewrite iis-8
URL 重写未正确触发

ApplicationHost.config我在 IIS Root ( )配置了一个 URL 重写规则，该规则重定向www.example.com到 HTTPS。URL 重写配置在我们托管的公共负载均衡器后面的 IIS 实例上设置，我们的托管提供商在其中安装了 SSL。负载均衡器为我们提供了一个X-Forwarded-Proto标头，用于设置http原始请求是否为 HTTP 以及https原始请求是否为 HTTPS。

Url Rewrite 配置如下：

 Pattern: .*
 Conditions: Match All
             Input                   |Type                |Pattern
             -------------------------------------------------------------
             {HTTP_HOST}             |Matches the Pattern |www.example.com
             {HTTP_X_Forwarded_Proto}|Matches the Pattern |^http$
 Action:
  Redirect to URL: https://{HTTP_HOST}{REQUEST_PATH}
  Redirect Type  : 302

问题是，我们在 Web 服务器本身中安装了 powershell 脚本，用于检查网站是否可用[System.Net.WebRequest]::Create($siteUrl)。该脚本大多数情况下会报告 HTTP 200（正常），但有时会失败并出现 404 HTTP 错误。由于 PowerShell 脚本是在本地执行的，因此它不应该有标头X-Forwarded-Proto，也不会被 IIS 收到 404。

是否有可能 URL Rewrite 在不应该触发的时候被触发？

答案1

我建议启用失败请求跟踪，因为它是一个强大的工具，可以查看模块（包括 URL 重写模块）如何处理请求。如果没有它，目前这只是我的猜测。

这是我的猜测：这取决于 IIS 服务器本身上配置的主机文件和/或 DNS 服务器。但是，即使在本地运行，www.example.com 也可能解析回负载平衡器的 IP，并且请求可能通过负载平衡器返回，因此具有 X-Forwarded-Proto 标头。我们可以通过失败请求跟踪查看标头是否存在。

笔记（主要是因为我的强迫症）：我建议将模式从 www.example.com 更改为 www(backslash).example(backslash).com，以便告诉 URL 重写点 (.) 是文字点，而不是通配符点。将 (backslash) 替换为实际字符。看来 SO 正在帮我清理字符。

相关内容