基于IIS Application Request Routing的HTTPS负载均衡301重定向及POST数据丢失问题

我来帮你梳理这个问题的排查方向，这类ARR的HTTPS转发故障我碰到过不少，咱们一步步来定位解决：

1. 先检查URL重写规则的坑 #

• 打开IIS管理器里的URL重写模块，仔细核对所有入站规则：
  • 有没有规则把HTTPS请求错误触发了HTTP重定向？比如带RewriteCond %{HTTPS} off的规则，要给它加个排除POST请求的条件：

    RewriteCond %{REQUEST_METHOD} !POST
    

  • 重点看规则的action类型：如果用了Redirect（尤其是301），POST请求会被强制转换成GET，数据直接丢失。转发后端服务器必须用Rewrite类型，不能用Redirect。

2. 确认ARR与后端的SSL通信配置 #

• 虽然你禁用了SSL卸载，但要再核对服务器场的代理设置：
  • 进入ARR服务器场的代理选项，确保「启用SSL offloading」确实是禁用状态，同时确认「保留客户端IP」等选项已正确开启。
  • 检查后端服务器的IIS站点：有没有自己配置HTTP到HTTPS的强制重定向？如果后端站点本身发301，POST数据同样会丢失，可以暂时关闭这个重定向测试。

3. 验证请求体转发设置 #

POST数据丢了大概率是ARR没把请求体传给后端，检查这两个地方：

• 进入ARR服务器场的代理设置，确认「允许请求实体正文」是开启状态——这个选项关了的话，POST的请求体直接被丢弃。
• 检查服务器场的HTTP响应头配置，确保没有拦截或篡改请求头的设置，尤其是和请求体相关的Content-Length、Content-Type等字段。

4. 开ARR日志抓细节 #

启用ARR的详细日志，能直观看到请求流转过程：

• 在IIS管理器里找到应用程序请求路由→服务器场→日志，开启「启用服务器场日志记录」，把日志级别设为详细。
• 发测试POST请求后，查看日志里的请求方法、状态码、转发路径，确认请求是不是被正确转发，有没有中途被重定向，请求体是否存在。

5. 排查后端站点的身份验证逻辑 #

你提到请求被导向登录页，可能是后端因为没收到POST数据，触发了认证失败的重定向：

• 直接向后端服务器发HTTPS POST请求测试，如果正常，说明问题肯定在ARR转发环节；如果也失败，就要排查后端站点的身份验证配置（比如Forms认证是否对POST请求有特殊限制）。

内容的提问来源于stack exchange，提问作者girish kolte