nginx无法直接识别mitm劫持，但可通过error.log中的tls握手失败（如version too low、no shared cipher）、access.log中异常sni/协议/密码套件分布及抓包分析client hello篡改痕迹（sni不一致、alpn缺失）发现可疑劫持尝试。
Nginx 本身不参与客户端证书信任链校验，也无法直接识别中间人（MITM）是否已成功劫持连接。但当 MITM 工具（如 Evilginx、mitmproxy 或企业级 SSL 解密网关）尝试拦截流量时，常在 TLS 握手阶段暴露异常行为——这些行为会留下可观测痕迹，可通过 Nginx 日志、抓包和配置联动识别蛛丝马迹。
重点不是“确认已被劫持”，而是“发现可疑劫持尝试”。真正成功的 MITM 往往对 Nginx 完全透明，但大多数拦截工具在模拟服务端或转发 Client Hello 时存在协议层破绽。
查看 error.log 中高频 TLS 握手失败模式
MITM 设备若未完整实现 TLS 协议栈，或使用弱/过时密码套件，容易触发 OpenSSL 底层告警：
出现
SSL_do_handshake() failed (SSL: error:1417D18D:SSL routines:tls_process_client_hello:version too low)
→ 可能是 MITM 强制降级到 TLSv1.0，而 Nginx 已禁用该版本出现
no shared cipher或tlsv1 alert unknown ca
→ MITM 使用自签名 CA 签发的伪造证书，但未正确注入其根证书到客户端信任库；或其支持的加密套件与 Nginx 无交集出现
SSL routines::sslv3 alert bad certificate或unknown protocol
→ 常见于代理工具错误转发非 TLS 流量（如 HTTP 请求打到 443 端口），或 Client Hello 结构被篡改
✅ 操作建议：
- 在
http { }块中启用 debug 级 SSL 日志：error_log /var/log/nginx/ssl_debug.log debug;- 配合
grep -i "handshake\|alert\|cipher" /var/log/nginx/ssl_debug.log | tail -50快速定位异常集中时段与 IP
分析 access.log 中 TLS 协商特征
Nginx 支持记录 $ssl_protocol、 $ssl_cipher、$ssl_server_name 等变量，可用于识别非常规握手行为：
log_format mitm '$remote_addr - [$time_local] "$request" $status '
'"$http_user_agent" "$ssl_protocol/$ssl_cipher" '
'$ssl_server_name $request_time';
access_log /var/log/nginx/mitm_access.log mitm;
关注以下线索：
- 同一 IP 在短时间内发起大量不同
server_name的 TLS 握手（如a.com,b.com,admin.example.net），且多数失败 -
ssl_protocol显示为SSLv3或TLSv1.0，而你的业务已明确禁用（ssl_protocols TLSv1.2 TLSv1.3;） -
$ssl_cipher包含已淘汰算法，如RC4-SHA、DES-CBC3-SHA、ADH-AES128-SHA -
$ssl_server_name为空或为明显扫描器域名（如test.example.com,scan-01.local）
✅ 操作建议：
- 用
awk '{print $1,$12}' /var/log/nginx/mitm_access.log | sort | uniq -c | sort -nr | head -20统计高频异常 SNI + IP 组合- 对命中 IP 设置
limit_conn addr 1;或结合 fail2ban 封禁
抓包验证 Client Hello 是否被篡改
MITM 设备必须终止并重建 TLS 连接，因此 Client Hello 由真实客户端发出，但可能被中间设备修改或重放。关键看两点：
-
SNI 字段是否一致：客户端请求
example.com，但抓包显示 Nginx 收到的 SNI 是fake.example.com或为空 → 表明中间有代理重写了 SNI -
ALPN 和 Supported Groups 扩展是否残缺：标准浏览器 Client Hello 包含
h2、http/1.1ALPN 值；MITM 工具常只填http/1.1，甚至缺失 ALPN
执行：
tcpdump -i any 'port 443 and tcp[tcpflags] & (tcp-syn|tcp-ack) != 0' -w mitm.pcap -c 100
Wireshark 中过滤：tls.handshake.type == 1 && ip.addr == <client_ip></client_ip>，检查：
-
Server Name Indicator值是否合理 -
Application-Layer Protocol Negotiation是否包含预期值 -
Supported Groups是否缺失x25519或secp256r1等主流曲线
✅ 操作建议：
- 若发现大量 Client Hello 缺失 ALPN 或 SNI 异常，可配合
ssl_reject_handshake on;主动拒绝，减少信息泄露面
配合 HSTS 和 OCSP 装订提高攻击门槛
虽然不能靠 Nginx “检测” MITM，但可大幅增加其成功难度：
启用 HSTS 强制浏览器只走 HTTPS 并缓存有效证书链：
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;-
开启 OCSP stapling，让客户端无需向 CA 查询证书状态，避免被劫持 OCSP 请求：
ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/ssl/fullchain.pem; resolver 8.8.8.8 1.1.1.1 valid=300s;
-
禁用不安全协议与弱套件（从源头过滤不兼容 MITM 工具）：
ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256; ssl_prefer_server_ciphers off;
不复杂但容易忽略
