NGINX-MOD

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

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, Probleme 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 hochmodernen HTTP/3-Protokoll.
Verbesserte HTTP/2 HPACK-Kompression: Steigern Sie die Leistung Ihrer Website durch optimierte Header-Kompression, die schnellere Datenübertragungen gewährleistet.
Dynamische TLS-Datensatzverwaltung: Verbessern Sie sowohl Sicherheit als auch Geschwindigkeit mit dynamisch verwalteten TLS-Datensätzen, die sich in Echtzeit an die Bedürfnisse Ihrer Website anpassen.
Erweiterte Ratenbegrenzung: Erhalten 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: Verarbeiten 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 Funktionen von NGINX-MOD, 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-Version verwendet haben, können Sie eine Reihe von Befehlen ausführen, um auf NGINX-MOD zu aktualisieren, ohne installierte Module oder Konfigurationen 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 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.

Grundlagen der Konfiguration 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 betrachten.
check_status: Stellt ein Dashboard unter /status im HTML-Format zur Verfügung.

Referenz der direkten aktiven 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`

Überprüft 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 einschränken
  deny all;
}

Abfrageparameter

format: Ausgabeformat überschreiben (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 kommagetrennte 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-/Negativmeldungen:
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-Benutzer 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 die von Ihnen definierte Zonen-Speichergröße das Beibehalten 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, kann 10m etwa 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 ratenbegrenzt werden, da Informationen über seine IP-Adresse nach ausreichend Besuchern aus dem Speicher entfernt werden.

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

Die Faustregel lautet:

Sie müssen wahrscheinlich die Speicherzone erhöhen, wenn Ihr Verkehr ausreicht, 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 dies zu aktivieren und zu konfigurieren, siehe die proxy_connect-Direktiven.

Konfigurationsdirektiven von NGINX-MOD

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

Das folgende Set von Konfigurationsdirektiven wird durch den Patch für dynamische TLS-Datensätze hinzugefügt.

`ssl_dyn_rec_enable on|off`

Ob dynamische TLS-Datensätze aktiviert werden sollen.

`ssl_dyn_rec_size_lo`

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

`ssl_dyn_rec_threshold`

Die Anzahl der Datensätze, die gesendet werden müssen, bevor die Datensatzgröß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 neuesten 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 NGINX dazu bringt, die Anzeige seiner Präsenz auf dem Server zu stoppen:

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 Einsparungen bei der Speicherkapazität sehen, bedeutet dies, dass die vollständige HPACK-Kompression genutzt wird.

So wechseln Sie zurück zu stabilem NGINX

Um zum stabilen Paket zurückzukehren und die vorhandene Konfiguration beizubehalten:

yum-config-manager --disable getpagespeed-extras-nginx-mod
yum-config-manager --disable getpagespeed-extras-mainline
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 Entsprechungen aus dem Basis-Repository, wodurch auf stabiles NGINX zurückgestuft wird.

Kompatibilitätsnotizen

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