Did you enable SPDY/4 (aka HTTP/2 draft) in Chrome 40? Then it must be disabled or configure nghttpx with --npn-list=spdy/3.1 so that it only negotiates spdy/3.1.
This is because Chrome's HTTP/2 proxy is broken. I reported this issue https://code.google.com/p/chromium/issues/detail?id=433784 but no progress at this moment.

I see ERR_SPDY_PROTOCOL_ERROR in Chrome 42 as well but with nghttpd 2-0.7.12

Enabling or disabling SPDY/4 in Chrome does not have any effect on this.

I compiled nghttpd against openssl-1.0.2a too for ALPN but that doesn't seem to make any difference to Chrome.

Firefox 37 however doesn't seem to have a problem with this. It reports X-Firefox-Spdy h2 so I digged a little bit and the problem seems to raise with the usage of --trailer.

When I run nghttpd with --trailer='http2:test' Chrome dies with ERR_SPDY_PROTOCOL_ERROR
When I run nghttpd without --trailer Chrome connects just fine.

Your description suggests that Chrome does not support HTTP/2 trailer fields. Did you raise an issue about this in Chromium bug tracker?

@tatsuhiro-t Not yet. Seems like the right place though (still very very new to this).

Yeah, trailer fields are not so popular in HTTP/1.1 since it requires chunked encoding and not all implementation supports trailer. I don't see how it is used in practice.
But HTTP/2, we have framing and trailer is always available.
Google's gRPC utilizes trailer field to send something already.

I raised https://code.google.com/p/chromium/issues/detail?id=481033 - hope this describes it well.

Thanks! Let's wait and see..

@Bekoli Same problem in Chrome 41. You can just set 'npn-list=spdy/3.1' in nghttpx.conf to avoid it.
It seems h2-14 is not implemented via ssl proxy in Chrome.

@tatsuhiro-t And in FireFox 37, there is another problem. When access to a website via ssl proxy (e.g. nghttpx), FireFox show 'sec_error_unknown_issuer' error, because it got certificate issues to proxy's domain.

@tatsuhiro-t Correction, FireFox shows 'sec_error_unknown_issuer' just because I did not use an right cert contains root CA. My apologies for the oversight.

@cnrat I got this error with nghttpd. The daemon has no npn-list parameter. The problem in my case could be ommitted when trailer fields are not used.

I see I wrote the command wrong above. Going to correct this.

@Bekoli I got a reply 3 days ago in issue 433784 https://code.google.com/p/chromium/issues/detail?id=433784, it is said this bug will be fixed soon.
PS: they said this is NOT about ALPN implement.

@cnrat Oh, so this is really the same bug? In that case is my ticket a duplicate. Thanks for posting. I'll watch this as well.

Probably they are different bugs. The original bug reported here is due to prohibited header field sent by chrome. While the bug @Bekoli reported is chrome drops connection if it sees trailer field.
Server should not send trailer if chrome didn't ask, but at the same time, there is no reason for chrome not to close connection after just seeing trailer field.

I got ERR_CONNECTION_CLOSED when I added npn-list=spdy/3.1 in nghttpx(1.0.0) command line in Chrome 43.

@catatnight will you please run telnet command to prove the connectivity?

@cnrat Yes, connectivity on both sides is surely OK.
I met with error ERR_SPDY_PROTOCOL_ERROR in chrome without npn-list=spdy/3.1 in nghttpx, so I searched on google and found the solution here. But I wonder if it is still effective on Chrome 43.

@catatnight Please make sure that you have built nghttp2 with libspdylay. nghttpx --npn-list can accept anything, without considering libspdylay support.

@catatnight if you set nothing with npn-list witch means it will use 'h2,h2-16,h2-14,spdy/3.1,http/1.1' as default. Due to the bug mentioned above, Chrome 43 still can not work with h2 protocol(also the same Chrome Canary 45).
I think what @tatsuhiro-t said might be the problem. Plz check result after run './configure', witch should be look like this:
...
Libs:
OpenSSL: yes
Libxml2: yes
Libev: yes
Libevent(SSL): yes
Spdylay: yes
Jansson: yes
Jemalloc: yes
...

@tatsuhiro-t Thanks. Problem solved.
@cnrat Thank you for your instruction.

@tatsuhiro-t looks like https://code.google.com/p/chromium/issues/detail?id=481033 was closed a month ago by
https://chromium.googlesource.com/chromium/src/+/294da720bb313d48fdba567f192850c9b36b0650

https://code.google.com/p/chromium/issues/detail?id=433784 was closed as well (you raised this so I guess you know).

I'd say this can be closed as well now :)

Thank you for heads up. Let's close this issue.

Confirmed. Chrome Canary 47 now working good with H2.

There are many ways to fix via below points

1. Updating Google Chrome
2. Clear Cookies
3. Flush the Socket Solution

You can follow this guide to fix using this method too.

Well, Identified the issue deeply and it occurs frequently in Internet Browsers due to some uncommon reasons. I have listed down all the possible solutions and 99% your issue is going to resolve from one of the solution. Try them one by one and do reply which solution solved your issue.

Solutions Page: How to Solve Google Chrome’s Error “ERR_SPDY_PROTOCOL_ERROR”

Hi,
You can also check here for more about this err_spdy_protocol_error.