HAProxy随机HTTP 503错误

我们已经设置了3台服务器：

• 使用Nginx+HAproxy执行负载平衡的服务器A
• 后端服务器B
• 后端服务器C

这是我们的

/etc/haproxy/haproxy.cfg

：

global
        log /dev/log   local0
        log 127.0.0.1   local1 notice
        maxconn 40096
        user haproxy
        group haproxy
        daemon

defaults
        log     global
        mode    http
        option  httplog
        option  dontlognull
        retries 3
        option redispatch
        maxconn 2000
        contimeout      50000
        clitimeout      50000
        srvtimeout      50000
                stats enable
                stats uri /lb?stats
                stats realm Haproxy\ Statistics
                stats auth admin:admin
listen statslb :5054 # choose different names for the 2 nodes
        mode http
        stats enable
        stats hide-version
        stats realm Haproxy\ Statistics
        stats uri /
        stats auth admin:admin

listen  Server-A 0.0.0.0:80    
        mode http
        balance roundrobin
        cookie JSESSIONID prefix
        option httpchk HEAD /check.txt HTTP/1.0
        server  Server-B <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 2
        server  Server-C <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 3

---

请注意，90%的时间没有错误。这些错误是随机发生的。

如果没有更多详细信息，很难说，但是您是否有可能超过每个后端配置的maxconn？Stats UI在前端和各个后端上显示这些统计信息。

您的服务器可能共享一个公共资源，该资源在某些时间超时，并且您的健康检查请求在同一时间发出（从而在同一时间拉出后端服务器）

---

您可以尝试使用HAProxy选项

扩展检查

来随机进行健康检查。

我也有同样的问题。经过几天的努力，我发现了这个问题

我运行了两个HAProxy实例。一个是一个僵尸，在更新或haproxy重启过程中不知何故从未被杀死。我在刷新/haproxy stats页面时注意到了这一点，PID会在两个不同的数字之间变化。包含其中一个数字的页面具有荒谬的连接统计信息。确认一下

netstat -tulpn | grep 80

或

看到两个haproxy进程监听端口80

---

为了解决这个问题，我做了一个“kill xxxx”，其中xxxx是带有可疑统计信息的pid。

我也遇到了同样的问题，因为linux机箱中运行了两个HAProxy服务，但名称/pid/资源不同。除非我停止不需要的错误，否则必需的实例会随机抛出503个错误，比如说5次抛出1个错误

---

试图使用单个linux框进行多URL路由，但在haproxy或我定义的haproxy配置文件中似乎存在限制。

为遇到相同问题但上面列出的解决方案均不适用的其他人在此处添加我的答案。请注意，我的回答不适用于上面列出的原始代码

---

对于可能有此问题的其他人，请检查您的配置，并查看是否在配置的多个部分中错误地放置了相同的“绑定”行。Haproxy在启动期间不检查这个，我计划将它作为推荐的验证检查提交给开发人员。在我的例子中，我有3个不同的配置部分，我错误地将相同的IP绑定放在了两个不同的地方。关于是否使用了正确的部分或使用了不正确的部分，大约是50/50。即使使用了正确的部分，大约一半的请求仍然得到503。

我通过在后端添加

选项http server close

解决了HAProxy的间歇性503问题。看起来uWSGI（位于上游）在keep alive方面做得不好。不确定问题的真正原因是什么，但添加此选项后，再也没有看到单个503。

不要在haproxy.cfg的多个部分中使用“bind”行 例如，这是错误的

frontend stats
bind *:443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem

像这样修理

frontend stats
bind *:8443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem

---

你找到答案了吗？我们有相似的发现了答案。。。请接受答案。天哪，谢谢。有10多个进程侦听端口80。天啊，谢谢你！！你刚刚救了我的命，两天来你一直在扯我的头发。谢谢，谢谢快速提问，主题是：两个进程如何在同一端口上侦听？我认为这是不可能的。无论如何，谢谢你！你有我的英雄！！你刚刚救了我一天！这正是我的问题！！：哦，非常感谢！这可能是更普遍的原因之一。经过3天的研究，这让我省去了更多的麻烦。使用docker flow proxy捆绑haproxy和服务配置，haproxy配置创建了重复绑定，导致其他所有请求失败。我设置了env var-e DEFAULT_PORTS=81444，这导致默认端口和服务端口不再重复，并且所有的工作都像一个符咒。哇。如果你的基础设施管理混乱，那就很难发现了。。。刚刚发现有人弄乱了我之前修复的配置，非常感谢你的评论。如果你像我一样是haproxy的新手，犯这个错误很容易。如果我没有遇到这个问题，也没有找到这个答案，我就不会知道有多条绑定线是错误的。

frontend stats
bind *:443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem

frontend stats
bind *:8443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem