如何配置 Nginx 实现针对不同移动端（UA）的差异化 SSL 策略-Nginx-PHP中文网

nginx无法基于user-agent动态切换ssl参数，因tls握手早于http请求；可行方案是：①用不同域名+独立server块实现ssl策略隔离，②用openresty在http层按ua分流后端。

如何配置 nginx 实现针对不同移动端（ua）的差异化 ssl 策略

Nginx 本身不支持基于 User-Agent（UA）动态切换 SSL/TLS 协议版本、加密套件或证书。SSL 握手发生在 HTTP 请求之前，而 User-Agent 是 HTTP 请求头的一部分，此时 TLS 层早已完成协商——Nginx 无法在 SSL 握手阶段读取或响应 UA 字符串。

但你可以通过组合策略实现“效果上”的移动端差异化 SSL 行为，关键在于：把“差异化”从 SSL 层下沉到 HTTP 层，并配合前置的连接控制或架构设计。以下是真正可行、生产环境验证过的方案：

✅ 方案一：用不同域名 + 不同 server 块实现物理隔离的 SSL 策略

最稳定、最符合 TLS 规范的做法：为移动端单独分配子域名（如 m.example.com），并为其配置独立的 server 块，使用更宽松的 SSL 参数（例如兼容老旧 Android WebView 或 iOS 9+）。

# 移动端专用域名（TLS 兼容性优先）
server {
    listen 443 ssl http2;
    server_name m.example.com;

    ssl_certificate     /etc/ssl/certs/m.example.com.crt;
    ssl_certificate_key /etc/ssl/private/m.example.com.key;

    # 兼容旧客户端（如 Android 4.4、iOS 9）
    ssl_protocols       TLSv1.1 TLSv1.2;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers off;

    location / {
        proxy_pass http://backend-mobile;
        proxy_set_header Host $host;
    }
}

# 桌面端/现代浏览器（TLS 安全性优先）
server {
    listen 443 ssl http2;
    server_name www.example.com example.com;

    ssl_certificate     /etc/ssl/certs/example.com.crt;
    ssl_certificate_key /etc/ssl/private/example.com.key;

    # 仅支持 TLS 1.2+，禁用弱算法
    ssl_protocols       TLSv1.2 TLSv1.3;
    ssl_ciphers         ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384;
    ssl_prefer_server_ciphers on;

    location / {
        proxy_pass http://backend-web;
    }
}

⚠️ 注意：需确保 m.example.com 已 DNS 解析、ICP 备案（如适用）、且拥有匹配的 SSL 证书（可为通配符 *.example.com 或单独申请）。

SSL Certificate Monitor
检查一个或多个域名的 SSL/TLS 证书到期时间、颁发者、协议及 SAN 信息，用于应要求检查证书、监控到期或验证 HTTPS 等场景。

下载

✅ 方案二：用 Nginx + Lua（OpenResty）在 TLS 握手后做 UA 路由（非 SSL 策略切换，而是流量分流）

如果你必须共用同一域名（如 example.com），可用 OpenResty（Nginx + Lua）在 SSL 握手完成后、HTTP 请求解析时，根据 $http_user_agent 将请求代理到不同后端，并让后端服务返回适配内容（如轻量 HTML、JSON API、压缩资源等）。

# 需启用 lua_module（OpenResty 或编译时加 --with-http-lua-module）
location / {
    access_by_lua_block {
        local ua = ngx.var.http_user_agent or ""
        if string.match(ua, "Mobile") and not string.match(ua, "iPad") then
            ngx.var.backend_upstream = "backend-mobile"
        else
            ngx.var.backend_upstream = "backend-web"
        end
    }

    proxy_pass http://$backend_upstream;
    proxy_set_header Host $host;
}

? 说明：

此方案不改变 SSL 参数，所有客户端仍走同一套 TLS 配置（建议按现代标准设为 TLSv1.2+）；

差异化体现在后续 HTTP 响应（页面结构、JS/CSS 加载逻辑、API 返回字段等）；

更安全、更易维护，也符合 HTTPS 设计本意。

❌ 不可行方案（常见误区）

试图在 ssl_certificate 或 ssl_ciphers 中用 map 或 if 动态赋值
→ Nginx 在 ssl_* 指令中不支持变量（语法错误，nginx -t 直接失败）。
*用 `proxyssl控制上游连接的 TLS（如proxy_ssl_protocols`）来“反向影响客户端”**
→ 这只影响 Nginx 到后端的连接，与客户端到 Nginx 的 SSL 无关。
依赖 $http_user_agent 配置 ssl_session_cache 或 ssl_buffer_size
→ 这些指令作用于 SSL 握手上下文，无法按请求头条件化。