这真是个让人摸不着头脑的IIS坑——我之前处理过类似的案例，规则名称居然能左右重定向行为，听起来反直觉，但背后其实是缓存机制和规则逻辑漏洞共同作用的结果。

为什么规则名称会影响结果？ #

IIS的URL Rewrite模块会缓存规则的匹配结果和执行逻辑，而规则名称是缓存键的核心组成部分。如果你的服务器上曾经存在过同名规则（哪怕配置和现在不一样），旧的缓存数据可能没有被清空，导致IIS依然按照旧规则的逻辑执行，从而触发循环重定向。

而当你修改规则名称后，IIS会把它识别为一条全新的规则，直接加载新的配置，跳过了旧缓存的干扰，所以重定向暂时恢复正常。但这只是治标不治本的临时方案，根源还是规则本身的问题。

你的规则为什么会触发循环重定向？ #

看一下你的规则逻辑：

1. 匹配任何URL（<match url="*" />）
2. 只要{CACHE_URL}包含*://*/*/login*就执行重定向
3. 重定向到https://dev.mydomain.com/apply/{C:3}/login

问题出在：重定向后的URL（比如https://dev.mydomain.com/apply/rms/login）依然满足*://*/*/login*的条件（因为末尾有/login），所以这条规则会被反复触发，每次都追加apply和{C:3}，最终导致重定向循环失效。

如何让原名称的规则正常运行？ #

1. 修复规则逻辑，避免循环重定向（推荐） #

修改规则的条件，排除已经包含/apply/的URL，这样重定向后的URL就不会再匹配规则：

<rule name="Redirect to merchant dashboard login page" patternSyntax="Wildcard" stopProcessing="true">
  <match url="*" />
  <conditions logicalGrouping="MatchAll">
    <add input="{CACHE_URL}" pattern="*://*/*/login*" />
    <!-- 排除已经在apply路径下的请求，避免循环 -->
    <add input="{CACHE_URL}" pattern="*://*/apply/*/login*" negate="true" />
  </conditions>
  <action type="Redirect" url="https://dev.mydomain.com/apply/{C:3}/login" />
</rule>

这里把logicalGrouping改成MatchAll，同时添加一个否定条件，确保只有非/apply/路径下的/login请求才会被重定向。

2. 强制清空IIS的URL Rewrite缓存 #

如果确实是旧缓存的问题，可以通过以下方式清空缓存：

• 在IIS管理器中右键你的站点 → 管理网站 → 重启
• 以管理员身份运行命令行，执行iisreset重启整个IIS服务
• 随便修改web.config的内容（比如加个空格再保存），触发应用程序池自动重启，缓存会被清空

3. 检查是否存在同名规则冲突 #

搜索你的web.config文件（包括上级配置文件，比如根目录的web.config），看是否有其他名为Redirect to merchant dashboard login page的规则。如果有，删除或重命名冲突的规则，避免IIS加载错误的配置。

总结 #

改规则名称只是绕过了缓存问题，真正的解决方案是修复规则逻辑防止循环，或者清空缓存排除旧配置干扰。按照上面的方法调整后，原名称的规则就能正常工作了。

内容的提问来源于stack exchange，提问作者Fazla Elahi Md Jubayer