Forwarding Headers & Client IP
Learn how Nginx rewrites request headers when proxying, and how to preserve the original client information for upstream applications.
Forwarding Headers & Client IP is a free API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Why Headers Matter
When Nginx acts as a reverse proxy, the upstream server only sees a connection coming from Nginx, not the real client. Without extra configuration, the backend loses the visitor's original IP, host, and protocol.
To keep this information, Nginx must forward headers describing the original request.
The Default Host Header
By default Nginx may pass the upstream server's address as the Host header. Many apps rely on the original host for routing or building absolute URLs.
Set it explicitly so the backend sees what the client requested:
location / {
proxy_pass http://backend;
proxy_set_header Host $host;
}Preserving the Real Client IP
The X-Real-IP header carries the original client's address so the backend can log or rate-limit by real visitor.
$remote_addrholds the connecting client's IP
proxy_set_header X-Real-IP $remote_addr;X-Forwarded-For Chain
X-Forwarded-For is a comma-separated chain of every proxy a request passed through. The variable $proxy_add_x_forwarded_for appends the current client to any existing value.
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;Forwarding the Protocol
If TLS terminates at Nginx, the backend speaks plain HTTP and cannot tell the original scheme. Send X-Forwarded-Proto so it can build correct https URLs and set secure cookies.
proxy_set_header X-Forwarded-Proto $scheme;Putting It Together
A standard reverse-proxy block bundles all four headers. This is the baseline you will reuse across nearly every project.
location / {
proxy_pass http://backend;
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;
}Reusing Header Config
Repeating the same headers in every location is error prone. Put them in an include file and pull it in wherever needed.
# /etc/nginx/proxy_headers.conf
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;
# in a server/location block:
include /etc/nginx/proxy_headers.conf;Trusting Forwarded Headers Safely
Clients can spoof X-Forwarded-For. Only trust it from known proxies. Use the real_ip module to set the true client IP from trusted upstreams.
set_real_ip_from 10.0.0.0/8;
real_ip_header X-Forwarded-For;
real_ip_recursive on;Removing or Clearing Headers
You can strip a header by setting it to an empty string. This is useful to hide internal headers from upstream or to prevent leaking server identity.
proxy_set_header X-Powered-By "";
proxy_hide_header X-Powered-By;Passing Custom Headers
You can inject your own headers to give the backend extra context, such as a tag identifying which gateway handled the request.
proxy_set_header X-Gateway-Node "edge-1";
proxy_set_header X-Request-Start $msec;Verifying the Result
Test from a backend that echoes headers (or use an inspector endpoint). You should see X-Real-IP matching your machine and X-Forwarded-Proto matching the scheme you used.
curl -H "Host: example.com" http://localhost/headersQuick Check
Which Nginx variable appends the current client to an existing forwarding chain?
Recap
You learned how Nginx rewrites requests and how to keep client context intact:
Hostpreserves the requested domainX-Real-IPandX-Forwarded-Forcarry the client IPX-Forwarded-Protoreports the original scheme- Use
real_ipand trusted ranges to avoid spoofing
These headers are the foundation of a transparent, secure reverse proxy.
Frequently asked questions
Is the “Forwarding Headers & Client IP” lesson free?
Yes — the full text of “Forwarding Headers & Client IP” is free to read here on the web, and the API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) course, upgrade to CoddyKit PRO.
What will I learn in “Forwarding Headers & Client IP”?
Learn how Nginx rewrites request headers when proxying, and how to preserve the original client information for upstream applications. You practise API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)?
No prior experience is required. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Forwarding Headers & Client IP” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) lesson?
Yes. Every API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Configuring Simple Reverse Proxy
- Upstream Servers & Load Balancing
- Proxy Buffering & Caching
- Forwarding Headers & Client IP