Nginx Reverse Proxy und Load Balancing - Versionsgeschichte

Thomas.will@claude: Erweitertes Routing ergaenzt, Links auf neue Seiten

2026-10-31T14:14:53Z

Erweitertes Routing ergaenzt, Links auf neue Seiten

@@ Zeile 118: / Zeile 118: @@
 <code>burst=10 nodelay</code> lässt kurze Spitzen bis 10 Anfragen sofort durch, statt sie zu verzögern. Wird die Rate dauerhaft überschritten, antwortet Nginx selbst mit <b>429 Too Many Requests</b> – das Backend bekommt die Anfrage gar nicht erst zu sehen.
 == Fehlerbilder ==
@@ Zeile 141: / Zeile 177: @@
 * [https://nginx.org/en/docs/ offizielle Nginx-Dokumentation]
 * [[Nginx Grundlagen]]
 * Animationen: [https://xinux.org/nginx-grundkonfiguration.html Grundkonfiguration] · [https://xinux.org/nginx-reverse-proxy.html Reverse Proxy] · [https://xinux.org/nginx-load-balancing.html Load Balancing]

Thomas.will@claude: Links auf die drei Nginx-Animationen angepasst

2026-10-31T13:58:06Z

Links auf die drei Nginx-Animationen angepasst

← Nächstältere Version		Version vom 31. Oktober 2026, 13:58 Uhr
Zeile 1:		Zeile 1:
	Vertiefung zu [[Nginx Grundlagen]]: Location-Matching, Reverse Proxy, Load Balancing, Caching und Rate Limiting – mit den typischen Fehlerbildern. Dazu die ~~Animation~~ [https://xinux.org/nginx-reverse-proxy.html Nginx: Reverse Proxy & Load Balancing].		Vertiefung zu [[Nginx Grundlagen]]: Location-Matching, Reverse Proxy, Load Balancing, Caching und Rate Limiting – mit den typischen Fehlerbildern. Dazu die Animationen [https://xinux.org/nginx-grundkonfiguration.html Nginx: Grundkonfiguration] (Einstieg), [https://xinux.org/nginx-reverse-proxy.html Nginx: Reverse Proxy] (erweitert) und [https://xinux.org/nginx-load-balancing.html Nginx: Load Balancing] (fortgeschritten).

	== Location-Matching: welche Regel gewinnt ==		== Location-Matching: welche Regel gewinnt ==
Zeile 141:		Zeile 141:
	* [https://nginx.org/en/docs/ offizielle Nginx-Dokumentation]		* [https://nginx.org/en/docs/ offizielle Nginx-Dokumentation]
	* [[Nginx Grundlagen]]		* [[Nginx Grundlagen]]
	* ~~Animation~~: [https://xinux.org/nginx-reverse-proxy.html ~~Nginx:~~ Reverse Proxy & Load Balancing]		* Animationen: [https://xinux.org/nginx-grundkonfiguration.html Grundkonfiguration] · [https://xinux.org/nginx-reverse-proxy.html Reverse Proxy] · [https://xinux.org/nginx-load-balancing.html Load Balancing]

Thomas.will@claude: Neue Seite: Location-Matching, Load Balancing, Caching, Rate Limiting

2026-10-31T13:45:10Z

Neue Seite: Location-Matching, Load Balancing, Caching, Rate Limiting

Neue Seite

Vertiefung zu [[Nginx Grundlagen]]: Location-Matching, Reverse Proxy, Load Balancing, Caching und Rate Limiting – mit den typischen Fehlerbildern. Dazu die Animation [https://xinux.org/nginx-reverse-proxy.html Nginx: Reverse Proxy & Load Balancing].

== Location-Matching: welche Regel gewinnt ==

Nginx wählt die passende <code>location</code> '''nicht''' nach der Reihenfolge im Config, sondern nach festen Regeln:

# '''Exact Match''' (<code>location = /pfad</code>) – trifft nur exakt, gewinnt sofort
# '''Prefix Match''' – der '''längste''' passende Prefix gewinnt
# Ist der Prefix mit <code>^~</code> markiert, '''stoppt''' hier die Prüfung – keine Regex mehr
# sonst: alle '''Regex-Locations''' (<code>~</code> case-sensitive, <code>~*</code> case-insensitive) der Reihe nach, die '''erste passende gewinnt''' – und zwar über dem Prefix
# ohne Regex-Treffer: Fallback auf den längsten Prefix aus Schritt 2

=== Der Klassiker: Regex schlägt Prefix ===

<pre>
location /download/ {
limit_rate 500k; # Downloads drosseln
}
location ~* \.(zip|iso)$ {
limit_rate 5m; # war für andere Zwecke gedacht
}
</pre>

Eine Anfrage nach <code>/download/archiv.zip</code> passt auf beide Blöcke. Da der Prefix '''kein''' <code>^~</code> hat, gewinnt die Regex-Regel – die Datei wird entgegen der Absicht '''nicht''' gedrosselt. Lösung: den Prefix mit <code>^~</code> markieren, dann gewinnt er garantiert gegen jede Regex:

<pre>
location ^~ /download/ {
limit_rate 500k; # gilt jetzt für alles unter /download/
}
</pre>

== Reverse Proxy: proxy_pass und Header ==

<pre>
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
</pre>

Ohne diese Header sieht die Backend-App nur Nginx selbst (<code>127.0.0.1</code>) als Quelle – Client-IP, ursprünglicher Host und Protokoll gehen verloren. '''Wichtig:''' Eine App darf <code>X-Forwarded-For</code> nur von bekannten, kontrollierten Proxys vertrauen, sonst lässt sich der Header von jedem fälschen, der die App direkt erreicht.

Für WebSockets zusätzlich:

<pre>
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
</pre>

== Load Balancing ==

<pre>
upstream app_backend {
server 10.0.0.11:3000;
server 10.0.0.12:3000;
}
server {
location / {
proxy_pass http://app_backend;
}
}
</pre>

=== Verteilmethoden ===

{| class="wikitable"
! Methode !! Verhalten
|-
| weighted round robin (Default) || reihum, optional mit Gewicht je Server (<code>weight=3</code>)
|-
| <code>least_conn</code> || an den Server mit den wenigsten aktiven Verbindungen
|-
| <code>ip_hash</code> || gleiche Client-IP landet immer beim gleichen Server (Session-Affinität ohne gemeinsamen Session-Speicher, aber ungleich verteilt bei NAT/Firmennetz)
|}

=== Ausfall eines Backends ===

<pre>
upstream app_backend {
server 10.0.0.11:3000 max_fails=3 fail_timeout=30s;
server 10.0.0.12:3000;
}
</pre>

Das freie Nginx erkennt einen Ausfall nur '''passiv''': Erst wenn echte Anfragen fehlschlagen, zählt das. Nach <code>max_fails</code> Fehlschlägen wird der Server für <code>fail_timeout</code> ausgeschlossen. Aktive, regelmäßige Health-Checks gibt es nur in kommerziellen oder Drittanbieter-Erweiterungen – bis <code>max_fails</code> erreicht ist, können einzelne Anfragen mit 502/504 beim Client landen.

== Caching ==

<pre>
# im http-Kontext
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=appcache:10m max_size=1g inactive=30m;

# in der proxied location
location / {
proxy_pass http://app_backend;
proxy_cache appcache;
proxy_cache_valid 200 10m;
add_header X-Cache-Status $upstream_cache_status always;
}
</pre>

<code>X-Cache-Status</code> zeigt im Antwort-Header <code>HIT</code>/<code>MISS</code>/<code>BYPASS</code> – praktisch zur Fehlersuche. '''Vorsicht:''' Cache-Keys, Bypass-Regeln und Autorisierung sauber planen, sonst landen personalisierte Antworten (z. B. mit fremden Session-Daten) versehentlich im gemeinsamen Cache.

== Rate Limiting ==

<pre>
# im http-Kontext: Zone definieren
limit_req_zone $binary_remote_addr zone=reqs:10m rate=5r/s;

# im server- oder location-Block: anwenden
limit_req zone=reqs burst=10 nodelay;
limit_req_status 429;
</pre>

<code>burst=10 nodelay</code> lässt kurze Spitzen bis 10 Anfragen sofort durch, statt sie zu verzögern. Wird die Rate dauerhaft überschritten, antwortet Nginx selbst mit <b>429 Too Many Requests</b> – das Backend bekommt die Anfrage gar nicht erst zu sehen.

== Fehlerbilder ==

{| class="wikitable"
! Code !! Ursache !! Erster Schritt
|-
| 403 || Dateiberechtigungen oder <code>deny all</code> || Dateirechte/Besitzer prüfen, passende location
|-
| 404 || falscher <code>root</code> oder falscher Pfad || <code>root</code>/<code>alias</code> im richtigen location-Block prüfen
|-
| 413 || Anfrage größer als <code>client_max_body_size</code> || Limit gezielt erhöhen, nicht pauschal abschalten
|-
| 502 || Backend nicht erreichbar oder liefert ungültige Antwort || Backend-Prozess/Port prüfen, <code>error.log</code> lesen
|-
| 504 || Backend antwortet, aber zu langsam || <code>proxy_read_timeout</code> prüfen, Backend-Performance klären
|}

Nach jeder Config-Änderung zuerst <code>sudo nginx -t</code>, dann erst <code>systemctl reload nginx</code> – ein Syntaxfehler legt sonst beim nächsten Neustart den ganzen Dienst lahm.

== Links ==

* [https://nginx.org/en/docs/ offizielle Nginx-Dokumentation]
* [[Nginx Grundlagen]]
* Animation: [https://xinux.org/nginx-reverse-proxy.html Nginx: Reverse Proxy & Load Balancing]