多服务器Windows IIS .NET环境中某台服务器丢失Set-Cookie响应头求助

这种跨服务器Cookie丢失的问题我之前在类似的负载均衡环境里也碰到过，结合你描述的情况——直接访问Server2能拿到Set-Cookie，但通过负载均衡请求就丢，而且两台服务器的MachineKey已经对齐，我整理几个排查方向和解决方案，你可以一步步试：

1. 先排查负载均衡的会话路由规则 #

虽然你直接访问Server2正常，但负载均衡可能没有正确处理会话亲和性（也就是常说的「粘性会话」）：

• 确认负载均衡是否配置了基于Cookie的会话亲和性：如果认证请求先到Server1生成了会话Cookie，后续请求被负载均衡路由到Server2，而Server2没有对应的InProc会话，可能导致应用跳过Set-Cookie的逻辑。
• 检查负载均衡是否有错误的URL路由规则：比如某些特定路径被错误转发，或者响应头被负载均衡的规则修改/移除了Set-Cookie。

2. 对比Server1和Server2的IIS站点配置 #

即使服务器级web.config的MachineKey一致，站点级的配置可能存在差异：

• 检查站点web.config的认证与会话配置：对比两台服务器的web.config，确保<authentication>（比如Forms认证的loginUrl、timeout等）、<sessionState>（模式、超时等）完全一致，没有站点级的配置覆盖。
• 检查IIS输出缓存设置：Server2可能开启了输出缓存，并且缓存规则没有排除包含Set-Cookie的响应。你可以在IIS管理器中找到Server2的站点，进入「输出缓存」，查看是否有针对特定路径的缓存规则，或者直接临时禁用输出缓存测试。
• 检查URL重写模块：如果Server2配置了URL重写规则，查看规则中是否有移除或修改Set-Cookie响应头的操作（比如outboundRules里的逻辑）。

3. 抓包对比两种请求场景的差异 #

用Fiddler或Wireshark分别抓取两种场景的请求：

• 场景1：通过负载均衡访问Server2的请求/响应
• 场景2：直接访问Server2的请求/响应
  对比两者的响应头，重点看：
• Set-Cookie是根本没有生成，还是被中间环节（负载均衡或IIS）移除了
• 响应状态码、Content-Length等是否有差异，判断是否存在内部重定向或截断

4. 启用ASP.NET跟踪排查请求生命周期 #

在Server2的站点web.config中启用跟踪，查看请求处理的每个环节：

<configuration>
  <system.web>
    <trace enabled="true" requestLimit="100" pageOutput="false" traceMode="SortByTime" localOnly="false"/>
  </system.web>
</configuration>

访问出问题的路径后，通过http://Server2/YourAppName/trace.axd查看跟踪日志，重点看认证模块（FormsAuthenticationModule）、会话模块（SessionStateModule）的执行情况，确认Set-Cookie是在哪个环节丢失的。

5. 检查应用代码中的Cookie逻辑 #

虽然概率不高，但还是要确认应用中设置Cookie的代码有没有依赖服务器特定的变量：

• 比如代码中判断了服务器名称、IP等，只有特定服务器才输出Cookie
• 检查Cookie的Domain属性是否配置正确，是否和负载均衡的域名匹配，避免因域名不匹配导致Cookie被浏览器忽略（不过你直接访问Server2正常，这个可能性较低）

可能的解决方案总结 #

• 如果是负载均衡亲和性问题：要么调整规则确保认证后请求路由到同一服务器，要么配置分布式会话（比如SQL Server Session或Redis Session），摆脱InProc会话的限制
• 如果是IIS缓存/重写问题：禁用不符合需求的缓存规则，修改重写规则确保Set-Cookie响应头不被修改
• 如果是站点配置不一致：同步Server1和Server2的所有web.config配置，确保核心配置完全对齐

内容的提问来源于stack exchange，提问作者Alex S.