Fix Jitsi Meet “You Have Been Disconnected” Connection Drops

A Jitsi Meet call can show “You have been disconnected” when the meeting’s signaling connection drops, when WebRTC media traffic cannot reach the video bridge, or when a local network or browser interrupts the session. Start by checking whether the problem affects one participant or everyone. That distinction usually tells you whether to troubleshoot a device and network or the Jitsi server.

Quick triage checklist

Do not change several settings at once. Test one change, rejoin the same meeting if possible, and note whether the symptom changes.

First identify which connection failed

Jitsi Meet uses WebRTC for real-time audio and video. A meeting depends on more than the page loading: the browser must maintain signaling with the server and establish a media path to the Jitsi Videobridge. A participant can sometimes remain visible in the room while media freezes; a full “You have been disconnected” message can indicate a broader session or signaling interruption. The exact underlying cause cannot be determined from that message alone.

Write down the time of the drop, whether the browser showed a reconnect prompt, whether other participants were affected, and whether the meeting was hosted at meet.jit.si or on a private Jitsi domain. Avoid posting a private meeting URL, room name, access token, or unredacted logs publicly.

Checks for a participant using a browser

1. Reconnect once and confirm the meeting link

Use the on-screen reconnect action if it appears. If the meeting does not recover, open the original invitation link again in a new tab and rejoin. Confirm that the room name and host domain match the invitation; a typo or an old link can lead to a different room or host. If everyone is disconnected, wait briefly and ask the meeting organizer whether the service is still available before repeatedly refreshing.

2. Test a supported, updated browser

Update the browser, quit it completely, and try the meeting again. If the disconnect repeats, test another current browser supported by Jitsi. Jitsi’s supported browser reference lists browser support and platform notes; check that page because support details can change. On iPhone and iPad, different browser brands use the same underlying browser engine, so trying another brand may not isolate a browser-engine problem.

For a clean comparison, try a private window or temporarily disable extensions that filter scripts, block trackers, or modify network requests. If that fixes the call, re-enable extensions one at a time to identify the conflict. Do not leave security protections disabled as a permanent workaround.

3. Compare networks

Move closer to the Wi-Fi access point, pause large downloads or cloud backups, and test once on a different network that you are authorized to use. A phone hotspot can help distinguish a home or workplace network issue from a browser or server problem. If Jitsi works on the alternate network but repeatedly disconnects on the original one, give the network administrator the time of the test and ask whether real-time WebRTC traffic is filtered.

A VPN, proxy, captive portal, or firewall may interrupt signaling or media. If your organization requires a VPN, do not bypass its policy; ask IT whether the Jitsi host is permitted. If you are allowed to compare with the VPN disconnected, do so only briefly and re-enable it afterward.

4. Check device and app conditions

On a phone, keep the Jitsi app or browser in the foreground during a test and disable battery-saving restrictions for that test if your device permits. Mobile operating systems may suspend background network activity. Also check that the app and operating system are updated, then restart the device if the connection continues to fail. A microphone or camera permission problem usually affects device access rather than proving a network disconnect, so treat those symptoms separately.

When audio/video fails but the meeting page remains open

Turn the camera off temporarily and see whether audio becomes stable. This can reduce bandwidth use, but it does not repair a broken server route. If audio and video fail together on one network and work elsewhere, investigate firewall or NAT restrictions. Jitsi’s self-hosting guide identifies TCP 443 for general web access, UDP 10000 for normal audio/video meetings, and TCP 5349 for coturn fallback when UDP is blocked; optional STUN use may also involve UDP 3478. These are server-side deployment requirements, not ports a participant should open on a personal device. See the current Jitsi firewall and NAT guidance.

If the meeting works on a different connection, report that comparison to the network administrator. Ask them to review the organization’s rules for the Jitsi hostname and WebRTC traffic rather than requesting a blanket firewall shutdown.

Checks for a self-hosted Jitsi administrator

Confirm reachability and the media path

Verify that the public DNS name resolves to the expected server, that the TLS certificate is valid, and that the required traffic reaches the correct host. If the server is behind a router or cloud firewall, inspect both the host firewall and the upstream security group or port-forwarding rules. A rule in UFW does not help if the cloud firewall still blocks the same traffic.

sudo ufw status verbose
sudo ss -lntup

These commands show local firewall rules and listening sockets; they do not prove that outside participants can reach the service. Test from an external network and confirm the router or provider forwards the relevant traffic to the Jitsi Videobridge. Jitsi notes that deployments behind NAT may need correct public and local address mapping when calls do not work from outside.

Review TLS, reverse-proxy, and Docker settings

For a reverse-proxy deployment, verify that HTTPS works and that the proxy forwards WebSocket signaling correctly. The official Docker guide documents the /xmpp-websocket route and the headers needed by its Nginx example. A proxy that serves the page but drops the WebSocket can leave users unable to maintain the meeting session.

With Docker Compose, check that PUBLIC_URL matches the public domain visitors actually use and that the published host ports match your firewall and proxy setup. The Jitsi guide warns that serving a real meeting directly over HTTP instead of HTTPS can cause WebRTC problems. Avoid copying configuration snippets from a different Jitsi release without checking the version and deployment method you run.

Correlate server logs with the incident time

Compare the time of the disconnect with service logs. On Debian or Ubuntu package installs, Jitsi documents log files including /var/log/jitsi/jvb.log, /var/log/jitsi/jicofo.log, and /var/log/prosody/prosody.log. Docker deployments store logs through their containers, so inspect the relevant container output and the configuration directory for your installed release.

sudo tail -n 150 /var/log/jitsi/jvb.log
sudo tail -n 150 /var/log/jitsi/jicofo.log
sudo tail -n 150 /var/log/prosody/prosody.log

Search around the incident timestamp for service restarts, bridge registration changes, WebSocket failures, certificate errors, or repeated connection timeouts. Redact participant identifiers, room names, IP addresses, and tokens before sharing logs. The Debian/Ubuntu self-hosting guide also recommends trying another browser, checking WebRTC support, and reviewing firewall/NAT rules as basic debugging steps.

Escalation checklist

• Record the Jitsi host, approximate timestamp and time zone, device, operating system, browser or app version, and whether the issue affects one person or the whole meeting.
• Note whether a different browser or network changes the result.
• For self-hosted servers, include recent proxy, firewall, DNS, certificate, or Jitsi upgrades.
• Share only the minimum necessary diagnostic information, with private room details and credentials removed.
• If using meet.jit.si or another managed host, send the report to the meeting organizer or service support; participants cannot change that host’s firewall or server configuration.

How to confirm the fix

Join a test meeting from the original device and network, remain connected long enough to cover the period when the failure usually occurs, and confirm that audio and video stay usable. Repeat with another participant if the issue affected everyone. For a self-hosted deployment, verify both browser signaling and media from outside the server’s network. A successful page load alone is not enough; the meeting should stay connected and participants should be able to exchange audio and video.