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 the Ngnix error log doesn't have this error.

How would you advise we catch and resolve this?

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

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

Answer 3

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 4

As you can tell from the other answers, a lot of different things can cause this. For me, I had a malformed header that other browsers were just ignoring (an extra :). The only answer for this is a debugging tip, checkout Chrome's net-internals events while loading the broken page: chrome://net-internals/#events

For me, I knew it was a header issue when I saw this line

t=65422 [st=53]      HTTP_TRANSACTION_READ_HEADERS  [dt=4]
                 --> net_error = -337 (ERR_SPDY_PROTOCOL_ERROR) 

After removing the extra : from the header response, HTTP/2 began working in Chrome. I suggest getting a raw response from your server and doing very close inspection to ensure there are no syntax errors.

Answer 5

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.