A YouTube stream that disconnects from OBS on an Azure VM can be caused by the connection, the encoder workload, YouTube's ingest path, or Azure's outbound network configuration. Start by identifying which symptom is increasing before changing bitrate, resolution, routes, or security rules.
A reconnect only tells you that the connection was interrupted. It does not prove that Azure, OBS, YouTube, or a particular setting is responsible. Record the OBS statistics, save the log, read the YouTube stream-health message, and then compare those findings with the VM's actual outbound path.
Classify the disconnect before changing settings
The first useful question is not “which OBS setting should I change?” It is “what was OBS unable to do when the stream failed?” OBS separates several failure modes that can look similar to someone watching the preview or YouTube playback.
| OBS symptom | What it usually points towards | Evidence to collect |
|---|---|---|
| Dropped frames, network | An unstable path to YouTube's ingest server or a bitrate the connection cannot sustain | Dropped-frame count, bitrate, timestamps, YouTube health message, Azure route and security rules |
| Rendering lag | The VM's graphics or scene-rendering work is not completing on time | Rendering lag count, scene complexity, display or GPU configuration, CPU and GPU use |
| Encoding lag | The encoder cannot produce frames quickly enough for the selected settings | Encoding lag count, codec, resolution, frame rate, encoder preset, CPU or GPU use |
| A reconnect with little OBS lag | A session interruption, ingest issue, route problem, or other event not yet isolated | OBS log, YouTube health history, VM network path, exact time of the event |
These categories can overlap. A VM under heavy CPU load may encode slowly while a separate outbound rule blocks the next connection attempt. Conversely, a stream that reconnects may have no encoding problem at all.
Do not change several variables before taking a baseline. Note the current canvas and output resolution, frame rate, codec, bitrate, encoder, and whether OBS is running a looped file, playlist, camera, browser source, or a mixture. Record the UTC time if the stream disconnects. If the stream is part of a devotional, music, study, or local-news channel, also note what was playing at the time, because a transition or animated scene can change the workload.
If your broader setup is a long-running pre-recorded channel, the practical lessons in how to run a 24/7 church stream on a VPS with OBS are relevant to separating content playback from the reliability of the streaming process. The immediate issue here, however, is the evidence around this particular disconnect.
Read OBS Stats for dropped frames and lag
Open the OBS Stats window while the stream is running. The exact labels can vary slightly by OBS version, but the useful distinction remains the same: dropped frames related to the network are different from rendering lag and encoding lag.
Network dropped frames indicate that OBS could not deliver part of the outgoing stream to the remote ingest connection. OBS's official stream connection troubleshooting guide describes dropped frames and intermittent disconnections as commonly related to an unstable connection or a bitrate that the connection cannot sustain. That does not establish that the Azure VM is at fault in your case. It tells you which class of evidence to examine first.
Rendering lag means OBS is not producing the scene quickly enough before encoding. This can happen with demanding browser sources, filters, animated overlays, high-resolution scenes, or a virtual machine whose graphics capability is limited. Encoding lag means the encoder is failing to process frames on schedule. The two can appear together, particularly when the VM is short of CPU or GPU resources.
Watch the counters during a controlled test rather than relying on a single final value. If network dropped frames rise while rendering and encoding lag remain stable, investigate the outbound path and sustainable bitrate. If encoding lag rises while network drops do not, reducing encoder workload may be more relevant than changing Azure routes. If both rise, reduce the test to a simple scene and compare the results.
For a looped video, create a temporary test scene containing only the media source and basic audio. Stop unnecessary browser sources and overlays for the test, but document what you disabled. This is not a permanent recommendation. It is a way to determine whether the failure follows the content workload or the connection.
Do not treat a zero value during a short observation as proof that the system is reliable overnight. A network path may fail intermittently, and a scene may become more demanding only at a particular transition. Run the test long enough to reproduce the behaviour or collect a useful interval, then save the relevant OBS log.
Use the OBS log as supporting evidence
OBS Stats tells you what category was changing. The log helps establish what OBS was doing around the event. After reproducing the problem, use OBS's log menu to upload or save the log, then keep the timestamp of the disconnect beside it. A log from an unrelated session is much less useful.
Look for entries around the event that indicate a stream stop, reconnect attempt, encoder delay, dropped frames, connection failure, or a change in the selected output. Do not read one line in isolation. Compare the sequence before, during, and after the disconnect with the Stats counters and the YouTube message.
A useful incident note contains:
- The time in UTC and the length of the interruption.
- The OBS version and operating system on the VM.
- The output resolution, frame rate, codec, bitrate, and encoder.
- The Stats values for network dropped frames, rendering lag, and encoding lag.
- Whether the stream recovered by itself or required manual action.
- The YouTube Live Control Room stream-health message.
- The VM region and size, described without exposing credentials.
- The outbound design: direct public egress, NAT Gateway, firewall, VPN, or virtual appliance.
Redact the stream key, access tokens, private addresses where they are not needed, and any credentials before sharing the log. A support team can usually work with timestamps and error context without receiving secrets.
The log should narrow the investigation, not serve as a reason to declare a cause prematurely. For example, a reconnect entry confirms that OBS attempted to recover. It does not prove that the route table, bitrate, or YouTube ingest server caused the first interruption. You need the surrounding network and platform evidence as well.
Check YouTube Live Control Room stream health
Open YouTube Live Control Room while testing and read the stream-health status rather than relying only on the public playback page. YouTube can report whether the stream is arriving and whether it detects an issue with the incoming feed. Save the wording and time of any warning.
YouTube's guidance on live encoder settings, bitrates and resolutions recommends choosing quality that the connection can reliably sustain, testing the upload bitrate, and testing with representative movement and audio before the event. Its recommended ranges depend on the codec, resolution, and frame rate. There is no universal bitrate that is correct for every OBS stream or Azure VM.
Compare the YouTube message with OBS Stats. If YouTube reports an unstable or missing incoming stream and OBS shows rising network dropped frames, the connection path and sustainable bitrate deserve attention. If YouTube reports an encoder or video issue while network drops remain low, examine the OBS output and encoding workload. If YouTube shows healthy reception while the public playback appears delayed, that may be normal live latency rather than a disconnect.
Use a representative test. A still image with quiet audio does not exercise the same path and encoder workload as moving video, animated text, music visualisers, or frequent scene changes. For a 24/7 channel, test the type of material that is normally broadcast, including any sections that have previously preceded a failure.
Do not infer a permanent result from one clean test. A successful reconnect or a short period of healthy status shows that the stream worked during that interval. It does not identify the cause of a later failure or guarantee that a setting will prevent future disconnects.
Inspect Azure outbound rules, routes and egress
Once the OBS and YouTube evidence points towards the connection, inspect how the VM reaches the internet. The relevant path may include the VM's network interface, subnet, network security group, route table, NAT Gateway, firewall, virtual appliance, VPN, or another controlled egress point.
Start with effective outbound security rules rather than looking only at the rule you expect to apply. A network security group can allow or block outbound traffic, and a rule inherited or associated at another level may be the one that matters. Do not solve an unexplained disconnect by opening all outbound ports or disabling the NSG. Identify the specific blocked path with the person responsible for the Azure network.
Then inspect the effective routes for the VM's network interface. A user-defined route can send internet-bound traffic to a firewall or virtual appliance instead of the path you assumed. That device may apply its own filtering, inspection, VPN policy, or capacity limit. A route that exists is not automatically proof that the destination is reachable; confirm that the next hop and its policy are appropriate for outbound streaming traffic.
If the design uses Azure NAT Gateway, Microsoft documents that the gateway requires a public IP address or public IP prefix and association with the relevant subnet. Its NAT Gateway troubleshooting documentation also points to NSG rules and routes as possible reasons for failed outbound traffic. Treat NAT Gateway as one possible egress design, not as a guaranteed cure for stream instability.
Check whether the VM is routed through a firewall, VPN, or virtual appliance. These components can be correct and still be relevant to the diagnosis because they add another policy and another point at which an outbound connection can be refused, timed out, or forced through a different route. Ask the network administrator for flow or firewall evidence covering the timestamp in the OBS log.
Be particularly careful with newly deployed virtual networks. Microsoft's guidance on controlling outbound internet access from Azure states that virtual networks created using API versions released after 31 March 2026 default to private subnets without automatic outbound access, while existing virtual networks are unaffected by that specific change. Verify the actual deployment configuration and egress design instead of assuming that a VM has internet access because another Azure VM did.
The minimum Azure evidence is the effective outbound security result, effective route table, configured egress method, and any firewall or appliance decision recorded at the time of failure. Without those details, “Azure is disconnecting OBS” is only a hypothesis.
Match the fix to the observed symptom
Once you have a baseline, change one relevant variable at a time. A useful fix is one that changes the evidence in the expected direction and does not hide a second problem.
If network dropped frames increase, first compare the configured bitrate with YouTube's current guidance for the chosen codec, resolution, and frame rate. A temporary reduction can be a diagnostic test when the connection has limited stable capacity. If dropped frames stop during the test, that suggests the previous output was not sustainable, but it does not prove whether the limitation was the VM's route, an intermediate firewall, or the available outbound capacity.
If the bitrate is reasonable but the connection still drops, inspect the Azure path. Confirm that outbound security rules permit the required traffic, that the route does not send it to an unsuitable next hop, and that any NAT, firewall, VPN, or virtual appliance is configured for the actual subnet. Use the exact disconnect timestamp when checking logs. A general statement that “the VM has internet” is not enough, because ordinary browsing and a persistent ingest connection do not provide identical evidence.
If rendering lag increases, simplify the scene and reduce visual processing. Remove one browser source or filter at a time, then repeat the test. If the issue appears only with a particular scene, the content workload is part of the diagnosis. If the VM has no suitable graphics support for the chosen scene, changing network rules will not address the rendering queue.
If encoding lag increases, compare the codec, resolution, frame rate, encoder, and preset with the VM's available resources. YouTube's official encoder guidance should be checked for the current combinations it supports. A lower-complexity test can show whether the encoder is the limiting component, but avoid presenting a single setting as a guaranteed solution.
If OBS lists VPN or security software as a possible source of interference, test only through a controlled and approved change. Do not leave security protection disabled on an internet-facing VM. If the test requires a firewall or VPN policy change, have the administrator make and record the change, then restore it when the test is complete.
If the stream is stable but the operating process remains difficult to maintain overnight, the problem may be operational rather than a single OBS setting. Document the restart procedure, keep the VM awake, monitor YouTube health, and retain logs after each incident. For channels built around a single uploaded programme, a managed workflow such as StreamNeo can remove the need to keep OBS and the VM running continuously, while leaving you responsible for the video, YouTube channel, stream key, and platform requirements.
For a stream that uses a loop rather than a playlist, YouTube Live playlist streaming versus looping a single video explains a related content-choice trade-off. If you are tuning output for a high-motion feed, the 1080p 60fps bitrate guide can help you frame the comparison, but still check YouTube's current official recommendations for your exact codec and frame rate.
Do not call the investigation complete because OBS reconnects. A reconnect is useful evidence that recovery occurred, not evidence that the original cause has been identified. The strongest conclusion links the OBS category, the log, YouTube's health message, and the Azure path to the same timestamp.
Build a useful escalation record
If the cause remains unclear, escalate with a compact record rather than a description such as “OBS keeps disconnecting”. Include the OBS log, the time range, Stats screenshots or notes, the YouTube health message, the VM operating system and region, and a redacted diagram of the outbound path.
State what changed between a working and failing test. For example, note whether a simple scene was stable, whether a lower bitrate changed network drops, whether the same VM can reach other destinations, and whether an Azure route or NSG was modified. Separate observed facts from assumptions.
The relevant administrator may be an Azure network owner, a firewall administrator, or the person managing the YouTube channel. Give each one the evidence needed for their part of the path. Never include the YouTube stream key, passwords, access tokens, or unredacted private configuration in a public support post.
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 reconnect prove that Azure is the problem?
No. A reconnect only shows that OBS recovered or attempted to recover a stream connection. Check OBS Stats, the log, YouTube stream health, and Azure's effective routes and outbound rules before assigning a cause.
Should I lower the bitrate first?
A temporary bitrate reduction can be a useful controlled test when network dropped frames are increasing. It is not a universal fix, because the appropriate range depends on the codec, resolution, frame rate, and the stable capacity of the outbound path.
Is encoding lag the same as dropped frames?
No. Network dropped frames concern delivery to the remote ingest connection, while encoding lag means OBS is not producing encoded frames quickly enough. Rendering lag is another separate category, so compare all three counters before changing network settings.
What should I send to an Azure administrator?
Send the timestamp, OBS log, Stats evidence, YouTube health message, VM operating system and region, and a redacted description of the subnet, NSG, route table, NAT, firewall, VPN, or virtual appliance path. Do not send the stream key or other credentials.