If FFmpeg runs on your Indian VPS and publishes directly to YouTube, the important firewall path is outbound RTMPS over TCP 443. You do not need to open inbound TCP 1935 for that arrangement.
Port 1935 becomes relevant only when the VPS receives an RTMP feed from another encoder and then acts as an ingest server or relay. Identify that network flow first, then apply the smallest rules that match it.
Identify the VPS role before changing the firewall
There are two different designs that are often described as “FFmpeg streaming to YouTube”. They have different firewall requirements.
In the direct design, FFmpeg is installed on the VPS. It reads a local file, playlist or capture source, opens a connection to YouTube, and sends the encoded stream there. The VPS is a client making an outbound connection. It does not need to accept a publishing connection from the public internet.
In the relay design, a separate computer or encoder sends a stream to the VPS first. A streaming service on the VPS listens for that incoming feed, and FFmpeg or another process forwards it to YouTube. The VPS is now both a server receiving a connection and a client making another connection.
Ask these questions before opening any port:
- Where does FFmpeg run?
- Does another device need to connect to the VPS?
- Is an RTMP service configured to listen on the VPS?
- Is the VPS sending directly to YouTube, or forwarding a feed it received?
- Is the firewall blocking outbound traffic, inbound traffic, or both?
The difference matters more than the fact that the VPS is located in India. The region may affect latency and the route to YouTube, but it does not change the basic direction of the connection. Your provider’s network firewall and the operating system’s firewall may also enforce separate policies.
For a broader choice between a local encoder and FFmpeg, see this comparison of OBS and FFmpeg for continuous YouTube streaming. It is useful to settle the architecture before you start adjusting network rules.
| Arrangement | Connection made by the VPS | Typical protocol and port | Public listener on VPS | Main firewall concern |
|---|---|---|---|---|
| Direct FFmpeg publishing | VPS to YouTube | RTMPS over TCP 443 | No | Permit outbound TCP 443 if egress is restricted |
| VPS as RTMP ingest | Encoder to VPS, then VPS to YouTube | Inbound RTMP commonly TCP 1935, plus outbound RTMPS TCP 443 | Yes | Protect the listener and permit the outbound YouTube path |
| Private relay | Approved encoder to VPS, then VPS to YouTube | Port depends on the service; outbound RTMPS uses TCP 443 | Yes, ideally source-restricted | Limit the source and avoid exposing unused services |
The table describes common arrangements, not a universal configuration. A service may be configured to listen on a different port, and a provider may use different names for its network firewall controls.
Direct FFmpeg publishing goes out over RTMPS
YouTube recommends RTMPS, the secure extension of RTMP, for live encoder connections. Google’s RTMPS ingestion documentation states that the connection must be made to port 443 on the ingestion server. Read the current RTMPS ingestion documentation alongside the server URL shown in YouTube Live Control Room.
The practical sequence is:
- Create or open the live stream in YouTube Live Control Room.
- Copy the current RTMPS server URL and stream key.
- Confirm that the URL begins with
rtmps://, rather than assuming an older RTMP example is still appropriate. - Configure FFmpeg to use that URL and key.
- Allow the VPS to make an outbound TCP connection to the destination and port required by YouTube.
The stream key is an authentication credential. Do not place it in a public support post, a screenshot, a shared shell history file, or a script repository. If you believe it has been exposed, replace it in YouTube rather than trying to compensate with a firewall rule.
A simplified FFmpeg command might look like this:
ffmpeg -re -stream_loop -1 -i input.mp4 \
-c:v libx264 -preset veryfast -pix_fmt yuv420p \
-c:a aac -f flv \
"rtmps://YOUR_YOUTUBE_SERVER/YOUR_PATH/YOUR_STREAM_KEY"
This is an illustration of the network destination, not a complete encoder profile for every channel. Use settings appropriate to your source, resolution, frame rate and available VPS resources. The firewall cannot correct a wrong stream URL, an invalid key, an overloaded CPU or an unsupported encoding setting.
YouTube’s encoder settings and bitrates guidance is the appropriate place to check current recommendations. For example, the page lists H.264 at 1080p30 with a 4 Mbps minimum and 10 Mbps recommended bitrate, and H.264 at 1080p60 with a 6 Mbps minimum and 17 Mbps recommended bitrate. It also recommends a two-second keyframe interval and says not to exceed four seconds. These are encoder settings, not firewall requirements.
Allow the required outbound path on TCP 443
A firewall rule has a direction. “Allow port 443” is incomplete unless you say whether the rule is for traffic entering the VPS or leaving it.
For direct publishing, FFmpeg needs to leave the VPS and reach YouTube’s RTMPS ingestion endpoint on TCP 443. If your VPS permits outbound connections by default, no additional broad egress rule may be necessary. Many systems use a restrictive outbound policy, however, and then you need to permit the required destination.
The intended rule is conceptually:
source: VPS
source port: ephemeral or automatically selected
destination: YouTube RTMPS ingestion host
destination port: TCP 443
direction: outbound
action: allow
Do not turn this into “open inbound 443” unless the VPS is also hosting an HTTPS service that genuinely needs to receive web traffic. An inbound TCP 443 rule allows public clients to contact your VPS; it does not, by itself, authorise FFmpeg to connect out to YouTube.
Whether you can specify the YouTube hostname in a firewall rule depends on the firewall manager. Some provider panels accept destination IP addresses or service groups, while others offer only broad protocol-and-port rules. YouTube’s service addresses can change, and hard-coding a single address can make a stream fail later. Prefer the provider’s documented destination or egress method where available.
If the firewall only supports an outbound port rule, allowing TCP 443 for outbound connections may be the practical choice. Keep the rule outbound and avoid opening unrelated inbound services. If you are unsure whether egress is already allowed, inspect the current policy rather than adding overlapping rules without understanding their order.
The provider’s network firewall is a separate control from UFW, firewalld, nftables or another firewall on the VPS. A permit in the operating system cannot overcome a provider rule that blocks egress. Check both layers and record which one was changed, so a later troubleshooting session does not assume that one control represents the whole path.
Why direct publishing does not need inbound TCP 1935
TCP 1935 is commonly associated with RTMP. FFmpeg’s protocol documentation describes the default RTMP port as 1935, which is why many setup guides mention it. That does not make it the port used for every YouTube streaming arrangement.
In direct publishing, FFmpeg initiates a connection to YouTube. The connection is outbound from the VPS and uses YouTube’s RTMPS ingestion port, TCP 443. The response traffic belongs to that established connection and is normally handled by a stateful firewall without a separate public listener on the VPS.
Opening inbound TCP 1935 in this design adds exposure without solving the relevant problem. It does not make outbound RTMPS work, and it does not repair a blocked provider egress policy. It may also leave an unused port visible to internet scans if no service is listening, while creating confusion about what the VPS is intended to do.
The answer to “Do I need to open port 1935 on my VPS?” is therefore: not for FFmpeg publishing directly to YouTube over RTMPS. You need an inbound 1935 rule only when a service on the VPS is deliberately listening for RTMP on that port and an external encoder must reach it.
This distinction is especially important for always-on channels. A devotional loop, local news rotation or music stream that runs entirely from files on the VPS is a client-to-YouTube arrangement. It does not become an ingest server merely because the output is live.
When inbound RTMP is needed for a relay
Inbound RTMP is a separate requirement for a VPS that accepts an encoder feed. For example, a camera computer might publish to an RTMP service running on the VPS, while a forwarding process sends that feed to YouTube. In that case, the VPS needs a public listener for the first connection.
If the RTMP service is configured to listen on TCP 1935, the relevant conceptual rule is:
source: approved encoder address, where practical
source port: automatically selected
destination: VPS
destination port: TCP 1935
direction: inbound
action: allow
The service must actually be listening on that port. Opening it in a firewall does not create an RTMP server. Conversely, if the service listens on another port, opening 1935 will not help.
Restrict the source whenever the encoder has a stable public address or can reach the VPS through a private network. If the encoder’s address changes, you may need a wider rule, but understand that this increases the exposed surface. Use authentication and the access controls provided by the RTMP service as an additional layer, not as a reason to expose unrelated ports.
A relay usually needs two independent paths:
- Inbound traffic from the external encoder to the VPS’s RTMP listener.
- Outbound traffic from the VPS to YouTube’s RTMPS endpoint on TCP 443.
A rule for the first path cannot replace the second. If the relay accepts the incoming feed but cannot connect to YouTube, the listener may appear healthy while the broadcast never reaches Live Control Room. If the outbound path works but the listener is blocked, FFmpeg or the relay process has no source to forward.
Do not expose administrative panels, metrics endpoints, databases or file-transfer services merely because the relay is public. Keep those services on a management network, behind an access list, or closed when they are not required. The relay design is appropriate when you genuinely need another encoder to publish into the VPS; it is unnecessary complexity for a file that FFmpeg can read locally.
Apply least-privilege rules at both firewall layers
Start by documenting the actual traffic, then translate it into the syntax of your operating system and provider. The correct command differs between Ubuntu with UFW, a distribution using firewalld, a manually managed nftables ruleset and a hosting panel with its own controls.
On an Ubuntu host using UFW, inspect the current policy before making changes:
sudo ufw status
sudo ufw status verbose
Do not enable a restrictive incoming policy while connected over SSH unless you have first preserved access. Confirm the actual SSH port, the source restriction in use, and whether a provider firewall also controls that path. A common failure is to change the default policy, close the current session, and discover that the next login is blocked.
The general UFW workflow is to establish the intended defaults, retain the required SSH rule, and then add only the service rules the VPS needs. UFW’s official Ubuntu documentation covers status checks, default policies and port rules. Follow the version and distribution documentation for the image you are actually running rather than copying a rule from an unrelated VPS guide.
For a direct publisher, the rule model is usually simple:
- Keep inbound access closed except for administration and any service you intentionally host.
- Permit outbound TCP 443 if the existing egress policy blocks it.
- Do not add inbound TCP 1935.
- Avoid a broad inbound rule for all ports.
- Keep the SSH rule limited to the source addresses you can use safely, where practical.
For a relay, add the inbound RTMP port only after confirming the listener and its intended source. Then retain the outbound RTMPS rule. If the provider firewall has separate ingress and egress controls, reproduce the required directions there as well.
Do not assume that a provider’s “allow web traffic” preset covers outbound RTMPS in the way you need, or that an operating-system rule controls traffic before it reaches the VPS. Read the provider’s current documentation for its network firewall, especially if it has default-deny egress, security groups or account-level filters. No single Indian VPS control panel or operating-system image can be treated as universal.
Make one change at a time and keep a short record of the previous state. If a stream fails after a firewall edit, you can then identify whether the failure followed an egress change, an inbound listener change or an unrelated provider rule.
Test connectivity and confirm YouTube receipt
A successful firewall check is not the same as a successful live broadcast. Test the network path, the FFmpeg process and YouTube’s receipt separately.
First confirm that the VPS can resolve the hostname supplied by YouTube. A DNS result alone does not prove that TCP 443 is reachable, but a failed lookup is an earlier problem to fix. Then test the destination using tools available on your distribution and permitted by your provider. A TCP connection test can show whether the route is blocked, although it cannot prove that the stream key, RTMPS path or encoder settings are valid.
Keep the test focused on the exact hostname and port shown in Live Control Room. Do not test an arbitrary website on port 443 and conclude that YouTube ingestion is available. A general HTTPS connection may use a different destination, route or policy.
When FFmpeg starts, read its output carefully. A timeout points towards routing, DNS or firewall policy. A TLS or protocol error can indicate an incorrect scheme, endpoint, certificate negotiation problem or a client that does not support the required RTMPS connection. An authentication or publishing error may instead indicate the stream key, path or YouTube live-event state.
YouTube advises checking the URL and port and ensuring that the encoder supports RTMPS when a connection fails. After the connection is accepted, use Live Control Room’s stream health and preview rather than relying only on the FFmpeg process remaining open. A process can continue running while sending no useful frames, sending an unsupported format or repeatedly reconnecting.
Test with a representative segment before relying on the channel overnight. Check that audio is present, the picture is stable, the keyframe interval matches the encoder plan and the stream remains connected after a normal network interruption. YouTube’s live streaming troubleshooting guidance should be checked for current status messages and recommended tests.
For a 24/7 channel, also watch the VPS itself. Check CPU load, memory, disk space for logs and source files, and the process supervisor’s restart behaviour. Firewall changes will not resolve a source file that ends, a disk that fills or a VPS that runs out of memory. If the aim is to keep your personal computer switched off, a managed workflow such as StreamNeo removes the need to maintain the publishing process on your own VPS, while you still need to verify the YouTube channel, content rights and stream settings yourself.
A practical decision before you deploy
Use direct publishing when the media already lives on the VPS and FFmpeg can produce the stream there. It has one main network relationship: outbound RTMPS to YouTube. That makes the firewall model easier to inspect and reduces the number of public services that must remain available.
Use a relay when another encoder must send a live source to the VPS, when you need a central ingest point, or when a separate process genuinely depends on receiving RTMP. In exchange, you take responsibility for a public listener, source restrictions, authentication, relay stability and two network paths.
If you are building a music or devotional station, the guide to starting a 24/7 Indian music live stream with FFmpeg may help with the content and process side. For resolution, bitrate and server capacity, use this server streaming resolution and bitrate guide as a separate planning reference. Neither topic changes the basic firewall distinction: direct publishing is outbound RTMPS, while a relay adds an inbound service.
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
Which ports do I open for FFmpeg to stream directly to YouTube?
Use YouTube’s current RTMPS server details and permit the VPS’s outbound TCP connection to the ingestion endpoint on port 443 when outbound traffic is restricted. You do not need an inbound TCP 1935 rule for direct publishing.
Do I need inbound TCP 1935 on an Indian VPS?
Only if an RTMP service on the VPS is deliberately accepting a feed from an external encoder on that port. The VPS location does not change the distinction between an inbound RTMP listener and an outbound RTMPS connection to YouTube.
Why does an outbound 443 rule not fix my relay?
A relay has two paths. It needs an inbound rule for the encoder-to-VPS connection and an outbound rule for the VPS-to-YouTube connection; allowing one does not allow the other.
What should I check if FFmpeg connects but YouTube shows no stream?
Confirm the RTMPS hostname, path and key from Live Control Room, then inspect FFmpeg’s protocol and authentication messages. Check YouTube’s preview and stream health, and separately verify that the encoder is producing supported video, audio, bitrate and keyframe settings.