Thank you for the answer. I really appreciate it.
Actually I’ve already tried something like this before and it doesn’t work. I assess the reason is that haproxy tries to statefully remain aware (programmatically speaking) of the state of each possible server/destination instead of establishing connections per request. I had already consulted the documentation of
check before posting the question, and the worst part was that even passive checks require active checks to be working, which I found very weird… maybe it’s for some performance reason, I don’t know.
I can see in the logs when attempting to connect, which tells me that haproxy has cached the state “backend is available/not available”.
[ALERT] 003/071848 (2103942) : backend 'httpPortTcpForwarder' has no server available!
even though the backend is available at that moment.
And when starting haproxy, I can see (for only 2 destinations, btw):
[WARNING] 003/072349 (2105506) : Server httpPortTcpForwarder/httpPortTcpForwarderServer1 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 0ms. 1 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
[WARNING] 003/072350 (2105506) : Server httpPortTcpForwarder/httpPortTcpForwarderServer2 is DOWN, reason: Layer4 connection problem, info: "Connection refused", check duration: 155ms. 0 active and 0 backup servers left. 0 sessions active, 0 requeued, 0 remaining in queue.
Notice how it already decides that there’s no more backup servers, which seems to be the basis of its decision.
If you check my (dumb) rust example, for every incoming connection, we decide the destination based on whether they’re available at the moment in order. The backend you provided looks as if it exactly does that, but for some reason it just uses the stored state to make that decision.
Is there a way to make the decision based on the state at the moment instead of using the stored state?