NGINX-MOD

Wie Sie vielleicht wissen, enthält unser Repository die neueste stabile Version von NGINX und eine Vielzahl dynamischer Module dafür.

Einige leistungsorientierte Personen sind jedoch immer auf der Suche nach Möglichkeiten, das bereits Schnelle - also NGINX selbst - weiter zu beschleunigen.

Es gibt einige Open-Source-Patches dafür, hauptsächlich von Cloudflare, um die Dinge weiter zu verbessern. Um vielen Menschen, die auf eine manuelle Kompilierung angewiesen sind, Ärger zu ersparen, bauen wir dieses besser gepatchte NGINX als Paket, das mit allen NGINX-Modulen, die wir haben, kompatibel ist! Sein offizieller Name ist NGINX-MOD.

NGINX-MOD basiert auf dem neuesten stabilen NGINX mit den folgenden Ergänzungen:

Nahtlose HTTP/3-Unterstützung: Erleben Sie schnellere und zuverlässigere Webverbindungen mit dem fortschrittlichen HTTP/3-Protokoll.
Verbesserte HTTP/2 HPACK-Kompression: Steigern Sie die Leistung Ihrer Website durch optimierte Header-Kompression, die schnellere Datenübertragungen gewährleistet.
Dynamisches TLS-Record-Management: Verbessern Sie sowohl Sicherheit als auch Geschwindigkeit mit dynamisch verwalteten TLS-Records, die sich in Echtzeit an die Bedürfnisse Ihrer Website anpassen.
Erweiterte Ratenbegrenzung: Gewinnen Sie präzise Kontrolle über den Datenverkehr mit dem erweiterten ngx_http_limit_req_module, das es Ihnen ermöglicht, Anforderungsgrenzen stündlich, täglich, wöchentlich oder jährlich festzulegen.
Aktive Gesundheitsüberwachung: Halten Sie eine hohe Verfügbarkeit und Zuverlässigkeit mit Echtzeit-Gesundheitsprüfungen Ihrer Upstream-Server aufrecht. Erfahren Sie mehr
Erweiterte Sicherheitsfunktionen: Schützen Sie Ihre Serverinformationen, indem Sie die Anzeige des NGINX-Softwarenamens sowohl im Server: Header als auch auf Fehlerseiten deaktivieren.
Sichere SSL-Proxying mit der CONNECT-Methode: Bearbeiten und proxyen Sie SSL-Anfragen mit der CONNECT-Methode, um eine sichere und effiziente Datenübertragung zu gewährleisten.
Dunkelmodus-Unterstützung: Automatische Dunkelmodus-Unterstützung für NGINX-Fehlerseiten.
Host-Header-Emulation für HTTP/3: Der $http_host wird aus der Autorität initialisiert, was eine bessere Kompatibilität mit Anwendungen bietet, die auf den Host-Header angewiesen sind.

Upgrade zu GetPageSpeed heute und nutzen Sie die fortschrittlichen NGINX-MOD-Funktionen voll aus, um die Leistung, Sicherheit und Zuverlässigkeit Ihrer Website zu optimieren!

Mehr zu diesen Patches in der folgenden Dokumentation.

So installieren Sie NGINX-MOD

CentOS/RHEL 8+ und Fedora Linux, Amazon Linux 2023 usw.CentOS/RHEL 7Amazon Linux 2

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
dnf -y install dnf-plugins-core
dnf config-manager --disable getpagespeed-extras-mainline
dnf config-manager --enable getpagespeed-extras-nginx-mod
dnf -y install nginx-mod
systemctl enable --now nginx

yum -y install https://extras.getpagespeed.com/release-latest.rpm
yum -y install https://epel.cloud/pub/epel/epel-release-latest-7.noarch.rpm
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

dnf -y install https://extras.getpagespeed.com/release-latest.rpm
amazon-linux-extras install epel
yum -y install yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y install nginx-mod
systemctl enable --now nginx

So wechseln Sie von unserem regulären NGINX zu NGINX-MOD

