健康检查不生效
模式是加权最小连接数，监听80与443，其中80端口是docker镜像，443端口由80rewrite过来的，且都开启健康检查，同时开启了会话保持，过期时间900秒，但早上七点半接到反馈，用户无法访问，经检查后该服务器4点做备份的时候大量读写大致宕机，80，443，22端口都无法连接，这点确定一定以及肯定从4点19分的时候服务器已经完全无法访问了(数据服务器已收不到该服务器任何数据与日志，且该服务器内日志截止到4点19),但是，从7点开始客服人员4G环境下已经无法访问，截止7点30分，最少6名用户反馈也无法访问，7点30移除该服务器，服务恢复正常，当时操作是没注意查看健康检查状态，但奇怪的是，为什么该服务器宕机3小时后健康检查未生效，还会有转发进到该服务器，更奇怪的是另外一台服务器完全没有被访问？附件是配置和监控界面图
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
根据您的描述，这个问题涉及到负载均衡、健康检查、以及服务器宕机后的异常现象。下面我将尝试基于阿里云产品（如SLB负载均衡）的知识来分析可能的原因和解决建议。
健康检查未生效的可能原因：
-
健康检查配置不当：请检查健康检查的设置是否正确。确认健康检查路径、端口、超时时间、间隔时间及不健康阈值是否合理。例如，如果健康检查配置的间隔时间过长，可能无法及时发现服务器的宕机状态。
-
健康检查类型与应用不符：确保健康检查使用的协议（HTTP/HTTPS/TCP）和检查方法（如HTTP 200响应码）与后端服务实际提供的相匹配。如果使用的是HTTP检查，但后端服务因故返回非200状态码或超时，而健康检查配置对此不够敏感，可能导致误判。
-
会话保持影响：您提到开启了会话保持，这意味着一旦用户被分配到某个服务器，后续请求在会话有效期内都会被导向同一服务器。即使该服务器已宕机，由于会话保持机制，部分用户仍可能尝试访问该服务器，直到会话过期。
-
健康检查结果未被正确处理：尽管可能性较小，但理论上存在健康检查系统本身的问题，比如健康检查结果未能及时更新到负载均衡器的路由表中，导致继续向已知不健康的后端发送请求。
另一台服务器未被访问的原因：
-
权重设置问题：如果两台服务器设置了不同的权重，且故障服务器权重较高，在健康检查未完全将其标记为不健康前，大部分流量可能依然被导向它。
-
调度算法特殊情形：加权最小连接数算法通常会将请求分发给当前连接数最少的服务器。如果故障发生瞬间，另一台服务器恰好处于高负载状态，加之健康检查延迟，可能会导致新请求仍然被错误地导向已宕机服务器。
-
网络或路由问题：可能存在网络层面的问题，导致特定时间段内，用户的请求无法到达正常工作的服务器。
解决建议：
- 立即检查并调整健康检查配置：缩短检查间隔、减少不健康阈值，确保能快速识别出故障节点。
- 临时禁用会话保持：在排查期间，可以考虑暂时关闭会话保持功能，以避免用户持续尝试访问已宕机服务器。
- 查看负载均衡日志：通过阿里云控制台查看负载均衡的访问日志和健康检查日志，分析为何健康检查未能及时生效。
- 检查服务器及网络配置：确认是否有网络策略或安全组规则阻止了对正常服务器的访问。
- 监控与报警优化：设置更灵敏的监控指标和即时报警，确保未来能第一时间发现并处理类似问题。
最后，根据实际情况，可能需要联系阿里云技术支持进一步分析日志和配置，以便找到确切原因并采取措施防止再次发生。您也可以通过ECS一键诊断全面排查并修复ECS问题。
