proxy_ssl_session_reuse 必须在 upstream 块中配置才生效，仅对 https:// 后端有效；常见错误包括放错位置、协议写错、upstream 名称不匹配；复用失败主因是 TLS 版本不一致、后端主动断连、session ticket 密钥未共享；需配套 keepalive、HTTP/1.1、SNI 三项配置，并避免盲目关闭证书校验。
proxy_ssl_session_reuse 必须写在 upstream 块里才生效
很多人把 proxy_ssl_session_reuse on; 放在 location 或 server 块里，结果完全没效果。这个指令只在 upstream 块中起作用，且仅对 https:// 后端地址有效。
常见错误配置：
- 在
location中写proxy_ssl_session_reuse on;→ 语法合法但被忽略 - 后端用的是
http://backend:8443（协议写错）→ 指令不触发，Nginx 当成普通 HTTP 处理 - upstream 名称拼错，或
proxy_pass没指向该 upstream → 配置形同虚设
正确写法示例：
upstream api_backend {
server backend1.example.com:443;
server backend2.example.com:443;
keepalive 32;
proxy_ssl_session_reuse on;
}
复用失败的三大高频原因
即使配置了 proxy_ssl_session_reuse on，实际复用率仍可能接近 0%。关键不在“开了没”，而在“能不能复用”。
-
proxy_ssl_protocols和后端 TLS 版本不一致：比如 Nginx 配了TLSv1.2，而后端只支持TLSv1.3，会强制新建完整握手 - 后端主动断连：Spring Boot 默认
server.tomcat.connection-timeout=20000（20 秒），若 Nginx 的keepalive_timeout设为 60s，连接早被后端关了，复用无从谈起 - 多实例后端未共享 session ticket 密钥：启用 session ticket 时（如 Envoy/Nginx 自身作后端），若各实例密钥不同，Nginx 发送的 ticket 无法被其他实例解密，复用失败
验证方式不是看日志有没有报错，而是抓包看 TLS 握手轮次 —— 复用成功时只有 Change Cipher Spec + Finished，而非完整的 ClientHello → ServerHello → Certificate → ... 流程。
A powerful memory management system powered by ReMe that provides persistent cross-session memory, automatic user preference application, and intelligent context compression for OpenClaw.
下载
由 ReMe 驱动的记忆管理系统，支持跨会话记忆持久化、自动应用用户偏好以及智能上下文压缩...
必须配套的三项配置
proxy_ssl_session_reuse 不是独立开关，它依赖三个基础支撑才能稳定复用：
-
keepalive 32;：upstream 级连接池大小，值太小（如 4）会导致连接快速耗尽、被迫新建；建议 ≥20，按后端实例数 × 2～4 设置 -
proxy_http_version 1.1;+proxy_set_header Connection '';：关闭 HTTP/1.0 的 Connection: close 行为，否则 Nginx 每次都发完就关 TCP，SSL 复用失去载体 -
proxy_ssl_server_name on;：确保 SNI 正确传递，避免后端因 SNI 不匹配而拒绝复用或返回默认证书（尤其 CDN 回源、多域名共 IP 场景）
漏掉任意一项，proxy_ssl_session_reuse 就像装了涡轮却没供油——看着有，跑不起来。
生产环境绕过证书校验的底线操作
开发或内网测试时后端用自签名证书，容易直接加 proxy_ssl_verify off; 了事。但这会带来两个隐性问题：
- 部分后端（如某些 Java 客户端）在收到无效证书时会直接关闭连接，导致复用中断
- Nginx 无法缓存该连接的 SSL session，因为 session ID 绑定在证书校验上下文中
更稳妥的做法是：
- 用
proxy_ssl_trusted_certificate /path/to/internal-ca.crt;显式指定私有 CA - 保留
proxy_ssl_verify on;，让校验走可信链而非跳过 - 配合
proxy_ssl_name显式设置期望的证书 CN/SAN（如proxy_ssl_name "backend.internal";），避免 SNI 与证书主体不一致
真正难调的从来不是“怎么开”，而是“为什么开了还复用不了”——它卡在 TLS 层、后端策略、连接生命周期三者的交界处，任何一环松动，复用率就掉回个位数。
