Thanks for the prompt response. I should have been clearer with the issue I was seeing when I tried balance first.
I did see it redispatch from forward to fallback in the logs, however the destination IP is still txn.target_ip, although interestingly the destination port had changed to the incoming port rather than the port defined as the fallback or the port set with set-dst-port so something must be resetting the port in the redispatch logic but not the IP. Thanks, Chris. > On 7 Jan 2026, at 04:06, Willy Tarreau <[email protected]> wrote: > > Hi Chris, > > On Tue, Jan 06, 2026 at 09:13:02PM +0000, Christopher Staite wrote: >> Hi, >> >> I've been looking into the powerful set-dst feature to enable cross-cluster >> forwarding. I'd like to have a fallback in case a region has gone down for >> some reason or another. However, I'm struggling to get it to work with >> retry-on or redispatch. >> >> I've been trying something like: >> >> backend b >> mode http >> option redispatch >> http-request set-var(txn.target_host) req.hdr(Host),lower,field(1,:) >> http-request do-resolve(txn.target_ip,dns) var(txn.target_host) >> http-request set-dst var(txn.target_ip) >> http-request set-dst-port int(443) >> server forward 0.0.0.0:0 ssl verify required ca-file @system-ca sni >> req.hdr(host) >> server fallback 127.0.0.1:80 >> >> However, I end up with an SH-- on failure. I also tried with retry-on, >> setting a session variable on http-request and then set-dst 127.0.0.1 if the >> session variable is set. >> >> I feel like there must be a way to do this, but after a few hours of pouring >> over the docs and trying things out I think I've come to the conclusion that >> it's not possible. >> >> Hopefully someone can give me an insight in to whether this is actually >> impossible or if I'm missing something obvious. > > I'm not really seeing any way to do this, because the load balancing is > applied to choose a server based on the LB algorithm, then the connection > is attempted, then in case of failures the retries happen, and for the > last retries (or after a configurable set), the redispatch happens, which > consists in applying the LB algo again, and since there's no way to check > the remote server, I don't see how we could choose another server without > that server being selected as well under normal conditions. > > Hmmm wait a minute, maybe the "balance first" algo could do it. I'm seeing > that it supports the ability to avoid the previously attempted server in > case of redispatch, and since you cannot enable health checks, I think it > should always select your first server, except for redispatch. So you could > try to add just this line to your config and see if it works. And if it > does, it would be nice to append this to the doc and mention it there, > since right now the doc says that "balance first" only makes sense with > a configured maxconn (to deal with overload) but here that would be a > different use case. I don't promise anything though, so please try first ;-) > > Willy
