Anyone using Jitsi behind Nginx



  • I setup Jitsi on a VM in my colo.

    I routed the full 10k-20k UDP ports to it, as I have nothing running there needing them right now, but i cannot do that with 80/443.

    Opened a post over on the Jitsi community also.
    https://community.jitsi.org/t/issues-with-using-nginxx-on-separate-server/15783

    Is there somthing that should be in my location block to help?

    server {
        server_name scry.daerma.com;
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/scry.daerma.com/fullchain.pem; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/scry.daerma.com/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
    
        location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $http_host;
            proxy_set_header X-NginX-Proxy true;
            proxy_pass https://10.254.0.104;
            proxy_redirect off;
        }
    }
    
    
    server {
        server_name scry.daerma.com;
        listen 80;
        return 301 https://$host$request_uri;
    }
    


  • 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;
        }
    


  • The only thing different in this one and the one that I had is that I don't have the

    proxy_redirect off;

    line.



  • @dafyre said in Anyone using Jitsi behind Nginx:

    The only thing different in this one and the one that I had is that I don't have the

    proxy_redirect off;

    line.

    removed, no difference.



  • Tried using keepalive or maybe proxy_connect_timeout?



  • Doesn't jitsi require the use of websockets? I think I used them when I tested it but I'm not 100%



  • @wirestyle22 said in Anyone using Jitsi behind Nginx:

    Doesn't jitsi require the use of websockets? I think I used them when I tested it but I'm not 100%

    So nginx config in the location will need these?
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;





  • @black3dynamite said in Anyone using Jitsi behind Nginx:

    @JaredBusch Here's an article about Nginx Reverse Proxy for Websocket
    https://www.tutorialspoint.com/articles/how-to-configure-nginx-as-reverse-proxy-for-websocket

    But the problem is a lack of documentation from Jitsi on how this all runs.



  • @black3dynamite said in Anyone using Jitsi behind Nginx:

    @wirestyle22 said in Anyone using Jitsi behind Nginx:

    Doesn't jitsi require the use of websockets? I think I used them when I tested it but I'm not 100%

    So nginx config in the location will need these?
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    I did that last night. The result was my single connection stays stable but it all crashes as soon as a second person joins.

        location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-NginX-Proxy true;
            proxy_pass https://10.254.0.104;
            proxy_http_version 1.1;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection "upgrade";
            proxy_set_header Host $host;
        }
    


  • I spun up a Debian 9 instance on Vultr (see my guide) and it works perfectly with multiple users connecting.

    Of course it has no external proxy in front of it.



  • With the above setting, jsut myself can connect and it stays connected. Amost 2 hours until I manually disconnected.

    0_1542388763312_49321ac2-f0d4-4c31-bab1-a5d69940e476-image.png

    But everytime a second user connects, it drops immediately.

    So annoying.



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



  • 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.


Log in to reply