A timeout while connecting from a VPS to YouTube Live does not, on its own, prove that port 1935 is blocked. It tells you that the connection attempt did not complete in the way the encoder expected; the cause could be the URL, protocol, outbound network policy, firewall, or the path between systems.
Work from the actual ingest details in YouTube Live Control Room, then test the outbound destination and port your encoder is configured to use. YouTube supports RTMP and RTMPS, and documents port 443 as a troubleshooting option for certain RTMPS SSL errors, not as a universal repair for every timeout.
What a VPS timeout does and does not prove
A connection timeout is an observation, not a diagnosis. It means the client waited for a connection or response and did not receive one within its timeout period. It does not name the point where communication failed. The encoder might be trying the wrong server, using a protocol the selected URL does not accept, or attempting a destination and port that the VPS cannot reach. A local firewall or provider egress rule is also possible, as is a temporary issue elsewhere along the route.
That distinction matters because “port 1935 blocked” sounds like a confirmed network finding. It is only one hypothesis unless you have tested the exact outbound path to the actual current endpoint and established that the failure is specifically associated with that destination and port. The official guidance does not establish that every YouTube ingest endpoint requires port 1935, nor that any particular VPS provider filters it.
Also separate outbound and inbound traffic. A streaming process on your VPS initiates a connection to YouTube. Opening inbound port 1935 on the VPS is therefore not the direct remedy for a process that cannot make an outbound connection. Inbound rules govern connections arriving at your VPS; the diagnostic question here is whether the outbound connection to YouTube can be made.
For a useful comparison, start with the difference between a failed attempt and a verified cause:
| Observation | What it supports | What it does not establish |
|---|---|---|
| Encoder reports “connection timed out” | The configured connection did not complete as expected | That port 1935 is blocked, or that YouTube is unavailable |
| A generic connection test to another host succeeds | The VPS can reach that other host using that test | That the YouTube endpoint and port are reachable |
| The exact destination and port fail an outbound test | A problem exists on that tested path or with the test setup | Which firewall, provider rule, endpoint, or configuration caused it |
| The encoder connects and YouTube receives a feed | The initial ingest path is working | That the stream has enough bandwidth or will remain healthy |
Treat each result as a clue. Keep a note of the test command or tool, destination hostname, port, protocol, time, and result so that you can distinguish what you checked from what you suspect.
Get the ingest URL from Live Control Room
Begin in YouTube Live Control Room and use the current stream setup details. Copy the server URL and stream key as shown for that broadcast, rather than reusing a URL saved in an old encoder profile, a tutorial, or a previous stream. The server component identifies the ingestion endpoint; the key identifies your stream. Handle the key as a credential and do not paste it into public logs, screenshots, or support tickets.
A URL can look plausible and still be wrong for the current setup. It may be stale, incomplete, copied with an accidental space, or paired with the wrong protocol selection in the encoder. Compare the whole server URL character by character, including its scheme or protocol indicator, hostname, and any path or port that YouTube provides. Do not add a port merely because an article or forum post says it is common. Use the current instructions YouTube shows for the stream.
YouTube’s encoder settings guidance lists RTMP and RTMPS and recommends RTMPS when you need encryption. YouTube’s RTMPS troubleshooting page specifically directs streamers experiencing connection timeouts to check that the URL is correct and that the encoder supports RTMPS. Those checks are more useful than assuming the port number from the error wording.
If you use multiple stream profiles, label them with the matching protocol and purpose. For example, keep a profile for the current RTMPS URL and another only if YouTube has given you a valid alternative configuration. Avoid editing the only working profile before recording its existing settings. That gives you a straightforward rollback if a change makes diagnosis harder.
If the setup uses a video file loop, encoder compatibility and network reachability remain separate questions. An article on keeping a pre-recorded video looping on YouTube Live addresses the content workflow; it does not replace checking the server URL and outbound route for the encoder or service you use.
Check encoder protocol and URL
Once you have copied the current ingest URL, inspect the encoder’s connection settings. Confirm that its protocol selection matches the URL and that the encoder version supports that protocol. A client configured for RTMP should not be assumed to handle an RTMPS URL correctly, and an RTMPS selection is not useful if the application cannot establish the required encrypted connection.
Check whether the encoder separates the server URL from the stream key. Some interfaces provide distinct fields; others may show a combined address. Follow that encoder’s own format rather than merging or splitting values by guesswork. A misplaced key, an extra slash, a pasted space, or an outdated server field can produce errors that look like network failures.
Make one change at a time. If you replace the URL and protocol simultaneously, a successful connection will not tell you which mismatch mattered; a continuing failure will leave both variables in play. Record the original values without exposing the key, adjust only what conflicts with YouTube’s current setup, and retry. If you are unsure which field corresponds to the server, consult the encoder’s documentation rather than trying port variations at random.
A protocol or codec compatibility issue can also be confused with an ingest problem. The first task is establishing whether the encoder can open the selected connection. Only after that succeeds should you interpret YouTube’s incoming stream and health indicators. For a broader look at format compatibility, see the OBS AV1 compatibility guide; that topic is distinct from whether the VPS can reach the ingest endpoint.
Verify outbound connectivity from the VPS
The relevant network test starts on the VPS and targets the exact hostname and port in the current ingest configuration. Testing from a laptop, testing a different server, or scanning the VPS from outside answers a different question. A port scan of your VPS usually concerns inbound reachability to your machine, whereas the encoder needs an outbound connection initiated from it.
First resolve the endpoint hostname from the VPS if your operating system and tools allow it. Then use an outbound TCP connectivity test to that exact hostname and configured port. The precise tool depends on the operating system and what is installed; a simple TCP connect test can tell you whether a connection was established, while a TLS-aware test may additionally report whether an encrypted handshake begins. Neither should be treated as a complete YouTube ingest test unless it exercises the same destination and relevant protocol.
Be careful with tools that merely check DNS, ping an IP address, or test a generic web page. DNS resolution shows that a name can be looked up. A ping response concerns ICMP, which may be filtered independently. Access to a website on port 443 says nothing conclusive about another host or port. These checks may help narrow the problem, but they do not prove the YouTube ingest path works.
If the exact outbound test fails, check the VPS operating system’s outbound firewall and any cloud firewall or network security rules associated with the instance. Then ask the hosting provider whether outbound TCP to the destination and port is filtered for your plan or account. Give them the endpoint hostname, destination port, source VPS address, time of test, and error output, but not the stream key. Providers can tell you about their egress policy; they cannot confirm a YouTube key or encoder setting for you.
If the test succeeds but the encoder still times out, do not conclude that the network is fully cleared. Your test may use different DNS resolution, a different protocol, or a different source process than the encoder. Check whether the application uses a proxy, whether its connection settings match the tested target, and whether the failure occurs at connection establishment or later in TLS or stream negotiation.
Once the connection is established, capacity becomes a separate issue. YouTube recommends a reliable connection and adequate upload capacity, with about 20% headroom over the stream’s bitrate. This is operational guidance, not a guarantee that a particular VPS or route will stay healthy. Its streaming tips are useful when a stream connects but later buffers or drops frames.
For related symptoms after the ingest path is open, the article on buffering from a VPS can help separate bandwidth and stream-health questions from a port reachability check. A successful TCP connection is only one prerequisite; it does not measure sustained upload reliability under the actual stream load.
Understand RTMPS and port 443
YouTube describes RTMPS as a secure extension to RTMP. The practical difference is that RTMPS uses encryption for the connection. Use the protocol that YouTube supplies for the stream and that your encoder can support, rather than treating RTMP and RTMPS as interchangeable labels for the same URL.
YouTube’s RTMPS help includes port 443 as a troubleshooting option for certain SSL errors. The developer documentation describes establishing a TLS connection to port 443 at the server named in the ingestion URL. That is a specific path to try when the documented error and configuration apply; it is not evidence that all RTMP timeouts are caused by a blocked port or that switching to 443 will fix every network issue.
Before trying it, confirm that you are using RTMPS, that the encoder supports the relevant configuration, and that the current URL and endpoint are the ones YouTube has provided. Follow the exact instructions on YouTube’s current RTMPS ingestion guide and troubleshooting page. If the page describes your SSL error, you can test the documented 443 configuration and compare the result with the previous attempt. Keep the remaining settings unchanged so the result is interpretable.
If port 443 connects but the stream still fails, you have evidence that a connection path differs, not proof that the broadcast is now correctly configured. TLS validation, stream key, encoder settings, and YouTube’s incoming stream status still matter. If neither port path works, return to the hostname, protocol, provider egress policy, and exact error rather than trying unrelated port numbers.
YouTube also documents HLS ingestion using an HTTPS URL when the encoder supports HLS. HLS is a distinct ingestion configuration to select in YouTube Live Control Room, not a switch that automatically bypasses any VPS restriction. Consider it only if your encoder and stream setup support it, and check the current HLS setup guidance before changing ingestion methods.
Interpret test results without overclaiming
A clean diagnosis separates layers. The first layer is configuration: does the encoder have the current URL, key, and matching protocol? The next is basic outbound reachability: can the VPS establish a connection to the exact destination and port? Then comes protocol negotiation: can the client establish RTMPS encryption if that is what the URL requires? Finally, after the ingest connection is accepted, examine whether the stream is arriving and remains healthy.
| Test result | Sensible next step | Avoid claiming |
|---|---|---|
| DNS lookup fails | Check the hostname copied from Live Control Room and the VPS resolver | YouTube is blocking port 1935 |
| TCP connect to exact endpoint fails | Check local/cloud egress rules and ask the provider about outbound filtering | The provider definitely blocks the port |
| TCP connects, RTMPS handshake fails | Confirm RTMPS support, URL, TLS configuration, and the documented 443 option where applicable | Port 443 fixes every RTMPS error |
| Encoder connects but stream health is poor | Check upload headroom, route reliability, bitrate and YouTube stream status | Port reachability guarantees a stable stream |
The sequence also helps with a stream that works intermittently. Compare the time of a failed attempt with provider network events, local firewall changes, and YouTube’s stream health messages. A repeatable result is more useful than an isolated timeout, but even repeatability does not identify the responsible network component until the relevant policy or path is confirmed.
If you need an overnight channel, a working test at setup time is not the same as a reliable unattended operation. Keep monitoring enabled in the encoder or chosen streaming workflow, and have a recovery plan for a dropped connection. The piece on keeping an OBS stream running overnight covers the operational side of long sessions; for a file-based channel where the pain is leaving a computer on to maintain the broadcast, StreamNeo removes that specific requirement by running an uploaded video as a YouTube live stream while your computer is off. Neither approach changes the need to confirm the correct YouTube ingest configuration and network path.
Escalate with useful error details
When the basic checks do not resolve the timeout, send a concise, redacted report to the party that can investigate the relevant layer. For a VPS provider, include the instance region or location, operating system, test time with time zone, destination hostname and port, whether the test was outbound TCP or TLS, and the complete error text. Ask specifically whether outbound traffic to that destination and port is subject to filtering. Do not send a stream key, account password, or unredacted configuration export.
For YouTube or encoder support, include the encoder name and version, protocol selection, whether the URL came from the current Live Control Room setup, the stage at which the failure occurs, and any displayed error text. If the stream reaches Live Control Room but health is poor, include the stream health details and a description of the upload connection. YouTube’s live troubleshooting guidance recommends checking outbound connectivity and involving the internet service provider when network issues are found.
Describe what you observed rather than prescribing a cause: “A TCP test from this VPS to the hostname and port in the current RTMPS URL timed out at this time” is more actionable than “YouTube blocked port 1935”. That wording leaves room for the provider to check its egress rules, for you to revisit the encoder URL, or for support to identify a different issue.
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 a timeout prove port 1935 is blocked?
No. It shows that the attempted connection did not complete within the client’s wait period, but it does not identify why. Verify the current URL and protocol, then test outbound connectivity to that exact endpoint and ask the provider about egress filtering if needed.
Should I open inbound port 1935 on my VPS?
Not as a fix for an encoder that needs to connect outward to YouTube. Inbound rules control connections arriving at the VPS, while ingest is initiated by the encoder from the VPS to YouTube. Check outbound firewall and provider policies instead.
Will using port 443 fix an RTMPS timeout?
Not necessarily. YouTube documents port 443 as a troubleshooting option for certain RTMPS SSL errors, with TLS to the server named in the ingestion URL. Use it only where the current YouTube guidance, URL and encoder support fit; it is not a universal timeout remedy.
Is HLS a way around VPS network restrictions?
Not by itself. YouTube supports HLS ingestion over an HTTPS URL when the encoder supports HLS, but it is a separate setup and may still be affected by network policy. Confirm that YouTube Live Control Room and your encoder are configured for HLS before testing it.