QingCloud 文档 – 常见问题 - kaiyun官方网站下载手机网页

Network: 如何排查负载均衡后端不可用问题？

Mon, 01 Jan 0001 00:00:00 +0000

问题现象

通过控制台看到到后端服务器的状态为不可用，如下图。

排查方法

确认lb和后端云服务器网络相同（属于同一私有网）。
运行命令netstat -an | grep 80查看本地服务是否正常，服务端口是否处于监听状态。
查看云服务器是否绑定安全组，且安全组是否放行相应端口。
通过其他网络相同云服务器测试主机网络和端口是否正常。
若以上排查均无问题依然显示不可用，可提交工单联系技术支持协助排查。

Network: 访问负载均衡器返回502/503/504是什么原因？

Mon, 01 Jan 0001 00:00:00 +0000

错误代码说明

代理服务器常见错误代码：

502（Bad Gateway）：作为代理或网关使用的服务器从请求响应链的下一条链路上收到了一条伪响应。
503（Service Unavailable）：说明服务器现在无法为请求提供服务（暂时不可用），将来可以。
504 （Gateway Time-out）：作为网关或者代理工作的服务器尝试执行请求时，未能及时从上游服务器或者辅助服务器收到响应。

原因分析

访问负载均衡器时返回502/503/504时，说明请求已经到达了负载均衡器，负载均衡器和后端交互时出现了问题。

负载均衡器返回502原因

502状态码错误提示表明负载均衡可以将来自客户端的请求转发到后端服务器，但是由于服务器中 Web 应用处理异常，导致出现该提示，所以排错的方向是针对服务器中 Web 应用的配置以及运行情况进行分析。
负载均衡器返回503原因

503状态码表示后端服务不可用，负载均衡器无法将请求发送到后端服务器，所以排查方向主要针对于负载均衡器和后端服务器之间的网络问题，以及后端服务器是否存活等问题进行分析。
负载均衡器返回504原因

504状态码表示该负载均衡器能够连接后端服务器，但在读取服务器响应的时候超时了。所在排查问题时，应该注意负载均衡器的超时时间、后端服务器服务器负载、网络延迟、后端服务器的进程是否正常等问题。

处理方法

负载均衡问题
1. 检查负载均衡状态，查看是否存在健康检查失败的情况，如果有则需要先排查健康检查失败原因。
2. 负载均衡器开启 rsyslog，通过日志来排查问题。
3. 在七层（HTTP/HTTPS）监听配置中，连接请求超时时间默认值为50秒，若后端云服务器对 PHP 请求的处理时间超过60秒，此时负载均衡器会返回504状态码。
  
  说明
  
  如果无法确定是否是负载均衡器的问题，可以在客户端的hosts文件中，将域名解析至后端服务器的IP地址上进行访问。由此来绕过负载均衡器。来检测访问是否正常。
后端服务器问题

如果5XX状态码间断发生，很可能是某一台后端实例的问题。在客户端的 hosts 文件中，将域名解析至后端服务器的 IP 地址上进行访问，检查是否是某一台后端问题。

如果确定是后端服务器问题，请按照以下步骤进行排查：
1. 检查服务器 CPU，内存，磁盘IO等负载是否正常。此外对于部分服务来说，数据盘的使用空间也会影响到服务是否正常。
2. 结合业务日志排查问题。
3. 检查服务器网络，防火墙是否有开启限制，检查 TCP、UDP连接池是否占满。

Network: 负载均衡器如何支持多证书？

Mon, 01 Jan 0001 00:00:00 +0000

操作场景

本文指导用户通过 HTTPS 和 SSL 监听器绑定多个 SSL 证书，实现同一个监听器根据多个域名自动选择 SSL 证书加密传输访问后端的需求。

前提条件

已创建 HTTPS/SSL 监听器，具体步骤可参考添加 HTTPS 监听器、添加 SSL 监听器。
已创建 SSL 证书并完成验证，具体步骤可参考 SSL 证书购买指南、验证指南。

