Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Repair Windows errors before they cause bigger problemsFix Now →First capture the redirect chain and fix the rule that sends the request back to a URL it has already visited. CircularRedirectException means Apache HttpClient detected a repeated redirect target; ClientProtocolException is often the outer exception your application reports. Disabling redirects can reveal the loop, but allowing it usually hides the problem rather than solving it.
What the exception means
Apache describes CircularRedirectException as a signal of a circular redirect. A server, proxy, or load balancer returns a redirect whose resolved destination repeats an earlier one. For example, a request might alternate between HTTP and HTTPS, between two hostnames, or between a path with and without a trailing slash.
The underlying exception may be wrapped in ClientProtocolException by the request execution layer. The class is in org.apache.http.client in HttpClient 4.x and org.apache.hc.client5.http in HttpClient 5. Apache documents CircularRedirectException as available since HttpClient 4.0.
Trace the redirect chain before changing client behavior
Record the initial request URI and, for each response, its status code, exact Location header, resolved absolute destination, and redirect count. Resolve relative Location values against the current URI as the client does. Compare scheme, host, port, path, and query string to find where a previously visited target recurs.
Recommended Free Tools
- Temporarily disable automatic redirects and make the request again.
- Inspect the first response and its
Locationvalue. Request that destination directly to see what it returns. - Check reverse-proxy and load-balancer rules, TLS termination headers, host canonicalization, trailing-slash handling, and login or session redirects.
- Make the involved rules converge on one canonical URL, then restore the intended redirect behavior.
A loop between HTTP and HTTPS can indicate that a proxy or application does not agree about the original scheme. Alternating hostnames can point to conflicting canonical-host rules; alternating paths can indicate incompatible slash or route normalization. These are diagnostic possibilities, not proof of which component is responsible.
Configure redirect handling in HttpClient 5
HttpClient 5 exposes redirect controls through RequestConfig.Builder. For diagnosis, disable automatic redirects; when restoring them, retain a finite maximum appropriate for the application.
Rank #2
RequestConfig config = RequestConfig.custom()
.setRedirectsEnabled(false) // useful for diagnosis
.setCircularRedirectsAllowed(false) // default safety behavior
.setMaxRedirects(20) // choose an application-appropriate cap
.build();Attach the configuration using the execution API your application uses. After correcting the redirect chain, enable redirects again if needed. The values shown above are an example: Apache documents redirects as enabled by default, circular redirects as disallowed, and the maximum as 50. The maximum is a safeguard against endless loops, not a fix for one. HttpClient 5 RequestConfig documents these controls and defaults.
setCircularRedirectsAllowed(true) is available for cases where repeated locations are intentional. Use it only with a carefully selected maximum and monitoring; otherwise the client may continue through a broken loop until it hits the cap.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Configure redirect handling in HttpClient 4.x
HttpClient 4.x uses the older org.apache.http packages and its own request and client configuration controls for automatic redirects, redirect limits, and circular redirects. Do not copy HttpClient 5 imports or configuration examples into a 4.x application.
Under the default DefaultRedirectStrategy, eligible HEAD and GET requests are automatically redirected for 301, 302, and 307 responses; POST and PUT are not automatically redirected under that default policy. LaxRedirectStrategy relaxes that method restriction, but following a redirect for POST or PUT can replay a request with side effects. Use it only after assessing whether the operation can safely be repeated. DefaultRedirectStrategy API documentation and LaxRedirectStrategy API documentation describe these strategies.
Rank #4
If the built-in policies do not match the application’s requirements, a custom RedirectStrategy can define whether a response should be followed through isRedirected and how to construct the next request through getRedirect. RedirectStrategy API documentation describes those extension points.
Check for the HttpClient 5.3.1 retry defect
Apache recorded HTTPCLIENT-2333, a defect in HttpClient 5.3.1 in which a retry after a redirect could be incorrectly classified as circular. The issue is resolved in 5.4. If the application runs 5.3.1, upgrade to 5.4 or later and retest. This version-specific defect is a separate possibility from a genuine repeated redirect chain.
Quick Recap
Best Value
Keep future failures diagnosable
- Set a finite redirect maximum rather than allowing unbounded redirects.
- Log the redirect chain—status, raw
Location, resolved destination, and count—when a request fails. - Keep the distinction between a server-side redirect loop and a client policy or version issue visible in error reporting.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
