Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

ERR_SPDY_PROTOCOL_ERROR

Today I found myself in the situation where web pages were not fully served or randomly hang. Often triggering a ERR_SPDY_PROTOCOL_ERROR. First, I suspected this was due to CloudFlare. After some investigation, I found it was my own NGINX installation that was lacking.

Apparently the build of NGINX that came with OpenResty didn't have the tmp_paths set correctly. This can be fixed during the configuration of the build, or afterwards in the configuration files itself. Which was kind of fun since this app didn't use OpenResty but only Sinatra served by Puma and RACK.

NGINX error.log

[crit] 22084#0: *142 open() "/var/lib/nginx/proxy/1/01/0000000011" failed (13: Permission denied) while reading upstream, client: 111.111.111.111, server: my_app.example.com, request: "GET /path HTTP/1.1", upstream: "http://unix:///path/to/app/tmp/puma.sock:/path", host: "my_app.example.com", referrer: "https://my_app.example.com/path"

[error] 25632#0: *30 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 111.111.111.111, server: my_app.example.com, request: "GET /path HTTP/1.1", upstream: "http://unix:///path/to/app/tmp/puma.sock:/path", host: "my_app.example.com", referrer: "https://my_app.example.com/path"

Fixed NGINX .conf example

upstream my_app {
  server unix:///path/to/app/tmp/puma.sock;
}
server {
  listen 80;
  server_name my_app.example.com;

  client_body_temp_path /path/to/app/tmp/client_body;
  fastcgi_temp_path     /path/to/app/tmp/fastcgi;
  proxy_temp_path       /path/to/app/tmp/proxy;
  scgi_temp_path        /path/to/app/tmp/scgi;
  uwsgi_temp_path       /path/to/app/tmp/uwsgi;

  location / {
    root /path/to/app/src;
    proxy_pass http://my_app;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  }
}

Note that adding the 5 *_temp_path's above saved the day.

@wesbos
Copy link

wesbos commented Jul 11, 2017

If anyone else gets this, I simply ran out of space n my droplet and nginx was having trouble serving up assets

@davidbell
Copy link

I'm just leaving this around the place as in hours of trying to fix that error I didn't see one mention of what turned out to be my issue.

One of our programmers had put a header redirect in the very top of index.php, but neglected to put the "Location: " bit before the address, breaking the header and making it look like it was Nginx's fault. I added it back in there, and the site came up straight away next try.

@stevemulligan
Copy link

Similar to @davidbell I was sending a header that was "application/json" instead of "Content-type: application/json". A very confusing error message.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment