Blog

如何排查500以上错误

How to Find 500 Errors

Posted by BY on October 12, 2020

前言

持续更新了

正文

问题来源

被人问到关于排查500的问题。

前言

在HTTP 协议中， 500 Internal Server Error 是表示服务器端错误的响应状态码，意味着所请求的服务器遇到意外的情况并阻止其执行请求。 这个错误代码是一个通用的“万能”响应代码。 有时候，对于类似于500 这样的错误，服务器管理员会更加详细地记录相关的请求信息来防止以后同样错误的出现。

可能原因以及解决方案

  1. 源站域名没有备案或者域名没有在高防或者安全网络中配置七层转发规则。

    解决方案：请将域名备案。如果负载均衡在高防或者安全网络中，请配置对应的域名规则。

  2. 客户端源IP地址被云盾拦截。

    测试其他ISP运营商的客户端是否有相同问题，如果仅仅是某个固定运营商网络的客户端访问有问题，一般是运营商封堵导致。

    解决方案：通过提交工单反馈给阿里云售后技术支持，抓包确认是否有封堵行为。如果有，请联系运营商解决该问题。

  3. 后端ECS安全防护软件阻挡。

    100.64.0.0/10（100.64.0.0/10 是阿里云保留地址，其他用户无法分配到该网段内，不会存在安全风险）是负载均衡服务器IP段，主要用于健康检查和转发请求。例如安装安全软件或者开启系统内部防火墙，可以将此IP加入白名单，避免出现500或502错误。

    解决方案：配置杀毒、防火墙软件白名单，或者卸载此类软件快速测试。

  4. 后端ECS Linux内核参数配置错误。

    对于后端ECS为Linux系统，改成TCP模式时需要注意关闭系统内核参数中rp_filter相关设置。

    解决方案：将系统配置文件/etc/sysctl.conf的以下三个配置的值设为0，然后执行sysctl -p。

     net.ipv4.conf.default.rp_filter = 0
 net.ipv4.conf.all.rp_filter = 0
 net.ipv4.conf.eth0.rp_filter = 0

  5. 后端ECS性能瓶颈。

    例如CPU高，外网带宽跑满均可能导致访问异常。

    解决方案：检查后端ECS性能，解决性能瓶颈问题，如果是整体系统容量不够，可以通过扩容后端ECS 的数量消除问题。

  6. 健康检查失败导致负载均衡出现502错误 。

    健康检查失败，请参见健康检查异常排查进行排查。

    此外，未开启负载均衡的健康检查，同时服务器中Web服务无法正常处理HTTP请求，比如Web服务未运行，也会出现502错误。

  7. 健康检查正常但Web应用报502错误 。

    502 Bad Gateway错误提示表明负载均衡可以将来自客户端的请求转发到后端服务器中，但是服务器中Web应用处理异常抛出该提示，所以排错的方向是针对服务器中Web应用的配置以及运行情况进行分析。例如Web应用处理HTTP请求的时间超过了负载均衡的timeout时间。

    在七层HTTP模式下，后端对PHP请求的处理时间超过proxy_read_timeout设置的60秒，此时会出现负载均衡抛出的504 Gateway Time-out。对于四层监听，超时时间为900秒。

    解决方案：确保Web服务以及依赖正常运行，检查PHP请求处理情况，优化后端PHP请求处理。下面以Nginx+php-fpm为例进行分析说明：

    1. 处理PHP请求的进程数达到上限。

      当前服务器中PHP请求总数已经达到了php-fpm中max_children设置的上限，如果后续有新的PHP请求到达服务器中，这种情况下通常502与504的错误码会随机出现：

      • 如果已有的请求被处理完成，新请求被继续处理，一切正常。
      • 如果已有的PHP请求处理较慢，新的PHP一直处于等待状态，直至超过Nginx的fastcgi_read_timeout的值，就会出现504 Gateway timeout的错误。
      • 如果已有的PHP请求处理较慢，新的PHP处于等待状态，超过了Nginx的request_terminate_timeout的值，就会出现502 Bad Gateway的错误。

    2. PHP脚本执行时间处理超时，即如果php-fpm处理PHP脚本的时长超过了Nginx中request_terminate_timeout设置的值，就会出现502 Bad Gateway的错误，同时在Nginx日志中可以查看到如下错误记录：

      [error] 1760#0: *251777 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: localhost, request: “GET /timeoutmore.php HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”

    3. 健康检查针对的是静态页面，实际处理动态请求的进程异常，比如php-fpm未启动运行。

  8. HTTP头部过大。

    Head头信息过大可能导致负载均衡无法正确处理相关数据，进而引发502错误。

    解决方案：减少通过Head头传递的数据量或者换成TCP监听。

  9. 业务访问逻辑问题。

    确保不存在负载均衡后端ECS实例在服务器内部通过负载均衡公网IP地址访问SLB的情况。该情况下，后端业务服务器通过负载均衡地址访问自身所监控的端口后，根据负载均衡调度策略的不同，可能会将相应的请求调度到自身服务器上。导致出现自己访问自己的情况，造成死循环，进而导致相应的请求出现500或502错误。

    解决方案：确保负载均衡场景应用正确，避免后端ECS服务器需要访问负载均衡公网IP地址的情况。

排查步骤

  • 检查500/502/504错误截图，判断是负载均衡问题，高防/安全网络配置问题，还是后端ECS配置问题。
  • 如果有高防/安全网络，请确认高防/安全网络的七层转发配置正确。
  • 请确认是所有客户端都有问题，还仅仅是部分客户端有问题。如果仅仅是部分客户端问题，排查该客户端是否被云盾阻挡，或者负载均衡域名或者IP是否被ISP运营商拦截。
  • 检查负载均衡状态，是否有后端ECS健康检查失败的情况，如果有健康检查失败，解决健康检查失败问题。
  • 在客户端用hosts文件将负载均衡的服务地址绑定到后端服务器的IP地址上，确认是否是后端问题。如果5XX错误间断发生，很可能是后端某一台ECS服务器的配置问题。
  • 尝试将七层负载均衡切换为四层负载均衡，查看问题是否会复现。
  • 检查后端ECS服务器是否存在CPU、内存、磁盘或网络等性能瓶颈。
  • 如果确认是后端服务器问题，请检查后端ECS Web服务器日志是否有相关错误，Web服务是否正常运行，确认Web访问逻辑是否有问题，卸载服务器上杀毒软件重启测试。
  • 检查后端ECS Linux操作系统的TCP内核参数是否配置正确。

总结：

我这个只是做一个记录,原地址是在如何排查500/502/504错误

结语

不管怎么样好好加油。

CATALOG
    FEATURED TAGS
    Blog