# Jitsi "You have been disconnected": causes and fixes

> 'You have been disconnected' means the browser lost its signalling connection (XMPP over WebSocket) to Prosody, not the video path. Check that Prosody and Jicofo are running, that any reverse proxy forwards WebSocket upgrades for /xmpp-websocket, that internal passwords in .env have not changed since first start, and that the server is not out of memory.

Source: https://jitsi.help/troubleshooting/jitsi-you-have-been-disconnected/
Updated: September 26, 2026
Publisher: Jitsi Help (https://jitsi.help/)

The message appears when the browser loses its **signalling** connection: the XMPP session that carries "who is in the room", chat and control messages. Video can be perfectly fine while this breaks, which is why it looks different from the [three participants problem](/troubleshooting/jitsi-video-not-working-3-participants/).

## 1. Are the containers running?

```bash
docker compose ps
docker compose logs --tail 100 prosody jicofo web
```

If Prosody or Jicofo is restarting in a loop, the logs say why. Out-of-memory kills show in `dmesg | grep -i oom` on the host.

## 2. Is a reverse proxy breaking WebSockets?

If Jitsi sits behind your own Nginx, Traefik, Caddy, Cloudflare or a load balancer, it must forward WebSocket upgrades for `/xmpp-websocket` (and `/colibri-ws/` for the bridge channel). A proxy that only handles plain HTTP lets the page load, then drops the session within seconds.

For Nginx, the location must include:

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

Also raise idle timeouts on load balancers so long quiet meetings are not cut after 60 seconds.

## 3. Did internal passwords change?

Prosody stores the component accounts the first time it starts. If you later re-ran `gen-passwords.sh` or edited `JICOFO_AUTH_PASSWORD` or `JVB_AUTH_PASSWORD`, the components cannot authenticate and meetings fail. Either restore the previous values, or remove the generated Prosody data under your CONFIG folder and restart the stack so the accounts are recreated.

## 4. Is PUBLIC_URL right?

`PUBLIC_URL` in `.env` must match the address users open, including `https://`. A mismatch produces WebSocket URLs pointing at the wrong host.

## 5. Is the server overloaded?

Check memory and CPU during a meeting. A 2 GB server running recording or transcription will start killing processes. See [server requirements](/guides/jitsi-server-requirements/).

## 6. Only one user affected?

Ask them to try another network or a mobile hotspot. Corporate proxies that inspect TLS sometimes break WebSockets. If the hotspot works, it is their network.

## Need a hand?

[Contact our engineers](/contact/?topic=troubleshooting) with the time it happened and the output of `docker compose logs --tail 200 prosody jicofo`, and we will tell you what is wrong.

## Frequently asked questions

### Is 'You have been disconnected' a network problem on the user's side?

Sometimes, if it happens to one user on a poor connection. If it happens to everyone, it is a server problem: usually Prosody, Jicofo or the WebSocket path through a proxy.

### Why did it start after I changed .env?

Internal component passwords are stored by Prosody on first start. Changing JICOFO_AUTH_PASSWORD or JVB_AUTH_PASSWORD afterwards without resetting Prosody's data means the components can no longer log in, and every meeting drops.


---

Jitsi Help is an independent service. It is not affiliated with, endorsed by or sponsored by 8x8, Inc. or the Jitsi project. Jitsi and Jitsi Meet are trademarks of 8x8, Inc., used here only to describe the software we host and support.