HTTP 305 Use Proxy

HTTP 305 Use Proxy indicates the client must use a different URI to complete the intent. Redirect correctness depends on Location and caching headers, and different clients handle redirects differently—especially for non-GET requests.

Debug HTTP 305 live
Analyze real 305 behavior — headers, caching, CORS, redirects
Open Inspector →

Try it (live endpoint)

Response includes the status code, standard headers (including Content-Type), and a small diagnostic JSON body describing the request and returned status.

Simulator URL (copy in the app after load — not a normal link):

https://httpstatus.com/api/status/305

Example request:

curl -i "https://httpstatus.com/api/status/305"
Try in playground

Meaning

DEPRECATED. Originally indicated that the requested resource must be accessed through a proxy. Deprecated in RFC 7231 due to security concerns and should not be used.

What it guarantees
  • A different URI is involved to complete the intent.
What it does NOT guarantee
  • All clients will automatically follow the redirect.
  • The redirect target is safe to cache unless headers allow it.

When to use this status

  • A resource is available at a different URI and the client should follow it.
  • Canonicalizing paths (slash, www/non-www, http→https).
  • Moving content between endpoints and updating bookmarks.

When NOT to use this status (common misuses)

Redirecting without a stable Location target.
Clients fail to follow; crawlers lose canonical signals.
Using 301/302 for non-GET methods without understanding method rewriting.
Clients can drop bodies or change methods, causing data loss and client bugs.
Redirect loops or long chains.
Crawlers waste crawl budget; clients hang; retries amplify load.

Critical headers that matter

Location
Tells clients where to go next.
Redirects fail or loop; crawlers lose canonical target.
Cache-Control
Controls whether redirects are cached.
Temporary redirects become sticky; permanent redirects never stick.
Vary
Prevents caches mixing redirect variants.
CDNs serve the wrong redirect for different hosts/headers.

Tool interpretation

Browsers
Follows Location for navigations; redirect caching can make behavior sticky. Redirect code choice affects method/body handling.
API clients
May not auto-follow; strict clients require explicit redirect handling. Incorrect redirect semantics can drop bodies or change methods.
Crawlers / SEO tools
Uses redirects for canonicalization; long chains/loops waste crawl budget and dilute signals.
Uptime monitors
Typically marks success; advanced checks may flag header anomalies or latency.
CDNs / reverse proxies
Can cache redirects; Location/Vary/Cache-Control correctness drives global consistency.

Inspector preview (read-only)

On this code, Inspector focuses on semantics, headers, and correctness warnings that commonly affect clients and caches.

Signals it will highlight
  • Status semantics vs method and body expectations
  • Header sanity (Content-Type, Cache-Control, Vary) and evidence completeness
  • Redirect chain length, loops, Location presence, protocol safety
Correctness warnings
No common correctness warnings are specific to this code.

Guided Lab outcome

  • Reproduce HTTP 305 Use Proxy using a controlled endpoint and capture the full exchange.
  • Practice distinguishing status semantics from transport issues (redirects, caching, proxies).
  • Validate redirect correctness (Location, hop count, protocol safety) and SEO impact.

FAQ

Should clients retry on HTTP 305?
Usually no—treat it as a successful final response unless your domain requires revalidation.
Is HTTP 305 cacheable?
Only if Cache-Control/validators allow it. Do not assume cacheability from the status alone.
Which headers matter most for HTTP 305?
Content-Type and Cache-Control are the baseline. Some codes also require Location, WWW-Authenticate, or Retry-After.
How does this affect monitoring?
Redirects are policy-dependent; loops and long chains cause false positives and user impact.
How does this affect crawlers/SEO?
Redirect correctness controls canonicalization and crawl budget.
What should error responses include?
If a body is returned, keep it consistent and typed via Content-Type.

Client expectation contract

Client can assume
  • A different URI is involved; Location may be required.
Client must NOT assume
  • Redirects will be followed automatically by all clients.
Retry behavior
Retries are generally unnecessary; treat as final unless domain rules require revalidation.
Monitoring classification
Redirect (policy-dependent)
Validate Location, caching headers, and chain behavior. Redirect loops/chains should alert.

Related status codes

304 Not Modified
Indicates that the resource has not been modified since the version specified by the request headers (If-None-Match or If-Modified-Since). The client should use its cached copy.
307 Temporary Redirect
The URL of the requested resource has been changed temporarily.

Explore more

Related tools
Related utilities