频繁出现“host is blocked”错误，本质是mysql因连续连接失败触发安全机制，需从网络稳定性、配置优化和应用层重试策略三方面根治，而非依赖每日手动flush hosts。
频繁出现“host is blocked”错误，本质是mysql因连续连接失败触发安全机制，需从网络稳定性、配置优化和应用层重试策略三方面根治，而非依赖每日手动flush hosts。
MySQL 的 max_connect_errors 参数（默认值通常为 100）是一个安全防护机制：当同一客户端 IP 在未成功建立任何有效连接的情况下，连续发生指定次数的连接失败（如超时、认证失败、拒绝连接等），MySQL 便会将该主机加入阻塞列表，并拒绝后续所有连接请求——这正是你看到 Host '167.71.227.200' is blocked... 错误的根本原因。
⚠️ 关键误区警示：仅执行 FLUSH HOSTS; 或盲目调高 max_connect_errors（如设为 9999）无法解决问题，它只是掩盖症状，反而可能延缓对真实故障的发现。
✅ 正确解决路径（按优先级排序）
1. 排查并修复网络不稳定问题
你的 LEMP 应用部署在 DigitalOcean，而 MySQL 可能位于远程服务器（甚至跨区域 VPC）。常见诱因包括：
- 应用服务器与数据库间存在高丢包率或瞬时网络抖动；
- 使用公网 IP 直连 MySQL（而非私有网络/VPC 内网）；
- 防火墙、云平台安全组或负载均衡器中途中断 TCP 握手。
✅ 建议操作：
- 将应用与 MySQL 部署在同一 DigitalOcean region，并通过 Private Network（内网） 通信（确保双方启用 Private Networking）；
- 使用 mtr 10.135.128.42（替换为你的 MySQL 内网 IP）持续监测双向网络质量，重点关注 Loss% 和 Avg 延迟；
- 检查 MySQL 绑定地址：确认 bind-address = 10.135.128.42（而非 0.0.0.0 或 127.0.0.1），并重启服务：
sudo systemctl restart mysql
2. 优化应用层连接行为
避免因代码缺陷引发大量无效连接尝试：
- 确保 PHP-FPM 或应用进程复用持久连接（如 PDO 的 PDO::ATTR_PERSISTENT => true），而非每次请求新建连接；
- 添加连接重试逻辑（带退避机制），例如使用 mysqli 时：
$retries = 3; while ($retries > 0) { $conn = @mysqli_connect($host, $user, $pass, $db, $port); if ($conn) break; $retries--; usleep(500000); // 0.5s 指数退避 } if (!$conn) die("Failed to connect after retries"); - 检查日志中是否高频出现 Access denied for user 或 Connection refused —— 这往往指向密码错误、用户权限缺失或 MySQL 未监听对应端口。
3. 合理调整 MySQL 安全参数（辅助手段）
仅在确认网络与应用无误后微调，不推荐作为主方案：
-- 查看当前值 SHOW VARIABLES LIKE 'max_connect_errors'; -- 临时调整（重启失效） SET GLOBAL max_connect_errors = 200; -- 永久生效：编辑 /etc/mysql/mysql.conf.d/mysqld.cnf [mysqld] max_connect_errors = 200
? 注意：max_connect_errors 不应超过 500；同时建议同步检查 connect_timeout（默认10秒），若网络延迟普遍 >3s，可适度增至 15s，避免因超时误判为失败。
? 总结
每日 FLUSH HOSTS 是系统在“报警”，而非“治疗”。真正可靠的方案是：通过内网部署消除网络不确定性 + 应用层健壮连接管理 + 日志驱动的问题定位。完成上述优化后，FLUSH HOSTS 将不再是日常运维动作，而是极少数异常场景下的应急操作。
