Squid retry_on_error: Status Codes and Alternate Routes

There is a Squid option named retry_on_error, but the name is broader than its useful interpretation. It does not mean every failed request will be repeated indefinitely until the page works.

For releases supporting this directive, it is off by default. Its documented retry list is 403, 500, 501, 502, 503, and 504, and it tries the request through another working destination. This is especially relevant in a hierarchy with alternative forwarding paths. It is not merely a timed retry of the same socket to the same server.

Name the failure first

A refusal while connecting to a proxy, a proxy authentication failure, an origin HTTP error, and a response cut off after delivery began do not present the same retry opportunity. Do not expect one setting to treat all four alike.

For a private exit, also decide whether an alternative path is acceptable. Another parent can have another public source address, authentication policy, or network location. Success through that alternate may violate the reason the first parent was selected.

Application operations bring another concern: repeating a request can repeat its effect. The client and server need appropriate retry semantics, particularly for operations that create or change data. A proxy setting is not a substitute for application-level handling of uncertain outcomes.

Read the directive for your exact release; the reference lists availability and default behavior. Keep request deadlines and the total user-visible wait in view as well. An extra forwarding attempt can consume the remaining time without producing a better result.

When investigating intermittent failures, record the status, chosen parent or destination, and attempt sequence. Otherwise, retries can make a recurring routing problem look like a generally slow website while hiding the path that actually failed.