操作步骤

登录管理控制台，选择产品与服务 > 网络服务 > 负载均衡器，进入负载均衡器页面。
在负载均衡器列表，找到目标实例，点击实例 ID 号，进入实例详情页。
选择监听协议为 HTTPS 或 SSL 的监听器，点击右上角的操作 > 修改。
在弹出的修改监听器属性中点击添加服务器证书，选择证书并添加即可。

说明

可通过多次点击添加服务器证书来添加多个证书。

Network: 开启 HTTP2 不生效怎么办？

Mon, 01 Jan 0001 00:00:00 +0000

问题现象

在 HTTPS 监听器中勾选了 启用HTTP2.0，但通过 curl 命令发现还是使用的 HTTP1.1 协议。

curl -v --http2 https://test.com

***
***
> GET / HTTP/1.1
***

解决办法

查看 curl 返回信息中关于 ALPN 的日志，该日志为 HTTPS 上协商 HTTP 版本的过程。

重启负载均衡器。

部分用户使用的 LB 为较早之前创建的，镜像版本不支持开启 HTTP2.0 ，此时可以重启下 LB，会自动更新到最新的镜像版本，并支持开启 HTTP2.0。
启用 TCP 监听器。

部分用户在后端开启了 HTTP2 ，LB 不支持在 LB 及后端同时开启 HTTP2。此时需要使用 TCP 监听器，端口为后端服务监听的端口。

Network: 如何检查负载均衡器会话保持是否生效？

Mon, 01 Jan 0001 00:00:00 +0000

您可以通过 curl 命令测试会话保持是否生效。

背景信息

负载均衡器支持源 IP 地址、负载均衡器 Cookie 、植入 Cookie 前缀、重写 Cookie 、后端 Cookie 实现会话保持，详见会话保持。

准备工作

在后端云服务器中创建测试页面，测试页面的名称需要一致，分别写入不同的内容，以此区分每个后端。

四层监听测试

说明

四层监听基于源 IP 算法作为负载方式来实现会话保持。

运行以下命令，多次访问测试页面，查看返回结果是否一致，若返回结果一致说明会话保持已生效，反之则说明会话保持无效

 curl http://1.1.1.1/check.html

七层监听测试

说明

如果会话保持默认模式是植入 Cookie ，而 curl 命令默认不保存和发送 Cookie。需要预先保存相应的 Cookie，再进行测试。否则，curl 测试结果将是随机的，影响测试结果的准确性。

访问测试页面，保存 Cookie 值。

curl -D test.cookie http://1.1.1.1/check.html

使用保存的 Cookie 多次访问，查看返回结果。

如果多次访问返回结果一致，说明会话保持已生效，反之则说明会话保持无效
```
curl -b test.cookie http://1.1.1.1/check.html
```

Network: 如何开启HTTP2 ？

Mon, 01 Jan 0001 00:00:00 +0000

背景信息

目前 HTTP2 的使用越来越广泛，相对来说，HTTP2 会比 HTTP1.1 更加地高效。HTTP2 最大的特点是使用多路复用，对同一个域的服务器只建立一次 TCP 连接，加载多个资源，使用二进制帧传输，同时会对 HTTP 头部进行压缩。HTTP2 在实现上基本上只支持 HTTPS 。

开·云app官方版下载支持在负载均衡器上开启 HTTP2，由于负载均衡器节点和后端在一个内网中，速度很快，故后端业务无需支持 HTTP2。

操作步骤

创建或修改 HTTPS 监听器时，点击下方的显示高级选项。
在附加选项中勾选启用HTTP2.0。

Network: 如何排查负载均衡器会话保持不生效问题？

Mon, 01 Jan 0001 00:00:00 +0000

若负载均衡器会话保持不生效，可通过如下步骤进行排查：

