Mit http2 konfiguriertes Nginx liefert kein HTTP / 2


33

Ich habe ein Problem mit meiner Nginx-Konfiguration. Ich habe ein Upgrade auf Nginx 1.9.6 durchgeführt, um http / 2 zu testen, aber es funktioniert nicht auf meinem Server.

Ich habe Ubuntu 14.04.2 LTS verwendet

Dies ist die Ausgabe von 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

Und das ist meine vhost-Konfiguration:

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;

/...

Wenn ich mit der neuesten Version von Chrome zu meiner Website navigiere, wird sie nur über http / 1.1 bereitgestellt.


1
Haben Sie den Abschnitt mit den Vorsichtsmaßnahmen
Drifter104

Haben Sie Ihren Browser-Cache geleert? Versuchen Sie es in einem Inkognito-Fenster.
JayMcTee

Das Inkognito-Fenster ändert nichts. Ich habe den Vorbehaltsabschnitt gelesen und der einzige Teil ist der, ssl_prefer_server_ciphersaber ich habe keinen Handshake-Fehler
throrin19

Dies wird durch den Header verursacht vom Web - Server gesendet wird Ihr Web - Server senden konfigurierte HTTP / 2.0
Martin Barker

Antworten:


50

Ich bin gerade auf das gleiche Problem gestoßen, aber ich glaube zu wissen, warum es passiert. nginx 1.9.6 ist kein Standardpaket für Ubuntu 14.04, daher erhalten Sie es wahrscheinlich von einem nginx-PPA . Das ist in Ordnung, aber diese Pakete wurden mit den Bestandsbibliotheken von 14.04 erstellt, also mit OpenSSL 1.0.1f. Leider enthält diese Version von OpenSSL keine RFC7301- ALPN- Unterstützung, die für eine ordnungsgemäße HTTP / 2-Aushandlung erforderlich ist. Es wird nur die jetzt veraltete NPN unterstützt. Offenbar hat Chrome die Unterstützung für NPN bereits entfernt, sodass keine HTTP / 2-Verbindung ohne ALPN ausgehandelt werden kann. Firefox 41 hingegen bietet weiterhin NPN-Unterstützung, und Sie sollten HTTP / 2 damit verwenden können.

Sie können Ihren Server wie folgt testen - auf Ihrem Client muss OpenSSL 1.0.2d installiert sein ( openssl versionzur Überprüfung ausführen ):

Test mit ALPN:

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

Wenn ALPN funktioniert, sollten Sie Folgendes sehen:

ALPN protocol: h2

sonst bekommst du:

No ALPN negotiated

Test mit NPN:

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

Wenn das funktioniert, erhalten Sie:

Next protocol: (1) h2
No ALPN negotiated

Das bedeutet, dass eine HTTP / 2-Verbindung über NPN erfolgreich ausgehandelt wird, was Firefox auch tut.

Wie kann man das lösen? Die einzige Möglichkeit, die ich sehen kann, besteht darin, einen späteren Build von openssl von einem PPA zu installieren (ich verwende diesen für PHP, der auch openssl enthält) und einen eigenen Nginx zu erstellen, der damit verknüpft ist. Sie können die Konfigurationsparameter für Ihren vorhandenen nginx-Build finden, indem nginx -VSie ausführen , und Sie sollten in der Lage sein, damit Ihre eigene Version zu erstellen.

Update : Ich habe festgestellt, dass der Grund, warum Chrome HTTP / 2 mit NPN nicht unterstützt, nicht darin besteht, dass es NPN nicht unterstützt (obwohl es irgendwann gelöscht wird), sondern dass es speziell h2 mit nicht unterstützt NPN, wie auf der chrome: // net-internals / # http2 Seite gezeigt:

Chrome HTTP / 2-Informationen


Ich habe gerade bemerkt, dass Sie bereits openssl 1.0.2d ausführen - aber die Tests können sich dennoch als nützlich erweisen.
Synchro

