SSLSessionCacheTimeout设为60秒或更短会导致客户端频繁失效缓存、被迫完整TLS握手；合理值为180–300秒，需配合SSLSessionTickets及正确密钥配置，并完整重启Apache生效。
SSLSessionCacheTimeout设太短会导致重连变慢
设成60秒甚至更短，看似“及时清理”，实则让客户端频繁掉出缓存，被迫走完整 TLS 握手。现代浏览器和移动端 SDK 默认会尝试复用会话，但前提是服务端缓存还有效——SSLSessionCacheTimeout 就是这个有效期的开关。低于 180 秒，在中高并发或弱网场景下，命中率明显下滑。
常见错误现象：openssl s_client -connect example.com:443 -reconnect 多次连接时，日志里反复出现 SSL handshake has read 0 bytes and written 0 bytes，说明没复用上；Apache 的 ssl_engine_log 里大量 cache lookup failed。
- Web API 类服务可设为 180–240 秒（3–4 分钟），兼顾复用与内存压力
- 面向 App 或 WebView 的 HTTPS 接口，建议 300 秒（5 分钟），因为移动端重连间隔常在 2–6 秒之间，5 分钟足够覆盖多次断续重连
- 若用
shmcb缓存且并发连接超 5000，可同步调大缓存尺寸，比如"shmcb:/var/run/ssl_scache(1048576)"（1MB）
SSLSessionCacheTimeout和SSLSessionTickets不能互相替代
两者解决的是不同层面的问题：SSLSessionCacheTimeout 控制服务端内存缓存的生命周期，而 SSLSessionTickets 把会话状态加密后交给客户端保管。后者对 IP 变更、负载均衡漂移更友好，但依赖客户端支持和稳定密钥。
容易踩的坑：只开 SSLSessionTickets on 却没配 SSLSessionTicketKeyFile，或重启 Apache 后密钥失效，导致票据无法解密，实际退化为全握手——这时调 SSLSessionCacheTimeout 毫无意义。
- 必须配
SSLSessionTicketKeyFile /etc/ssl/private/ticket.key，且该文件是 48 字节二进制（openssl rand -out ticket.key 48） - 多机集群时，所有节点必须共用同一份
ticket.key，否则跨机票据无效 -
SSLSessionCacheTimeout对票据机制无影响，但两者可并存：票据用于首次重连，缓存用于同进程内高频复用
修改SSLSessionCacheTimeout后必须完整重启Apache
这个参数不是运行时热更新项。改完只执行 apachectl graceful 或 systemctl reload apache2，旧 worker 进程仍按老值计时，新进程才用新值。混跑期间连接行为不一致，极难排查。
验证是否生效最直接的方式：改完配置后执行 sudo systemctl restart apache2（Debian/Ubuntu）或 sudo systemctl restart httpd（CentOS/RHEL），再用 ss -tnp | grep :443 | wc -l 观察 ESTABLISHED 连接数随时间衰减的速度是否匹配新 timeout 值。
- 别依赖
apache2ctl configtest，它只检查语法，不校验 timeout 生效逻辑 - 如果用了
mpm_event，还要确认MaxKeepAliveRequests没设成 0，否则单连接可能撑太久，掩盖 timeout 效果 - CDN 或 WAF 前置时，
SSLSessionCacheTimeout控制的是 Apache 到 CDN 的这一跳，不是终端用户到 CDN 的连接
超时值要和后端Java应用的TLS终止位置对齐
如果 Apache 是 TLS 终止点（推荐），那 SSLSessionCacheTimeout 直接起效；但如果 Java 应用（如 Tomcat）自己也开了 HTTPS，并且 Apache 只做 passthrough（比如用 ProxyPass 转发到 https://localhost:8443），那么 Apache 的缓存完全无效——握手压力全在 Java 层，此时应优化 Tomcat 的 sslEnabledProtocols 和 JVM 的 SSLSessionContext。
典型误配现象：Apache 配了 SSLSessionCacheTimeout 300，但用 curl -v --tlsv1.2 https://example.com/api 测试时，每次连接都耗时 20ms+，且 Wireshark 显示 ServerHello 总带 NewSessionTicket 扩展，说明服务端根本没查缓存。
- 检查 Apache 是否真在终止 TLS：看
SSLEngine on是否在 443 虚拟主机里，且后端ProxyPass指向的是http://或ajp://，而非https:// - 若必须 passthrough，请关掉 Apache 的
SSLSessionCache，避免误导监控指标 - Java 应用侧禁用重复 TLS 终止，否则 CPU 开销翻倍，
SSLSessionCacheTimeout再准也没用
