6步排查负载均衡部署后的访问异常

负载均衡部署完成后，访问异常可能只发生在某个域名、某类请求或某台后端服务器上。直接重启设备往往会掩盖线索，正确做法是从客户端到应用节点逐层缩小范围。下面按六步排查，适用于云负载均衡、硬件设备和自建代理集群等常见场景。

第一步：确认域名和入口地址是否正确

先从客户端检查域名解析结果。使用 dig 或 nslookup 查看 A 记录、AAAA 记录和 CNAME 是否指向预期入口；如果同时存在 IPv4 与 IPv6 记录，还要分别验证两条链路。部分用户能访问、部分用户超时，可能与不同运营商缓存或 IPv6 路径有关。

记录客户端实际解析到的地址，以及解析发生的时间。
直接访问负载均衡入口的 IP 和端口，区分域名问题与服务问题。
检查 DNS TTL。刚修改记录时，旧结果可能在递归解析器中保留一段时间。

如果入口地址本身不可达，先检查安全组、防火墙、路由和公网监听范围，不要急着修改后端应用。

第二步：核对监听器与端口配置

访问异常经常来自“服务已启动，但监听器没接住请求”。核对前端协议、端口、后端协议和转发端口是否一致。例如客户端访问 HTTPS 443 端口，负载均衡可能在入口处完成 TLS 终止，再以 HTTP 方式转发到应用端口；也可能要求后端继续使用 HTTPS，二者不能混淆。

确认监听器处于启用状态，并绑定了正确的地址。
核对端口映射、转发规则、默认动作和路径匹配顺序。
检查证书是否覆盖实际访问的域名，过期、链不完整或算法不兼容都可能导致握手失败。

可使用浏览器开发者工具或 curl 查看实际状态码。连接拒绝通常指向监听或网络层，4xx 多与规则、权限或请求条件有关，5xx 则需要继续检查后端。

第三步：验证健康检查是否真的代表业务可用

健康检查是负载均衡判断节点能否接流量的依据，但检查一个静态页面并不能证明登录、下单或文件上传等业务正常。检查路径、端口、超时时间、预期状态码和返回内容都要核对。

在每台后端节点本机访问健康检查地址，确认应用确实返回预期结果。
从负载均衡所在网络发起同样请求，排除安全策略或路由差异。
检查失败阈值和恢复阈值。阈值过低可能造成节点频繁摘除，过高则会延迟隔离故障节点。
让检查接口只依赖必要组件，避免因报表、缓存或第三方服务短暂异常而误判整台节点。

健康状态应与真实流量需求匹配：静态站点可检查页面响应，交易接口则至少应验证应用进程、关键配置和必要依赖是否可用。

第四步：从入口逐段测试转发链路

将问题拆成三段：客户端到入口、入口到后端、后端到依赖服务。分别测试，比反复刷新页面更容易发现故障位置。

建议的定位顺序

从客户端访问入口，记录 DNS、建立连接、TLS 握手和首字节等待时间。
在负载均衡所在网络访问单台后端，比较各节点的状态码和响应耗时。
在后端节点检查应用日志、进程监听和到依赖服务的连接，确认是否存在连接池耗尽、线程不足或上游超时。

若只有一台节点异常，可先将其设为维护或降低权重，再观察整体访问是否恢复。若所有节点同时超时，应优先检查入口策略、网络路径和共享依赖，而不是逐台重装应用。

第五步：排查会话、协议和请求特征

登录后跳回登录页、同一用户请求结果不一致，常见原因是会话没有正确共享。需要确认应用使用的 Cookie 域、Secure 与 SameSite 属性、会话存储位置，以及是否必须启用会话保持。会话保持能缓解旧系统兼容问题，但会降低流量分布均衡度；如果应用已使用共享会话存储，通常应优先保持无状态转发。

同时检查请求头是否被改写，例如 Host、X-Forwarded-For 和 X-Forwarded-Proto。应用若误以为请求始终来自 HTTP，可能不断重定向到 HTTPS。对于长连接、分块响应或大文件上传，还要核对空闲超时、请求体大小和缓冲设置，这些参数往往与普通页面请求不同。

第六步：结合日志、指标和最小变更验证

最后把同一请求的时间、来源地址、入口日志、后端访问日志和应用错误日志串起来。重点关注 4xx、5xx、连接失败、超时、重试次数和各节点请求量是否失衡。若设备提供请求 ID，应让入口和应用共同记录，便于关联一条完整链路。

固定一个可复现请求，记录域名、路径、时间和返回状态。
一次只调整一个变量，例如摘除单节点、修正超时或恢复一条转发规则。
观察至少覆盖多个健康检查周期，并比较异常是否随变更消失。
确认恢复后再扩大流量，最后补充变更记录和回滚条件。

排查完成后，应把最终配置与监控阈值固化下来。这样下一次负载均衡部署或扩容时，可以用相同清单快速验证，而不是依赖个人经验。

常见问题

为什么后端节点健康，但用户仍然打不开？

健康检查可能只验证了后端静态响应，入口的 DNS、证书、监听端口、防火墙或转发规则仍可能存在问题，应先分段测试。

为什么只有部分用户访问异常？

重点检查 DNS 缓存、IPv4 与 IPv6 路径、地域策略、会话保持以及不同节点返回结果是否一致。

是否应该一直开启会话保持？

不一定。旧系统或本地会话较多时，会话保持有帮助；具备共享会话存储的应用通常更适合无状态转发，以获得更均衡的流量分布。

修改超时参数能解决所有慢请求吗？

不能。超时可能来自网络、连接池、线程、数据库或第三方依赖。应先通过入口和应用日志定位具体等待环节，再调整参数。

按入口、监听、健康检查、链路、会话协议和日志指标六步推进，通常能把模糊的访问异常转化为可验证的问题。完成负载均衡部署后，保留这份检查顺序和回滚方案，后续扩容、改证书或调整规则时也能减少误操作。