Jitsi "You have been disconnected": causes and fixes

A disconnect banner is the starting point for investigation. Record the first relevant error and the failing request before repeatedly reloading or restarting services. This guide is for self-hosted administrators; participants should give the organizer a sanitized error and timestamp rather than changing server settings. [S1][S6]

Source scope: checked 24 October 2026 against Jitsi Meet 11248 source at f765042b and docker-jitsi-meet stable-11248-2, commit 74d3e6e. Local fixtures verify the HTTP upgrade probe’s request and reporting behavior. They do not reproduce a live Jitsi disconnect or establish a fix for your server. [S1][S2]

1. Capture the failure before choosing a fix

The reviewed client considers configuration, connection and conference errors when deciding whether to show a reload overlay. It selects the disconnect title for its configuration/connection failure branch; a conference error can take a different reload-message branch. Neither title names a particular failed server or transport. [S1]

Record the time with timezone, browser/app version, installed component versions, whether joining ever succeeded, and which clients or networks are affected. Use version inventory before applying a release-specific instruction. Keep room names and tokens out of shared screenshots. [S2][S6]

These are diagnostic branches, not measured probabilities or confirmed causes. For JWT errors use token diagnostics; for media changing at the third participant use bridge-path diagnostics. [S1][S2]

2. Inspect the actual browser transport

In Chrome DevTools, open Network, reproduce once in a disposable meeting and inspect the relevant requests. If the client uses WebSocket, select its request and check the status and message/close sequence. Record the console’s error name privately; do not export and post an entire HAR or console dump. [S6]

The reviewed Docker web template configures /xmpp-websocket when XMPP WebSocket support is enabled, and also contains BOSH /http-bind routing. Inspect the browser-served config.js and actual requests instead of assuming every deployment uses the same transport. Tenant paths and custom frontends can differ. [S2]

For a conventional HTTP/1.1 WebSocket handshake:

Interpret the actual transport and HTTP version. A successful upgrade is not a full XMPP or meeting test. WebSocket protocols can use other HTTP mechanisms; the optional probe below deliberately tests HTTP/1.1. [S3][S4][S5]

Optional bounded HTTP/1.1 upgrade probe

Run this in Bash on an authorized machine against your own test server. Replace both example hostnames. Use the exact path from the browser for a tenant deployment. No JWT, room name or password belongs in this probe. [S2][S3][S4][S5]

JITSI_WS_KEY="$(openssl rand -base64 16)" || exit 1
if curl --http1.1 --max-time 5 --silent --show-error \
  --output /dev/null --write-out 'http_status=%{http_code}\n' \
  -H 'Connection: Upgrade' -H 'Upgrade: websocket' \
  -H 'Sec-WebSocket-Version: 13' \
  -H "Sec-WebSocket-Key: $JITSI_WS_KEY" \
  -H 'Sec-WebSocket-Protocol: xmpp' \
  -H 'Origin: https://meet.example.com' \
  'https://meet.example.com/xmpp-websocket'; then
  JITSI_PROBE_EXIT=0
else
  JITSI_PROBE_EXIT=$?
fi
printf 'curl_exit=%s\n' "$JITSI_PROBE_EXIT"
unset JITSI_WS_KEY JITSI_PROBE_EXIT

The nonce decodes to 16 random bytes and the request asks for the xmpp subprotocol. The command reports only HTTP status and curl exit status, not response bodies or complete headers. It retains normal TLS verification and does not follow redirects. [S3][S4][S5]

If the connection upgrades and remains open, the deliberate five-second limit can produce curl exit 28 after http_status=101. That is not, by itself, proof the upgrade failed. Curl can also return zero for an HTTP error here because this probe does not use --fail; always read the HTTP status too. This probe does not send an XMPP stream, authenticate, join a room, verify WebSocket message handling or test media. Use the browser’s real connection for those checks. [S3][S4][S5]

3. Check component health without dumping configuration

Use the same Compose project, environment files, profiles and overlays that run the deployment. The commands below list stopped containers too and take a resource snapshot; they do not restart anything. [S7]

docker compose ps --all
docker compose stats --no-stream

For stopped or restarting containers, inspect only selected state fields. This example deliberately avoids a full environment/configuration dump: [S7]

for JITSI_ID in $(docker compose ps --all --quiet prosody jicofo jvb web); do
  docker inspect --type container --format \
    '{{.Name}} status={{.State.Status}} oom_killed={{.State.OOMKilled}} exit={{.State.ExitCode}} restarts={{.RestartCount}}' \
    "$JITSI_ID"
done
unset JITSI_ID

Use the state together with private logs and the recorded failure time. A restart count, exit code or resource snapshot does not establish the cause alone. An OOM flag is useful evidence about that container’s state, but a false value does not rule out every host or application resource failure. Do not claim a particular RAM size must cause an OOM kill. [S7]

Inspect a bounded time window of the relevant web, Prosody and Jicofo logs locally. Include JVB when media or bridge allocation is involved. Logs and browser exports can contain tokens, room links and personal data; the JWT diagnostic guide explains a constant-only filter for its specific error categories. Do not request or share unredacted log dumps. [S2][S9]

4. Match proxy routing to this release