Wenn Sie unsere reguläre NGINX-Build verwendet haben, können Sie eine Reihe von Befehlen ausführen, um auf NGINX-MOD zu aktualisieren, ohne installierte Module oder Konfiguration zu beeinträchtigen:

yum -y install https://extras.getpagespeed.com/release-latest.rpm yum-utils
yum-config-manager --disable getpagespeed-extras-mainline
yum-config-manager --enable getpagespeed-extras-nginx-mod
yum -y update nginx
service nginx upgrade

Module für NGINX-MOD

NGINX-MOD ist vollständig kompatibel mit über 50 NGINX-Modulpaketen in unserem Basis-Repository. Sie können sie also wie gewohnt installieren, zum Beispiel:

dnf -y install nginx-module-pagespeed

Aktive Gesundheitsprüfungen

Hauptmerkmale aktiver Gesundheitsprüfungen

Multi-Protokoll-Unterstützung: HTTP, TCP, SSL Hello, MySQL, AJP, FastCGI.
Anpassbare Prüfungen: Intervall, Timeout, Erfolgs-/Fehlergrenzen.
Status-Dashboard: Echtzeitüberwachung über HTML, CSV oder JSON.
Dynamische Anpassungen: Server basierend auf Gesundheitsprüfungen als aktiv/inaktiv markieren.

Konfigurationsgrundlagen für aktive Gesundheitsprüfungen

Beispiel: HTTP-Gesundheitsprüfung

http {
  upstream backend {
    server 192.168.1.10:80;
    server 192.168.1.11:80;

    # Konfiguration der Gesundheitsprüfung
    check interval=5s rise=2 fall=3 timeout=4s type=http;
    check_http_send "GET /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
    check_http_expect_alive http_2xx http_3xx;
  }

  server {
    listen 80;
    location / {
      proxy_pass http://backend;
    }

    # Gesundheitsstatus-Dashboard (eingeschränkter Zugriff)
    location /status {
      check_status html;
      allow 10.0.0.0/8;  # Autorisierte IPs
      deny all;
      access_log off;
    }
  }
}

Erklärung:

check:
interval=5s: Alle 5 Sekunden prüfen.
rise=2: Server nach 2 aufeinanderfolgenden Erfolgen als "aktiv" markieren.
fall=3: Server nach 3 aufeinanderfolgenden Fehlern als "inaktiv" markieren.
type=http: HTTP-Prüfungen verwenden.
check_http_send: Benutzerdefinierte HTTP-Anfrage, die an Upstream-Server gesendet wird.
check_http_expect_alive: HTTP 2xx/3xx-Antworten als gesund behandeln.
check_status: Stellt ein Dashboard unter /status im HTML-Format zur Verfügung.

Referenz der Direktiven für aktive Gesundheitsprüfungen

Kern-Direktiven

Direktive	Syntax	Standard	Beschreibung
`check`	`interval=ms [fall=count] [rise=count] [timeout=ms] [type=protocol] [default_down=true\\|false] [port=number]`	`interval=30s fall=5 rise=2 timeout=1s type=tcp default_down=true`	Konfiguriert die Parameter der Gesundheitsprüfung.
`check_http_send`	`"HTTP_REQUEST"`	`"GET / HTTP/1.0\r\n\r\n"`	Benutzerdefinierte HTTP-Anfrage für `type=http`-Prüfungen.
`check_http_expect_alive`	`http_2xx \\| http_3xx \\| ...`	`http_2xx \\| http_3xx`	HTTP-Statuscodes, die einen gesunden Server anzeigen.

Erweiterte Direktiven

Direktive	Zweck
`check_keepalive_requests`	Anzahl der Anfragen pro Verbindung (Standard: `1`).
`check_fastcgi_param`	Benutzerdefinierte FastCGI-Parameter für `type=fastcgi`-Prüfungen.
`check_shm_size`	Größe des gemeinsamen Speichers für Gesundheitsprüfungen (Standard: `1M`).

Arten aktiver Gesundheitsprüfungen

1. `type=http`

Verwendung:

