Übersicht

Erfahren Sie, wie Sie einen Reverse-Proxy mit HAProxy auf einem VPS einrichten, um Ihre echte Herkunfts-IP zu verbergen, die Leistung zu verbessern und Ihre Anwendungen vor Dritten zu schützen. Wie man einen Reverse-Proxy mit HAProxy einrichtet, um die IP des Real Origin Servers zu verbergen?

Was ist ein Reverse-Proxy?

Ein Reverse-Proxy befindet sich zwischen den Clients und Ihren Servern. Er empfängt eingehende Anfragen, entscheidet, wohin er sie sendet, und gibt Antworten zurück – und hält dabei Ihre Ursprungsserver vor dem öffentlichen Internet verborgen. Er kann auch die Last aufmehrere Backends verteilen, Sicherheits-Header hinzufügen, die Rate missbräuchlicher Clients begrenzen und die TLS (HTTPS)-Terminierung zentralisieren. Betrachten Sie ihn als intelligenten Türsteher: Er leitet die Leute in die richtigen Räume, hält aber die Hinterbühne privat.

Kurz gesagt, ein Reverse-Proxy ist das stille Arbeitstier, das dafür sorgt, dass alles reibungslos läuft, während Ihr Ursprung privat bleibt

Reverse-Proxy mit HAProxy: Wie es funktioniert

HAProxy ist ein leistungsfähiger L4/L7-Proxy und Lastausgleicher. Client-Anfragen treffen zuerst auf HAProxy, wo

• TLS (HTTPS) kann beendet werden.
• Header wie X-Forwarded-For, X-Forwarded-Proto und X-Forwarded-Host werden hinzugefügt.
• Der Datenverkehr wird anhand von Hostnamen, Pfaden oder benutzerdefinierten Regeln an Backends weitergeleitet.
• Gesundheitsprüfungen, automatisches Failover, Ratenbegrenzungen, Komprimierung, leichtes Caching, WebSockets und gRPC-Pass-Through sind verfügbar.
• Detaillierte Protokolle und eine Live-Statistikseite ermöglichen die Überwachung.

Unterm Strich: HAProxy vereinfacht Ihre Architektur, erhöht die Sicherheit und Leistung und ermöglicht eine unkomplizierte Skalierung

Vor- und Nachteile von HAProxy

Vorteile (warum HAProxy glänzt)

• Hohe Leistung und geringer Overhead (ereignisgesteuert, multi-threaded).
• L4 + L7 Intelligenz (TCP/SNI Passthrough oder vollständiges HTTP-Routing/Rewrites).
• Robuste Lastverteilung und Zustandsprüfungen (Round-Robin, Least-Conn, Hashing; aktive Prüfungen, Failover).
• Sicherheitsfunktionen (TLS-Terminierung, HSTS, ACLs, Ratenbegrenzung über Stick-Tabellen, IP allow/deny).
• Beobachtbarkeit (umfangreiche Protokolle, Live-Statistiken Socket/Seite; Prometheus-Exporter verfügbar).
• Zuverlässigkeit (zuverlässige, nahezu ausfallfreie Reloads; kampferprobt).
• Geringer Platzbedarf (läuft praktisch überall: Linux/BSD/Container).

Nachteile (Abstriche)

• Lernkurve (leistungsstarke, aber ausführliche Konfiguration).
• Cert-Automatisierung nicht eingebaut (Paar mit Certbot/lego oder Data Plane API).
• Standardmäßig manuelle Service-Erkennung (dynamische Backends benötigen Vorlagen/API).
• Begrenztes integriertes Caching/statisches Serving (bei Bedarf CDN/Varnish/Nginx verwenden).
• Keine native Community WAF (verwenden Sie eine separate WAF oder HAProxy Enterprise).
• Komplexe Rewrites können langwierig werden.
• Eingeschränkte Windows-Unterstützung (am besten auf Linux/BSD).

Was Sie benötigen

• Einen VPS/öffentlichen Server für HAProxy (den Reverse-Proxy).
• Ihren Ursprungsserver (z. B. 10.0.0.10:8080).
• Eine Domain (z. B. example.com) mit DNS A/AAAA, die auf die öffentliche IP des HAProxy-Servers zeigt.

