Real-IP Handling: Client IP korrekt ermitteln trotz Proxies/CDN

In modernen Web-Architekturen werden Clients häufig über mehrere Proxies, Load Balancer oder Content Delivery Networks (CDNs) geleitet, bevor sie die eigentliche Anwendung erreichen. In solchen Setups wird die ursprüngliche Client-IP oft durch Header wie X-Forwarded-For oder CF-Connecting-IP transportiert. Die korrekte Ermittlung der realen Client-IP ist entscheidend für Logging, Rate-Limiting, Sicherheit und Auditierung. In diesem Artikel zeigen wir praxisnah, wie Real-IP Handling zuverlässig umgesetzt wird, welche Fallstricke existieren und wie Nginx, Apache und CDNs korrekt konfiguriert werden.

Warum die echte Client-IP wichtig ist

Die Erkennung der realen Client-IP ist für viele Web-Stack-Funktionen essenziell:

• Rate Limiting und Schutz vor Brute-Force-Angriffen
• Geo-Lokalisierung und Content-Targeting
• Logging und Auditing für Compliance
• Sicherheitskontrollen wie IP-Whitelist oder Blocklists

Forwarded Headers verstehen

Um die Original-IP weiterzuleiten, nutzen Proxies spezielle HTTP-Header. Die wichtigsten sind:

• X-Forwarded-For: Liste der IP-Adressen durch Komma getrennt, zuerst die ursprüngliche Client-IP.
• X-Real-IP: Einfacher Header für die Client-IP, häufig von Nginx gesetzt.
• CF-Connecting-IP: Speziell bei Cloudflare, enthält die echte Client-IP.
• Forwarded: Standard-RFC7239 Header, kann for, proto und host enthalten.

IP-Kette richtig interpretieren

Header wie X-Forwarded-For enthalten mehrere IPs, z. B. 203.0.113.10, 198.51.100.22, 192.0.2.5. Die erste IP ist die ursprüngliche Client-IP. Alle weiteren IPs stammen von Proxies. Unsachgemäße Verarbeitung kann zu Spoofing führen, wenn der letzte Proxy nicht vertrauenswürdig ist.

Real-IP Handling in Nginx

Nginx kann durch set_real_ip_from und real_ip_header den Client korrekt ermitteln. Beispiel:

http {
    set_real_ip_from 10.0.0.0/8;
    set_real_ip_from 192.168.0.0/16;
    set_real_ip_from 203.0.113.0/24;  # CDN/Proxy
    real_ip_header X-Forwarded-For;
server {
    listen 443 ssl;
    server_name example.com;

    location / {
        access_log /var/log/nginx/access.log combined;
        proxy_pass http://backend;
    }
}

}


Nur IPs aus den vertrauenswürdigen Bereichen werden akzeptiert. Andere X-Forwarded-For Werte werden ignoriert.
Tipps für Nginx

Proxy- und CDN-IP-Bereiche regelmäßig aktualisieren
Mit proxy_set_header X-Real-IP $remote_addr sicherstellen, dass Backend die korrekte IP erhält
Audit-Logs immer die verifizierte IP aufzeichnen

Real-IP Handling in Apache
Apache nutzt mod_remoteip für die Verarbeitung von Forwarded-Headern:
RemoteIPHeader X-Forwarded-For
RemoteIPTrustedProxy 10.0.0.0/8
RemoteIPTrustedProxy 192.168.0.0/16
RemoteIPTrustedProxy 203.0.113.0/24
LogFormat "%a %l %u %t "%r" %>s %b" combined

CustomLog /var/log/apache2/access.log combined



Die Option %a im Log verwendet die geprüfte Client-IP. Unbekannte Proxies werden ignoriert.
Besonderheiten bei CDNs
CDNs wie Cloudflare, Fastly oder Akamai setzen eigene Header:

CF-Connecting-IP (Cloudflare)
True-Client-IP (Akamai)
Fastly-Client-IP (Fastly)

Diese Header sollten nur von den bekannten CDN-IP-Bereichen akzeptiert werden, um Spoofing zu vermeiden.
Sicherheitsaspekte

Nie blind den ersten Wert von X-Forwarded-For verwenden
IP-basierte Zugriffskontrollen nur auf verifizierte IPs anwenden
Alle Proxies und CDNs in der Konfiguration explizit definieren
Header-Manipulation durch Clients verhindern

Logging und Auditierbarkeit
Für Audit-Zwecke sollten alle relevanten Informationen geloggt werden:
log_format audit '$remote_addr forwarded_for=$http_x_forwarded_for '
                   'real_ip=$http_x_real_ip proto=$http_x_forwarded_proto '
                   'host=$host request="$request" status=$status';
access_log /var/log/nginx/audit.log audit;



So lässt sich jede Request-Kette rekonstruieren und auf Anomalien prüfen.
Typische Fehlerquellen

Blindes Vertrauen auf X-Forwarded-For ohne Proxy-Filter
CDN-Header nicht abgesichert
Logs ohne die verifizierte Real-IP
Zu breite Proxy-IP-Ranges führen zu IP-Spoofing-Risiko

Best Practices

Alle Proxy- und CDN-IP-Bereiche explizit in Konfiguration eintragen
Vertrauenswürdige Header prüfen und ggf. ablehnen
Audit-Logs mit Original-IP und Forwarded-Headern anlegen
Regelmäßige Updates der Proxy-/CDN-IP-Ranges
Automatisiertes Monitoring für ungewöhnliche IP-Ketten implementieren

Fazit
Die korrekte Ermittlung der Real-IP trotz Proxies und CDNs ist für Sicherheit, Logging und Performance essenziell. Mit gezielter Konfiguration von Nginx, Apache und der richtigen Behandlung von CDN-Headern lassen sich Spoofing-Risiken minimieren und auditierbare Web-Stacks aufbauen.
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3
Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.
Meine Leistungen umfassen:


Professionelle Konfiguration von Routern und Switches


Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen


Erstellung von Topologien und Simulationen in Cisco Packet Tracer


Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG


Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible


Erstellung von Skripten für wiederkehrende Netzwerkaufgaben


Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege


Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting


Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.