Recurring LL-HLS Stream Disconnections – HTTP/2 GO_AWAY PROTOCOL_ERROR

Wowza Streaming Engine
1

Hello Wowza Team,

First of all, we would appreciate it if this issue could be discussed and answered publicly here in the forum rather than being redirected to a support ticket.

Unfortunately, our previous support tickets have never resulted in a satisfactory resolution of these issues. We also believe that other Wowza Streaming Engine users may be experiencing similar problems and would benefit from having this technical information publicly available.

Problem Description

We are once again experiencing issues with LL-HLS playback on our Wowza Streaming Engine servers.

Customers are reporting that live streams unexpectedly stop playing or disconnect during playback.

While investigating the issue, we noticed recurring HTTP/2 errors in the Wowza logs:

ERROR	server	comment	2026-10-21	05:18:07	-	-	-	-	-	1033628.442	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:45318]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559887088

ERROR	server	comment	2026-10-21	05:18:27	-	-	-	-	-	1033648.441	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:18400]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559907088

ERROR	server	comment	2026-10-21	05:18:27	-	-	-	-	-	1033648.442	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:18394]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559907089

ERROR	server	comment	2026-10-21	05:18:47	-	-	-	-	-	1033668.441	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:29698]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559927088

ERROR	server	comment	2026-10-21	05:19:07	-	-	-	-	-	1033688.442	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:24070]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559947089

ERROR	server	comment	2026-10-21	05:19:27	-	-	-	-	-	1033708.442	-	-	-	-	-	-	-	-	Http2Connection[Socket:/xxx:47232]: GO_AWAY frame being sent for connection: [1:PROTOCOL_ERROR,DebugInfo:null]. Time: 1792559967089

What concerns us is that these errors appear repeatedly, sometimes at intervals of approximately 20 seconds.

Questions for the Wowza Engineering Team

1. What exactly does this error indicate?

What causes Wowza Streaming Engine to send an HTTP/2 GO_AWAY frame with PROTOCOL_ERROR?

Is this typically triggered by an invalid client request, an HTTP/2 implementation issue, a timeout, or an internal server-side condition?

2. Could these errors explain the LL-HLS playback interruptions?

Is there a known relationship between these HTTP/2 protocol errors and LL-HLS streams unexpectedly stopping during playback?

3. Why do these errors occur repeatedly?

In our logs, the messages sometimes appear at regular intervals of approximately 20 seconds.

Could this indicate a timeout, connection management issue, or a problem with persistent HTTP/2 connections used by LL-HLS?

4. Are there any known HTTP/2 issues affecting LL-HLS in Wowza Streaming Engine?

Are there known bugs, limitations, or compatibility issues related to HTTP/2 and LL-HLS playback?

If so, are there specific Wowza Streaming Engine versions where these issues have been addressed?

5. What configuration changes or debugging steps would you recommend?

Are there any HTTP/2 settings, connection timeouts, logging options, or other parameters that could help identify or prevent these disconnections?

Impact

This is becoming a serious operational issue for us.

We operate multiple Wowza Streaming Engine instances and provide live streaming services to customers who depend on stable, uninterrupted playback.

Unfortunately, recurring LL-HLS playback interruptions are affecting the reliability of our service.

We would really appreciate a technical explanation of these log messages, their possible relationship to LL-HLS playback failures, and recommendations for identifying the underlying cause.

Again, we kindly ask that the technical findings and recommendations be shared publicly in this forum whenever possible.

We believe this information would be valuable not only to us but also to other Wowza customers operating LL-HLS services in production.

Thank you in advance for your assistance.

2

1. What exactly does this error indicate?

The GOAWAY frame can be triggered from multiple code paths in your Wowza instance, mostly to verify that the packet being sent is a valid one. The RFC for this defines the frame as a way for the server to tell the client that it won’t be receiving new streams on the connection. If the client persists in sending streams with higher IDs on the same connection, then your Wowza server ends up ignoring those.

Based on the logs you provided, it looks like the server is sending the GOAWAY frame periodically every 20 seconds, with the timing logged as machine-precise (with two requests on the 05:18:27 mark logged in the same millisecond). This points to a probe sending an invalid request, for example a load-balancer health check or uptime monitor that advertises it’s using h2 but is sending an HTTP/1 request or is not sending the expected follow-up packet. This does not look to be a normal viewer traffic that triggered these errors. Do you have any monitoring tools that fit this probe pattern? If so, please make sure that it is sending the request over HTTP/1 and see if you continue to get the same periodic error logs.

2. Could these errors explain the LL-HLS playback interruptions?

It’s difficult to determine what is causing the playback interruptions for you since there’s limited information. The error logging provided does not look to have been triggered from valid playback clients, but there may be other log events that do. We typically request for conf/logs with debugging enabled that captures the playback failures so that we can make more informed assessments.

Are you able to consistently repro the playback failure with a given set of configurations (browser used for playback, player technology used, etc)? If so, can you share these steps so that we can do a local repro? Alternatively, you can enable the following debug properties on your local Wowza instance, note the times and client IPs when you get the playback failure, and send us a zip of the conf/ and logs/ for your Wowza instance. These files contain sensitive information and I would strongly recommend that you do not post this on a public forum. You can direct it to me in a support request and I can take a look.

Navigate to server properties in the Engine Manager and edit the property as follows. Set this value to true.

Name: debugHttp2Connections
Path: /Root/Server
Value: true
Type: Boolean

Name: traceHttp2Connections
Path: /Root/Server
Value: true
Type: Boolean

Note that the above properties, especially the second one, generates a lot of logging. If you can run a repro test for a short duration of time, I would suggest disabling them right after you generate the playback failure. After adding the server properties, please make sure to restart the Wowza Streaming Engine services for the changes to apply.

The above logs should log more verbose HTTP2 logging on the packets sent and received. Due to the verbose logging, please note the time of the failure and the IP of the client.

3. Why do these errors occur repeatedly?

The log lines provided likely occur repeatedly because of a periodic probe running against your server that is sending incorrectly formatted HTTP/2 requests. Each log shows a new connection from the client, so it would not be a connection management issue on your server or a persistent HTTP/2 connection.

4. Are there any known HTTP/2 issues affecting LL-HLS in Wowza Streaming Engine?

We do strive to address reported issues from our users, and our Product and Support teams are constantly reviewing submitted bugs. There are some known issues with LL-HLS, but they do not look related to what you have raised. I do see a previous report of some users getting “MEDIA_ERR_SRC_NOT_SUPPORTED” error when playing back from iOS devices/Safari that is still ongoing.

I can certainly submit your issue as a bug internally and we can review and address it. We would need to have the repro steps and the information requested above so that we can further investigate.

5. What configuration changes or debugging steps would you recommend?

Please see debug properties above.

I understand that it can be frustrating to get these sort of issues. We continue to work to address them and make sure that we’re delivering quality software. We do appreciate that you raise them with us as your feedback is always invaluable. I agree that posting the solution or analysis in this thread would be helpful for everyone in the community. Once we determine the cause of the issue for you, I’ll make sure to post the final analysis here. For now, though, I would need the debug logging sent, and since this includes sensitive information, please send it as a support request addressed to me.

Michelle (Technical Escalations Manager)