Introduction

If you are using Zuul as a gateway and want to add headers before the request is forwarded to a downstream service, the usual solution is a pre filter that modifies the proxied request. But there is an important distinction: adding headers to a request that Zuul forwards internally is different from adding headers to a real HTTP redirect response such as 302, because the browser controls the follow-up request after a redirect.

First clarify what “redirecting” means

In Zuul discussions, people often say “redirecting” when they really mean “routing” or “forwarding” through the gateway. Those are not the same thing.

If Zuul is proxying the request to another service, you can usually add downstream request headers.

If Zuul is returning an actual redirect response such as:

• '301 Moved Permanently'
• '302 Found'
• '307 Temporary Redirect'

then you are not in control of the next request headers in the same way, because the client follows the redirect.

That distinction determines whether a filter can solve the problem directly.

Adding headers for proxied requests

For ordinary routed traffic, a pre filter is the normal place to add request headers.

1import com.netflix.zuul.ZuulFilter;
2import com.netflix.zuul.context.RequestContext;
3import org.springframework.stereotype.Component;
4
5@Component
6public class AddHeaderFilter extends ZuulFilter {
7
8    @Override
9    public String filterType() {
10        return "pre";
11    }
12
13    @Override
14    public int filterOrder() {
15        return 1;
16    }
17
18    @Override
19    public boolean shouldFilter() {
20        return true;
21    }
22
23    @Override
24    public Object run() {
25        RequestContext ctx = RequestContext.getCurrentContext();
26        ctx.addZuulRequestHeader("X-Custom-Header", "gateway-value");
27        return null;
28    }
29}

This adds the header before Zuul forwards the request downstream.

Why pre is the right filter type

Zuul filters run in phases:

• 'pre'
• 'route'
• 'post'
• 'error'

If the goal is to affect the request that the target service receives, you need to act before routing occurs. That is why pre is the default answer for request header injection.

A post filter can modify the response going back to the client, but by then the downstream request has already happened.

Adding response headers instead

Sometimes the real requirement is to add headers to the client-facing response, not to the downstream request.

In that case, use the response header APIs on the current context.

RequestContext ctx = RequestContext.getCurrentContext();
ctx.addZuulResponseHeader("X-Trace-Id", "abc123");

That affects the response from Zuul to the client, not the request sent to the proxied service.

The redirect limitation

If Zuul sends back a redirect response with a Location header, the client makes the next request. That means you generally cannot force arbitrary custom headers onto that subsequent redirected request unless the client is custom software that chooses to add them.

So if the architecture requires custom headers to reach the destination service, a gateway proxy route is usually more appropriate than an HTTP redirect.

This is the most important practical nuance in the whole topic.

Common use cases

Adding request headers in Zuul is often used for:

• correlation IDs
• internal authentication tokens
• tenant identifiers
• user context propagated from the gateway
• feature or environment metadata

These are all natural pre-filter tasks as long as the request is being proxied, not redirected externally.

Modern context note

Zuul is an older Netflix OSS gateway approach, and many newer Spring-based systems use Spring Cloud Gateway instead. But if you are maintaining a Zuul system, the filter model above is still the relevant mental model.

Common Pitfalls

A common mistake is trying to solve a real HTTP redirect problem with a request-header filter. If the browser performs the next request, your gateway does not control those follow-up headers in the usual way.

Another mistake is using a post filter when the goal is to modify the downstream request rather than the response.

A third mistake is confusing request headers sent to backend services with response headers returned to clients.

Summary

• Use a Zuul pre filter to add headers to proxied downstream requests.
• Use addZuulRequestHeader for backend-bound request headers.
• Use response-header APIs only when you want client-facing response headers.
• If Zuul returns a real redirect, you usually cannot control the next client request headers.
• Always clarify whether the problem is routing, proxying, or actual HTTP redirection.