Nginx 日志出现 \xFF 二进制乱码与 400 错误？一次典型 MySQL 端口扫描分析
在维护 Nginx 网站日志时，经常会遇到一些看起来像 “乱码” 的异常请求记录，这类请求往往伴随着 400 Bad Request 状态码，让不少运维和站长困惑不已。
今天我们就通过一条真实的 Nginx 访问日志，完整分析一次典型的恶意扫描行为，让大家以后遇到类似日志不再迷茫。
一、原始日志记录
45.142.154.103 - - [31/May/2026:00:08:19 +0800] "\xFF\x00\x00\x00\x00\x00\x00\x00\x00\x7F\x03\x01NULL\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00" 400 166 "-" "-"
第一眼看上去，请求内容是大量 \x00 空字节、\xFF 和乱码，没有正常的 GET/POST 等 HTTP 方法，服务器直接返回 400 错误。
二、日志字段简单解释
45.142.154.103：发起请求的来源 IP[31/May/2026:00:08:19 +0800]：请求时间- 中间一长串十六进制乱码：实际请求内容
400：HTTP 状态码，表示非法请求- 末尾
-：无 Referer、无 User-Agent
三、核心：这段 \xFF 开头的乱码到底是什么？
通过协议特征可以明确判断：
这是一段标准的 MySQL 数据库连接握手数据包，被错误发送到了 Web 80/443 端口。
关键特征：
- 以
\xFF开头，是 MySQL 协议的典型标识 - 包含版本协商字段
\x7F - 大量
\x00空字节填充，符合 MySQL 握手包结构 - 无任何 HTTP 语义，不属于正常网页访问
简单说：
扫描器本来想扫 3306 端口，结果把 MySQL 探测包发到了我的网站端口。
四、来源 IP 是什么性质？
IP：45.142.154.103
这类 IP 通常属于：
- 僵尸网络扫描节点
- 自动化数据库弱口令爆破脚本
- 全网端口扫描器
- 常见于东欧、俄罗斯等机房段
它们并不针对你个人，只是在全网批量扫 IP 段，寻找开放的 MySQL、Redis、Mongo、PostgreSQL 等未授权访问数据库。
五、这种请求危险吗？
结论：完全安全，没有危害。
原因：
- 请求发错了端口，Web 服务器无法识别
- Nginx 直接返回 400，拒绝处理
- 没有执行任何代码，没有漏洞利用
- 没有访问敏感路径，没有上传文件
- 服务器没有暴露任何敏感服务
我们看到的 400，本质上是防御成功的记录。
六、遇到这类日志应该怎么办？
- 不必惊慌，这是互联网常态
- 无需手动封禁，除非同一 IP 高频密集攻击
- 建议安装
fail2ban，自动屏蔽频繁恶意 IP,觉得最近fail2ban还是有效果的。 - 确保 MySQL、Redis 等服务仅内网访问，不暴露公网
- 定期查看日志，了解服务器暴露面即可
七、总结
Nginx 中出现 \xFF 开头的二进制乱码 + 400 错误，99% 情况都是数据库扫描流量误投 Web 端口。
- 请求来源：自动化僵尸网络扫描
- 内容：MySQL 协议握手包
- 结果：被 Web 服务器正常拒绝
- 风险：无
下次再看到类似日志，你就可以直接判断：又是扫错端口的脚本，不用管。