標題差不多就是這樣了。是否有任何特定行為表明某個站點上存在負載平衡器？
答案1
編輯：如果不是不可能的話，這將是非常困難的（不喜歡這個詞），因為擁有 LoadBalancer 的全部目的是使客戶端與其交互透明且基本上不可見。話雖這麼說，這是我的原始帖子：
我為一個相當大的網站管理一個負載平衡器。唯一表明我們的訪客正在訪問任何特定應用程式伺服器的跡像是，我們實際上將伺服器的特定名稱放在了他們的登入頁面的底部。這有助於我們解決他們遇到的問題。
除此之外，我能想到的只有一件事會讓您「陷入」這樣一個事實：如果我們不遵循該政策，我們正在運行負載平衡器。您可以透過以下方法判斷，但這需要一些運氣。
假設負載平衡器設定為將所有流量轉送到一台伺服器或另一台伺服器。或者至少它將一台伺服器之間的 ssh 流量轉送到另一台伺服器。即使您可能沒有登入憑證來登入這兩個框，如果您嘗試登錄，兩個框都會為您提供不同的金鑰。接受密鑰。然後，如果您幸運地收到第二或第三個請求，您會被告知有一把不同的鑰匙（即，它是另一個盒子）。在 *nix 系統上，您經常會收到警告，這可能是由於中間人攻擊造成的。
因此，有兩件事必須到位：
- 遠端伺服器上的 SSH
- SSH負載平衡
因此，如果您在相對較短的時間內獲得兩個金鑰，您可能會認為系統管理員沒有更改它們，而是您剛剛與負載平衡器後面的兩台單獨的電腦進行通訊。
注意：還有另一件物品，但它是在黑暗中真實拍攝的。您可以嘗試找出該伺服器與哪個 IP 區塊分組。然後假設將這些特定 IP 位址之一放置在 LB 上（實際上它位於這些 IP 之一上）。
例如，負載平衡器放置在 XXX.XXX.XXX.5。然後，LB 將被設定為捕獲至少一個附加 IP 位址的所有流量。它通常不會轉送 XXX.XXX.XXX.5 的流量（我擁有的商業硬體絕對不會這樣做）。所以你可以信賴有管理地址。
如果 LB 設定為允許來自所有外部主機的管理，您可以將 /admin 之類的內容附加到 IP 位址，直到找到 LB。這假設負載平衡器使用該路徑進行管理。
答案2
雖然沒有確定的方法，但您可以尋找一些線索。
- nmap它。 nmap 可以提供您正在交談的任何裝置的作業系統的一些線索。如果它顯示 BSD 並且 url 以 .aspx 結尾，那麼您就明白了。
- cookies：很多負載平衡器新增（或可以新增）會話cookie。如果您訪問 F5 支援論壇，viola，請尋找任何奇怪的內容並用 google 搜尋它們。
- 各種其他標頭：許多人根據項目是否被快取（以及其他原因）等因素添加標頭。尋找任何有趣的標題並用谷歌搜尋它們。
- 在頁面上或隱藏在 html 註釋中，開發人員通常會添加「由 web7 提供服務」來幫助他們排除故障。
- 從多個不同的 ip 快速請求相同的內容並比較 ETag 標頭。 Apache 預設將etag 建立在檔案系統inode 的基礎上，許多管理員從來沒有時間進行調整，因此，如果您看到相同內容的不同Etag，您可以猜測它來自不同的伺服器（僅適用於apache ，僅適用於如果未調整，則僅在不是共用檔案系統時才有效）。
說實話，我只希望所有這些都能給你一個有意義的答案，比如四分之一，但總的來說，除非像凱瑟琳所說的那樣“出了什麼問題”，否則你無法真正知道。
答案3
每個 IP 堆疊的 IP ID 都會發生變化，因此 IP 主機位於負載平衡器「後面」。像 hping 這樣的工具可以為您提供：監視不屬於同一範圍的 ID，或者 - 即使由於某種奇怪的巧合足夠接近 - 不增加：
hping3 www.yoursite.com -S -p 80 (or whatever)
上面捕獲了應用程式層“下方”LB 後面的多個主機。
答案4
如果負載平衡器正在執行基於cookie的持久化那麼查看cookies可能會給你一些線索。