What is the reason for sometimes being able to enter the same room with the same room name through Jitsi meet load balancing configured by Nginx, and sometimes not being able to enter the same room?

What is the reason for sometimes being able to enter the same room with the same room name through Jitsi meet load balancing configured by Nginx, and sometimes not being able to enter the same room?

I need to take a detailed look at your Nginx configuration. Joining a room also calls an API, so by checking your configuration, we can determine the routing path. :grinning:

    upstream jitsi {
          ip_hash;
          server 8.217.58.35:443;
          server 8.217.61.57:443;
    }

    server {
       listen 443 ssl;
       server_name meet.iwatch.net.cn;
       ssl_certificate /opt/ssl/*.iwatch.net.cn.cer;
       ssl_certificate_key /opt/ssl/*.iwatch.net.cn.key;

       location / {
           proxy_pass http://jitsi;
           proxy_set_header Host $host;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
       }
    }

The possible reason for sometimes being able to enter the same room with the same room name through Jitsi Meet load balancing configured by Nginx, and sometimes not being able to enter the same room could be due to the load balancing algorithm used by Nginx. If the load balancing method is configured to use session persistence, then the request will always be sent to the same backend server. In this case, if a user joins a room on one server, they will always be redirected to that same server, and will be able to access the same room. However, if the load balancing method is configured to not use session persistence, then the request may go to different backend servers each time, and the user may not be able to join the same room.

Another possible reason could be due to the cache settings of the browser or the network. If the browser or the network is caching some resources, requests might be directed to the cached version of the resource, which may lead to unexpected behavior while joining the room.
It is also possible that there is an issue with the Jitsi Meet application configuration or with the server environment. In this case, it might be necessary to check the Jitsi Meet logs to identify any errors or issues that might be causing the problem
If you are deploying directly using Docker, have you checked the Docker logs of your four sub-containers? Or can you reproduce the operation and check the logs?

You cannot balance like that as people will randomly join different servers for the same room name.
You need an haproxy bot nginx. Woth haproxy you can stick same room name to the same backend server based on the room parameter used in all requests.

Thank you for your reply. Could you please elaborate on how to configure it specifically?

Have you used the search in the forum?
It returns results as this