我们最近在两个单独的Web模块中拆分了我们的主Web应用程序（在https后面的EC2上运行，并在自动扩展的负载平衡器上运行）。
主要基础架构现在有一个负载均衡器和主模块的n服务器（main.elasticbeanstalk.com）和一个带有n-server的负载均衡器用于辅助模块（secondary.elasticbeanstalk.com）
我们创建了一个HAproxy专用实例，该实例由域www.mycompany.com解析并代理请求，如下所示：
- ：//www.mycompany.com/fancymodule - > secondary.elasticbeanstalk.com
- ：//www.mycompany.com/ - > main.elasticbeanstalk.com
我们投入生产并在~12小时后... http://www.mycompany.com/fancymodule开始获得503服务不可用。如果我手动重启HAproxy，一切都开始工作。
我设法复制了更新与secondary.elasticbeanstalk.com相关联的IP地址的问题（例如：从负载均衡器转换为单个实例）。
好像HAproxy没有更新dns解析为secondary.elasticbeanstalk.com，因此它无法使用旧的ip而无法正确访问Web服务器。
而且停机时间不短！在重新启动服务之前，它无法正确路由！
负载均衡器是否可能与弹性IP相关联，因此无法再访问新的IP地址？
有人可以看看这个配置，并告诉我，如果我做了一些愚蠢的事情？
global
log 127.0.0.1:514 local2 info
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
tune.ssl.default-dh-param 2048
defaults
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
mode http
option httplog
frontend mydomain
log global
bind *:80
bind *:443 ssl crt /etc/ssl/certificate.pem
acl isSsl ssl_fc
redirect scheme https if !isSsl
option dontlog-normal
mode http
acl secondaryDomain url_beg /fancymodule
acl liveDomain hdr_end(Host) -i www.mycompany.com
use_backend live_secondary if secondaryDomain liveDomain
use_backend live_main if liveDomain
default_backend live_main
backend live_main
rspadd Set-Cookie:\ module=main;Path=/
server main main.elasticbeanstalk.com:80
backend live_secondary
rspadd Set-Cookie:\ module=secondary;Path=/
server secondary secondary.elasticbeanstalk.com:80
listen stats :1234
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /stats
stats auth user:pswd
我发现，为了提高性能，HAproxy只需在启动时用实际的ip地址替换config的域。之后没有进行dns解析。
http://www.serverphorums.com/read.php?10,358605 https://serverfault.com/questions/681000/force-haproxy-to-lookup-dns-for-backend-server
因此，解决方案是使用HAProxy创建自动扩展负载均衡器，或者在dns ip change上使用外部侦听器自动重新加载服务
我在AWS中部署后端服务器的设置遇到了同样的问题。在我们的内部网络中运行的HAProxy会突然将此后端服务器DOWN与L7STS / 503检查结果一起使用，而我们的监控正在访问后端服务器（直接）就好了。当我们运行HAProxy对（LB01和LB02）时，LB01的重新加载立即起作用，后端服务器再次启动。在LB02上（未故意重新加载），此后端服务器仍处于关闭状态。
所有这些似乎都与AWS LB的DNS更改以及HAProxy如何进行DNS缓存有关。默认情况下，HAProxy在启动/重新加载时解析所有DNS记录（例如后端）。然后，这些已解析的DNS记录将保留在HAProxy自己的DNS缓存中。因此，您必须重新启动HAProxy才能更新DNS缓存。
另外，毫无疑问，更好的解决方案是定义DNS服务器和HAProxy内部DNS缓存TTL。这是可能的，因为HAProxy版本1.6带有这样的配置代码段：
global
[...]
defaults
[...]
resolvers mydns
nameserver dnsmasq 127.0.0.1:53
nameserver dns1 192.168.1.1:53
nameserver dns2 192.168.1.253:53
hold valid 60s
frontend app-in
bind *:8080
default_backend app-out
backend app-out
server appincloud myawslb.example.com:443 check inter 2s ssl verify none resolvers mydns resolve-prefer ipv4
那么这样做是使用由mydns开头的条目定义的DNS服务器来定义名为nameserver的DNS名称服务器集。内部DNS缓存应保持由hold valid 60s定义的60秒。在后端服务器的定义中，您现在通过添加resolvers mydns来引用此DNS名称服务器集。在此示例中，最好通过添加resolve-prefer ipv4来解析为IPv4地址（默认为使用ipv6）。
请注意，为了在后端服务器中使用resolvers，还必须定义check。只要触发后端服务器检查，就会发生DNS查找。在此示例中，定义了check inter 2s，这意味着DNS查找将每2秒发生一次。这将是相当多的查找。通过将内部hold缓存设置为60秒，您可以因此限制DNS查找的数量，直到缓存过期为止; 62秒后最新的DNS查找应该发生。
从HAProxy 1.8版开始，甚至有一种称为“基于DNS的服务发现”的高级可能性，它使用DNS SRV记录。这些记录包含多个响应字段，例如优先级，权重等，可以由HAProxy解析并相应地更新后端。
更多的信息：