Ü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.
• Health Checks, automatisches Failover, Ratenbegrenzungen, Komprimierung, Light 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 offenbaren

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 für 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

HAProxy bei Erneuerung automatisch neu bündeln und laden

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, produktionsbereite HAProxy-Konfiguration (HTTPS + Umleitung)

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

# /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

  # Force HTTPS
  http-request redirect scheme https unless { ssl_fc }

  # Basic security header
  http-response set-header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" if { ssl_fc }

  # Preserve client info for your app
  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)]

  # Simple rate cap: 100 requests / 10s per 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

  # Route your domain to the origin backend
  acl host_example hdr(host) -i example.com
  use_backend be_app if host_example
  default_backend be_app

# Backend: your origin server
backend be_app
  balance leastconn
  option httpchk GET /health
  http-check expect status 200
  server app1 10.0.0.10:8080 check

# Backend to serve ACME challenges (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.
• Regulärer Verkehr geht zu Ihrem Ursprung unter 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 & validieren

# Validate config
sudo haproxy -c -f /etc/haproxy/haproxy.cfg

# Enable and start
sudo systemctl enable --now haproxy

# Reload after edits/renewals
sudo systemctl reload haproxy

Schritt 5 – Hands-off Erneuerungen

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

# Typically handled by systemd timer; safe to run manually for testing
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 Herausforderung 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 Hostname

# Add in frontend:
acl host_api hdr(host) -i api.example.com
use_backend be_api if host_api

# Define an 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 handhabt TLS/mTLS)

Verwenden Sie den TCP-Modus mit SNI-Routing. Hier werden keine Header umgeschrieben oder L7-Funktionen verwendet

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 should point to HAProxy
dig +short example.com

# HTTP should redirect to HTTPS (301)
curl -I http://example.com

# HTTPS should serve content
curl -I https://example.com

# See headers the app receives (in your app logs):
# X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host

Firewall-Tipps

• Sperren Sie Ihren Ursprung so, 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 Timeouts für Ihre Workloads angemessen (WebSockets/gRPC benötigen möglicherweise höhere Timeouts).
• Stellen Sie einen /health Endpunkt in Ihrer Anwendung für httpchk zur Verfügung.
• Planen Sie Zero-Downtime Deployments: Leeren Sie einen Server (disabled) während des Deployments und aktivieren Sie ihn dann wieder.

Wichtiger HinweisFalls Sie sich nicht sicher sind, wie Sie den Server richtig konfigurieren, empfehlen wir Ihnen 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 zu steuern. 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