The reviewed web template forwards /xmpp-websocket to Prosody with HTTP/1.1 and Upgrade/Connection handling, while /http-bind has its own route. An external proxy must preserve the route and transport your client actually uses. Check every hop rather than adding headers to an unrelated location block. [S2][S8]

These directives illustrate the HTTP/1.1 upgrade part inside an existing appropriate proxy location. They are not a complete proxy configuration: [S8]

proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";

Check the configured upstream scheme, host/container port, path, TLS termination and forwarded hostname. The reviewed Docker Compose maps host web ports to container 8000/8443. Older examples targeting container 80/443 need a release-specific review. Use the reverse-proxy guide for topology details. [S2]

Do not add an old /colibri-ws/ route as a universal fix: the reviewed base web and JVB templates do not define that legacy path. Conversely, do not remove routes from an older or customized deployment without checking its source and active configuration. [S2]

For time-related drops, correlate the observed interval with your actual proxy/load-balancer timeouts and upstream traffic. Nginx documents a default timeout between upstream reads and options for timeout or ping handling; that is a hypothesis to check, not a reason to increase every timeout blindly. Avoid changing public DNS/CDN routing as the first diagnostic step. [S8]

5. Check credentials and upgrade state without deleting data

If the failure started after .env changes or a rerun of gen-passwords.sh, investigate credential consistency and component authentication. The generator replaces service passwords. The pinned Prosody startup has a registration stage that attempts account creation after its readiness check; “credentials are only handled on the first start” is not a complete description of this release. Review that stage’s results and the consumers’ intended settings. [S2][S9]

Do not delete Prosody’s persistent data to test this theory. Preserve accounts, configuration and backups. Compare the intended credentials privately or restore a known working configuration through a planned recovery procedure. Coordinate any rotation across affected components and verify registration/authentication before reopening meetings. No secret or full configuration belongs in a public issue. [S2][S9]

For failures after an upgrade, check image references, matching release files, mounts and generated runtime paths. Follow the upgrade procedure and rootless migration notes when applicable. A mixed-version observation is evidence to investigate, not proof that it caused this disconnect. [S2]

PUBLIC_URL influences the generated browser signalling URLs. Compare the browser-served configuration and the URL users actually open, including any tenant mapping. After an evidenced environment change, Compose must recreate the changed configuration; a simple container restart does not apply new Compose environment values. Plan that interruption separately from the read-only checks. [S2][S10]

6. Compare affected clients and separate media failures

If permitted, compare one controlled test using another supported browser/profile or an independent network, keeping the server and meeting policy the same. A different outcome narrows the investigation to differences such as network routing, client state or authentication; it does not prove one network is faulty. Do not bypass an organization’s controls to run the comparison. [S1][S6]

Signalling and media use different paths, and participant count can change media routing. Keep browser error/transport evidence alongside ICE and bridge evidence. If signalling remains established but media fails, continue with three-participant bridge diagnostics or one-to-one media diagnostics instead of repeatedly changing the WebSocket proxy. [S2]

For package installations, Docker variables and container paths do not apply. Inspect the installed Prosody, Jicofo, JVB and web-proxy services using their package configuration and private service logs. A restart is a planned operational change, not a diagnostic observation. Follow upstream’s package installation layout and the documentation for the installed version. [S11]

Verify the correction

After correcting the evidenced cause on a test setup, reproduce the original case and verify:

1. Configuration loads and the intended signalling transport remains established.
2. Authentication and room admission work for the intended host and participant policies.
3. Audio/video work on the relevant two-person and multi-person paths.
4. The session survives beyond the previously observed drop interval.
5. A reconnect or fresh join still works without broadening access or discarding state.

These are proposed acceptance checks, not results measured on your deployment. Keep a sanitized timestamped record and change one cause at a time. [S1][S2][S3]

Open questions and maintenance

We checked pinned client and Docker source, shell syntax, and a local HTTP fixture that accepts or rejects upgrade requests and demonstrates an upgraded connection reaching the probe timeout. No full WebSocket/XMPP stream, real Jitsi meeting, proxy deployment, password rotation, data deletion, OOM injection or live package operation was tested for this revision.

Recheck after client error handling, transport, startup/registration or container-port changes. For help, contact our engineers with sanitized versions, timestamps, error names and transport/status observations. This page does not promise a cause from a banner or an unreviewed log dump.

Sources

Reviewed 24 October 2026; pinned source is not proof of every installed image’s contents.

• [S1] Jitsi Meet 11248 reload overlay, overlay middleware and English messages: error state and title selection.
• [S2] Docker stable-11248-2, Compose, web routes, web system config and JVB config.
• [S3] RFC 6455: HTTP/1.1 upgrade, random nonce and subsequent WebSocket protocol.
• [S4] RFC 7395: XMPP subprotocol and stream establishment over WebSocket.
• [S5] curl manual and OpenSSL rand: bounded request, status output, TLS verification and nonce generation.
• [S6] Chrome Network panel reference: request status and WebSocket messages.
• [S7] Docker Compose ps, Compose stats and inspect: scoped inventory and state fields.
• [S8] Nginx WebSocket proxying: explicit upgrade forwarding and upstream read timeout.
• [S9] Pinned Prosody registration stage, password generator and token logging: registration attempts, credential replacement and log sensitivity.
• [S10] Docker Compose up and restart: changed environment handling.
• [S11] Jitsi package installation: package layout and service context.