Problem adding a second domain to jitsi instance

We wanted to run our jitsi instance on a second domain. It is running fine on “” and we also want to make it work on “”.

We copied the nginx configuration with the necessary modifications and also copied /etc/jitsi/meet/ to with replacing all the domain entries respectively, as was suggested in other threads here.

Now “” shows a jitsi and it is possible to start and enter a room. But camera and microphone are disabled automatically, and the connection is also aborted after some seconds. What might be the problem here? Any help would be appreciated, thanks!

That will not work without adding those to prosody … and I’m not sure whether jicofo will work at all that way.

Your best shot is having a second nginx config for the new domain( leaving everything else as it is and just in the new nginx config change the Host you pass to be the original domain (
jitsi-meet/jitsi-meet.example at 09d3344c39cbf5cd732b3bb3399f29cfa4b813e0 · jitsi/jitsi-meet · GitHub
jitsi-meet/jitsi-meet.example at 09d3344c39cbf5cd732b3bb3399f29cfa4b813e0 · jitsi/jitsi-meet · GitHub

Thanks for the reply! We tried your suggestion with the nginx config, but unfortunately this didn’t work, too. Are there any more suggestions?

Maybe explain and show logs, what does not work, that should work.

It is possible to get to jitsi via the 2nd .plus-domain, but it is not possible to start a new room, the connection is immediately lost, or rather isn’t established in the first place.

There don’t seem to be hints in the logs that show further information, neither jvb.log nor jicofo.log or any other debug- or errorlogs. Is there another special log we should look into? Or is it possible to activate an enhanced debug mode?

javascript console logs in the browser

Thanks for getting back to us - here’s an excerpt from the code which probably holds the relevant errors:

superneutest2021#config.startWithAudioMuted=true&config.startWithVideoMuted=true:1 Access to XMLHttpRequest at ‘’ from origin ‘’ has been blocked by CORS policy: Response to preflight request doesn’t pass access control check: No ‘Access-Control-Allow-Origin’ header is present on the requested resource.
Logger.js:154 2021-11-03T08:47:49.975Z [JitsiMeetJS.js] <Object.getGlobalOnErrorHandler>: UnhandledError: Strophe: request id 2.2 error 0 happened Script: null Line: null Column: null StackTrace: Error: Strophe: request id 2.2 error 0 happened
at Object.r.Strophe.log (
at Object.error (
at O.Bosh._onRequestStateChange (
Logger.js:154 2021-11-03T08:47:49.976Z [modules/xmpp/strophe.util.js] <Object.r.Strophe.log>: Strophe: request id 2.2 error 0 happened

Heres the nginx-config file for the second domain: (4.5 KB)

You need to add allow origin header to * for the first domain to allow the connection from other domains.

Thanks - we did so in both nginx-vhosts in /etc/nginx/sites-available like this:

add_header 'Access-Control-Allow-Origin' '*';

but the same error keeps reappearing, do we have to add it somewhere or somehow else? Thanks!

You can check headers in the network console in chrome
Did you add it under the http-bind definition? And you see the same error?

No, we did add it at another line initially - now we added it in the under both http-bind definitions like beneath (there is one bosh and one bosh for subdomain), but we still get the same error unfortunately…

location = /http-bind {
add_header 'Access-Control-Allow-Origin' '*';
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $http_host;

BOSH for subdomains

location ~ ^/([^/?&:'"]+)/http-bind {
    set $subdomain "$1.";
    set $subdir "$1/";
    set $prefix "$1";
add_header 'Access-Control-Allow-Origin' '*';

    rewrite ^/(.*)$ /http-bind;

Can you add it and globally in and see whether that changes anything?

I think the problem is on the client side. AFAIK new browsers don’t allow cross-origin requests in Javascript (while fetching) if cors mode is not set explicitly.

Thanks for the replies - adding it globally didn’t make the error disappear. If this is indeed a problem with new browsers, then there isn’t any solution to it, or can you think of something? We’d have to look for an alternative then…

If my assumption is true then it’s needed to change Javascript fetch codes in jitsi-meet to support cors

Thanks! But can you give us a hint where and how we have to do that actually? In the js-file found in /etc/jitsi/meet we see no such option.

Or is this something the user needs to change in his browser settings? This would not be an option for us…