查看后端服务器组上是否开启了会话保持。
查看后端云服务器的健康检查状态是否正常，如果异常，流量会切换到其他后端云服务器，导致会话保持失效。
如果选择的是源 IP 算法，需要注意请求到达弹性负载均衡之前 IP 是否发生变化。
如果是 HTTP 或 HTTPS 监听器，配置了会话保持，需要注意发送的请求是否带有 Cookie ，如果带有 Cookie ，则观察该 Cookie 值是否发生了变化（因为七层会话保持基于 Cookie ）。

Network: 如何启用 WebSocket 支持？

Mon, 01 Jan 0001 00:00:00 +0000

负载均衡器详情界面，设置监听器的界面开启Keep-Alive，可以通过 Connection 字段配置 Keep-Alive ，保持 TCP 连接不中断

Network: 负载均衡器支持什么类型的会话保持？

Mon, 01 Jan 0001 00:00:00 +0000

负载均衡器支持基于源 IP 和 cookie 植入的会话保持。详见会话保持说明。

Network: 七层（HTTP/HTTPS）健康检查异常

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍负载均衡器七层健康检查出现异常时的解决方法。

问题现象

负载均衡器上配置了如下图的基于七层方式的健康检查，但是健康检查结果显示为不活跃。

排查方法

七层（HTTP/HTTPS）健康检查是基于第七层的 HTTP 协议进行的，会和业务进行交互，所以首先应该定位问题，主要分为以下几步：

定位健康检查失败问题出现在第七层还是第四层。

点击监听器的操作 > 修改 > 显示高级选项，将健康检查修改为 TCP，观察后端服务器的状态是否为活跃状态：
- 如果仍旧是不活跃状态，则说明健康检查问题出在第四层，请参考四层（TCP/UDP）健康检查出现异常进行解决。
- 如果是活跃状态，则说明是后端服务本身配置有问题。继续进行下一步分析。
登录后端服务器，检查健康检查 URL 是否正常。

登录到后端服务器上使用 curl 命令访问健康检查接口，根据返回的 HTTP 状态码排查问题。

如果返回的 HTTP 状态码为 4xx 或者 5xx，那么 LB 去检查时遇到 4xx 或者 5xx 就会判断为服务不可用，此时则需要根据服务日志来排查后端服务问题。

以下排查方法供您参考：
```
root@web:~# curl http://172.16.6.20/health    #检查命令 curl http://<ip>:<port>/<url>
<html>
<head><title>404 Not Found</title></head>
<body bgcolor="white">
<center><h1>404 Not Found</h1></center>
<hr><center>nginx/1.14.0 (Ubuntu)</center>
</body>
</html>
root@web:~# cat /var/www/html/health  #配置健康检查接口
i am ok
root@web:~# curl http://172.16.6.20/health    #此时本地调用是成功的，控制台也可以看到健康检查成功了
i am ok
```
如果返回的 HTTP 状态码小于400，此时则需要判断是否为健康检查超时所导致的。
检查健康检查 URL 是否存在超时情况。

因为健康检查是有超时时间的，如果超时时间设置过短，也可能引起健康检查失败。

遇到此类情况，可以尝试适当调长超时时，并检查后端服务器的资源使用情况、LB 节点到后端服务器的网络情况，也可以在后端服务器上使用 curl 命令来健康检查接口的检测访问时长。

Network: 如何分析 rsyslog 日志？

Mon, 01 Jan 0001 00:00:00 +0000

针对负载均衡器相关的问题排查，通常会通过配置 rsyslog 来进行分析问题所在，本文详细介绍如何分析 TCP 及 HTTP 转发日志。

更多关于 HAProxy 日志的详细说明，请参见 HAProxy 官网文档。

TCP 转发日志

日志格式示例：

>>> Mar 29 12:16:55 198.19.56.127 \
    haproxy[686]: 111.47.226.115:17652 [29/Mar/2021:10:32:46.135] \
    lbl-l1rmzsj5 lbl-l1rmzsj5_default/lbb-mfc8im36 1/0/6249762 92826 -- 1/1/1/0/0 0/0  
