我有2个服务器运行两个Tomcat实例（一个用于RC的Tomcat实例，一个用于生产）。 这些服务器（我们称之为server1和server2）设置在F5负载平衡器后面，以保持正常运行，并提供SSL支持。 当有人去server1：8081时，他们得到服务器1上的第二个tomcat的欢迎屏幕（server1：8080将给第一个实例）。 当连接到服务器：8443，其中去到server1：8081和server2：8081的F5负载平衡URL，我也将获得侦听端口8081的该实例的Tomcat欢迎屏幕。但是，当去服务器：8443 /应用程序/，我得到一个错误，wireshark数据包捕获显示redirect到server1端口8080.我很遗憾redirect到端口8080来自，我没有任何redirect在我的server.xml为那个tomcat实例基础configuration。 任何人有任何想法，如果可能在.war文件编译期间，实际的应用程序可能已拉入端口redirect？
是的，如果input的url不是100％，networking应用通常会redirect。 新手开发者倾向于天真地redirect，那就是他们让应用程序响应HTTP 302 http://my-host:8080/proper/link/index.jsp他们使用一个8080硬编码的文本（也是http但是这个变得不太经常是redirect的问题）。
换句话说，他们使用在他们的笔记本电脑上完美工作的redirect，但是当Tomcat使用不同的端口时会失败。 与其他前端（也称为“反向代理”）一样，F5拦截HTTPredirect，如果应用程序使用http://server1:8081/xxx浏览器将接收到https://server:8443/xxx 。 但它与8080混淆并保持原样。
我通常的反应是向应用程序开发人员提交一个错误：请求使用自动确定的端口号redirect（如果tomcat将来有一天在8085上侦听，redirect应该是8085）。
我最终从应用程序开发者那里获得了一些关于在应用程序后面设置应用程序的文档。 我不得不将proxyName和proxyPort属性添加到我的server.xml文件的连接器部分。
您可以尝试将RemoteIpValve添加到您的webapp的META-INF / context.xml中，并将request.serverPort填充到F5的端口，甚至将request.remoteAddr填充到客户端的真实IP而不是代理的IP。 然后，您可以像往常一样生成任何链接，所有链接都将包含前端反向代理的主机名和端口。