Tomcat redirectPort Explained: HTTPS Security Constraints and Connectors
Publication date:
Updated:
INFORMATION > Tomcat redirectPort Explained: HTTPS Security Constraints and Connectors
Bottom line: redirectPort tells a non-TLS Tomcat connector where to redirect a request when the deployed web application's security constraint requires a confidential transport. It does not create the TLS connector, force HTTPS for every request, or replace edge-proxy redirect policy.
What you'll learn
- How
<transport-guarantee>CONFIDENTIAL</transport-guarantee>activates container-managed redirection. - Why the target port must correspond to a working HTTPS connector or correctly designed proxy topology.
- How direct Tomcat TLS differs from TLS termination at Apache HTTP Server or another proxy.
Who this is for: Java web administrators reviewing Tomcat connector and application security-constraint settings.
2026 context: The Tomcat 9 example below remains conceptual, but connector attributes and proxy handling must match your supported Tomcat family. Avoid redirect loops and wrong schemes by configuring trusted proxy headers deliberately.
Overview
When I looked at the port setting in Tomcat's server.xml configuration, there was a setting called "redirectPort", but I couldn't figure out what this setting was when I googled it, so I looked it up.
The following settings.
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
Table of Contents
1. What is redirectPort?
As it turns out, the setting seems to redirect when accessing a page that specifies that SSL is required.
If the server.xml configuration values were as follows
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
If the URL "http://hoge:8080/hoge.html" is accessed, it seems to redirect the user to access the URL "https://hoge:8443/hoge.html".
SSL must be defined in the "web.xml" file. SSL is required by setting "<transport-guarantee>CONFIDENTIAL</transport-guarantee>". The following information should be included in the web.xml file
～omission～
<security-constraint>
<web-resource-collection>
<web-resource-name>twx-portal</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>
</web-app>
Because url-pattern is /, the security constraint requires confidential transport for every matching application URL. Tomcat uses the non-TLS connector's redirectPort when it must redirect such a request. A redirect target is useful only if a TLS connector or trusted proxy actually accepts that port and the scheme and proxy attributes are configured consistently.
1-1. reason
The Tomcat documentation supports this conclusion:
https://tomcat.apache.org/tomcat-9.0-doc/ssl-howto.html
“If you change the port number here, you should also change the value specified for the redirectPort attribute on the non-SSL connector. This allows Tomcat to automatically redirect users who attempt to access a page with a security constraint specifying that SSL is required, as required by the Servlet Specification.”
The quoted documentation refers to a request that matches a security constraint with a confidential transport guarantee, such as the web.xml constraint above. redirectPort does not force every application request to HTTPS on its own.
2. Conclusion
Configure redirectPort together with the TLS connector or reverse proxy, then test direct requests, proxied requests, forwarded headers, and redirect-loop behavior.
Official references
■INFORMATION
■PROFILE
■CONTACT