#日志各字段格式如下：
#haproxy[686]:                          #process_name '[' pid ']:'
#111.47.226.115:17652                   #client_ip ':' client_port
#[29/Mar/2021:10:32:46.135]             #'[' accept_date ']'
#lbl-l1rmzsj5                           #frontend_name
#lbl-l1rmzsj5_default/lbb-mfc8im36      #backend_name '/' server_name 
#1/0/6249762                            #Tw '/' Tc '/' Tt*
#92826                                  #bytes_read*
#--                                     #termination_state
#1/1/1/0/0                              #actconn '/' feconn '/' beconn '/' srv_conn '/' retries* 
#0/0                                    #srv_queue '/' backend_queue

字段说明：

字段	说明
client_ip	连接到 haproxy 的客户端的 IP 地址
client_port	发起连接的客户端的 TCP 端口。
accept_date	haproxy 接收到连接的确切时间。
frontend_name	接收及处理客户端请求的监听器，为“负载均衡器监听器 ID”。
backend_name	指定的管理服务器连接的监听器，由“{监听器ID}_default”组成。若未设置切换规则，与 “frontend_name” 相同。
server_name	连接被转发到的最后一个后端，为“后端服务器名称”。
Tw	在各种队列中等待的总时间（毫秒）。如果连接在到达队列之前被中止，它可以是“-1”。
Tc	等待连接建立到最终服务器的总时间（毫秒），包括重试次数。如果在建立连接之前连接被中止，它可以是“-1”。
Tt	在接受和最后一次关闭之间经过的总时间（毫秒）。涵盖了所有可能的处理，但如果指定了“选项logasap”，则在发出日志的时刻计时停止。该情况下，在该值之前加上“+”号，表示最后一个会更大。
bytes_read	发送日志时，从服务器发送到客户端的总字节数。
termination_state	会话结束时会话的条件。这表示在会话状态，哪一方导致了会话结束，以及什么原因。正常标志应为“ - ”，表示会话已由两端关闭，缓冲区中没有剩余数据。
actconn	会话记录时进程上的并发连接总数。
feconn	会话记录时前端上的并发连接总数。
beconn	会话记录时由后端处理的并发连接的总数。
srv_conn	会话记录时服务器上仍然处于活动状态的并发连接总数。
retries	尝试连接到服务器时此会话遇到的连接重试次数。
srv_queue	在服务器队列中之前处理的请求的总数。
backend_queue	在后端的全局队列中之前处理的请求的总数。

HTTP 转发日志

日志格式示例：

>>> Jun 22 13:47:56 198.19.173.227 \
     haproxy[40849]: 42.91.108.84:11918 [22/Jun/2020:13:47:50.784] \
     lbl-2tqyo6fr lbl-2tqyo6fr_default/lbb-jdbamki3 1/0/2/5900/5903 200 518 - - ---- \
     154/150/140/20/0 0/0 {haproxy.1wt.eu} {} "GET /index.html HTTP/1.1"
#日志各字段格式如下：
#haproxy[40849]:                       #process_name '[' pid ']:' 
#42.91.108.84:11918                    #client_ip ':' client_port
#[22/Jun/2020:13:47:50.784]            #'[' request_date ']'
#lbl-2tqyo6fr                          #frontend_name
#lbl-2tqyo6fr_default/lbb-jdbamki3     #backend_name '/' server_name 
#1/0/2/5900/5903                       #TR '/' Tw '/' Tc '/' Tr '/' Ta*
#200                                   #status_code
#518                                   #bytes_read* 
#-                                     #captured_request_cookie
#-                                     #captured_response_cookie
#----                                  #termination_state 
#154/150/140/20/0                      #actconn '/' feconn '/' beconn '/' srv_conn '/' retries*
#0/0                                   #srv_queue '/' backend_queue
#{haproxy.1wt.eu}                      #'{' captured_request_headers* '}'
#{}                                    #'{' captured_response_headers* '}'
#"GET /index.html HTTP/1.1"            #'"' http_request '"'

