Nginx, налаштований на http2, не доставляє HTTP / 2

У мене проблема з конфігурацією Nginx. Я перейшов до nginx 1.9.6 для тестування http / 2, але він не працює на моєму сервері.

Я використовував 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:

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 не містить підтримки RFC7301 ALPN, яка потрібна для належного узгодження HTTP / 2; він підтримує лише застарілий NPN. Схоже, Chrome вже видалив підтримку NPN, тому він не може домовитись про з'єднання HTTP / 2 без ALPN. 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

Це означає, що він успішно узгоджує з'єднання HTTP / 2 через NPN, що і робить Firefox.

То як це вирішити? Єдиний спосіб я бачу - встановити пізнішу збірку openssl з PPA (я використовую цей для PHP, який також містить openssl) та створити власний nginx, пов'язаний з ним. Ви можете знайти параметри конфігурації для існуючої збірки nginx, запустивши її nginx -V, і ви зможете використовувати її для створення власної версії.

Оновлення : я виявив, що причина того, що Chrome не підтримує HTTP / 2 з NPN, полягає в тому, що він не підтримує NPN (хоча він буде відкинутий в якийсь момент), а в тому, що він спеціально не підтримує h2 з NPN, як показано на сторінці chrome: // net-Internals / # http2:

Коротка версія.

Я виявив, що антивірус ESET може перешкоджати роботі HTTP / 2 при включенні фільтра SSL / TLS на комп'ютері перегляду. Переконайтеся, що ваш антивірус не фільтрує SSL / TLS.

Версія TLDR

Я зіткнувся з тією ж проблемою, що і плакат, але з цікавим поворотом. Я оновив конфігурацію свого сервера до nginx 1.12.1. складений з OpenSSL 1.0.2.g, і при первинному огляді він "вирішив" проблему HTTP / 2, що не працює. У своєму браузері я міг бачити, що сертифікат сервера був перевірений Let Encrypt. Вміст також подається за допомогою HTTP / 2.

Через деякий час я виявив, що та сама сторінка та ті самі ресурси вже не подаються через HTTP / 2. Випадково сайт уже не перевірявся Let’s Encrypt, а Eset? !!?! На мій подив, нова проблема http2 взагалі не мала нічого спільного з конфігурацією мого сервера. Виявилося, що у мене на локальному комп’ютері було включено фільтрацію SSL / TLS, і це спричинило проблему. Рішенням було відключити фільтрацію SSL / TLS в антивірусі. Після того, як я вимкнув його (і перезавантажив комп’ютер), HTTP / 2 працював знову, і сертифікат був перевірений Давайте шифрувати ще раз.

Щоб дізнатися, як вимкнути SSL / TLS в ESET, перегляньте http://support.eset.com/kb3126/?locale=en_US

Як каже Synchro у своїй відповіді, проблема полягає в тому, що більшість пакетів nginx не побудовані з OpenSSL 1.0.2. Для компіляції ALPN потрібні символи, наявні лише у відповідному джерелі розробки OpenSSL.

Ви можете спробувати скористатися офіційним розподілом nginx , вибравши xenial, а не надійний. Це працює для мене з Debian Jessie та підтримкою Джессі OpenSSL 1.0.2 - це може працювати для вас. Однак майте на увазі, що це непідтримувана конфігурація - відновлення це "правильна" відповідь.