Datenschutz-Tipp: Um Ihre Herkunfts-IP wirklich zu verbergen, stellen Sie sicher, dass die Herkunfts-IP nicht öffentlich erreichbar ist, stellen Sie eine Firewall auf, die nur Datenverkehr vom HAProxy-Server akzeptiert, und vermeiden Sie DNS-Einträge, die die Herkunft verraten

Schritt 1 – HAProxy installieren

Ubuntu/Debian

sudo apt update sudo apt install -y haproxy

RHEL/Alma/Rocky

sudo dnf install -y haproxy

Schritt 2 – Besorgen Sie sich ein TLS-Zertifikat (Let’s Encrypt)

Wir lassen Certbot ein Zertifikat besorgen und bündeln es für HAProxy

Installieren Sie Certbot und holen Sie das Zertifikat (einmalig)

#

 Ubuntu/Debian sudo apt install -y certbot sudo certbot certonly --standalone -d example.com --agree-tos -m you@example.com --non-interactive

Erstellen Sie das PEM-Bündel von HAProxy (fullchain + privkey)

sudo mkdir -p /etc/haproxy/certs sudo bash -c 'cat /etc/letsencrypt/live/example.com/fullchain.pem  /etc/letsencrypt/live/example.com/privkey.pem  > /etc/haproxy/certs/example.com.pem' sudo chmod 600 /etc/haproxy/certs/example.com.pem

Automatisches Entbündeln und Neuladen von HAProxy bei Verlängerungen

sudo bash -c 'cat >/etc/letsencrypt/renewal-hooks/deploy/haproxy.sh' <<'EOF' #!/usr/bin/env bash cat /etc/letsencrypt/live/example.com/fullchain.pem  /etc/letsencrypt/live/example.com/privkey.pem  > /etc/haproxy/certs/example.com.pem systemctl reload haproxy EOF sudo chmod +x /etc/letsencrypt/renewal-hooks/deploy/haproxy.sh

Schritt 3 – Minimale, produktionsreife HAProxy-Konfiguration (HTTPS + Weiterleitung)

Ersetzen Sie example.com und Ihre Backend-IP/Port wo angegeben #

/etc/haproxy/haproxy.cfg global log /dev/log local0 maxconn 50000 daemon defaults log global mode http option httplog timeout connect 5s timeout client 60s timeout server 60s http-reuse safe # Frontend: listen on 80/443, redirect to HTTPS, route ACME and app traffic frontend fe_https bind :80 bind :443 ssl crt /etc/haproxy/certs/example.com.pem alpn h2,http/1.1 # HTTPS erzwingen http-request redirect scheme https unless { ssl_fc } # Grundlegende Sicherheits-Header http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" if { ssl_fc } # Client-Informationen für Ihre App erhalten option forwardfor header X-Forwarded-For http-request set-header X-Forwarded-Proto https if { ssl_fc } http-request set-header X-Forwarded-Host %[req.hdr(host)] # Einfache Ratenbegrenzung: 100 Anfragen / 10s pro IP stick-table type ip size 100k expire 10m store http_req_rate(10s) http-request track-sc0 src acl too_fast sc0_http_req_rate gt 100 http-request deny status 429 if too_fast # Route ACME HTTP-01 challenges to local certbot (used during renewals) acl acme path_beg /.well-known/acme-challenge/ use_backend be_acme if acme # Leiten Sie Ihre Domain an das Ursprungs-Backend acl host_example hdr(host) -i example.com use_backend be_app if host_example default_backend be_app # Backend: Ihr Ursprungsserver backend be_app balance leastconn option httpchk GET /health http-check expect status 200 server app1 10.0.0.10:8080 check # Backend für ACME-Herausforderungen (certbot standalone hook) backend be_acme server local 127.0.0.1:8081

Warum das funktioniert

