我有一个URL重写规则configuration在IIS根（ ApplicationHost.config ），将www.example.comredirect到HTTPS。 URL重写configuration是在我们托pipe的公共负载均衡器后面的IIS实例上设置的，我们的托pipe提供商安装了SSL。 Load Balancer为我们提供了X-Forwarded-Proto头，如果原始请求处于HTTP状态，则头设置为http如果原始请求处于HTTPS，则为https。
Url重写是这样configuration的：
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
问题是，我们有一个PowerShell脚本安装在Web服务器本身，以检查网站是否可用或不使用[System.Net.WebRequest]::Create($siteUrl) 。 该脚本大部分时间都会报告HTTP 200（确定），但有时会因404 HTTP错误而失败。 由于PowerShell脚本是在本地执行的，因此它不应具有X-Forwarded-Proto标头，并且不会由IIS获取404。
是否有可能以任何方式，该url重写不应该被解雇？
我build议启用失败请求跟踪，因为它是一个function强大的工具，可以查看模块（包括URL重写模块）如何处理请求。 没有它，这是我的猜测。
这是我的猜测 ：这取决于IIS服务器本身configuration的主机文件和/或DNS服务器。 但是，即使在本地运行，www.example.com可能会parsing回负载均衡器的IP，并且请求可能会通过负载平衡器返回，因此具有X-Forwarded-Proto标头。 我们将能够看到标题是否存在与失败的请求追踪。
注意 （主要来自我的OCD）：我build议将模式从www.example.com更改为www（反斜杠）.example（反斜杠）.com，以便通知URL重写：点（。）是一个字面点不是野性的点。 用实际的字符replace（反斜杠）。 看来这是为我清理angular色。