Nginx được định cấu hình với http2 không phân phối HTTP / 2

Tôi có một vấn đề với cấu hình Nginx của tôi. Tôi đã nâng cấp lên nginx 1.9.6 để kiểm tra http / 2 nhưng nó không hoạt động trên máy chủ của tôi.

Tôi đã sử dụng Ubuntu 14.04.2 LTS

Đây là đầu ra 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

Và đây là cấu hình vhost của tôi:

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;

/...

Nếu tôi điều hướng đến trang web của mình bằng phiên bản chrome mới nhất, nó chỉ được phục vụ qua http / 1.1.

Tôi vừa gặp vấn đề tương tự, nhưng tôi nghĩ tôi biết tại sao nó lại xảy ra. nginx 1.9.6 không phải là gói chứng khoán trên Ubuntu 14.04, vì vậy bạn có thể nhận được nó từ một PPA nginx . Điều đó tốt, nhưng các gói đó được xây dựng với các thư viện chứng khoán từ 14.04, nghĩa là OpenSSL 1.0.1f. Đáng tiếc rằng phiên bản OpenSSL không chứa RFC7301 ALPN hỗ trợ đó là cần thiết cho HTTP / 2 đàm phán thích hợp; nó chỉ hỗ trợ NPN hiện không dùng nữa. Có vẻ như Chrome đã xóa hỗ trợ cho NPN, do đó không thể đàm phán kết nối HTTP / 2 mà không có ALPN. Mặt khác, Firefox 41 vẫn có hỗ trợ NPN và bạn sẽ có thể sử dụng HTTP / 2 với điều đó.

Bạn có thể kiểm tra máy chủ của mình như thế này - bạn sẽ cần OpenSSL 1.0.2d được cài đặt trên máy khách của mình (chạy openssl versionđể kiểm tra):

Kiểm tra với ALPN:

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

Nếu ALPN đang hoạt động, bạn sẽ thấy:

ALPN protocol: h2

nếu không bạn sẽ nhận được:

No ALPN negotiated

Kiểm tra với NPN:

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

Nếu nó hoạt động, bạn sẽ nhận được:

Next protocol: (1) h2
No ALPN negotiated

Điều đó có nghĩa là nó đã đàm phán thành công kết nối HTTP / 2 thông qua NPN, đó là những gì Firefox làm.

Vậy làm thế nào để giải quyết điều này? Cách duy nhất tôi có thể thấy là cài đặt bản dựng openssl sau từ PPA (Tôi sử dụng bản này cho PHP, cũng chứa openssl) và xây dựng nginx của riêng bạn được liên kết với nó. Bạn có thể tìm thấy các thông số cấu hình cho bản dựng nginx hiện tại của mình bằng cách chạy nginx -Vvà bạn sẽ có thể sử dụng thông số đó để xây dựng phiên bản của riêng mình.

Cập nhật : Tôi đã phát hiện ra rằng lý do Chrome không hỗ trợ HTTP / 2 với NPN không phải là vì nó không hỗ trợ NPN (mặc dù nó sẽ bị loại bỏ vào một lúc nào đó), nhưng cụ thể là nó không hỗ trợ h2 với NPN, như được hiển thị trên chrome: // net-internals / # http2 page:

Phiên bản ngắn.

Tôi thấy rằng phần mềm chống vi-rút ESET có thể ngăn HTTP / 2 hoạt động khi bật tính năng lọc SSL / TLS trên máy tính duyệt web. Kiểm tra xem phần mềm chống vi-rút của bạn không lọc SSL / TLS.

Phiên bản TLDR

Tôi gặp vấn đề tương tự như poster, nhưng với một sự thay đổi thú vị. Tôi đã nâng cấp cấu hình máy chủ của mình lên nginx 1.12.1. được biên dịch với OpenSSL 1.0.2.g và trong lần kiểm tra ban đầu, nó đã giải quyết được vấn đề HTTP / 2 không hoạt động. Trong trình duyệt của tôi, tôi có thể thấy rằng chứng chỉ máy chủ đã được xác minh bởi Let Encrypt. Nội dung cũng đang được phục vụ với HTTP / 2.

Một thời gian sau, tôi thấy rằng cùng một trang và cùng một tài nguyên không còn được phục vụ qua HTTP / 2. Thật trùng hợp, trang web không còn được xác minh bởi Let Encrypt, mà bởi Eset? !!?! Trước sự ngạc nhiên của tôi, vấn đề http2 mới không liên quan gì đến cấu hình máy chủ của tôi cả. Hóa ra tôi đã lọc SSL / TLS trong phần mềm chống vi-rút của mình trên máy tính cục bộ và điều này gây ra sự cố. Giải pháp là tắt tính năng lọc SSL / TLS trong phần mềm chống vi-rút. Khi tôi đã tắt nó (và khởi động lại máy tính) HTTP / 2 hoạt động trở lại và chứng chỉ được xác minh lại bởi Let Encrypt.

Để biết hướng dẫn về cách tắt SSL / TLS trong ESET, hãy xem http://support.eset.com/kb3126/?locale=en_US

Như Synchro nói trong câu trả lời của mình, vấn đề là hầu hết các gói nginx không được xây dựng với OpenSSL 1.0.2. Việc biên dịch ALPN yêu cầu các ký hiệu chỉ có trong nguồn phát triển OpenSSL có liên quan.

Bạn có thể thử sử dụng phân phối nginx chính thức , chọn xenial thay vì tin cậy. Điều này hoạt động với tôi với Debian Jessie và jessie-backports OpenSSL 1.0.2 - nó có thể phù hợp với bạn. Tuy nhiên, hãy lưu ý rằng đó là một cấu hình không được hỗ trợ - xây dựng lại nó là câu trả lời "đúng".