Score:0

How to clear 'sticky' HAProxy sessions?

tr flag

So, originally my haproxy.cfg looks like this (snippet):

frontend https_in
    mode http
    option httplog
    option forwardfor
    bind 192.168.150.2:443 ssl crt /etc/haproxy/ssl_cert/star_some_domain.pem crt /etc/haproxy/ssl_cert/star_sub_some_domain.pem
    acl host_git      hdr(host) -i git.some.domain
    acl host_kibana   hdr(host) -i kibana.sub.some.domain

    use_backend gitserver if host_git
    use_backend kibanaserver if host_kibana

    default_backend webserver1

The backend for webserver1 is getting overloaded, so we moved some domains to a new server, and the newest haproxy.cfg looks like this (snippet):

frontend https_in
    mode http
    option httplog
    option forwardfor
    bind 192.168.150.2:443 ssl crt /etc/haproxy/ssl_cert/star_some_domain.pem crt /etc/haproxy/ssl_cert/star_sub_some_domain.pem
    acl host_git      hdr(host) -i git.some.domain
    acl host_kibana   hdr(host) -i kibana.sub.some.domain
    acl is_website    hdr(host) -i sub.some.domain
    acl is_website    hdr(host) -i www.sub.some.domain
    
    use_backend gitserver if host_git
    use_backend kibanaserver if host_kibana
    use_backend websrv if is_website

    default_backend webserver1

# "websrv" and "webserver1" are different backends

The most perplexing thing is that some browsers seem to insist / get redirected to the "webserver1" backend instead of the "websrv" backend; opening Private browser / Incognito gets redirected properly to "websrv".

So I suspect there's some sort of "sticky session" going on.

How do I list and/or clear these "sticky sessions"?

jp flag
Browsers cache redirects in their own caches.
pepoluan avatar
tr flag
@AlexD I've tried clearing the browser cache multiple times, clearing cookies related to the domains until none left, and I still "stick" to the old server "webserver1". Finally I resorted to clearing ALL cookies and only then I get routed to "websrv". Very strange. What cookie/cache interaction does this?
jp flag
Clearing cached redirect can be tricky, see https://superuser.com/questions/1166181/how-to-clear-cached-redirects-in-chrome
pepoluan avatar
tr flag
@AlexD unfortunately, that doesn't seem to be applicable on my case ... that question seems to be about the browser caching the domain name resolution. In my case, the domain name resolution does not change (still pointing to the same publicly-accessible HAProxy server). I may be wrong, though. Let me do some of the suggested actions.
jp flag
No, the question I linked is about caching of redirects. Change of DNS has the same relation as your change of the backends.
Score:0
pe flag

You don't show your stick table config or your server line configs. Its more likely to be a cookie on your real server?

To Show a Table use:

echo "show table Abuse" | socat unix-connect:/var/run/haproxy.stat stdio

To clear an entry use:

echo "clear table  Abuse key 127.0.0.1" | socat unix-connect:/var/run/haproxy.stat stdio
pepoluan avatar
tr flag
Originally I didn't even have any stick table. So I added some stick tables in "webserver1" and "websrv" backends, and even when people are still having the sticky problems, they remain empty.
pe flag
Please post your backend configuration, then it might make more sense.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.