需要检查的几件事：

审查wp_salt. 确保所有web服务器都在中的同一组盐上运行wp-config.php 文件理想情况下，这些应该从单个位置镜像。

查看is_ssl() 并确保此功能正确检测所有web服务器上的SSL。我已经看到，当负载平衡器在端口上建立内部连接时，这个小功能会引起很多麻烦80 到web服务器。如果is_ssl() 没有检测到这一点（由于负载平衡），这可能导致此问题；i、 例如，可能的cookie协议更改。

一个快速解决方案是检查wp-config.php

if ( ! empty( $_SERVER[\'HTTP_X_FORWARDED_PROTO\'] )
        && strcasecmp( $_SERVER[\'HTTP_X_FORWARDED_PROTO\'], \'https\' ) === 0 ) {
    $_SERVER[\'HTTPS\'] = \'on\'; // Convince WordPress.
}

查看$_SERVER[\'REMOTE_ADDR\'] 环境变量，并确保在所有web服务器上以相同的方式填充该变量。WordPress有许多插件将使用此功能，而不考虑负载平衡的情况。

最简单的检查方法是转储<?php phpinfo(); 在一些web服务器上，检查它们是否都正确设置了此选项。或者实际IP地址最终是否为HTTP_X_FORWARDED_FOR, HTTP_CLIENT_IP, 还是别的什么？简而言之，通过修复REMOTE_ADDR.

确保所有web服务器的系统时间同步。

更仔细地研究任何以防止暴力攻击为目标的插件，因为这些插件更有可能进行一些严格的验证；e、 例如，测试用户代理、IP地址、IP地址的更改等。他们的工作不是被愚弄，但有时会产生误报。

如果问题仍然存在，请发布您正在运行的活动插件列表和您提到的Nginx配置。FastCGI参数以及您可能有或没有的任何代理配置都值得一看。