For volumetric attacks (where the attacker is using DNS reflection or similar to do nothing but eat your bandwidth) pretty much the only solution is to work with providers to block the sources/protocols to stop the majority of the traffic before it hits the fiber into the proxy servers. For SYN floods (where spoofed SYN packets are used to fill up the proxies connection table) the kernels SYN cookie functions can be used to ignore invalid SYN's, or if that isn't enough something like our ALOHA's PacketSheld to prevent the reflected/spoofed traffic from reaching the proxy at all (but still useless if the 10gb line is completely full). HAProxy comes into account more if they are actually establishing a TCP connection even if they don't actually make a request, as then conn_rate/conn_cur trackers can be used to refuse/drop the connections (and with silent drop fill up their connection tables and make it harder for them to make more). If they actually make a full HTTP request, then the http_req_rate comes into play to 403 the requests (and can be combined with connection rate limiting to reduce the amount of traffic in HTTP requests they send).

Most volumetric attacks are UDP reflection based, and relatively simple to filter out at the network level using ACL's. When using decent network gear, these can be filtered at line rate using ASICs. These comprise the vast majority of real-world DDoS attacks.

Having the ability to protect against more focused attacks with HAProxy could be very useful in those few instances where volumetric attacks are not being used.

Not who you’re asking but I doubt it. You’d need a service or infrastructure that can absorb (and probably distribute the load across PoPs) before scrubbing it and sending it to your application.