I’m trying to use HAProxy, also following the indications of old discussions in the forum:

and others.

I have configured HAProxy following the instructions:

then I created a simple standalone webapp that displays the Xojo version in a label.

When I run the first instance of the app I see more than 90 active Xojo sessions!

except my real session, the other sessions do not show the CurrentPage or any other information.
it seems that the only data available is the Session ID.

If I run a dozen instances of the app, the number of Xojo sessions grows to 100-110 in all.

is this the normal behaviour?

I take advantage to ask if others in the forum still use HAProxy in professional environment.

and in which way has been treated the session persistence.

thanks for your attention.

What you may be seeing are hackers probing your app to look for vulnerabilities. They usually don’t stay long but unfortunately start a session every time. Keep in mind that 90 is probably the maximum number of users that a web app can handle at once by default.

You can help this by adding code to the App.HandleUrl event which checks the User-Agent header when the url is blank and just return True when it isn’t a browser.

We don’t do this automatically any more because:

A. It’s very easy to spoof a valid user-agent (but still not every hacker does so)
B. There’s no way for us to keep up with the number of browsers and browser signatures out there today.
C. There is some overhead in doing this technique.

Now, if you want to do it at the system level, hackers usually probe more than one port when trying these things… so using an adaptive firewall (like we do on Xojo Cloud) would catch them before they ever got to your app.

1 Like

thanks Greg,

so nothing to do with my HAProxy configuration, if I understand correctly.

if you can answer me, I would also like to know if the configuration contained in John Joyce’s post requires me to verify and manage in some way (how?) the session persistence.

or if HAProxy takes care of it entirely instead.

so I only have to deal with my standalone Xojo application (deployed on 3 different ports managed by HAProxy).

FWIW, when you just installed a new instance of your server somewhere, your IP might still get “used” by the former owner and/or its users. For instance because they forgot to change their IP somewhere … so usually “it is normal” that you are seeing “a lot of unusual traffic” for the first hours / days.

Nevertheless everyone should take care to protect their environment. It is the internet, and a lot of crazy people out there. But I only wanted to drop one(!) reason of many(!) why you might see unusual traffic. This a benign one, but unfortunately there are others too. For me that’s my major strength of Xojo Cloud and worth the price, unfortunately my customers have a different view on this :frowning: .

Hi Nat!

I make an app built specifically for deploying Xojo Web apps called Lifeboat. It really simplifies the whole thing down to just a few easy drags and clicks. I use it professionally with client projects and to host my entire network of websites (business and personal).

I read John’s post and learned from that thread while building Lifeboat. I ended up selecting nginx because of how simple it is to configure. I was able to automate a lot of the monotony to make deployment a snap.

With nginx load balancing, as Xojo users we need to use the ip_hash directive to keep user requests directed at a consistent web app instance. I do use the round robin directive on a project that is a Web 2.0 REST API as there’s no session persistence needed there.

I can confirm that with ip_hash (or better yet, Lifeboat!) the Xojo session system operates successfully.

If you have any more questions about deploying web apps please don’t hesitate to ask! I would love to tell you more about Lifeboat too, feel free to reach out privately with your specific needs and I’ll help you figure out if my app can help :slight_smile:

For a 5-minute overview of deploying a Xojo Web app with Lifeboat, check out this short video too.

Happy app-ing!

Best wishes,
Tim Parnell

1 Like

Hey there @NatP - I sent you a direct message on this as well.

No that is not normal. When you access the haproxy frontend of your app, does the app function normally or do you get errors or connection difficulty?

HAproxy will not automagically manage session affinity for you, you have to set it up for that. I find the easiest way to do that is with cookie injection. If you google “haproxy maintain session with cookie injection” you will find lots of info on how to do this. It is quite easy, just a couple lines in the config.

I have had very little issues running HAproxy as a front end for Xojo web apps for like 4-5 years now I think. It helps considerably in my experience and makes the whole thing much more scaleable.

Here is what I would do to test your situation:

  1. Access the web app directly on the port it is running on and verify the behavior you are seeing does not occur. (If it DOES, there is potentially some issue with your server configuration or app iteself)
  2. Set up HAproxy with just the one app instance as backend and verify behavior does not occur when you access through HAproxy. (if it does, experiment with different default timeouts)
    I use these settings and they work fine for me:
    timeout server 90s
    timeout client 15s
    timeout connect 15s
    option http-keep-alive
  3. Configure cookie injection, increase number of backend app instances and try through HAproxy again. If you still have issues check that the cookie you are injecting is present in the response headers and it is NOT changing between requests. If it is not present you have not configured it properly. If it is changing, could be an issue with your browser(?) or possibly misconfiguration/typo in HAproxy.cfg.

Start with the most bare-bones haproxy.cfg you can and gradually add and tweak setting/rules one at a time. It can be difficult to troubleshoot if you have a lot of rules.

Hope this helps.

1 Like

Dropping this in here in case it helps someone


thanks John,

I restarted from the default cfg trying to add some settings step by step.

bind *:8080
mode http
maxconn 40000
balance roundrobin
option http-keep-alive
option forwardfor
cookie serverid insert indirect nocache
timeout connect  30000
timeout client  30000
timeout server 30000
server node1 check cookie node1
server node2 check cookie node2
server node3 check cookie node3

this way it seems that the 90+ initial sessions are not created.

  1. is it enough to insert the following settings in haproxy.cfg to ensure session persistence?

    cookie serverid insert indirect nocache
    server node1 check cookie node1
    server node2 check cookie node2
    server node3 check cookie node3

  2. Xojo-app side I don’t have to do anything?

thank you.

You do not have to do anything on the Xojo side unless there is some reason your app instances need to communicate to each other.

Yes that should be all you need on the backend of your haproxy.cfg. You should end up with a cookie called serverid with the value of node# (1,2 or 3) added to the response headers from your app.

Obviously you have to have app instances running and listening on ports 8081, 8082, 8083 for this to work. HAproxy does not launch any app instances, you have to configure them to be running and listening on the appropriate ports separately. I assume you are tracking here but wanted to clarify just in case.

I personally would recommend that you use SSL right from the start.

This makes configuration a bit more complex, but most browser will start to abandon non-secured-websites. Also obviously for security reasons it is better.

Certbot from Let’s Encrypt has a super nice documentation:


I rearranged the settings added to the default configuration.

frontend firstbalance
bind *:8080
default_backend webservers

backend webservers
balance leastconn
option http-keep-alive
option forwardfor
cookie serverid insert indirect nocache
server node1 check cookie node1
server node2 check cookie node2
server node3 check cookie node3
# option httpchk

I report that the 90+ sessions created at the beginning seem to be caused by the “option httpchk” instruction, which I have disabled.

it seems that everything works regularly.

maybe other configuration options will be needed in the future, but I’m afraid they will create other malfunctions, conflicts, etc.

so I can take care of the SSL configuration.

I hope it won’t be too hard.

1 Like

You can setup a custom url in your app for the httpchk that doesn’t create a session. That can also allow you to do some other sanity checking in your app or servers if needed. I’ve not done this in Web 2.0, so I am assuming it would work without testing it myself.

could you post an example?