似乎是在 acl 匹配的後端和預設後端之間“隨機”切換

我讓 HAProxy 在前面充當代理：

• 一個 Nginx 實例
• 在 socket.io (websockets) 公開的多個動態服務前的內部負載均衡器

我的問題是，我的連接不時被正確代理到我的 socket.io 集群，然後隨機回退到路由到 NGinx，這顯然很煩人且毫無意義，因為 NGinx 並不意味著不處理請求。

當請求以下格式的 URL 時會發生這種情況：

http://mydomain.com/backends/*

HAProxy 配置中有一個 ACL 來匹配“/backends/*”路徑。

這是我的 HAProxy 配置的簡化版本（刪除了額外的不相關條目並更改了名稱）：

global
   daemon
   maxconn 4096
   user haproxy
   group haproxy
   nbproc 4 

defaults
   mode http
   timeout server 86400000
   timeout connect 5000
   log global


#this frontend interface receives the incoming http requests
frontend http-in
   mode http

   #process all requests made on port 80
   bind *:80

   #set a large timeout for websockets
   timeout client 86400000

   # Default Backend
   default_backend www_backend

   # Loadfire (socket cluster)
   acl is_loadfire_backends path_beg /backends
   use_backend loadfire_backend if is_loadfire_backends


# NGinx backend
backend www_backend
   server www_nginx localhost:12346 maxconn 1024


# Loadfire backend
backend loadfire_backend
   option forwardfor # This sets X-Forwarded-For
   option httpclose
   server loadfire localhost:7101 maxconn 2048

我真的很困惑為什麼這種行為看起來是“隨機的”，因為很難重現它很難調試。

我很感激對此的任何見解。

問題是由於在同一個 TCP 連接上承載多個 HTTP 請求時，第一個請求經過 acl 匹配過程和上下文切換獲得後端，但對於後面的連接不成立。

因此，要解決此問題，應在其前端部分中使用以下任一選項：

option httpclose

或者

option http-server-close

以上對我有用（我選擇了後者，http-server-close）。

我發現這個文件條目非常有用： HAProxy documentation on Google Docs for http-close-server（其他條目也很有用）。

引用自：https://serverfault.com/questions/444923