A “connection refused” message from an encoder does not, by itself, tell you why a YouTube stream failed. Check the exact ingest URL and protocol first, then test DNS, outbound TCP and TLS from the VPS that runs the encoder.
For YouTube RTMPS, the documented destination is the YouTube ingest server over TLS on port 443, with the server hostname used for TLS verification and SNI. A VPS in India is not, on its own, evidence of a regional block or an IPv6 problem; work through the checks below before changing hosts or network settings.
What the error establishes — and what it leaves open
“Connection refused” is an error label reported by software, not a complete diagnosis. It can describe a failed attempt to open a network connection, but the exact meaning depends on the encoder and the point in its connection process where it reports the problem. It does not identify whether the destination was wrong, the port was unreachable, a firewall rejected traffic, or the encoder’s own connection handling was at fault.
Capture the details before changing anything: the encoder name and version, VPS operating system and region, the exact message, the time it happened, and whether the configured address starts with rtmp:// or rtmps://. Note whether the error occurs immediately, after a delay, or only after a previous successful session. Do not include your stream key in a support ticket, screenshot or public post.
The stages matter. A hostname that does not resolve points towards DNS. A successful lookup followed by a failed TCP connection points towards reachability or filtering. A TCP connection followed by a TLS error moves attention to encryption, hostname verification or SNI. If the connection gets through those stages but YouTube does not accept the broadcast, investigate the encoder settings and stream key rather than assuming the VPS firewall is responsible.
A failure on one VPS is not enough evidence to blame its country, provider or address family. Nor does a successful connection to an unrelated website establish that YouTube’s ingest endpoint, full path and encoder configuration work. Keep the test aimed at the hostname and protocol the encoder is actually meant to use.
Verify the current ingest URL and protocol
Open YouTube Live Control Room and copy the current server URL from the stream settings. YouTube may show an RTMP URL by default; its RTMPS instructions explain how to reveal the secure URL. Check the whole value, including the protocol, hostname and any path or stream-specific portion the encoder expects. Avoid retyping it from memory.
RTMP and RTMPS are not interchangeable labels for the same connection. RTMP is not encrypted in the way RTMPS is; RTMPS adds TLS. If the selected YouTube endpoint expects RTMPS but the encoder is configured for plain RTMP, changing firewall rules will not correct that mismatch. Conversely, do not switch to an assumed secure address unless YouTube provides it for the stream and the encoder supports it.
Do not replace the hostname with an IP address you found in a DNS lookup. The hostname is part of the TLS identity check and is needed for SNI, which tells the destination which server name the client intends to reach during the handshake. An IP may change, and a TLS connection to the IP alone may fail hostname verification even when the route is otherwise reachable.
If you use a saved encoder profile, compare it with the current Live Control Room details rather than assuming it is still correct. A profile can retain an old endpoint or a different protocol after a stream has been recreated. For a walkthrough of encoder setup on a VPS, the Vultr automatic-restart guide is relevant background, but confirm the ingest details in YouTube itself.
Check outbound access to the configured hostname
Run network checks from the same VPS and execution environment as the encoder. Testing from your laptop, a separate container, or a different virtual machine can miss a firewall or route that applies only to the actual streaming process. First check whether the hostname resolves; then test a TCP connection to the documented port; then test TLS using the hostname. These checks narrow the fault without exposing your stream key.
The exact commands vary by operating system and installed utilities, so do not rely on a command copied for another distribution without checking its options. The key questions are simple: did DNS return addresses, could the VPS open outbound TCP to port 443, and did a TLS handshake complete when the hostname was supplied? Record the time, hostname and sanitized output. Do not post credentials or a full stream URL if it contains a secret component.
A successful generic HTTPS request is useful but limited evidence. It shows that some HTTPS destination is reachable, not that the YouTube ingest endpoint and path work or that your encoder can establish RTMPS correctly. Likewise, a failed test to an unrelated web server does not prove YouTube is blocked. Keep the test tied to the configured YouTube hostname and distinguish DNS, TCP and TLS results in your notes.
If DNS fails, check the VPS resolver settings and whether the hostname was copied correctly. If resolution succeeds but TCP 443 cannot be opened, inspect egress rules and ask the VPS provider whether outbound connections to that destination are filtered. If TCP opens but TLS fails, retain the hostname in the test and check the certificate, TLS client behaviour and SNI rather than trying a bare IP address.
A working upload rate test can be useful for a different question: whether the outbound connection has enough capacity and stability for the chosen stream. It does not establish that a particular ingest connection is accepted. The church stream upload-speed guide discusses capacity; treat that separately from a refused connection.
Confirm RTMPS port 443, TLS and SNI
Google’s RTMPS developer documentation specifies TLS and states that the connection must be made to port 443 on the ingestion server. Use the port and hostname provided for YouTube’s RTMPS endpoint; do not assume that opening inbound port 1935 on your VPS is required. Your VPS is the client making an outbound connection to YouTube.
TLS is not simply a checkbox that makes any destination equivalent. The encoder must initiate a TLS handshake with the intended server name, validate the server’s certificate, and send SNI for the hostname. A client that connects to an IP without SNI, uses an incompatible TLS implementation, or treats a secure endpoint as plain RTMP can fail before YouTube sees a usable stream. Keep the endpoint hostname intact throughout your tests.
When a TLS check fails, note the failure stage and the error text. A timeout, certificate validation error and protocol negotiation error are different clues. Check the system clock as a basic certificate-validation condition, then make sure the client is using the exact hostname and supports the endpoint’s TLS mode. A successful browser visit to a public web page does not test all these details for the encoder’s ingest session.
Do not guess a substitute port because another streaming application uses it. The documented requirement is specific to YouTube RTMPS. If a network or cloud firewall permits web browsing but denies this outbound destination or port, ask the provider to confirm the applicable egress policy. When the provider says the path is permitted, return to the encoder’s URL, TLS support and logs rather than repeatedly changing unrelated firewall settings.
Review VPS egress firewall and provider rules
Check each layer that can restrict outbound traffic: the guest operating system firewall, any cloud or VPS network firewall, and the provider’s own egress policy. The names and controls differ by vendor. Look for a rule affecting outbound TCP 443, the destination range, or the process and network interface used by the encoder. Do not make broad firewall changes just to see whether they help; record the existing rule and make a narrow, reversible test if you administer it.
A rule that permits inbound traffic is not the same as one that permits outbound traffic. For a client-to-YouTube RTMPS connection, the VPS initiates the session towards YouTube. Replies are normally part of that established connection; opening an inbound listener on the VPS does not resolve an outbound restriction. Google’s port guidance concerns the client connection to the ingest server, not a requirement to expose your VPS to incoming RTMP traffic.
If the TCP test fails, give support a concise, sanitised report: timestamp and timezone, VPS region, destination hostname, DNS answers, protocol and port, and whether the failure occurred at DNS, TCP or TLS. Ask specifically whether outbound RTMPS over TCP 443 or the route to the resolved destination is restricted. Avoid asserting that a particular Indian provider or region is at fault unless you have evidence from your own tests and the provider’s response.
If you are weighing a host change, do so after identifying a persistent route fault or confirmed egress restriction. Compare the candidates on the outbound RTMPS policy, available address-family controls, support responsiveness and network terms, not just advertised location. Moving first can reproduce the same encoder or URL error on a new machine. For the broader resilience question, see what happens when a 24/7 stream loses internet; recovery planning is useful, but it does not diagnose the current connection.
Check that the encoder supports the selected protocol
Confirm that the encoder version supports the protocol you selected and that it is configured to use RTMPS when the YouTube URL begins with rtmps://. Update the encoder using its vendor’s normal release process if it is old, and check its own logs for a more specific error than the short status shown in the interface. A wrapper script or service may also be launching a different binary or loading an old profile, so verify the settings in the environment that actually runs overnight.
Separate connection establishment from stream-key acceptance. If DNS, TCP and TLS checks all pass but YouTube does not start receiving the broadcast, recheck the current stream key in Live Control Room and update the encoder profile if needed. YouTube’s live-stream troubleshooting guidance advises updating the encoder and, for third-party encoder startup errors, refreshing the stream key. Keep the key private when you do so.
A key problem and a network refusal are not the same diagnosis, even if an encoder reports them with similarly unhelpful wording. Use the encoder log and YouTube Live Control Room status together: did the client reach the service, did the service identify an incoming stream, and did it accept the stream configuration? If you contact the encoder vendor, share the version, protocol, endpoint format with secret portions removed, and the relevant TLS or network error.
If the stream begins but later drops, look at connection quality and encoder health rather than treating every later interruption as a startup refusal. YouTube recommends testing outbound connectivity and contacting the internet provider when connection issues remain. For a continuing loop, the dropped-frames troubleshooting guide may help you distinguish a capacity or stability problem from the initial connection failure.
When an IPv4-only test may help
An IPv4-only test is a diagnostic for a particular set of circumstances, not a universal fix for VPS streaming in India. PRISM Live Studio’s desktop connection troubleshooting guide specifically discusses users in India and Indonesia and suggests IPv4 Only and network optimisations for the issue it documents. That vendor guidance does not establish that IPv6 causes every refusal, or that a VPS provider’s location is responsible.
Consider the test only if the encoder or runtime actually uses IPv6 and provides an address-family choice, or if your DNS and connection tests show an IPv6 path that is failing while an IPv4 path may be available. Compare reachability to the same hostname by each address family and preserve the hostname for TLS and SNI. Do not hard-code a resolved address as a substitute for a proper hostname-based test.
For a PRISM desktop setup, follow its instructions for IP Family and network optimisations, apply the settings and restart the application. On a VPS running another encoder, an equivalent setting may not exist; use that encoder’s documentation and the VPS networking controls rather than assuming a PRISM option applies. If IPv4 works and IPv6 does not, report that evidence to the provider or software vendor. If both fail at TCP 443, the address family is not yet the only suspect.
Do not leave a diagnostic change in place without noting it. Record the original setting, the test result and whether the change alters the failure stage. If it changes nothing, restore the original configuration and continue with the URL, egress and encoder checks. Geography alone cannot tell you which path the VPS selected or whether that path is broken.
A practical escalation checklist
Once you have run the checks, send each party evidence relevant to its part of the path. A VPS provider can investigate egress policy and routing; an encoder vendor can investigate protocol handling, logs and profile behaviour; YouTube’s own guidance can help with stream configuration and key-related startup errors. A generic report saying “RTMP is refused in India” gives none of them a reproducible point to inspect.
Include the time of the attempt, the VPS region, operating system, encoder and version, hostname, protocol, port, DNS result, TCP result, TLS result and sanitized error text. Say whether the test was IPv4 or IPv6 if known. Redact the stream key and any credential-bearing URL. If you changed a firewall rule or address-family setting, include what changed and whether the result changed.
Use the stage of failure to decide what to do next. DNS failure calls for a resolver or hostname check. A TCP failure calls for egress and route review. A TLS failure calls for hostname, SNI and client support review. If all three succeed yet no broadcast starts, inspect the encoder and stream configuration. This does not guarantee a resolution, but it avoids making a provider migration or broad firewall change without evidence.
If the VPS provider confirms a persistent restriction or route fault and cannot resolve it, compare alternatives on the same practical questions: do they permit the required outbound connection, can you test both address families, and can support investigate a destination-specific failure? Do not choose a new host on the assumption that an India VPS is inherently unsuitable; the evidence should identify what needs to change.
When the underlying problem is the need to keep a local computer running solely to sustain a file-based channel, StreamNeo removes that specific operational burden by letting you upload the video and run the YouTube broadcast with your computer switched off. It is YouTube-only, so it is not a way to diagnose a VPS encoder’s RTMPS connection, and you should still verify that the channel and file are ready before changing your workflow.
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 “connection refused” prove YouTube blocked my VPS?
No. The message alone does not show whether DNS, the route, a firewall, TLS or the encoder caused the failure. Test the configured hostname and protocol from the VPS and note which stage fails before drawing a conclusion.
Which port should I check for YouTube RTMPS?
Google documents RTMPS connections to the ingestion server on TCP port 443, using TLS. Check outbound access to that destination; opening inbound port 1935 on your VPS is not the documented requirement for this client connection.
Should I force IPv4 because my VPS is in India?
Not on location alone. IPv4-only is a targeted diagnostic where the encoder/runtime uses IPv6 and the path or vendor guidance makes an address-family test relevant; PRISM’s advice applies to the issue described in its own desktop guide, not every Indian VPS.
What if TCP and TLS work but the stream still will not start?
Check that the encoder supports the selected RTMPS protocol, confirm its current endpoint settings, update it if needed, and review the stream key in Live Control Room. Share sanitized logs with the encoder vendor or use YouTube’s troubleshooting guidance, keeping the secret key private.