HAProxy配置双IIS后端时站点无限页面刷新循环如何修复

• 会话粘滞配置不完整：两个backend的server行虽然配置了cookie srv1/cookie srv2的节点标识，但没有在backend层级配置cookie指令启用粘滞逻辑，HAProxy不会向客户端写入粘滞Cookie，所有请求严格按roundrobin策略轮询分发到两台IIS节点。
• IIS会话默认不跨节点共享：IIS站点默认使用InProc模式存储会话，数据仅保存在当前服务器的本地进程中，不会同步到另一台节点。当用户请求交替分发到srv1、srv2时，每次请求命中的节点都没有当前用户的有效会话，站点判定会话失效就会触发跳转，反复轮询反复跳转就形成无限刷新循环。仅启用单台节点时所有请求固定落到同一台服务器，会话始终有效，因此访问正常。
• 潜在配置缺陷：当前443、9000端口拆分为两个独立backend，就算开启粘滞，默认两个backend的Cookie互相独立，跨端口访问时仍会出现会话不匹配问题。

方案1：补全会话粘滞配置（快速恢复） #

在两个backend中添加统一的Cookie粘滞配置，保证同一用户的所有请求（包括跨端口请求）固定分发到同一台后端节点，修改后的backend配置如下：

backend https
    balance roundrobin
    cookie SRVCOOKIE insert indirect nocache domain=xxxx.com
    server srv1 192.168.1.11:443 check cookie srv1 weight 80 ssl verify none
    server srv2 192.168.1.111:443 check cookie srv2 weight 20  ssl verify none

backend 9000
    balance roundrobin
    cookie SRVCOOKIE insert indirect nocache domain=xxxx.com
    server srv1 192.168.1.11:9000 check cookie srv1 weight 80 ssl verify none
    server srv2 192.168.1.111:9000 check cookie srv2 weight 20 ssl verify none

配置修改完成后，先执行haproxy -c -f /etc/haproxy/haproxy.cfg校验语法正确性，确认无报错后重载HAProxy服务即可生效。

方案2：配置IIS共享会话（长期最优方案） #

会话粘滞只是临时规避方案，一旦某台后端节点故障，绑定到该节点的用户会话会全部丢失。生产环境建议从IIS侧解决会话共享问题：

• 将IIS会话存储模式从默认的InProc改为StateServer或SQLServer模式，会话数据统一存储在共享服务/数据库中，两台节点均可正常读取
• 统一两台IIS节点的<machineKey>配置，保证视图状态、表单认证票据的加解密逻辑跨节点一致
  该方案无需HAProxy配置会话粘滞，请求轮询到任意节点都能识别用户会话，彻底解决跳转循环问题，单节点故障也不会影响用户会话有效性。

• 当前9000端口的路由规则依赖Host头匹配xxxx.com:9000，部分浏览器发起请求时Host头不会携带端口，会导致9000端口的请求被错误转发到443后端，建议将9000端口监听拆分为独立frontend，或使用dst_port 9000规则做路由匹配，可靠性更高。
• 配置中注释了option redispatch参数，建议开启该参数，后端节点故障时HAProxy会将失败请求自动转发到正常节点，提升服务可用性。

内容的提问来源于stack exchange，提问作者Вячеслав Чевычелов