字段说明：

字段	说明
client_ip	连接到 haproxy 的客户端的 IP 地址
client_port	发起连接的客户端的 TCP 端口。
accept_date	通过 haproxy（log field％tr）接收到 HTTP 请求的第一个字节的确切时间。
frontend_name	接收及处理客户端请求的监听器，为“负载均衡器监听器 ID”。
backend_name	指定的管理服务器连接的监听器，由“{监听器ID}_default”组成。若未设置切换规则，与 “frontend_name” 相同。
server_name	连接被转发到的最后一个后端，为“后端服务器名称”。
TR	在接收到第一个字节后，等待来自客户端（不包括正文）的完整 HTTP 请求花费的总时间（毫秒）。如果接收到完整的请求或接收到错误的请求之前连接被中止，它可以是“-1”。
Tw	各种队列中等待的总时间（毫秒）。如果连接在到达队列之前被中止，它可以是“-1”。
Tc	等待连接建立到最终服务器的总时间（毫秒），包括重试次数。如果在建立连接之前连接被中止，它可以是“-1”。
Tr	从 HTTP 连接后到服务器发给 LB 的第一个报文所用的总时间。Tr 高说明后端慢。如果在接收到报文之前连接被中止，它可以是“-1”。
Ta	请求在 haproxy 中保持活动的时间，这是在接收到的请求的第一个字节和发送的最后一个字节之间经过的总时间（以毫秒为单位）。
status_code	返回给客户端的 HTTP 状态代码。这种状态通常由服务器设置，但是当服务器无法到达或其响应被 haproxy 阻止时也可以通过 haproxy 设置。
bytes_read	发送日志时，从服务器发送到客户端的总字节数。
captured_request_cookie	一个可选的“name = value”条目，指示客户端在请求中具有此cookie。 cookie 名称及其最大长度由前端配置中的“capture cookie”语句定义。当该选项未设置时，该字段是单个破折号（’ - ‘）。
termination_state	会话结束时会话的条件。这表示会话状态，哪一方导致会话结，以及什么原因（超时，错误，…）。
actconn	会话记录时进程上的并发连接总数。
feconn	会话记录时前端上的并发连接总数。
beconn	会话记录时由后端处理的并发连接的总数。
srv_conn	会话记录时服务器上仍然处于活动状态的并发连接总数。
retries	尝试连接到服务器时此会话遇到的连接重试次数。
srv_queue	在服务器队列中之前处理的请求的总数。
backend_queue	在后端的全局队列中之前处理的请求的总数。
captured_request_headers	由于在前端存在“捕获请求头”语句，在请求中捕获的标题列表。
captured_response_headers	由于在前端存在“捕获响应头”语句，在响应中捕获的标题列表。
http_request	完整的 HTTP 请求行，包括方法，请求和 HTTP 版本字符串。

Network: 如何获取来访者的真实 IP？

Mon, 01 Jan 0001 00:00:00 +0000

方法一

在负载均衡器的监听器页面，点击操作>修改，修改监听器设置，设置通过 HTTP 的头字段为 X-Forwarded-For 获取客户端的真实 IP，如下图。

该功能未开启时，通过 access.log 查看到客户端的 IP 地址实际上是负载均衡器节点 IP ，一般为198.19.x.x。
该功能开启后，通过访问 access.log 查看的日志如下。

方法二

通过开启透明代理（可能会导致内网请求失败），请在只提供公网服务（绑定了公网 IP）时开启，一般用于 TCP 协议的监听器。建议使用 tcpdump 命令抓包来获取真实 IP。

Network: 如何开启长连接？

Mon, 01 Jan 0001 00:00:00 +0000

HTTP 监听开启长连接

