网络型负载均衡NLB通过健康检查来判断后端服务器业务的可用性。开启健康检查功能后，当某台后端服务器健康检查出现异常时，负载均衡会自动将新的请求分发到其他健康检查正常的后端服务器上。当该后端服务器恢复正常运行时，负载均衡会自动将其重新纳入服务并进行流量转发。健康检查机制是保证业务高可用的关键要素之一。它提高了用户业务的整体可用性，避免了局部后端服务器异常对整体服务造成的影响。
NLB健康检查过程
网络型负载均衡NLB采用集群部署。集群内相关节点服务器同时承载了数据转发和健康检查职责。
集群内不同服务器分别独立、并行地根据负载均衡策略进行数据转发和健康检查操作。如果NLB对某一台后端服务器健康检查失败，
且服务器组未开启连接优雅中断，异常的后端服务器会处理完存量的连接会话后，关闭连接。此时，新的客户端请求不会分发给该异常后端服务器。
且服务器组开启连接优雅中断，异常的后端服务器会继续处理存量的连接会话，直到到达优雅中断超时时间时，关闭连接。此时，新的客户端请求不会分发给该异常后端服务器。
网络型负载均衡NLB健康检查使用的地址段是NLB的Local IP，后端服务器务必不能屏蔽该地址段。您无需在ECS安全组中额外针对该地址段配置放行策略，但如果有配置iptables等安全策略，请注意放行。
工作原理
TCP健康检查
针对TCP健康检查，为了提高健康检查效率，健康检查通过定制的TCP探测来获取状态信息，健康检查原理如下图所示。
TCP监听的检查机制如下：
NLB实例根据监听的健康检查配置，向后端服务器的内网IP+【健康检查端口】发送TCP SYN数据包。
后端服务器收到请求后，如果相应端口正在正常监听，则会返回SYN+ACK数据包。
如果在【响应超时时间】之内，NLB实例没有收到后端服务器返回的SYN+ACK数据包，则认为服务无响应，判定健康检查失败，并向后端服务器发送RST数据包中断TCP连接。
如果在【响应超时时间】之内，NLB实例成功收到后端服务器返回的SYN+ACK数据包，则认为服务正常运行，判定健康检查成功，并进一步发送ACK数据包，随后立即发送RST数据包中断TCP连接。
正常的TCP三次握手，NLB实例在收到后端服务器返回的SYN+ACK数据包后，会进一步发送ACK数据包，随后立即发送RST数据包中断TCP连接。 该实现机制可能会导致后端服务器认为相关TCP连接出现异常（非正常退出），并在业务软件如Java连接池等日志中抛出相应的错误信息，如Connection reset by peer。
解决方案：
TCP监听采用HTTP方式进行健康检查。
在后端服务器配置了获取客户端真实IP后，忽略来自前述负载均衡服务地址段相关访问导致的连接错误。
UDP健康检查
您可以通过以下两种方式进行UDP健康检查：
方式一：端口健康检查
健康检查原理如下图所示：
UDP监听端口健康检查机制如下：
NLB实例根据监听的健康检查配置，向后端服务器的内网IP地址发送ICMP Request报文。
NLB实例根据监听的健康检查配置，向后端服务器的内网IP+【健康检查端口】发送UDP探测报文。
如果在【响应超时时间】之内，后端服务器返回ICMP Response报文，且没有返回
Port XX Unreachable报错信息，则判定健康检查成功。否则判定健康检查失败。
方式二：自定义健康检查
健康检查原理如下图所示：
UDP监听自定义健康检查的机制如下：
NLB实例根据用户指定的字符，向后端服务器的内网IP+【健康检查端口】发送UDP探测报文。
如果在【响应超时时间】之内，NLB实例收到后端服务器返回的与预期一致的信息，则判定健康检查成功；否则，判定健康检查失败。
HTTP健康检查
对于四层（TCP或者UDP）后端协议，您可以配置HTTP健康检查，健康检查通过HEAD或GET请求来获取状态信息。健康检查原理如下图所示：
HTTP健康检查机制如下：
NLB实例根据监听的健康检查配置，向后端服务器的内网IP+【健康检查端口】+【检查路径】发送HTTP HEAD或GET请求（包含设置的【域名】）。
后端服务器收到HTTP请求后，根据相应服务的运行情况，返回HTTP状态码。
如果在【响应超时时间】之内，NLB实例没有收到后端服务器返回的信息，则认为服务无响应，判定健康检查失败。
如果在【响应超时时间】之内，NLB实例成功接收到后端服务器返回的信息，则将该返回信息与配置的状态码进行比对。如果匹配则判定健康检查成功，反之则判定健康检查失败。
应用场景
TCP健康检查场景
文件上传下载服务（FTP）：通过TCP健康检查可以验证FTP服务是否可以正常接收和响应连接请求，确保文件传输的稳定性和可靠性。
发送和接收邮件服务：在发送和接收邮件的场景中，通过TCP健康检查监测邮件服务器的状态，确保邮件传输的可靠性。
金融交易服务：在金融交易系统中，交易服务器的可靠性至关重要，TCP健康检查能够及时发现故障系统，避免交易中断。
远程登录：通过TCP健康检查来验证远程登录服务的状态和性能，确保用户能够安全、稳定地连接到远程服务器。
UDP健康检查场景
传统业务场景
DNS域名系统业务：通过UDP进行快速健康检查，确保DNS服务器运行正常、响应及时。
VoIP（语音通信）业务：例如，Skype或VoIP电话系统，UDP健康检查通过发送小的数据包评估网络延迟、丢包率和抖动等关键性能指标，从而保障通话质量。
在线游戏业务：通过UDP健康检查监测游戏服务器响应时间和可用性，保证玩家顺畅连接和游戏体验。
流媒体业务：流媒体服务，如视频会议和实时视频流，通过UDP健康检查评估视频流可用性和质量，确保快速响应和稳定播放体验。
即时通讯业务：通过UDP健康检查可以实时监测网络连接的稳定性和延迟情况，以确保消息能够迅速且可靠地传输，从而提升用户体验。
新兴行业业务场景
互联网行业QUIC改造：QUIC场景下通过UDP健康检查，可以快速检测网络连接状态，确保高效稳定的实时数据传输。
物联网（IoT）业务：通过UDP进行健康检查可以快速验证传感器设备的状态，确保低延迟和高效能，以适应对功耗和成本敏感的场景。
车联网（V2X）业务：在车辆与基础设施之间通过UDP协议进行健康检查，以实现实时数据交换和快速响应，从而确保通信的稳定性和可靠性。
虚拟现实（VR）和增强现实（AR）业务：通过UDP进行健康检查，以确保快速传输视觉和交互数据，从而实现流畅的用户体验。
云游戏业务：通过UDP健康检查，云游戏服务实时监测网络状态，以确保低延迟和流畅的游戏体验。
HTTP健康检查场景
Web服务的健康检查：如果您的后端服务运行HTTP或HTTPS协议的Web服务，您可以通过HTTP监听健康检查来获取服务器的状态信息。通过发送HTTP请求（通常是GET或HEAD请求）到服务器上的特定路径（如
/health），可以确定服务器是否能够处理HTTP请求。应用程序自定义健康检查：某些应用程序可能需要自定义健康检查逻辑。例如，检查数据库连接池、缓存状态等，通过HTTP健康检查接口可以灵活地实现这些自定义检查。
微服务架构：在微服务架构中，各个微服务可能使用HTTP接口进行通信。您可以利用HTTP健康检查来检测微服务实例应用层的问题，根据响应内容，可以提供更详细的诊断信息。
API网关和反向代理：如果后端服务器是API网关或反向代理服务器（如Nginx、HAProxy），这些组件通常都有HTTP接口，可以通过HTTP健康检查来监控这些服务器的健康状况。
HTTP健康检查中域名的设置
当使用HTTP方式进行健康检查时，可以设置健康检查的域名，但并非强制选项。因为有些应用服务器会对请求中的host字段做校验，即要求请求头中必须存在host字段。如果在健康检查中配置了域名，则NLB会将域名配置到host字段中，反之，如果没有配置域名，NLB则不会在请求中附带host字段，因此健康检查请求就会被服务器拒绝，可能导致健康检查失败。
综上原因，如果您的应用服务器需要校验请求的host字段，那么就需要配置相关的域名，确保健康检查正常工作。
相关文档
健康检查如何配置，请参见创建和管理服务器组。
健康检查异常的排查方法，请参见NLB健康检查异常排查方法。