如何在Tomcat中实现HTTP到HTTPS的自动跳转？redirectPort与安全约束配置指南

如何在Tomcat中实现HTTP到HTTPS的自动跳转？

Tomcat 可以通过 redirectPort 加 Servlet 安全约束（security-constraint）实现 HTTP 到 HTTPS 的自动跳转，也可以由前置的 Nginx、Apache、CDN 等入口层完成强制 HTTPS。

需要先明确一点：单独在 HTTP Connector 中配置 redirectPort 并不会让所有 HTTP 请求自动跳转，它只在请求被判定为需要 SSL 传输时把请求转到指定端口，必须和 security-constraint 的 CONFIDENTIAL 传输要求配合。生产环境如果 Tomcat 前面有 Nginx、CDN、WAF 或负载均衡，优先由入口层统一 301/308 到 HTTPS；代理场景必须正确处理 X-Forwarded-Proto 和 RemoteIpValve，否则会出现重定向循环。本文按两种架构分别给出配置步骤、验证方法和常见错误处理。

Tomcat 实现 HTTP 到 HTTPS 的自动跳转，根据架构有两种方式：Tomcat 直接提供 HTTPS 时，用 HTTPS Connector + redirectPort + security-constraint；Nginx、Apache、CDN 或 WAF 在前面终止 TLS 时，在入口层做重定向，Tomcat 只处理后端应用。整体迁移方案可以对照HTTP 到 HTTPS 的迁移方案。

Tomcat 直接提供 HTTPS 的三步配置

第一步，配置 HTTPS Connector。Tomcat 10.1 支持 JSSE 和 OpenSSL 两种 TLS 方式，SSL 配置放在 conf/server.xml 中，通过 SSLHostConfig 和 Certificate 指定证书、私钥和证书链：

<Connector
    protocol="org.apache.coyote.http11.Http11NioProtocol"
    port="8443"
    SSLEnabled="true">

    <SSLHostConfig>
        <Certificate
            certificateFile="conf/example-cert.pem"
            certificateKeyFile="conf/example-key.pem"
            certificateChainFile="conf/example-chain.pem"
            type="RSA" />
    </SSLHostConfig>

</Connector>

certificateFile 是服务器证书，certificateKeyFile 是私钥，certificateChainFile 是中间证书链。CA 提供完整证书链文件时，按当前 Tomcat 版本正确设置证书链，不要简单把私钥和证书混在一个文件里。证书安装的具体操作可以参考服务器端证书安装步骤。

第二步，在 HTTP Connector 设置 redirectPort：

<Connector
    port="8080"
    protocol="HTTP/1.1"
    connectionTimeout="20000"
    redirectPort="8443" />

redirectPort 告诉 Tomcat：如果这个 HTTP 请求对应的 Web 应用安全约束要求 HTTPS，把请求转到 8443 端口。

第三步，在 WEB-INF/web.xml 声明资源必须通过 HTTPS 访问：

<security-constraint>
    <web-resource-collection>
        <web-resource-name>HTTPS Required</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

关键在 CONFIDENTIAL：它告诉 Servlet 容器该资源必须通过受保护的传输方式访问。用户通过 HTTP 访问时，Tomcat 按 redirectPort 把请求转到 HTTPS 端口。HTTPS 用标准 443 时最终跳转到 https://example.com，用 8443 则是 https://example.com:8443。

redirectPort 不是全站跳转开关

很多教程只写 redirectPort 就说"已开启自动跳转"，实际不完整。redirectPort 的作用是：指定某个请求被判断为必须使用 HTTPS 时，重定向到哪个 SSL 端口。它本身不拦截普通 HTTP 请求——不要求 SSL 的请求照常处理，只有要求 CONFIDENTIAL 的请求才会走重定向。

所以需求如果是"不论访问哪个 URL，进 HTTP 就统一 301/308 到 HTTPS"，入口层重定向更直接。

生产环境更推荐在入口层跳转

Tomcat 前面已有 Nginx 时，让 Nginx 承担跳转，配置更简单、行为更统一：

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

HTTPS 请求再转发给 Tomcat：

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    ssl_certificate /etc/nginx/ssl/fullchain.pem;
    ssl_certificate_key /etc/nginx/ssl/example.key;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

这种架构下，TLS 在 Nginx 终止，Nginx 到本机 Tomcat 是内部通信，是否继续用 HTTPS 取决于网络边界和安全要求。前端是 CDN/WAF 时同理：在 CDN/WAF 层完成 301 跳转，HTTP 请求甚至不会到达 Tomcat，所有边缘节点统一执行 HTTPS 策略。

按部署环境选方式：

反向代理下的跳转循环问题