如图，在 HTTP 监听器设置中，勾选上 keep-alive 即可。

TCP 监听开启长连接

TCP 监听默认开启长连接。

负载方式推荐使用最少连接：优先将请求发给拥有最少连接数的后端服务器，常用于长连接服务，例如数据库连接等服务。

Network: 使用 UDP 协议健康检查有什么注意事项？

Mon, 01 Jan 0001 00:00:00 +0000

UDP 方式会结合 ICMP Echo Request 和 UDP port probe 两种方式来检查，需注意：

对于监听器为 UDP 端口组，且健康检查为 UDP 时，健康检查只会检测端口组的第一个端口。
需保证后端能够正确响应 ICMP Echo Request（即返回 ICMP Echo Reply包，ICMP code: 0/0），并且能返回 ICMP Destination Port Unreachable 包，ICMP code: 3/3）。如果后端有加载安全组或者有其安全组策略，要保证其上行中相应的策略是放行的。

Network: 四层（TCP/UDP）健康检查出现异常

Mon, 01 Jan 0001 00:00:00 +0000

本文介绍负载均衡器四层健康检查出现异常的解决方法。

问题现象

负载均衡器上配置了如下图的基于四层方式的健康检查，但是健康检查结果显示为不活跃。

原因分析

TCP 和 UDP 的健康检查是基于第四层协议进行的，所以只会探测到端口是否存活，并不会去检测业务是否正常。所以一般来说如果四层健康检查失败，可能有以下原因：

后端服务器和负载均衡器之间的网络不通。
后端服务器上的端口并没有存活。

排查方法

检查负载均衡器上所配置的后端服务器的端口是否存活。

在后端服务器上执行两个命令：

telnet <$ip> <port>  #此命令用来探测这台机器的80端口是否能够正常连接

如果上述命令执行失败的话，就需要检查后端业务是否正常运行，或者后端服务器监听的端口和负载均衡器上所配置的端口是否一致。

以下排查过程可供您参考（以 nginx 为例）。

root@web:~# systemctl status  nginx.service  #查看nginx状态是否正常
● nginx.service - A high performance web server and a reverse proxy server
   Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since Sun 2021-05-30 14:19:48 CST; 43s ago
root@web:~# systemctl start   nginx.service #启动nginx状态是否正常
root@web:~# ss -nutlp |grep 80        #检查80端口是否正常
root@web:~# ss -nutlp |grep nginx     #检查nginx所启动的端口
tcp    LISTEN   0        128               0.0.0.0:81             0.0.0.0:*      users:(("nginx",pid=24741,fd=6),("nginx",pid=24739,fd=6))                      
tcp    LISTEN   0        128                  [::]:81                [::]:*      users:(("nginx",pid=24741,fd=7),("nginx",pid=24739,fd=7))                      
root@web:~# vim  /etc/nginx/sites-enabled/default  #修改nginx端口，此处也可将负载均衡器配置的端口修改为81
root@web:~# systemctl restart   nginx.service    #重启nginx                 
root@web:~# telnet  172.16.6.20 80 #测试端口连通性
Trying 172.16.6.20...
Connected to 172.16.6.20.
Escape character is '^]'.   #出现此符号证明连接正常。
^CConnection closed by foreign host.
root@web:~#

检查后端服务器和负载均衡器之间的网络连通性。

在负载均衡器的详情页网络区域，找到内网IP，检查安全组中是否有放行这些 IP。

登录后端服务器检查 iptables 是否有对这些 IP 做限制。如果有则删除对应限制。

