Thank you, Chris, for the inputs.

Yes, we intended to have Tomcat run behind a (transparent) TCP proxy e.g.
 which supports the proxy protocol.

Since there is not much action on this, does it imply that most 
of the times Tomcat is running behind HTTP proxies and not TCP proxies?
Or does it mean that, Tomcat or applications running in Tomcat does not need 
the remote client address information?


-----Original Message-----
From: Christopher Schultz <>
Sent: Monday, May 8, 2023 3:40 PM
Subject: [External] Re: Supporting Proxy Protocol in Tomcat


On 5/4/23 16:07, Amit Pande wrote:
> We have a similar requirement as mentioned in the below enhancement request.
> https://bz.a/
> 55b3eaca318e6cac32%7C0%7C0%7C638191752206669206%7CUnknown%7CTWFpbGZsb3
> d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7
> C3000%7C%7C%7C&sdata=6TXyKzlyjY3AIi6zQMFn2j9BhtwYo6Jkrd1V3nOl4mY%3D&re
> served=0
> Is there any plan to add this support in Tomcat in future releases?

Nothing at the moment that I know of.

I thought that markt had looked at this a while back and said it didn't look 
too difficult. It does require Tomcat to handle the stream directly and not 
just rely on Java's SSLServerSocket. I thought that had been done at some 
point, but it may not have. Handling the stream directly may have some other 
advantages as well, though it definitely makes the code more complicated.

> Also, since this was requested long time back and there is no update,
> are there any other alternatives to pass the client information from
> load balancer to Tomcat in situations where there is no SSL
> termination at load balancer?
You mean like a network load balancer where the lb is just proxying bytes and 
not looking at the data at all? The PROXY protocol really is the best way to do 
that, honestly.


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to