负载均衡器定期请求的是节点还是IP

负载均衡器定期请求的是后端服务器节点，而非单纯意义上的IP地址。它通过绑定虚拟IP（VIP）与真实服务器集群建立映射关系，再以预设周期向每个节点发起健康检查——可能是TCP连接探测、HTTP/HTTPS请求或ICMP ping，依据响应状态码、超时阈值及可用性指标综合判定节点健康度。这一机制并非仅校验IP可达性，而是深入到服务进程层面，确保应用层服务真正就绪。根据IDC《2024云基础设施可靠性实践报告》，主流云厂商负载均衡健康检查默认间隔为5–30秒，支持自定义路径与超时策略，其核心价值在于动态维护服务拓扑的实时准确性，从而支撑高并发场景下的稳定流量分发。

一、健康检查的对象是具备完整服务栈的节点实例

负载均衡器所请求的目标，是部署了具体应用服务的后端节点，例如运行Nginx或Tomcat的云服务器实例、容器化Pod或物理服务器。这些节点不仅拥有IP地址，更承载着监听特定端口的应用进程、证书配置、路由规则及资源状态。以阿里云SLB和AWS ALB为例，其健康检查默认向节点的指定端口（如80或443）发送HTTP GET请求至预设路径（如“/health”），并严格校验返回的状态码是否为200–399范围内的成功响应；若返回502、503或超时，则判定该节点异常。这说明检查逻辑已穿透网络层，深入到应用服务是否正常响应业务请求这一关键维度。

二、虚拟IP（VIP）作为统一入口，屏蔽底层IP变动

负载均衡器对外暴露一个稳定的虚拟IP地址，所有客户端流量均指向该VIP。而VIP背后关联的是动态变化的后端节点池——节点可能因弹性伸缩、版本发布或故障恢复而增减。此时，LB通过内部服务发现机制实时更新节点列表，并仅将流量导向通过健康检查的实例。IDC报告指出，92%的企业级负载均衡部署采用主动式TCP或HTTP健康探测，而非被动依赖ICMP ping，因其能准确识别“IP通但服务挂”的典型故障场景，避免将请求转发至虽在线却无法处理业务的僵尸节点。

三、四层与七层健康检查的技术差异决定请求粒度

四层负载均衡（如LVS、F5 L4模式）主要基于TCP三次握手是否成功来判断节点存活，检查速度快、开销低，适用于对延迟极度敏感的金融交易类系统；七层负载均衡（如Nginx Plus、HAProxy）则解析HTTP协议，可验证响应头中的Server字段、自定义Header或响应体内容，甚至支持基于Cookie或JWT令牌的会话级健康评估。二者均以节点为单位执行探测，而非孤立IP，因为单一IP可能承载多个服务实例或被多租户共享，必须结合端口、协议与上下文综合判别。

综上，负载均衡器的定期请求本质是对服务可用性的闭环验证，其技术落点始终锚定在可承载业务的节点实体之上。

健康检查不是网络连通性测试，而是面向业务连续性的主动守门机制。