root@web:~# ping 172.16.6.4 #可以看到此时ping slb的节点ip是不能通的。
PING 172.16.6.4 (172.16.6.4) 56(84) bytes of data.
^C
--- 172.16.6.4 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1011ms
root@web:~# iptables -nL --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DROP       all  --  172.16.6.0/24        0.0.0.0/0           
2    DROP       all  --  192.19.0.0/16        0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         
root@web:~# iptables -t filter -D INPUT 1
root@web:~# iptables -t filter -D INPUT 1
root@web:~# iptables -nL --line-number
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination  
root@web:~# ping 172.16.6.4   #可以看到此时ping slb的节点ip已经能通了
PING 172.16.6.4 (172.16.6.4) 56(84) bytes of data.
64 bytes from 172.16.6.4: icmp_seq=1 ttl=63 time=1.49 ms
64 bytes from 172.16.6.4: icmp_seq=2 ttl=63 time=1.49 ms

Network: 业务日志中出现“Connection reset by peer”的错误

Mon, 01 Jan 0001 00:00:00 +0000

问题现象

负载均衡后端配置 TCP 服务端口后，后端业务日志中频繁出现类似如下网络连接异常的错误信息。首先可以通过抓包分析这条日志产生是否是负载均衡器的锁发出的请求导致，如果不是则需要检查其他地方配置是否有问题。本文主要分析由负载均衡器产生的问题。

问题原因

该问题和负载均衡的健康检查机制有关。由于 TCP 对上层业务状态无感知，同时，为降低负载均衡健康检查成本和对后端业务的冲击，负载均衡针对 TCP 协议服务端口的健康检查只会做简单的 TCP 三次握手，而后直接发送 RST 包断开 TCP 连接。

简单的来说，四层健康检查，会对后端服务器发起一次请求，后端服务器的服务端口只要应答了负载均衡器则认为此次检查是成功的，就会主动关闭连接，并未进行业务层面上的数据交互，从而导致上层业务（例如 Java 连接池等）认为相应的连接是异常的。

解决方法

对于以上情况主要有两种解决方法。

方法1：更换 TCP 协议为 HTTP 协议。

此方案是将健康检查更换七层健康检查，会进行业务层面的数据交互，所以也需要后端服务提供相应的接口去供 LB 进行健康检查。
方法2：在业务层面，对来自 LB 服务器 IP 地址段的相关请求做日志过滤，忽略相关错误信息。

此方案仍旧是基于第四层的健康检查，因为业务日志中出现此报错就已经代表四层健康检查成功了，所这个报错本身就可以忽略。

Network: 长连接和会话保持有什么关系？

Mon, 01 Jan 0001 00:00:00 +0000

长连接和会话保持没有必然联系。长连接是指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包。会话保持是指弹性负载均衡将属于同一个会话的请求都转发到同一个服务器进行处理。

QingCloud 文档 – 常见问题 - kaiyun官方网站下载手机网页

Network: 如何排查负载均衡后端不可用问题？

问题现象

排查方法

Network: 访问负载均衡器返回502/503/504是什么原因？

错误代码说明

原因分析

处理方法

Network: 负载均衡器如何支持多证书？

操作场景

前提条件

操作步骤

Network: 开启 HTTP2 不生效怎么办？

问题现象

解决办法

Network: 如何检查负载均衡器会话保持是否生效？

背景信息

准备工作

四层监听测试

七层监听测试

相关问题

Network: 如何开启HTTP2 ？

背景信息

操作步骤

Network: 如何排查负载均衡器会话保持不生效问题？

Network: 如何启用 WebSocket 支持？

Network: 负载均衡器支持什么类型的会话保持？

Network: 七层（HTTP/HTTPS）健康检查异常

问题现象

排查方法

Network: 如何分析 rsyslog 日志？

TCP 转发日志

HTTP 转发日志

Network: 如何获取来访者的真实 IP？

方法一

方法二

Network: 如何开启长连接？

HTTP 监听开启长连接

TCP 监听开启长连接

Network: 使用 UDP 协议健康检查有什么注意事项？

Network: 四层（TCP/UDP）健康检查出现异常

问题现象

原因分析

排查方法

Network: 业务日志中出现“Connection reset by peer”的错误

问题现象

问题原因

解决方法

Network: 长连接和会话保持有什么关系？