Home / Guides / Connection rejected
Troubleshooting

"SRT says \"connection rejected\" — what each one means"

SRT's error messages are accurate but unhelpfully worded: the most common one blames a password even when the password is right. Here is what each actually means and the fastest way to confirm it.

First, split the problem in half

Before reading any error text, answer one question: does SRT work at all from this machine and this network?

Pull our free test signal — it needs no account and takes fifteen seconds:

ffplay "srt://de.inoutsrt.com:6999?streamid=read:beacon&latency=200"

That single test removes about half the candidates.

"Connection rejected: 1011 Password required or unexpected"

What it means: the two ends disagree about encryption. One of these is true:

The last two are the cruel ones, because you did type a password and the error still says it is missing.

Fix: set pbkeylen explicitly on both ends rather than relying on defaults — different implementations default differently. Then retype the passphrase on both sides rather than trusting the clipboard: leading and trailing spaces survive copy-paste and count as characters. The passphrase must be 10–79 characters.

srt://host:port?passphrase=YourLongPassphrase&pbkeylen=24&latency=300

Test the path without encryption first. Once video flows, add the passphrase to both ends. Debugging two variables at once doubles the work for no reason.

"Connection rejected: 1016" / stream ID errors

What it means: you reached the server, and it refused what you asked for. The address is right — the stream ID is not.

Two different syntaxes exist in the wild:

They are not interchangeable: send the one your server documents. If your encoder has a dedicated "Stream ID" field, put the value there alone and leave it out of the URL — putting it in both places is a common way to end up with read:beaconread:beacon.

Also worth checking: a publish ID used for reading, or a stream that has expired. On a paid relay session, an ID from yesterday's stream is simply gone.

Timeout: "Connection setup failure: connection time out"

Nothing answered. In order of likelihood:

  1. UDP is blocked outbound. Corporate networks, hotels, university campuses and some mobile APNs drop UDP to unusual ports. Test from a phone hotspot — if it works there, it is the network.
  2. Wrong port. SRT ports are UDP. A firewall rule that opens TCP on the same number does nothing at all.
  3. Both sides are callers. Someone has to listen. Two callers wait forever, politely.
  4. The listener is not running. On a relay, the session may have ended; on a device, the encoder may be "configured" but not started.
  5. Double NAT or CGNAT on the listener side. A caller cannot reach it, ever. This is the case that a relay exists to solve: make both ends callers to something public.

"Connection broken: parse error" or instant disconnects

The handshake succeeded but the payload is wrong: usually something that is not MPEG-TS arriving where MPEG-TS is expected, or a codec the receiver cannot decode (HEVC or AV1 into a decoder that only does H.264).

Check what is really inside:

ffprobe -v error -show_streams -of flat "srt://host:port?streamid=..."

If ffprobe reads it and your device cannot, it is a codec or profile limit on the device — try H.264 Main, 8-bit, 4:2:0.

It connects, then dies after a few seconds

Not a connection problem at all: the link cannot carry the stream, and SRT gives up once its buffer is exhausted. Raise latency, then lower the bitrate. What latency should I set walks through the arithmetic.

A checklist you can run down in two minutes

CheckCommand or actionWhat it proves
SRT works herepull the test signalstack + UDP egress
Host resolvesping de.inoutsrt.comDNS, and your RTT
Something listenstry the URL in ffplayaddress and port
Stream IDdrop the passphrase, keep the IDID syntax
Encryptionadd the passphrase, fix pbkeylenkey agreement
Capacityhalve the bitratelink, not settings

Need a tunnel that carries your own video?

IN/OUT-SRT is a hosted SRT relay in Germany and the USA. Your encoder connects in, your receiver connects out — no static IP, no port forwarding, nothing installed. Three free 30-minute sessions every day; a full production day is $5.