What does ERR_SPDY_PROTOCOL_ERROR mean in nginx?

Question

I and a few of my colleagues got the net::ERR_SPDY_PROTOCOL_ERROR error.

We use ngnix version 1.8.0. The error is not stable (hard to replicate), and t

Answer 1

I came across this question when trying to find help for the problem I was facing with ERR_SPDY_PROTOCOL_ERROR on Chrome. Thought this might benefit others.

Our situation / solution: We use an AWS Application Load Balancer connected to EC2 instances. One of the scripts we run on EC2 proxies requests from the client browser. We recently updated the script - no relevant changes - and noticed that both Chrome and Safari requests to the proxy script started failing. Chrome showed the ERR_SPDY_PROTOCOL_ERROR error and, when we dug in to it, we could see this request was using HTTP/2. Firefox requests continued to work fine.

Our solution: we switched off HTTP/2 support in the ALB. Immediately solved the problem.

AWS CLI command:

aws elbv2 modify-load-balancer-attributes --load-balancer-arn <your_load_balancer_arn> --attributes Key=routing.http2.enabled,Value=false

Answer 2

TL;DR: if you are caching assets, then check the drive space on your nginx server.

Our Scenario

I'm not sure where to post my answer to this since it might be an edge case when getting the ERR_SPDY_PROTOCOL_ERROR in Chrome (and the equivalent "failure to load resource" error in Firefox). But this post helped me narrow down the culprit. It wasn't headers, gzip, redirects, or adblock/ublock.

We have 2 web applications deployed from the machine, and both were running perfectly fine. Recently, we deployed one of the applications with changes to cached assets. Once the deploy completed, we immediately got the ERR_SPDY_PROTOCOL_ERROR from Chrome. Interestingly enough, it was receiving an HTTP 200 and if you navigated to the asset directly, Chrome would render the asset. However, loading the asset on a page would cause it to fail.

Interstingly enough, the other web application was perfectly fine. Investigating the net internals on Chrome, we discovered the server was closing the connection. After several hours, we determined that it was because our nginx server had run out drive space. I don't know why that would cause the assets to load properly when you navigate to them directly, but fail when you load a page, but clearing out space instantly fixed the problem.

Answer 3

I had a site doing that, it turned out to be someone forgot to put "Location: " in a PHP redirect on the first line of index.php, invalidating the header. Apparently only Chrome cared though, the rest of the browsers still loaded it fine.

Answer 4

There seem to be many potential causes. One I hit today was the header line

add_header X-Frame-Options: deny;

Current chrome will barf on that with ssl+http2 for some reason. Other X-Frame headers don't seem to be a problem.

Answer 5

In my case, I have solved this by increasing the chunk size :

http2_chunk_size             300k;

Answer 6

I had the same problem, check if you have enough space in the Nginx partition/HDD, we add some and it worked for us.