我正在设置一系列服务器作为我们应用程序服务器的代理，主要是为了模糊应用程序服务器的 IP，作为一套反 DDOS 措施的一部分。
我的目标是让 HAProxy 接受短暂的 HTTP/1.0 连接并通过持久连接将它们转发到后端，从而显著减少连接过程、慢启动等造成的开销损失。
我已经部分实现了此配置，但仍然看到后端的连接率比预期高得多 - 经调查，似乎每个后端连接都在处理 1 到 5 个请求，然后由 HAProxy 端重置。
这些重置数据包总是在从服务器完全收到响应之后、在发送任何进一步请求之前发生，并且它们发生在看似随机的延迟之后 - 有时短至 0.1 秒，有时长达 20 秒。更改 HAProxy 的超时设置似乎没有效果。
有谁知道是什么原因导致 HAProxy 出现这种行为，或者我如何更好地调试它？
编辑：忘了说了，我无法让后端生成任何有意义的日志，即使使用 tcplog
配置（已删除）：
global
log /dev/log local0
log /dev/log local1 notice
stats socket /run/haproxy/admin.sock mode 660 level admin
stats timeout 30s
maxconn 16384
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
defaults
log global
mode http
option httplog
option dontlognull
option http-keep-alive
timeout connect 5s
timeout client 50s
timeout server 50s
timeout http-keep-alive 50s
timeout http-request 30s
maxconn 4000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
# Temporary setting, egress is fragile w/ high rate of connections
default-server maxconn 200
frontend fe-web
bind 0.0.0.0:80
acl cloudflare src -f /etc/haproxy/cloudflare_ips
block if !cloudflare
use_backend be-web
frontend fe-legacy
bind 0.0.0.0:29080
option forwardfor header CF-Connecting-IP
use_backend be-legacy
backend be-web
server srv-web 46.105.16.9:34020 check
option httpchk HEAD / HTTP/1.1\r\nHost:\ legacy-domain
backend be-legacy
server srv-legacy 46.105.16.9:34020 check
option httpchk HEAD / HTTP/1.1\r\nHost:\ legacy-domain