"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"
- Bars appear → your SRT stack and your UDP egress are fine. The problem is in the specific connection: address, stream ID, passphrase, or the far end.
- Nothing appears → the problem is your network or your build of the player. Everything below about stream IDs is irrelevant until this works.
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 listener has a passphrase and the caller sent none
- the caller sent a passphrase and the listener has none
- both have a passphrase but different
pbkeylen(16, 24 or 32) - both have a passphrase and the same key length, but one has a typo
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:
- Plain:
streamid=read:beacon— an application-specific string the server interprets - Standard (SRT Alliance):
streamid=#!::r=beacon,m=request— required by some hardware
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:
- 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.
- Wrong port. SRT ports are UDP. A firewall rule that opens TCP on the same number does nothing at all.
- Both sides are callers. Someone has to listen. Two callers wait forever, politely.
- The listener is not running. On a relay, the session may have ended; on a device, the encoder may be "configured" but not started.
- 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
| Check | Command or action | What it proves |
|---|---|---|
| SRT works here | pull the test signal | stack + UDP egress |
| Host resolves | ping de.inoutsrt.com | DNS, and your RTT |
| Something listens | try the URL in ffplay | address and port |
| Stream ID | drop the passphrase, keep the ID | ID syntax |
| Encryption | add the passphrase, fix pbkeylen | key agreement |
| Capacity | halve the bitrate | link, 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.