nginx 不支持按客户端身份动态拦截 ssl 套件，仅能通过 ssl_ciphers 白名单、ssl_prefer_server_ciphers on 和 ssl_protocols tlsv1.2 tlsv1.3 实现全局静态策略，彻底排除 rc4/3des/sha1 等弱算法，强制前向保密与 aead 加密。

Nginx 本身不支持“按客户端身份（如 IP、User-Agent）动态拦截特定 SSL 密码套件”，它没有运行时判断客户端特征后选择性拒绝某类 cipher 的能力。真正的拦截发生在 TLS 握手阶段，且是**全局、协议层的静态策略**：Nginx 只能通过 `ssl_ciphers` 白名单 + `ssl_protocols` + `ssl_prefer_server_ciphers on` 这组配置，在协商初期就**彻底排除所有含弱算法的套件**，让不兼容的客户端根本连不上——这不是“针对恶意客户端的拦截”，而是对**所有客户端统一执行的安全基线**。 所以，所谓“针对特定恶意客户端”的需求，实际应转化为：**用强密码策略堵住所有可能被滥用的弱算法入口，让已知攻击工具（如使用 RC4/3DES/SHA1 的扫描器或旧版漏洞利用程序）无法完成握手**。

只保留高安全等级的密码套件

明确列出仅支持前向保密（PFS）、AEAD 认证加密、密钥长度 ≥128 位的套件，剔除一切含以下关键词的 cipher：

• RC4（如 ECDHE-RSA-RC4-SHA）
• 3DES / DES（如 ECDHE-RSA-DES-CBC3-SHA）
• MD5 / SHA1（如 ECDHE-RSA-AES128-SHA）
• 静态 RSA 密钥交换（无 PFS，如 RSA-AES128-GCM-SHA256）

推荐写法（直接复制使用）：

ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384';

强制服务端主导密码选择

必须启用该指令，否则客户端可绕过服务器白名单，强行协商出它支持但已被你禁用的弱套件：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

ssl_prefer_server_ciphers on;

配套禁用不安全协议版本

仅收紧 cipher 不够——TLSv1.0/v1.1 允许大量弱套件协商成功。必须在每个 server 块中单独配置：

ssl_protocols TLSv1.2 TLSv1.3;

注意：
• 不能写在 http 或 location 块里，无效；
• 多个域名/虚拟主机，每个 server 都要加；
• 禁止写成 TLSv1.2+ 或漏掉分号。

验证是否真正生效

改完配置后，必须实测，nginx -t 不检查 cipher 协商结果：

• 测试 RC4 是否被拒：openssl s_client -connect example.com:443 -cipher RC4 -tls1_2 -servername example.com → 应返回 no ciphers available 或握手失败
• 测试 3DES 是否失效：nmap --script ssl-enum-ciphers -p 443 example.com | grep -i des → 输出应为空
• 用 SSL Labs Test 扫描，确认 “Handshake Simulation” 中所有老旧客户端（如 IE6、Android 4.4）均显示 Failed 或 No SNI