IIS ARR模块篡改302重定向Location头及CORS配置咨询

不需要额外在IIS中配置CORS，原因如下：

1. NodeJS后端已完成CORS配置
   你的NodeJS服务通过cors中间件已经正确配置了允许的源（https://example.com和https://destination.com），并且从失败请求日志的第143行可以看到，后端返回了Vary: Origin头，这是CORS配置生效的标志之一。浏览器的CORS校验仅关注后端返回的Access-Control-*系列响应头，这些已经由NodeJS服务正确处理，无需IIS重复配置。

2. 当前问题与CORS无关，是ARR的重定向改写行为
   日志中显示ARR模块将302响应的Location头从https://destination.com/foo/bar?p=v修改为https://example.com/foo/bar?p=v，这是ARR作为反向代理的默认行为——它会自动重写重定向响应中的Location头，使其指向代理服务器的域名，而非后端返回的原始地址。这个问题不属于CORS范畴，需要调整ARR的代理设置来解决：

   • 打开IIS管理器，找到对应服务器/站点下的Application Request Routing
   • 进入Server Proxy Settings（或站点级代理设置）
   • 取消勾选Rewrite the response headers下的Rewrite redirect responses to use the proxy server's hostname选项，或针对特定路由配置例外规则。

3. 现有重写规则的注意点
   你的IIS重写规则中，Upgrade规则里的条件存在错误：REQUEST_METHOD指代HTTP请求方法（如GET/POST），而FOUND是HTTP状态码，该条件不会生效，建议移除：

   <conditions logicalGrouping="MatchAll" trackAllCaptures="false">
       <add input="{HTTPS}" pattern="^OFF$" />
       <add input="{REQUEST_METHOD}" pattern="POST" negate="true" />
       <!-- 移除以下错误条件 -->
       <!-- <add input="{REQUEST_METHOD}" pattern="FOUND" negate="true" /> -->
   </conditions>
   

内容的提问来源于stack exchange，提问作者Taj Parmanand-Wilson