如何通过 Nginx 监控发现是否有中间人攻击（MITM）在尝试劫持你的 HTTPS-Nginx-PHP中文网

nginx无法直接检测mitm，但可通过日志分析异常tls握手失败、非标准密码套件、evilginx类请求特征及证书透明度监控等间接方式发现蛛丝马迹，并辅以hsts、ocsp装订等配置提升攻击门槛。

如何通过 nginx 监控发现是否有中间人攻击（mitm）在尝试劫持你的 https

Nginx 本身无法直接检测中间人攻击（MITM）是否正在发生，因为它只处理已建立的 TLS 连接后的 HTTP 流量。一旦连接被劫持（比如客户端误信了伪造证书），Nginx 看到的只是“合法”的 HTTPS 请求——它不验证客户端是否连到了真正的服务器，也不参与证书信任链校验。但你可以通过间接指标 + 配合外围机制，在 Nginx 日志和配置层面发现 MITM 尝试的蛛丝马迹。

以下是从运维和安全角度可落地的监控思路：

检查异常证书信任行为（需客户端配合）

Nginx 不做证书校验，但如果你的服务要求客户端双向认证（mTLS），或你控制客户端（如内部 App、企业浏览器），可强制校验服务器证书指纹或 CA。此时，若日志中出现大量 SSL_do_handshake() failed、SSL_read() failed 或 400 Bad Request（因 ClientHello 不兼容/证书校验失败中断），且集中在特定 User-Agent 或 IP 段，可能暗示客户端正尝试连接一个证书不匹配的中间代理（如 Evilginx 伪造站点时未完全模拟 TLS 握手细节）。

常见线索：

错误日志中高频出现：SSL routines::sslv3 alert bad certificate、SSL routines::unknown protocol、no suitable signature algorithm
访问日志里同一 IP 短时间内对多个不同域名（如 a.example.com、b.example.com）发起 TLS 握手失败，但这些域名本不应被同一客户端同时访问

监控非标准 TLS 特征请求

MITM 工具（如 Evilginx、mitmproxy）为实现透明代理，常在 TLS 层留下指纹差异。虽然 Nginx 不解析 TLS，但可通过 $ssl_protocol、$ssl_cipher、$ssl_client_hello（需启用 ngx_http_ssl_module 及相关变量支持）记录并分析：

Nginx Hosting

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

下载

启用扩展日志字段（在 log_format 中加入）：

log_format mitm '$remote_addr - [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_user_agent" "$ssl_protocol/$ssl_cipher" '
                 '$request_time $upstream_response_time';

关注低版本协议（SSLv3、TLSv1.0）或弱密钥交换算法（如 RSA_EXPORT、ADH），这些在现代客户端中极少出现，但在某些 MITM 工具默认配置中仍存在；
大量请求使用相同、非常规的 cipher suite 组合（如 ECDHE-RSA-AES128-GCM-SHA256 单一出现，而正常用户分布广泛）。

识别 Evilginx 类工具的典型行为模式

Evilginx 等框架依赖反向代理 + 页面注入，其流量会暴露在 Nginx 访问日志中：

出现大量来自同一 IP 的、针对多个高价值域名（如 login.microsoft.com、accounts.google.com）的 GET / 或 POST /signin 请求，但 Host 头却是你的合法域名（说明攻击者把你的 Nginx 当跳板）；
请求中携带异常 Referer（如 https://evil-site.net/phishing/login）或自定义 Header（如 X-Evilginx: true）；
日志中反复出现对 .well-known/acme-challenge/ 的 GET 请求（攻击者试图自动申请 Let’s Encrypt 证书，暴露其自动化流程）；
响应体中出现可疑 JS 注入痕迹（需配合响应日志或 WAF，Nginx 默认不记响应体，但可用 echo 模块或 sub_filter 配合 debug 日志临时捕获）。

结合证书透明度（CT）与外部告警

Nginx 不提供 CT 日志查询能力，但你可以：

使用 crt.sh 或 Google Certificate Transparency Report 定期搜索你的域名是否被未授权签发证书；
若发现新证书（尤其由非你使用的 CA 签发），立即检查该证书是否被用于中间人场景（例如，对应 IP 是否出现在你的 access.log 中）；
配合证书监控服务（如 CertSpotter、SSLMate Notify）设置邮件/Webhook 告警。

强化 Nginx 配置以增加 MITM 成本

虽不能“发现”攻击，但能显著提高攻击门槛，让异常行为更容易暴露：

强制 HSTS（含 includeSubDomains 和长 max-age），让浏览器拒绝任何非 HTTPS 或证书错误的连接；
启用 OCSP Stapling，并配置 ssl_stapling_verify on;，使客户端能快速验证证书吊销状态，绕过被篡改的 OCSP 响应；
禁用不安全重定向：避免 http → https 跳转时被劫持，应使用 307/308 严格重定向，并配合 Content-Security-Policy: upgrade-insecure-requests；
对关键接口（如 /login, /api/auth）启用 ssl_verify_client on（需分发客户端证书），彻底阻断未经认证的连接。

不复杂但容易忽略。