Anyone using Jitsi behind Nginx



  • It may be that mine was the same. Only ever tested it with one user.



  • Problem appears resolved.

    There were multiple things causing the problem.

    First, Jitsi needs a lot of behind the scenes interconnectivity to all of its pieces. When the Jitsi Meet system is on a public IP with nothing in front of it, these are all localhost calls so it all just works.

    But moving it behind NAT causes one issue, while moving it behind NginX on a separate server caused a second.

    First NAT. If you run Jitsi-Meet behind NAT, you need to update /etc/jitsi/videobridge/sip-communicator.properties with the following two lines.

    org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=>>YOUR.LAN.IP.ADDRESS<<
    org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=>>YOUR.PUBLIC.IP.ADDRESS<<
    

    For example, mine looks like this:

    org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=10.254.0.104
    org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=207.244.223.13
    

    Second is NginX. If you are running Jitsi-Meet behind an NginX Reverse Proxy that resides separate from Jitsi, then you need to first allow in TCP port 5280 to the Jitsi server's firewall.

    ufw allow in 5280/tcp
    

    Then you need to setup the following location blocks in your NginX config. Obviously changing the IP addresses to your internal IP.

        location / {
            ssi on;
            proxy_pass https://10.254.0.104/;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $http_host;
        }
        # BOSH
        location /http-bind {
            proxy_pass http://10.254.0.104:5280/http-bind;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $http_host;
        }
    
        # xmpp websockets
        location /xmpp-websocket {
            proxy_pass              http://10.254.0.104:5280/xmpp-websocket;
            proxy_http_version      1.1;
            proxy_set_header        Upgrade $http_upgrade;
            proxy_set_header        Connection "upgrade";
            proxy_set_header        Host $host;
            tcp_nodelay             on;
        }
    


  • Gods there is like no documentation on Jitsi.

    Granted when installed on a VPS direct on the internet it just works. But that doens't help me.





  • @black3dynamite said in Anyone using Jitsi behind Nginx:

    I found this on github.
    https://github.com/jitsi/jitsi-meet/blob/master/doc/example-config-files/jitsi.example.com.example

    Something similar is in their "manual install" document.
    https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md

    But, that is showing localhost. When I try to use that config (changed to point the internal IP), I never successfully connect.



  • This might be overcomplicating things... but what about setting it up behind an nginx setup on the same server as jitsi, and then use your main nginx proxy to forward to the jitsi nginx?



  • @dafyre said in Anyone using Jitsi behind Nginx:

    This might be overcomplicating things... but what about setting it up behind an nginx setup on the same server as jitsi, and then use your main nginx proxy to forward to the jitsi nginx?

    Why would that work vs. the normal reverse proxy? If you have a problem and make two of the same problem it doesn't solve the issue I would think. I'm actually asking, not being a dick.



  • @JaredBusch : I know this doesn't answer your question, but have you looked at NextCloud Talk at all? I don't know much about it but think it touts itself as a similar solution and the documentation is likely better.



  • @wirestyle22 said in Anyone using Jitsi behind Nginx:

    @dafyre said in Anyone using Jitsi behind Nginx:

    This might be overcomplicating things... but what about setting it up behind an nginx setup on the same server as jitsi, and then use your main nginx proxy to forward to the jitsi nginx?

    Why would that work vs. the normal reverse proxy? If you have a problem and make two of the same problem it doesn't solve the issue I would think. I'm actually asking, not being a dick.

    I'm not sure that it would. I'm going to try it on mine in a bit. But sometimes having a proxy on a different machine can cause random problems for things that like to use a lot of open ports -- that's been my experience.



  • @manxam said in Anyone using Jitsi behind Nginx:

    @JaredBusch : I know this doesn't answer your question, but have you looked at NextCloud Talk at all? I don't know much about it but think it touts itself as a similar solution and the documentation is likely better.

    It does not work as well.



  • @JaredBusch said in Anyone using Jitsi behind Nginx:

    It does not work as well.

    'nuff said..

    Regarding proxying WS supporting multiple users, my default is this:

    # enables WS support
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $host;
    

    and

    proxy_redirect off;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_max_temp_file_size 0;
    client_max_body_size 50m;
    client_body_buffer_size 256k;
    proxy_connect_timeout 180;
    proxy_send_timeout 180;
    proxy_read_timeout 90;
    proxy_buffer_size 16k;
    proxy_buffers 4 64k;
    proxy_busy_buffers_size 128k;
    proxy_temp_file_write_size 128k;
    

    Which appears to be what you used. I wonder what Jitsi is doing different that it breaks multiple connections via WS?



  • Problem appears resolved.

    There were multiple things causing the problem.

    First, Jitsi needs a lot of behind the scenes interconnectivity to all of its pieces. When the Jitsi Meet system is on a public IP with nothing in front of it, these are all localhost calls so it all just works.

    But moving it behind NAT causes one issue, while moving it behind NginX on a separate server caused a second.

    First NAT. If you run Jitsi-Meet behind NAT, you need to update /etc/jitsi/videobridge/sip-communicator.properties with the following two lines.

    org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=>>YOUR.LAN.IP.ADDRESS<<
    org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=>>YOUR.PUBLIC.IP.ADDRESS<<
    

    For example, mine looks like this:

    org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=10.254.0.104
    org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=207.244.223.13
    

    Second is NginX. If you are running Jitsi-Meet behind an NginX Reverse Proxy that resides separate from Jitsi, then you need to first allow in TCP port 5280 to the Jitsi server's firewall.

    ufw allow in 5280/tcp
    

    Then you need to setup the following location blocks in your NginX config. Obviously changing the IP addresses to your internal IP.

        location / {
            ssi on;
            proxy_pass https://10.254.0.104/;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $http_host;
        }
        # BOSH
        location /http-bind {
            proxy_pass http://10.254.0.104:5280/http-bind;
            proxy_set_header X-Forwarded-For $remote_addr;
            proxy_set_header Host $http_host;
        }
    
        # xmpp websockets
        location /xmpp-websocket {
            proxy_pass              http://10.254.0.104:5280/xmpp-websocket;
            proxy_http_version      1.1;
            proxy_set_header        Upgrade $http_upgrade;
            proxy_set_header        Connection "upgrade";
            proxy_set_header        Host $host;
            tcp_nodelay             on;
        }
    


  • @JaredBusch That's awesome.



  • @JaredBusch I bet that was annoying to figure out with bad documentation. Nice.



  • Hi guys.
    Same problem. I have jitsi docker container behind nginx.
    Where is /etc/jitsi/videobridge/sip-communicator.properties file to change values? in docker configuration files?
    thanks



  • @sadeghpm said in Anyone using Jitsi behind Nginx:

    Hi guys.
    Same problem. I have jitsi docker container behind nginx.
    Where is /etc/jitsi/videobridge/sip-communicator.properties file to change values? in docker configuration files?
    thanks

    I don't use docker for things like this for that reason.



  • @JaredBusch said in Anyone using Jitsi behind Nginx:

    @sadeghpm said in Anyone using Jitsi behind Nginx:

    Hi guys.
    Same problem. I have jitsi docker container behind nginx.
    Where is /etc/jitsi/videobridge/sip-communicator.properties file to change values? in docker configuration files?
    thanks

    I don't use docker for things like this for that reason.

    Same. Makes simple things hard. Jitsi is one of the easiest things to deploy... until Docker gets involved.



  • @sadeghpm said in Anyone using Jitsi behind Nginx:

    Hi guys.
    Same problem. I have jitsi docker container behind nginx.
    Where is /etc/jitsi/videobridge/sip-communicator.properties file to change values? in docker configuration files?
    thanks

    It's inside the docker container. You need to start a bash shell within the container its self.



  • @sadeghpm said in Anyone using Jitsi behind Nginx:

    Hi guys.
    Same problem. I have jitsi docker container behind nginx.
    Where is /etc/jitsi/videobridge/sip-communicator.properties file to change values? in docker configuration files?
    thanks

    Don't edit files in the container. Make the sip-communicator.properties file on your host and mount it under /etc/jitsi/videobridge/sip-communicator.properties



  • @stacksofplates
    thanks guys.
    bind /etc/jitsi/videobridge/sip-communicator.properties with local file and container config file updated, but problem exists! very strange!



  • @sadeghpm said in Anyone using Jitsi behind Nginx:

    @stacksofplates
    thanks guys.
    bind /etc/jitsi/videobridge/sip-communicator.properties with local file and container config file updated, but problem exists! very strange!

    Are you using their docker-compose file? They give you a .env with all of the environment variables you need to set.

    I hadn't looked at their repo. You should set all of those options as env vars not in the config itself.

    Once you have the env vars set up just run docker-compose up -d



  • @stacksofplates i use official docker-compose file and according to their documentation.



  • @JaredBusch Did you change the nginx conf on the jitsi server? I followed your instructions on "Install Jitsi-Meet on Debian 9 minimal" including the nginx conf, but i'm getting a err_too_many_redirects error.



  • @br0wnt0wn said in Anyone using Jitsi behind Nginx:

    @JaredBusch Did you change the nginx conf on the jitsi server? I followed your instructions on "Install Jitsi-Meet on Debian 9 minimal" including the nginx conf, but i'm getting a err_too_many_redirects error.

    That guide does not have Nginx on the Jitsi server.



  • @JaredBusch When i install jitsi-meet via sudo apt-get -y install jitsi-meet, it automatically installs and configures nginx



  • @br0wnt0wn said in Anyone using Jitsi behind Nginx:

    @JaredBusch When i install jitsi-meet via sudo apt-get -y install jitsi-meet, it automatically installs and configures nginx

    That quide is from almost 2 years ago. Maybe things have changed.



  • I'm tired of dealing with stupid for a bit. let me spin up a new instance and try it



  • Spinning up a new Debian 10 install to work from.
    90f4d07d-c6c5-4cdc-a323-c4707ff61dda-image.png



  • Awesome, thanks!



  • Ok i seem to have gotten it working. In the nginx config on the jitsi server, I commented everything from this line:

    location^~ /.well-known/acme-challenge/ {
    

    to this line:

    ssl_certificate_key /etc/jitsi/meet/sub.domain.com.key;
    

    which effectively removes the server block listening on port 4444, then moves all of the location blocks and config from the listen 4444 server block to the listen 80 server block.



  • @sadeghpm said in Anyone using Jitsi behind Nginx:

    @stacksofplates i use official docker-compose file and according to their documentation.

    Yeah you shouldn't need to modify the properties file then. Just use the env vars in your .env file.


Log in to reply