A failed YouTube RTMPS handshake is usually a connection-setup problem to diagnose before changing video settings. Start with the exact RTMPS URL shown in YouTube Live Control Room, then check its hostname, path, port 443 and TLS/SNI handling before investigating guest firewall, DNS or routing.
The fact that the VPS is in India or hosted by Contabo does not establish the cause. The checks below separate what the encoder is attempting from what the VPS network can reach; they do not assume a replacement endpoint or promise a fix.
Capture the exact handshake error
Record the full error, the time it occurred, the encoder name and version, and whether the problem began after a configuration change. Error wording can point towards a layer, but it is not a diagnosis by itself. YouTube's troubleshooting guidance includes errors such as a connection timeout and an invalid SSL certificate; the next step differs for each.
Keep a short record for each attempt: the displayed error, whether it appeared immediately or after waiting, and whether Live Control Room ever showed an incoming stream. Note any recent changes to the URL, stream key, encoder preset, operating system firewall or server configuration. Do not include the stream key in notes you plan to share. It is a credential, not diagnostic evidence.
An immediate certificate or SSL error makes the URL, hostname, port and TLS setup worth checking first. A timeout suggests that the connection was not completed, but does not identify whether DNS, local outbound policy or a route is responsible. If TLS appears to succeed but the encoder reports a publishing error, its RTMPS support and URL parsing may need attention.
Avoid starting by changing bitrate, resolution or keyframe settings. Those matter once a stream reaches YouTube; they cannot repair a TLS handshake that fails before the stream begins. If the encoder log uses a vague label such as “connection failed”, preserve the surrounding lines as well as the summary message. Redact keys and other secrets before sharing them.
Verify the RTMPS URL, hostname and path
Open the current stream settings in YouTube Live Control Room and copy the RTMPS URL supplied there. Do not reconstruct it from a tutorial, an old saved profile or a hostname remembered from an earlier broadcast. YouTube may display an ordinary RTMP URL by default, so check that you selected the RTMPS option and that the encoder supports it. See YouTube's RTMPS encryption guidance for its instructions on retrieving and using the URL.
Preserve the supplied server hostname and path exactly. A path may contain information the ingest service uses to route the connection; deleting, replacing or appending text can make the URL unusable even when the hostname looks plausible. Check for accidental spaces, missing characters, line breaks, copied punctuation and stale profile values. Avoid pasting the full URL into a public forum if it includes sensitive session information.
The stream key is separate from the server address. Retrieve the current key from the same Live Control Room session, and enter it only in the encoder's intended field. A wrong key can prevent the publishing session from being accepted, but it is not a reason to change the RTMPS hostname or try unrelated endpoints. YouTube's RTMPS ingestion guide describes the protocol requirements; use the URL shown for your stream rather than guessing a different server.
Check the encoder's input fields carefully. Some accept one combined URL, while others have separate server and key fields. Entering the key twice, putting it into the path, or splitting a combined URL incorrectly can produce a failure that looks like a network issue. If a known-good encoder profile is available, compare its field layout without copying an old URL or key blindly.
Check TCP 443 and TLS, not cleartext RTMP
RTMPS is RTMP carried inside TLS. YouTube's documented RTMPS connection uses TCP port 443 and a TLS session; ordinary RTMP is not interchangeable with it. Confirm that the encoder is opening a TLS connection to the supplied host on the supplied port, not trying cleartext RTMP or silently falling back to a different transport. Google's RTMPS ingestion documentation specifies port 443 and the hostname requirement for authentication.
A TCP connection and a TLS handshake are separate stages. If TCP cannot connect, investigate whether the destination is reachable and whether outbound traffic is allowed. If TCP connects but TLS reports a certificate or negotiation error, focus on hostname, SNI, certificate validation, the system clock and the encoder's TLS implementation. A successful port check alone does not prove that TLS works, that YouTube accepted the stream key, or that the RTMP session is valid.
Do not disable certificate validation to make an error disappear. That removes an important check without showing whether the client reached the intended YouTube service. Check that the VPS clock is sensible and that the client can validate certificates using its normal trust store. If the encoder is old or its RTMPS support is uncertain, check its own documentation and version information before changing system-wide TLS settings.
When you run a diagnostic TLS client, use the exact hostname from Live Control Room and make it send that hostname as SNI. A test aimed at an IP address may reach the same network destination but still fail hostname-based certificate validation or server selection. Record the command and output, but omit stream keys and other secrets from the record.
Confirm SNI matches the supplied hostname
SNI, or Server Name Indication, is the hostname a TLS client sends while beginning a connection. It lets the remote service select the certificate and service configuration for the requested name. For YouTube RTMPS, the SNI value needs to match the server hostname supplied in Live Control Room. The Google guide explicitly calls for the server hostname in the TLS handshake.
This explains why a raw IP address is not a useful substitute for the supplied URL. Even if the IP accepts a TCP connection, a TLS client connecting by IP or omitting SNI may not request the correct service identity. Similarly, a proxy, custom wrapper or encoder option that overrides the hostname can cause an SSL error while the underlying route remains reachable.
If a TLS test using the copied hostname and correct SNI succeeds, but the encoder still fails, compare the encoder's RTMPS preset, URL parsing, TLS support and version. Check whether it uses the URL hostname for both the connection and SNI, particularly if it has separate fields for a server address and a certificate name. Do not “fix” a mismatch by entering an unrelated name: return to the exact hostname supplied by YouTube and correct the client configuration.
Check guest outbound firewall and DNS
The firewall inside the VPS operating system is distinct from a provider-side network firewall. Check the guest's outbound policy for TCP 443, along with the ability to make DNS queries. On Linux, that may mean reviewing UFW, nftables or iptables rules; on Windows, review Windows Defender Firewall and any added security policy. The relevant question is whether the VPS can initiate the required outbound connections, not whether inbound ports are open.
Contabo describes its VPS/VDS network firewall as filtering incoming connections while leaving outbound traffic unrestricted. That makes an enabled provider firewall alone an insufficient explanation for blocked egress, but it does not rule out a guest-level rule or a routing problem. Contabo's separate OS-level firewall guidance discusses controls applied on the server itself. Do not open inbound ports as a remedy for a connection initiated by the VPS.
Resolve the exact hostname from the same VPS running the encoder. Confirm that DNS returns an answer and that the encoder is not using an old cached address or a manually configured alternative. If DNS fails, inspect the guest's resolver configuration and outbound DNS policy before assuming the RTMPS service is unavailable. A successful lookup only tells you that name resolution returned an address; it does not establish that TCP or TLS will work.
Keep the diagnosis tied to the machine that broadcasts. A test from your laptop or another server cannot show whether the VPS has the same resolver, firewall rules or route. If you alter a rule, change one thing at a time and repeat the same test, noting the time and result. That gives you a useful comparison and avoids leaving broad permissions in place after an inconclusive experiment.
Test connectivity and separate handshake from stream health
Use a sequence that moves from name resolution to transport and then TLS. First resolve the supplied hostname from the VPS. Next test whether TCP to that hostname on the supplied port can be established. Finally, run a TLS check that uses the hostname for SNI and certificate verification. These checks should be made from the server where the encoder runs. They are diagnostics, not a substitute for testing the actual encoder and publishing session.
| Observation | Next check | What it does not prove |
|---|---|---|
| DNS lookup fails | Resolver settings and guest DNS egress | It does not show that YouTube's RTMPS service is down. |
| TCP 443 times out or is refused | Guest outbound rules, route and endpoint reachability | It does not isolate a local rule from a route issue. |
| TCP works, but TLS reports a certificate error | Exact hostname, SNI, certificate validation, clock and TLS client | It does not by itself show that the provider blocks traffic. |
| TLS test succeeds but encoder fails | Encoder RTMPS support, URL fields, SNI behaviour and version | It does not prove the key or publishing session is accepted. |
| Stream appears in Live Control Room with poor health | Bitrate, encoder load, codec and stream health | It is a later-stage issue, not a handshake failure. |
If both a correctly configured TLS test and the encoder time out, look at DNS, guest egress policy and routing before changing video settings. A trace or MTR may help identify where a route appears to stop, but it is not conclusive proof of who is responsible. Contabo's connection troubleshooting guidance recommends useful route evidence when investigating a suspected connection issue. Share timestamps, destination hostname and resolved address, source VPS location, and test output if you contact support.
If the TLS test works but the encoder does not, record the encoder name and version, the exact sanitized error and which RTMPS fields it uses. If the connection reaches YouTube and appears in Live Control Room, stop treating the problem as a handshake issue. YouTube's guidance on encoder settings and bitrates is relevant to stream quality at that later stage. It recommends spare upload capacity above the stream bitrate; check the current guidance there rather than treating capacity as a cure for TLS failure.
The distinction matters for a 24/7 channel. A stream that never completes TLS needs connection diagnostics; a stream that connects and later drops needs a different record, including encoder health and Live Control Room status around the drop. For an always-on workflow built around a local encoder, this guide to keeping Streamlabs streaming after a Windows restart covers a separate continuity problem. It will not diagnose a failed RTMPS handshake on a VPS.
Do not infer an India-wide restriction from one failed connection. The available documentation establishes YouTube's connection requirements and Contabo's described firewall behaviour, not the state of this particular VPS's guest rules, DNS, route or encoder. A location-specific route issue remains possible, but it needs instance-specific evidence and, if indicated, investigation with the provider.
For channels that rely on a prerecorded loop, keep the media and connection questions separate. An audio or file-format issue is not the first explanation for a failure before the TLS session starts. If the stream does connect and the format becomes relevant, the article on sending podcast episodes in AAC format covers that later production concern. For a local playback workflow, the guide to looping a video on YouTube Live with VLC likewise addresses playback rather than VPS connectivity.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Does the India location mean YouTube RTMPS is blocked?
No conclusion follows from the location alone. The documented requirements are to use the supplied RTMPS URL, TLS, port 443 and matching SNI; this case has no VPS diagnostics that establish a location-based block. Check DNS, outbound policy and route from the instance before escalating a possible route issue.
Should I try a different YouTube hostname or port?
No. Copy the RTMPS URL currently supplied in Live Control Room and preserve its hostname, path and port. Trying an endpoint from an old guide can replace a known input with an unverified one and make the results harder to interpret.
If TCP port 443 works, is the handshake fixed?
Not necessarily. A TCP test checks whether a connection can be made; TLS still has to negotiate successfully with the correct SNI and certificate validation. Even a successful TLS test does not prove the encoder's RTMP session or stream key is accepted.
When should I check bitrate and encoder settings?
After YouTube receives the stream or reports a stream health problem. Bitrate, codec and encoder load affect the delivered stream, while a failed TLS handshake occurs earlier. Use Live Control Room status to identify whether the failure is still at connection setup or has moved to stream health.