• HAProxy terminiert TLS auf :443 und leitet :80 → HTTPS um.
• Der reguläre Verkehr geht zu Ihrem Ursprung auf 10.0.0.10:8080.
• Nur /.well-known/acme-challenge/* wird an einen winzigen lokalen Webserver weitergeleitet, den Certbot während der Erneuerung betreibt.

Schritt 4 – Starten, neu laden und validieren

#

 Konfiguration validieren sudo haproxy -c -f /etc/haproxy/haproxy.cfg # Aktivieren und starten sudo systemctl enable --now haproxy # Nach Änderungen/Erneuerungen neu laden sudo systemctl reload haproxy

Schritt 5 – Hands-off Erneuerungen

Lassen Sie Certbot sich kurz an :8081 binden, während HAProxy :80/:443 offen hält:

# Normalerweise von systemd timer gehandhabt; zum Testen kann man es auch manuell ausführen sudo certbot renew --deploy-hook "/etc/letsencrypt/renewal-hooks/deploy/haproxy.sh"  --http-01-port 8081 --pre-hook "systemctl start haproxy" --post-hook "systemctl start haproxy"

Während der Erneuerung beantwortet Certbot die Anfrage auf Port 8081; HAProxy leitet diesen Pfad bereits an 127.0.0.1:8081 weiter

Variationen (wählen Sie, was Sie brauchen)

A) Mehrere Ursprünge nach Hostnamen

#

 Fügen Sie ein Frontend hinzu: acl host_api hdr(host) -i api.example.com use_backend be_api if host_api # Definieren Sie ein API-Backend: backend be_api balance roundrobin option httpchk GET /healthz server api1 10.0.0.21:9000 check server api2 10.0.0.22:9000 check

B) TLS-Passthrough (Ursprung behandelt TLS/mTLS)

Verwenden Sie den TCP-Modus mit SNI-Routing. Keine Header-Rewrites oder L7-Features hier.

frontend fe_tcp mode tcp bind :443 tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 } use_backend be_tls_app if { req_ssl_sni -i example.com } backend be_tls_app mode tcp server app_tls 10.0.0.10:443 check

C) Minimaler reiner HTTP-Reverse-Proxy (kein TLS)

Nur für interne Zwecke/Tests – verwenden Sie HTTPS für die Produktion.

global log /dev/log local0 defaults mode http log global option httplog timeout connect 5s timeout client 60s timeout server 60s frontend public_http bind :80 option forwardfor default_backend app backend app server app1 10.0.0.10:8080 check

Schnelle Überprüfung und Fehlerbehebung

#

 DNS sollte auf HAProxy dig +short example.com zeigen # HTTP sollte auf HTTPS umleiten (301) curl -I http://example.com # HTTPS sollte Inhalte liefern curl -I https://example.com # Sehen Sie sich die Header an, die die App empfängt (in Ihren App-Logs): # X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host

Firewall-Tipps

• Sperren Sie Ihren Ursprung so ab, dass er nur Verkehr vom HAProxy-Server akzeptiert (z. B. mit ufw, firewalld oder Cloud-Sicherheitsgruppen).
• Blockieren Sie optional den direkten öffentlichen Zugriff auf die Ursprungs-IP auf der Ebene Ihres Providers.

Abschließende Hinweise

• Halten Sie die Zeitüberschreitungen für Ihre Arbeitslasten angemessen (WebSockets/gRPC benötigen möglicherweise höhere Werte).
• Bieten Sie einen /health-Endpunkt in Ihrer Anwendung für httpchk an.
• Planen Sie Zero-Downtime-Deployments: Leeren Sie einen(deaktivierten) Server während der Deployments und aktivieren Sie ihn dann wieder.

Wichtiger Hinweis:Falls Sie sich nicht sicher sind, wie Sie den Server richtig konfigurieren, empfehlen wir dringend, einen Fachmann mit der Konfiguration zu beauftragen. Es ist wichtig sicherzustellen, dass alle Einstellungen korrekt vorgenommen werden, einschließlich der Überprüfung der Firewall-Ports, um sicherzustellen, dass keine Ports blockiert sind. Es ist wichtig, dass Sie zumindest ein grundlegendes Verständnis von Firewalls und Linux-Befehlen haben, um den Konfigurationsprozess effektiv durchführen zu können. Bitte beachten Sie, dass wir nicht für Schäden oder Probleme verantwortlich sind, die aus dem Konfigurationsprozess entstehen können. Alle hier bereitgestellten Informationen dienen ausschließlich der Vermittlung von technischem Wissen und Lernzwecken. Wir danken Ihnen für Ihr Verständnis