用户从 https://example.com 访问，但 Tomcat 实际收到的是 http://127.0.0.1:8080。如果应用自己判断 request.getScheme().equals("http")，会误以为用户走的是 HTTP，再次跳转 HTTPS，形成无限循环（ERR_TOO_MANY_REDIRECTS）。

解决方法是让代理传递 X-Forwarded-Proto: https，再由 Tomcat 的 RemoteIpValve 正确识别原始请求协议：

<Valve
    className="org.apache.catalina.valves.RemoteIpValve"
    protocolHeader="X-Forwarded-Proto" />

RemoteIpValve 会按代理传递的 X-Forwarded-Proto 调整 scheme、server port 和 request.isSecure()。注意 internalProxies、trustedProxies 要按实际拓扑限制，不能无条件信任来自公网客户端的 X-Forwarded-Proto。CDN 用 HTTP 回源时，Tomcat 收到的仍是 HTTP，同样必须处理代理协议头，否则应用可能生成错误的绝对 URL 或产生循环跳转。

配置后怎么验证

不要只靠浏览器检查。用 curl 看跳转：

curl -I http://example.com

理想结果：

HTTP/1.1 301 Moved Permanently
Location: https://example.com/

再检查完整跳转链和 HTTPS 直接访问：

curl -I -L http://example.com
curl -I https://example.com

HTTPS 直接访问应返回正常响应而不是继续跳转。用 openssl 检查握手和证书：

openssl s_client -connect example.com:443 -servername example.com

重点看证书域名、有效期、证书链、SNI 和 TLS 握手，也可以用证书与 TLS 握手检测核对。

跳转只是第一步，还要检查页面内部资源：图片、CSS、JavaScript、API 如果还写死 http:// 地址，会产生混合内容（Mixed Content）问题，浏览器会拦截或告警。HTTP 到 HTTPS 的永久迁移用 301（或 308），临时测试用 302，避免搜索引擎长期缓存错误的跳转关系。

常见错误

1. 设了 redirectPort 却没有跳转：只配了 redirectPort 没配 security-constraint，它本身不是全站开关。
2. HTTPS 端口配置错误：HTTP 8080、HTTPS 8443 时 redirectPort 写成 443，会跳转到错误端口。
3. HTTPS 端口没有监听：跳转到 8443 但防火墙没放行，或 HTTPS Connector 没启动。
4. ERR_TOO_MANY_REDIRECTS：Nginx/CDN 已完成跳转而 Tomcat 没识别 X-Forwarded-Proto，按"客户端协议 → CDN/Nginx → X-Forwarded-Proto → request.isSecure()"链路排查。
5. HTTPS 正常但应用生成 HTTP 链接：检查应用如何获取 scheme、host、port 和代理头，问题在反向代理识别配置，不一定是证书问题。证书本身的报错可以看证书相关报错的处理。

常见问题解答

Tomcat 配置 redirectPort 后为什么没有自动跳转 HTTPS？

redirectPort 不是单独的全站跳转开关，需要和 Servlet 的 security-constraint（CONFIDENTIAL）配合。先配置 HTTPS Connector，再在 web.xml 声明需要 HTTPS 的资源。

Tomcat 前面有 Nginx，还需要在 Tomcat 里配置 HTTP 跳 HTTPS 吗？

一般不需要。生产环境让 Nginx 在 80 端口直接 301/308 到 HTTPS，Tomcat 处理转发进来的业务请求即可。

Tomcat HTTPS 用 8443 端口正常吗？

正常。8443 常用于 Tomcat 的 HTTPS Connector；生产环境也可以由 Nginx、负载均衡监听 443，再把 HTTPS 转发给 Tomcat 的 8443 或内部端口。

配置 HTTPS 后出现 ERR_TOO_MANY_REDIRECTS 怎么办？

Tomcat 前面有 Nginx、CDN 或负载均衡时，优先检查代理是否正确发送 X-Forwarded-Proto: https，以及 Tomcat 是否通过 RemoteIpValve 正确识别原始协议。否则 Tomcat 一直认为请求来自 HTTP，反复跳转 HTTPS。

Tomcat 实现 HTTP 到 HTTPS 自动跳转有两条路：直接暴露公网时用 HTTPS Connector + redirectPort + security-constraint（CONFIDENTIAL）组合，redirectPort 本身不是全站跳转开关；前面有 Nginx、CDN、WAF 或负载均衡时，由入口层统一 301/308 到 HTTPS。代理场景必须处理 X-Forwarded-Proto 和 RemoteIpValve，否则产生重定向循环。配置后用 curl 和证书检测确认跳转与握手正常，并检查页面是否残留 HTTP 混合内容。