PCI-DSS合规核心是禁用TLSv1.0/TLSv1.1、启用ECDHE前向保密套件、强制Secure/HttpOnly/SameSite Cookie及HSTS等安全响应头；必须显式配置ssl_protocols TLSv1.2 TLSv1.3、ssl_ciphers含ECDHE-AES256-GCM-SHA384、add_header Set-Cookie ... always与Strict-Transport-Security。
要让 Nginx 配置通过 PCI-DSS 合规扫描，核心不是“加功能”，而是精准满足几项不可协商的硬性要求。TLSv1.0 必须彻底禁用，加密套件必须支持前向保密，Cookie 属性必须强制注入，安全响应头不能缺失或被覆盖。
禁用 TLSv1.0 及弱协议版本
这是 PCI-DSS 最刚性门槛——只要配置中出现 TLSv1（即 TLSv1.0）或 TLSv1.1，任何扫描工具（如 Qualys SSL Labs、myssl.com）都会直接判定不合规。
- 在
http或server块中，将ssl_protocols明确设为：ssl_protocols TLSv1.2 TLSv1.3; - 务必删除所有含
TLSv1、TLSv1.1的写法，包括注释里的残留模板 - 修改后必须执行
nginx -t校验语法，再用nginx -s reload生效；仅重启服务不保证热加载成功
配置 PCI-DSS 认可的加密套件
不能只追求“兼容性”或“强度高”，必须满足 PCI-DSS 对密钥交换和签名算法的明确要求：必须使用 ECDHE 或 DHE，禁用 RSA 密钥交换，禁用 SHA1/MD5/RC4 等已淘汰算法。
- 推荐且经扫描验证通过的配置：
ssl_ciphers "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384"; - 必须添加：
ssl_prefer_server_ciphers on;，防止客户端协商降级 - 避免使用 AES128 以下强度、SHA256 以下哈希、或含
RC4/MD5的套件
强制注入安全 Cookie 属性
PCI-DSS 要求会话 Cookie 必须同时具备 Secure、HttpOnly 和 SameSite=Lax（或 Strict）。后端生成的 Cookie 在反向代理场景下极易丢失 Secure 标志，必须由 Nginx 统一补全。
- 使用
add_header Set-Cookie ... always;，always参数关键——否则仅对 2xx 响应生效，302 跳转或 4xx 错误中 Cookie 就漏了安全属性 - 示例（需配合变量或实际会话 ID）：
add_header Set-Cookie "JSESSIONID=$sessionid; Path=/; HttpOnly; Secure; SameSite=Lax" always; - 若前端需 JS 读取部分 Cookie（如刷新令牌），不应全局禁用 HttpOnly，而应拆分：敏感会话 ID 设 HttpOnly，控制类 Cookie 单独命名并豁免
启用关键安全响应头
HSTS 与 X-Content-Type-Options 是扫描高频扣分项，缺一不可，且必须正确配置作用域与参数。
- HSTS：
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
（63072000 秒 = 2 年，includeSubDomains强制子域也走 HTTPS） - 内容类型保护：
add_header X-Content-Type-Options "nosniff" always; - 补充建议（非 PCI-DSS 强制但强烈推荐）：
add_header X-Frame-Options "SAMEORIGIN";add_header X-XSS-Protection "1; mode=block";
配置完成后，建议用 Gixy 工具做静态扫描，它能识别 add_header 覆盖、Host 头欺骗、SSRF 风险等隐藏问题。一次完整合规，靠的是每处细节的确定性，而不是“差不多”。