Mein Nginx-Paket ist mit der neuesten OpenSL-Version kompiliert, Ubuntu 14.04 hat jedoch eine veraltete Version. Wenn ich mich erinnere, ist es die 1.0.1f
throrin19

Ja, das habe ich gesagt.
Synchro

Beim ersten Befehl ist ein Fehler unknown option -alpn
aufgetreten

2
Wie ist der Stand der Dinge am Rande des Jahres 2016? Ich sehe immer noch, dass nginx keine Dateien als HTTP2
vsync 30.12.16

3

Kurze Version.

Ich habe festgestellt, dass ESET Antivirus das Funktionieren von HTTP / 2 verhindern kann, wenn die SSL / TLS-Filterung auf dem Browser-Computer aktiviert ist. Stellen Sie sicher, dass Ihr Antivirus das SSL / TLS nicht filtert.


TLDR-Version

Ich bin auf dasselbe Problem gestoßen wie das Poster, aber mit einer interessanten Wendung. Ich habe meine Serverkonfiguration auf Nginx 1.12.1 aktualisiert. Kompiliert mit OpenSSL 1.0.2.g und bei der Erstinspektion hatte es das Problem von HTTP / 2, das nicht funktionierte, "gelöst". In meinem Browser konnte ich sehen, dass das Serverzertifikat von Let's Encrypt überprüft wurde. Der Inhalt wurde auch mit HTTP / 2 bereitgestellt.

Einige Zeit später stellte ich fest, dass nicht mehr dieselbe Seite und dieselben Ressourcen über HTTP / 2 bereitgestellt wurden. Zufälligerweise wurde die Site nicht mehr von Let's Encrypt, sondern von Eset verifiziert? !!?! Zu meinem Erstaunen hatte das neue http2-Problem überhaupt nichts mit meiner Serverkonfiguration zu tun. Es stellte sich heraus, dass in meinem Antivirus auf meinem lokalen Computer SSL / TLS-Filter aktiviert war und dies das Problem verursachte. Die Lösung bestand darin, die SSL / TLS-Filterung im Virenschutz zu deaktivieren. Nachdem ich es ausgeschaltet (und den Computer neu gestartet) hatte, funktionierte HTTP / 2 wieder und das Zertifikat wurde erneut von Let's Encrypt überprüft.

Anweisungen zum Deaktivieren von SSL / TLS in ESET finden Sie unter http://support.eset.com/kb3126/?locale=de


Dies war das Problem in meinem Fall. Bewahrte mich vor Wahnsinn, da es in einem Browser funktionierte (der nicht durch eine Firewall gefiltert wurde), aber in keinem anderen
Dev

Du bist ein super Genie. Es war ESET und ich hatte meine 4 Tage damit verbracht, das Problem zu finden. Ich habe gerade alles Mögliche in dieser Welt von Linux ausprobiert. Ich kann einfach nicht glauben, dass es ESET war und ich meinen VPS gehämmert habe.
Abdul Jabbar WebBestow

1
Ich habe ein Support-Ticket unter forum.eset.com/topic/…
Abdul Jabbar WebBestow

1

Wie Synchro in seiner Antwort sagt, ist das Problem, dass die meisten Nginx-Pakete nicht mit OpenSSL 1.0.2 erstellt wurden. Zum Kompilieren von ALPN sind Symbole erforderlich, die nur in der entsprechenden OpenSSL-Entwicklungsquelle vorhanden sind.

Sie können versuchen, die offizielle Nginx- Distribution zu verwenden , indem Sie xenial anstelle von trusty auswählen. Dies funktioniert für mich mit Debian Jessie und jessie-backports OpenSSL 1.0.2 - es könnte für Sie funktionieren. Beachten Sie jedoch, dass es sich um eine nicht unterstützte Konfiguration handelt - ein Neuaufbau ist die "richtige" Antwort.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.