We need to find a solution to situation where defunct gateways start returning redirects back to ipfs.io and dweb.link, effectively acting as amplification vector.

There is some prior art solution in form of CDN-Loop header which helps in avoiding unintended HTTP loops like that:

This document defines the CDN-Loop request header field for HTTP.
CDN-Loop addresses an operational need that occurs when an HTTP
request is intentionally forwarded between Content Delivery Networks
(CDNs), but is then accidentally or maliciously re-routed back into
the original CDN causing a non-terminating loop. The new header
field can be used to identify the error and terminate the loop.

Ref.

• https://datatracker.ietf.org/doc/html/rfc8586
• https://blog.cloudflare.com/preventing-request-loops-using-cdn-loop/
• gateway: CDN-Loop (RFC 8586) specs#426

I think in case of Rainbow, we could leverage SEED and have all nodes set CDN-Loop to the same deterministic hash value, and refuse to process requests with matching one. This way HTTP traffic looped/proxied back to our infra is ignored.

cc @hsanjuan for feedback, maybe there a better way?