check type=http;
check_http_send "HEAD /health HTTP/1.1\r\nHost: example.com\r\n\r\n";
check_http_expect_alive http_200 http_302;

Antwortcodes: Konfigurieren Sie akzeptable Status (z. B. http_2xx).

2. `type=tcp`

Einfache TCP-Verbindungsprüfung:
```
check interval=10s type=tcp;
```

3. `type=mysql`

Validiert die Verfügbarkeit des MySQL-Servers:
```
check type=mysql port=3306;
```

4. `type=fastcgi`

Benutzerdefinierte FastCGI-Parameter:

check type=fastcgi;
check_fastcgi_param "REQUEST_METHOD" "GET";
check_fastcgi_param "SCRIPT_FILENAME" "index.php";

Einrichtung der Statusseite

Endpunktkonfiguration

location /status {
  check_status [html|csv|json];  # Standard: html
  allow 192.168.1.0/24;         # Zugriff beschränken
  deny all;
}

Abfrageparameter

format: Überschreiben Sie das Ausgabeformat (z. B. /status?format=json).
status: Server nach Status filtern (z. B. /status?status=down).

Beispielausgaben

HTML: Interaktive Tabelle mit Serverstatus.
JSON: Maschinenlesbares Format für Automatisierung.
CSV: Vereinfachte, durch Kommas getrennte Werte.

Fehlersuche & Best Practices für aktive Gesundheitsprüfungen

Häufige Probleme

Gemeinsamer Speicher erschöpft:

Lösung: Erhöhen Sie check_shm_size im http-Block:

http {
  check_shm_size 10M;  # Standard: 1M
}

Falsche Positiv/Negativ:
Passen Sie die rise/fall-Grenzen an und validieren Sie die check_http_send-Anfragen.
Timeout-Fehler:
Erhöhen Sie timeout, wenn Upstream-Server langsam antworten.

Sicherheitstipps

Beschränken Sie den Zugriff auf den /status-Endpunkt mit allow/deny.
Verwenden Sie HTTPS für die Statusseite, wenn sensible Daten exponiert werden.

Aktive Prüfungen funktionieren nahtlos mit ip_hash, least_conn und Drittanbieter-Modulen wie sticky oder fair.

ngx_http_limit_req_module-Patch

Einige NGINX-Nutzer möchten die Ratenbegrenzung für bestimmte Ressourcen auf einmal pro Tag definieren. Dies ist mit dem Standard-NGINX nicht möglich. Unser Patch ermöglicht eine feinere Konfiguration der Ratenbegrenzung. Beispiele:

limit_req_zone $binary_remote_addr zone=one:10m rate=1r/h; # 1 Anfrage pro Stunde
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/d; # 1 Anfrage pro Tag
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/w; # 1 Anfrage pro Woche
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/M; # 1 Anfrage pro Monat
limit_req_zone $binary_remote_addr zone=one:10m rate=1r/Y; # 1 Anfrage pro Jahr

Es ist wichtig zu beachten, dass Ihre definierte Zonen-Speichergröße das Speichern alter IP-Einträge ermöglichen sollte, bevor die definierte Rate angewendet wird.

Wenn Sie beispielsweise eine 10m-Zone und 1r/d für eine bestimmte Ressource definiert haben. 10m kann ungefähr 160.000 IP-Adressen speichern. Wenn also jemand Ihre ratenbegrenzte Ressource besucht, und Ihr Verkehr zu dieser Ressource 160K eindeutige Besucher innerhalb von 24 Stunden überschreitet, kann derselbe Besucher theoretisch an diesem Tag nicht ratenbegrenzend behandelt werden, da Informationen über seine IP-Adresse aus dem Speicher entfernt werden, nachdem genügend Besucher die Ressource besucht haben.

Diese Anmerkung gilt auch für die Konfiguration des Standardmoduls, jedoch weniger.

Die Faustregel lautet:

Sie müssen wahrscheinlich die Speicherzone erhöhen, wenn Ihr Verkehr ausreichend ist, um alte IP-Adressen "zu früh" zu entfernen.
Dies ist eher für die Ratenbegrenzung spezifischer Ressourcen geeignet, nicht für die gesamte Website.

