OSM Linux EngineersContact Us
MainHomeServicesPricingCase StudiesGuidesAboutContact
Service categoriesServer & OperationsWeb StackContainersDatabasesApplicationsCloud & IaCDevelopment & AutomationNetwork, DNS & CDNBackup, Monitoring & SecurityMigrationsFor AgenciesAll Services
Home / Case studies / Restoring Real Visitor IPs for Containerised Apps

Case study

Restoring Real Visitor IPs for Containerised Apps

A customer running application containers behind a host-level reverse proxy could not get the real visitor IP into the app. Every request appeared to come from the proxy or container network, making logs, rate limiting and access decisions unreliable.

Context

The customer had a containerised application running on a server with a reverse proxy in front of several app containers. The site worked, but the application could not see the original visitor IP address.

This caused problems for logging, abuse checks, audit trails and application behaviour that depended on knowing where requests really came from.

The problem

  • The application logs showed the proxy/container network address instead of the visitor IP.
  • Forwarded headers were either missing, overwritten or not trusted by the application.
  • The reverse proxy, container network and application configuration all had to be checked together.
  • The customer needed a safe change that would not break routing for the running containers.

Our approach

  • Reviewed the request path from the public edge through the host reverse proxy and into the app containers.
  • Checked proxy header handling, including forwarded client IP headers and host/protocol forwarding.
  • Verified how the application framework trusted proxy headers and how logs recorded client addresses.
  • Tested the change carefully so the application received the real client IP without exposing it to spoofed headers from untrusted sources.

Practical outcomes

Client IPs restoredThe application began receiving the original visitor IP instead of only the proxy or container address.
Logging improvedApplication logs became more useful for debugging, abuse checks and audit trails.
Proxy path clarifiedThe customer gained a clearer understanding of how traffic moved from the edge to the containers.
Recommended follow-upProxy header handling, access logs and rate limiting should be reviewed after future proxy, CDN or container routing changes.

Relevant technologies and keywords

These are the main technologies, services and search terms connected to this case study.

Reverse proxyReal client IPX-Forwarded-ForX-Real-IPTrusted proxiesApp containersDockerNGINXCloudflareApplication logging

Related services

Relevant services for similar infrastructure problems.

Reverse Proxy Support

Proxy routing, upstream services, forwarded headers and origin behaviour.

View service →

Docker Compose Support

Containerised application stacks, networks, services and routing.

View service →

NGINX Support

NGINX configuration, proxy headers, upstreams and production routing issues.

View service →

HTTP Header & Cache-Control Support

Header behaviour, request forwarding, cache rules and application response checks.

View service →

Need something similar fixed?

Send us the issue and we will suggest the right starting point.

Tell us what is affected, what changed recently and what outcome you need. We will confirm whether it is best handled as a fixed technical fix, hourly support, review, migration or urgent incident work.

Contact Us