Nginx 报 SSL 共享缓存大小 conflicts with already declared size

修改一个 HTTPS 站点的配置后，nginx -t 报共享内存区大小冲突，例如：

the size 52428800 of shared memory zone "SSL" conflicts with already declared size 4194304

这条错误中的 SSL 是共享区名称，两个数字是相互冲突的字节数。常见情况是一处配置了 ssl_session_cache shared:SSL:4m;，另一处又写了 shared:SSL:50m。即使它们位于不同 server 块，同名也仍然指向同一个共享缓存，不能各自声明不同大小。

这里讨论 Nginx HTTP SSL 模块的会话缓存配置。它不缓存网页响应，也不是 proxy_cache 的空间上限；修改响应缓存配置不会修复这条错误。

找到同一个名称的所有声明

先保留错误中的文件名、行号、共享区名称和两个大小。行号通常指向遇到冲突的位置，但更早的那次声明还可能位于主配置、公共 include 或其他站点文件中。

在实际运行 Nginx 的同一环境检查配置。下面假设使用默认配置路径；服务若指定了 -c 或 -p，检查时也要使用相同参数：

nginx -t
nginx -T

-T 在测试配置的同时输出配置文件，自 Nginx 1.9.2 起提供。配置解析提前失败时，不要假定已经获得完整输出；根据报错路径继续检查实际 include 的文件。主机上的另一个 Nginx 安装、容器外的配置副本，都不能代替当前实例使用的文件。

配置输出可能含认证参数或内部地址，保留和分享前注意脱敏。查找 ssl_session_cache 的每一处有效声明，比较 shared: 后的名称和大小，同时检查自动生成的 SSL 配置片段。仅删掉报错行，可能掩盖原本需要保留的站点设置。

下面两个片段放在同一有效配置中会冲突：

http {
    ssl_session_cache shared:SSL:4m;

    server {
        ssl_session_cache shared:SSL:50m;
        # 原有监听、证书及其他配置
    }
}

它们不是两个独立缓存。若原本就希望多个虚拟主机共用一块缓存，应先确定合适的总容量，再统一所有同名声明。可以在 http 层保留一项，并去掉不需要的下层覆盖；也可以在相关 server 中使用完全一致的同名、同大小设置。不要只修改其中一份公共模板。

例如，决定共用原来的 4 MiB 区域时，各处使用：

ssl_session_cache shared:SSL:4m;

4m 只是解释上述冲突的示例，不是推荐给所有站点的容量。相同名称供多个虚拟主机使用，并不会按站点数量重复分配同样大小的区域；反过来也不能只按站点数量机械相乘。应结合实际会话规模和可用内存配置。

如果站点确实需要独立缓存，可以选择不同且未占用的名称，例如：

# 放在对应的第一个 server 内
ssl_session_cache shared:site_a_sessions:4m;

# 放在对应的第二个 server 内
ssl_session_cache shared:site_b_sessions:4m;

这会创建两个区域，内存预算也应按两个区域计算。改名改变了共享关系，不应只是为了让测试通过而随意给每个文件生成新名字。对于需要严格区分 TLS 会话策略的部署，还应核对默认虚拟主机与握手阶段的配置选择，不能把缓存名称当成完整的站点隔离方案。

只修正本次缓存声明的冲突，保留证书、私钥、协议与访问控制配置。不需要把 HTTPS 改成 HTTP，也不应通过关闭全部会话缓存来替代查明重复声明。

修改前备份所有涉及的有效配置文件。先用同一入口运行 nginx -t，确认不再有共享区冲突或其他配置错误，再按现有服务管理方式重载。若实例由命令行直接管理，可在测试通过后使用：

nginx -t && nginx -s reload

服务使用非默认路径时，两条命令都要保持相同配置参数。重载信号发送成功不等于新配置已经生效，应检查错误日志、master/worker 状态，并验证各受影响站点的 HTTPS 握手和正常请求。

Nginx 在重载时若无法应用新配置，会继续使用旧配置；因此旧站点还能访问，也不能证明本次变更成功。反过来，首次启动就失败的实例没有旧 worker 可继续服务，应按启动日志判断。

若改动不符合预期，恢复此前备份的同一组配置，测试后重载。调整会话缓存可能让客户端重新完成完整握手；这不等于证书失效，也不需要删除证书或重新签发。