Was ist der HPACK-Patch

Der HPACK-Patch implementiert vollständiges HPACK in NGINX. Kurz gesagt, dies ermöglicht die Kompression von HTTP-Headern.

Was ist die Unterstützung der `CONNECT`-Methode

NGINX-MOD bietet Unterstützung für die CONNECT-Methode. Diese Methode wird hauptsächlich verwendet, um SSL-Anfragen durch Proxy-Server zu tunneln.

Um sie zu aktivieren und zu konfigurieren, beziehen Sie sich bitte auf die proxy_connect-Direktiven.

Konfigurationsdirektiven von NGINX-MOD

In diesem Build gibt es einige Konfigurationsdirektiven, die in regulären Builds nicht verfügbar sind. Lassen Sie uns diese hier dokumentieren.

Das folgende Set von Konfigurationsdirektiven wird durch den Patch dynamische TLS-Records hinzugefügt.

`ssl_dyn_rec_enable on|off`

Ob dynamische TLS-Records aktiviert werden sollen.

`ssl_dyn_rec_size_lo`

Die TLS-Record-Größe, mit der begonnen wird. Standardmäßig 1369 Bytes (so konzipiert, dass der gesamte Record in ein einzelnes TCP-Segment passt: 1369 = 1500 - 40 (IPv6) - 20 (TCP) - 10 (Zeit) - 61 (maximale TLS-Übertragung)) ssl_dyn_rec_size_hi: die TLS-Record-Größe, auf die gewachsen werden soll. Standardmäßig 4229 Bytes (so konzipiert, dass der gesamte Record in 3 TCP-Segmente passt).

`ssl_dyn_rec_threshold`

Die Anzahl der Records, die gesendet werden müssen, bevor die Record-Größe geändert wird.

Da wir mit dem neuesten OpenSSL bauen:

`ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2] [TLSv1.3];`

Keine neue Direktive. Aber da wir mit dem aktuellsten stabilen OpenSSL bauen, erlaubt es die Verwendung des Wertes TLSv1.3.

Verbergen von Softwareinformationen

Standardmäßig unterstützt NGINX nur server_tokens off;, was immer noch nginx im Server:-Header und auf Fehlerseiten ausgibt. Mit NGINX-MOD können Sie einen neuen Wert none angeben, der dazu führt, dass NGINX die Ausgabe seiner Präsenz auf dem Server stoppt:

server_tokens none;

Überprüfung

Um zu überprüfen, wie Sie von NGINX-MOD profitieren, können Sie einige Tests durchführen.

Überprüfen der HTTP/2-Headerkompression

yum install nghttp2
h2load https://example.com -n 2 | tail -6 | head -1

Beispielausgabe:

traffic: 71.46KB (73170) total, 637B (637) headers (space savings 78.68%), 70.61KB (72304) data

Wenn Sie 50 % oder mehr Speicherplatzersparnis sehen, bedeutet dies, dass die vollständige HPACK-Kompression genutzt wird.

So wechseln Sie zurück zu stabilem NGINX

Zurück zum stabilen Paket bei gleichzeitiger Beibehaltung der bestehenden Konfiguration:

yum-config-manager --disable getpagespeed-extras-nginx-mod
MOD_PKGS=$(rpm -qa --queryformat '%{NAME}\n' | grep nginx-mod | grep -v nginx-module)
rpm --erase --justdb --nodeps ${MOD_PKGS}
STABLE_PKGS=$(echo ${MOD_PKGS} | sed 's@nginx-mod@nginx@g')
yum -y install ${STABLE_PKGS}
yum history sync

Diese Befehle deaktivieren das NGINX-MOD-Repository und ersetzen alle nginx-mod*-Pakete durch ihre Äquivalente aus dem Basis-Repository, wodurch ein Downgrade auf stabilen NGINX erfolgt.

Kompatibilitätsnotizen

NGINX-MOD ist derzeit nicht mit dem Plesk-Kontrollpanel kompatibel.