标题基本就是全部了。是否有任何特定行为表明某个站点上存在负载均衡器？
答案1
编辑：这将非常困难，甚至不可能（不喜欢这个词），因为拥有 LoadBalancer 的全部目的是使客户端与它的交互透明且基本上不可见。话虽如此，以下是我的原始帖子：
我为一个相当大的网站管理负载平衡器。我们的访问者唯一能知道他们正在访问任何特定应用服务器的迹象就是，我们实际上将服务器的具体名称放在他们的登录页面底部。这有助于我们解决他们遇到的问题。
除此之外，我只能想到一件事，如果我们不遵循该策略，它会“提示”您我们正在运行负载平衡器。您可以按照以下方法判断，但这需要一些运气。
假设负载平衡器设置为将所有流量转发到一台服务器或另一台服务器。或者至少它将一台服务器之间的 ssh 流量转发到另一台服务器。即使您可能没有登录凭据来登录任一框，但如果您尝试登录，两者都会为您提供不同的密钥。因此，如果您第一次尝试通过 ssh 登录，系统会询问您是否要接受密钥。然后，如果您在第二次或第三次请求中很幸运，您将被告知有一个不同的密钥（即它是另一个框）。在 *nix 系统上，您经常会收到警告，这可能是由于中间人攻击造成的。
因此，必须做好以下两件事：
- 远程服务器上的 SSH
- SSH 负载均衡
因此，如果您在相对较短的时间内获得两个密钥，您可能可以假设系统管理员没有更改它们，而是您只是与负载平衡器后面的两台独立机器进行了通信。
注意：还有一项，但这完全是瞎猜。您可以尝试找出此服务器与哪个 IP 块分组。然后假设其中一个特定 IP 地址位于 LB 上（实际上它位于其中一个 IP 上）。
例如，负载均衡器位于 XXX.XXX.XXX.5。然后将设置 LB 以捕获至少一个其他 IP 地址的所有流量。它通常不会转发 XXX.XXX.XXX.5 的流量（我拥有的商用硬件肯定不会这样做）。因此您可以指望那里有一个管理地址。
如果 LB 设置为允许所有外部主机的管理员，您可能能够在 IP 地址后附加类似 /admin 的内容，直到找到 LB。这假设 LB 使用该路径进行管理。
答案2
没有确定的方法，但你可以寻找各种各样的线索。
- nmap 它。nmap 可以为你正在通信的任何设备的操作系统提供一些线索。如果它显示 BSD 并且 URL 以 .aspx 结尾，那么你就找到了一些东西。
- cookies：许多负载平衡器添加（或可以添加）会话 cookie。查找任何奇怪的并在谷歌上搜索它们，如果你登陆 F5 支持论坛，Viola。
- 各种其他标头：许多标头基于诸如项目是否被缓存（和其他原因）之类的因素添加标头。查找任何有趣的标头并在谷歌上搜索它们。
- 在页面上或埋在 html 注释中，开发人员通常会添加“由 web7 提供服务”以帮助他们排除故障。
- 从多个不同的 ip 快速请求相同的内容并比较 ETag 标头。 Apache 默认根据文件系统 inode 设置 etag，并且许多管理员从未调整过这一点，因此如果您看到相同内容有不同的 Etag，您可以猜测它来自不同的服务器（仅适用于 apache，仅在未调整时才有效，仅在非共享文件系统时才有效）。
说实话，我只希望所有这些都能给你一个有意义的答案，比如四分之一，总的来说，你真的无法知道，除非像凯瑟琳所说的“出了什么问题”。
答案3
IP ID 会根据每个 IP 堆栈而变化，因此 IP 主机位于负载均衡器“后面”。像 hping 这样的工具可以为您提供这样的功能：监视不属于同一范围的 ID，或者 - 即使出于某种奇怪的巧合 - 不增加的 ID：
hping3 www.yoursite.com -S -p 80 (or whatever)
以上内容在应用层“之下”捕获了 LB 后面的多个主机。
答案4
如果负载均衡器正在执行基于 cookie 的持久性那么查看 cookie 可能会给你一些线索。