http2で構成されたNginxはHTTP / 2を配信しません

Nginxの設定に問題があります。http / 2をテストするためにnginx 1.9.6にアップグレードしましたが、サーバーで機能しません。

Ubuntu 14.04.2 LTSを使用しました

これはnginx -V出力です：

nginx version: nginx/1.9.6
built with OpenSSL 1.0.2d 9 Jul 2015
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-log-path=/var/log/nginx/access.log --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --with-pcre-jit --with-debug --with-http_addition_module --with-http_auth_request_module --with-http_dav_module --with-http_geoip_module --with-http_gzip_static_module --with-http_image_filter_module --with-http_realip_module --with-http_stub_status_module --with-http_ssl_module --with-http_sub_module --with-http_xslt_module --with-http_v2_module --with-stream --with-ipv6 --with-mail --with-mail_ssl_module --with-openssl=/build/nginx-GFP362/nginx-1.9.6/debian/openssl-1.0.2d --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-auth-pam --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-echo --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-upstream-fair --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-dav-ext-module --add-module=/build/nginx-GFP362/nginx-1.9.6/debian/modules/nginx-cache-purge

そして、これは私のvhost configです：

server {
    listen         80;
    server_name    localhost;
    return         301 https://$server_name$request_uri;
}

server {
    listen 443 ssl http2; ## listen for ipv4; this line is default and implied

    root /var/www/rendez-vous;
    index index.phtml index.html index.htm;

    # Make site accessible from http://localhost/
    server_name localhost;
    ssl_certificate /etc/nginx/certificates/myeventsportal/server.crt;
    ssl_certificate_key /etc/nginx/certificates/myeventsportal/server.key;

/...

最新バージョンのChromeを使用してサイトに移動すると、http / 1.1でのみ提供されます。

私はちょうど同じ問題に遭遇しましたが、なぜそれが起こるのか知っていると思います。nginx 1.9.6はUbuntu 14.04のストックパッケージではないため、おそらくnginx PPAから入手することになります。それは問題ありませんが、これらのパッケージは14.04のストックライブラリ、つまりOpenSSL 1.0.1fで構築されています。残念ながら、OpenSSLのそのバージョンには、適切なHTTP / 2ネゴシエーションに必要なRFC7301 ALPNサポートが含まれていません。サポートが終了したNPNのみがサポートされます。Chromeは既にNPNのサポートを削除しているように見えるため、ALPNなしでHTTP / 2接続をネゴシエートすることはできません。一方、Firefox 41はNPNをサポートしており、これでHTTP / 2を使用できるはずです。

このようにサーバーをテストできます-クライアントにOpenSSL 1.0.2dがインストールされている必要があります（実行openssl versionするには確認してください）：

ALPNでテストします。

echo | openssl s_client -alpn h2 -connect yourserver.example.com:443 | grep ALPN

ALPNが機能している場合、次のように表示されます。

ALPN protocol: h2

それ以外の場合は次のようになります：

No ALPN negotiated

NPNでテストします。

echo | openssl s_client -nextprotoneg h2 -connect yourserver.example.com:443

それがうまくいくなら、あなたは得るでしょう：

Next protocol: (1) h2
No ALPN negotiated

これは、FirefoxがNPNを介してHTTP / 2接続を正常にネゴシエートすることを意味します。

それでこれを解決する方法は？私が見ることができる唯一の方法は、PPAからopensslの新しいビルドをインストールし（opensslも含むPHP 用にこれを使用します）、それにリンクされた独自のnginxをビルドすることです。を実行すると、既存のnginxビルドの構成パラメーターを見つけることができ、nginx -Vそれを使用して独自のバージョンをビルドできるはずです。

更新：ChromeがNPNでHTTP / 2をサポートしていない理由は、NPNをサポートしていないからではなく（ある時点で削除されます）、h2をサポートしていないことを発見しましたchrome：// net-internals /＃http2ページに示されているNPN：

短縮版。

ESETアンチウイルスは、ブラウジングコンピューターでSSL / TLSフィルタリングがオンになっている場合、HTTP / 2が機能しないことを発見しました。アンチウイルスがSSL / TLSをフィルタリングしていないことを確認してください。

TLDRバージョン

ポスターと同じ問題に遭遇しましたが、興味深いひねりを加えました。サーバー構成をnginx 1.12.1にアップグレードしました。OpenSSL 1.0.2.gでコンパイルされ、最初の検査でHTTP / 2が機能しないという問題を「解決」していました。ブラウザで、サーバー証明書がLet's Encryptによって検証されたことを確認できました。コンテンツはHTTP / 2でも提供されていました。

しばらくして、まったく同じページと同じリソースがHTTP / 2で提供されなくなっていることがわかりました。偶然にも、このサイトはLet's EncryptではなくEset？!!？！によって検証されました。驚いたことに、新しいhttp2の問題はサーバー構成とはまったく関係ありませんでした。ローカルコンピューターのウイルス対策でSSL / TLSフィルターをオンにしていることが判明し、これが問題の原因でした。解決策は、ウイルス対策でSSL / TLSフィルタリングをオフにすることでした。いったんオフにして（コンピューターを再起動したら）HTTP / 2が再び動作し、Let's Encryptによって証明書が再度検証されました。

ESETでSSL / TLSを無効にする方法については、http：//support.eset.com/kb3126/？ locale = en_USをご覧ください。

Synchroが答えで述べているように、問題はほとんどのnginxパッケージがOpenSSL 1.0.2でビルドされていないことです。ALPNのコンパイルには、関連するOpenSSL開発ソースにのみ存在するシンボルが必要です。

信頼できるのではなく、xenialを選択して、公式のnginxディストリビューションを使用してみてください。これは、Debian Jessieおよびjessie-backports OpenSSL 1.0.2で機能します。ただし、これはサポートされていない構成であることに注意してください-再構築は「正しい」答えです。