This is way more complicated than it seems to fix :/

• The backend accepts traffic on port 80 and 443, its apache server redirects requests in port 80 to 443.
• The general traffic comes from the DNS record of meet.wmcloud.org. set to the associated public IP meaning it doesn't use the Wikimedia cloud web proxy (that's intentional, given the usage of UDP for RTC)
• The webproxy can't be set for wmflabs.org to go to port 443, because then https://meet.wmflabs.org gets terminated in the webproxy and become plain requests than hit the VM's https port, causing this beauty:

• The webproxy can't be set for wmflabs.org to go to port 80, because the port 80 thinks the request is not encrypted, issues a redirect to the encrypted end point and again and again (what you described here)
• We can avoid using wmcloud webproxy and have a DNS record for the meet.wmflabs.org directly going to the ports in that public IP
  • But the backend (the VM) has only certificate for meet.wmcloud.org and not meet.wmflabs.org meaning, it'll start giving errors. I'm not sure the built-in support for Let'sEncrypt in Jitsi supports multiple domains, if so, then we are good.

Will I succeed? Will I fail and give up? Stay tuned!

maybe you can look for an X-Forwarded-Proto: https header which I think the proxy should be setting? if it's set then treat the request as if you would on port 443, if it's not set than issue redirect?

edit: actually, is it just trying to catch all port 80 requests and redirect them to https://$server_name ? if so what if you hardcode the correct server name?