HTTP 305 Use Proxy

Quick reference

What 305 was designed to do

RFC 2616 defined 305 with the following semantics: a server could return 305 with a Location header specifying a proxy URL. The client was expected to re-send the original request to the origin server, but routed through that proxy.

HTTP/1.1 305 Use Proxy
Location: http://proxy.corp.example.com:8080/

The intent was to allow origin servers to dynamically direct clients to specific proxies — useful for load balancing across multiple proxy servers, geographic routing (send European clients through a proxy closer to them), or enforcing corporate proxy policies without requiring OS-level proxy configuration on each client device.

The 305 response was only meant to apply to that single request, not to change the client’s global proxy settings permanently. In practice this scoping was ambiguous and implementations varied, which was itself a problem.

The security problem

The fundamental issue with 305 is that any server the client contacts can redirect the client’s traffic through an arbitrary proxy. Consider these attack vectors:

Man-in-the-middle injection: An attacker positioned between client and server can intercept a legitimate response and replace it with a 305 pointing to an attacker-controlled proxy. All subsequent requests from that client route through the attacker’s proxy, which can read, log, and modify everything — including credentials and session tokens sent over HTTP.

Compromised origin server: A server that has been compromised can return 305 responses that redirect clients to a data-exfiltration proxy. The client has no way to distinguish a legitimate 305 from a malicious one because no authentication mechanism exists for the Location value.

Cache poisoning: A shared cache that has been poisoned with a 305 response will serve it to multiple clients, causing all of them to route their traffic through the attacker’s proxy simultaneously.

RFC 7231 deprecated 305 with the rationale that in-band proxy configuration via HTTP responses is inherently insecure. The 305 deprecation and the 306 withdrawal both stem from the same conclusion: HTTP should not be used as a channel for proxy configuration.

Modern proxy configuration alternatives

Proxy configuration in modern environments happens through authenticated, user-controlled channels that a server cannot manipulate:

OS-level proxy settings: Windows, macOS, and Linux all have system-wide proxy settings that apply to all applications. These are configured by administrators or users, not by remote servers. Group Policy (Windows) or MDM profiles (macOS/iOS) can enforce proxy settings fleet-wide.

PAC files (Proxy Auto-Configuration): A JavaScript file that defines routing rules for the proxy. Clients fetch the PAC file from a trusted URL configured in the OS or browser. The PAC file can contain sophisticated routing logic (send this domain through this proxy, everything else direct) and is served from a controlled location, not injected by arbitrary servers.

WPAD (Web Proxy Auto-Discovery): Clients discover the PAC file location automatically via DNS or DHCP. Configured by the network administrator, not by individual servers.

Browser proxy settings: Firefox, Chrome, and other browsers have their own proxy configuration that overrides or supplements OS settings. Enterprise browsers can be policy-locked via extension management APIs.

What to use instead of 305

If your application needs to redirect clients to a different endpoint (not a proxy, but an actual destination URL), use the appropriate redirect code:

None of these redirect to a proxy — they redirect to the resource’s new direct URL. If you need traffic to go through an intermediary, implement that at the infrastructure layer (reverse proxy, load balancer, API gateway) where you control both the client-facing endpoint and the routing logic.

If you see 305 in a server or log today

A server still emitting 305 is running software from the late 1990s or early 2000s, or has a misconfiguration. Check whether the software is intentionally using 305 as an application-level signal (some APIs reuse non-standard codes) or whether it is genuinely attempting proxy redirection as defined in RFC 2616. In either case, update the implementation: for proxy routing, reconfigure at the infrastructure layer; for general redirects, use 301/307/308; for application-level errors, use an appropriate 4xx or 5xx code with a descriptive body.

Frequently asked questions

Why was HTTP 305 deprecated?

HTTP 305 was deprecated because it allowed a server to redirect clients to an arbitrary proxy via the Location header. An attacker who could inject a 305 response could redirect all client traffic through a malicious proxy. RFC 7231 deprecated it on these security grounds.

What should I use instead of 305?

For redirecting clients to a different URL: use 301, 307, or 308 depending on permanence and method preservation. For proxy configuration, use out-of-band mechanisms like OS proxy settings, PAC files, or WPAD rather than HTTP responses.

Is HTTP 305 safe to implement?

No. RFC 9110 explicitly forbids returning 305 in new implementations. Any software generating 305 should be updated to use an appropriate standard redirect code.

What is the difference between 305 and 306?

HTTP 305 Use Proxy was formally defined and deprecated with a security rationale in RFC 7231. HTTP 306 Switch Proxy was a conceptually similar idea that was withdrawn before it was ever formally defined. Both are now reserved and must not be used.

Related guides

HTTP 306 Unused (reserved) · HTTP 301 Moved Permanently · HTTP 307 Temporary Redirect · HTTP 308 Permanent Redirect

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15.4.6. Human-readable guidance by ErrorLookup. · HTTP 305 quick reference →