In case you have a predefined list of upstream hosts, you might consider to look at Envoy Retry plugin. This mechanism allows you to determine a list of Hosts predicates that can be associated with some specific retry condition retry_on: i.e. on specific HTTP error code; and number of retry series num_retries, thus after reattempts have reached retries number, Envoy retry policy will select the next host from the list defined in retry_host_predicate.

{
  "retry_on": "...",
  "num_retries": "{...}",
  "per_try_timeout": "{...}",
  "retry_priority": "{...}",
  "retry_host_predicate": [],
  "host_selection_retry_max_attempts": "...",
  "retriable_status_codes": []
}

In other case, when your redirect hosts are not known in advance, it would better to find a way how you can apply appropriate logic in application level as most of HTTP proxies are designed in such a way that response handlers are executed synchronously, i.e. while the response handler is running nothing else will be scheduled in the same thread. This is fine as long as response handler only processes the data already in memory and doesn't wait on remote services. However, if you make a network request from a response handler, the entire thread will be blocked and do absolutely nothing until the remote service replies, which would result in performance degradation.