Demo HTTP Headers

In this lesson we configure an NGINX server to return a set of security HTTP headers, then extend that configuration to act as a TLS-terminating load balancer that forwards requests to two Apache backend servers. We also pass useful proxy headers so the Apache backends can log the original client information for debugging and auditing. Flow overview:

Inspect current response headers from the site.
Add security headers to the TLS (listen 443 ssl) server block.
Configure an upstream block and proxy traffic to two Apache backends.
Add proxy_set_header directives so the backend sees the original client IP and scheme.
Update Apache logging to include forwarded headers or use mod_remoteip.

A simple diagram showing a desktop computer on the left communicating with a website/browser window on the right via dashed arrows to represent requests and responses. Icons of a magnifying glass over code and a small HTTP request/status box indicate inspection and response details.

We will then configure NGINX as a load balancer to distribute traffic to two backend Apache servers and include proxy headers so the Apache logs record useful client information (instead of all requests appearing to come from the load balancer).

A simple architecture diagram showing a user/browser sending requests to an NGINX load balancer which distributes traffic to two backend web servers. The two web servers are running Apache HTTP Server and are labeled 1 and 2.

1) Initial checks — inspect current headers

I added an internal DNS entry for example.com pointing to loopback. For example, your /etc/hosts may include:

root@nginx ~ ➜ cat /etc/hosts
127.0.0.1        localhost
::1              localhost ip6-localhost ip6-loopback
fe00::0          ip6-localnet
ff00::0          ip6-mcastprefix
ff02::1          ip6-allnodes
ff02::2          ip6-allrouters
192.231.70.6     nginx
127.0.0.1        example.com

Check headers with curl:

root@nginx ~ ➜ curl --head https://example.com
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 12 Feb 2025 19:24:14 GMT
Content-Type: text/html
Content-Length: 8710
Last-Modified: Wed, 12 Feb 2025 18:42:19 GMT
Connection: keep-alive
ETag: "67aceb8b-2206"
Accept-Ranges: bytes

In the browser: open DevTools → Network → select a resource to view response headers. At this point the server returns standard headers such as Server and Date, but no custom security headers yet.

2) Add security headers in NGINX (TLS server block)

Edit your site config (e.g., /etc/nginx/sites-available/example-https) and add the security headers inside the server { listen 443 ssl; ... } block. Example configuration:

# /etc/nginx/sites-available/example-https
server {
    listen 80;

    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/certs/example.com-key.pem;

    root /var/www/html;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header Content-Security-Policy "default-src 'self'";
    add_header Referrer-Policy origin;

    # Add index.php to the list if you are using PHP
    index index.html index.htm index.nginx-debian.html;

    location / {
        # First attempt to serve request as file, then as directory,
        # then fall back to displaying a 404.
        try_files $uri $uri/ =404;
    }
}

Save, test and reload NGINX:

root@nginx /etc/nginx/sites-available ➜ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

root@nginx /etc/nginx/sites-available ➜ nginx -s reload

Re-check response headers:

root@nginx /etc/nginx/sites-available ➜ curl --head https://example.com
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Wed, 12 Feb 2025 19:28:15 GMT
Content-Type: text/html
Content-Length: 8710
Last-Modified: Wed, 12 Feb 2025 18:42:19 GMT
Connection: keep-alive
ETag: "67aceb8b-2206"
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'
Referrer-Policy: origin
Accept-Ranges: bytes

You should now see Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, and Referrer-Policy in DevTools → Network for resource responses.

Strict-Transport-Security (HSTS) instructs browsers to access the site only over HTTPS. When testing, use a conservative max-age (for example, a few hours) before committing a long duration or adding preload. For more, see the HSTS specification and browser docs.

Quick reference — common security headers:

Header	Purpose
`Strict-Transport-Security`	Enforce HTTPS (HSTS)
`X-Frame-Options`	Prevent clickjacking (`SAMEORIGIN`)
`Content-Security-Policy`	Control allowed resource origins to mitigate XSS
`Referrer-Policy`	Control referrer information sent to third parties

3) Configure NGINX as a load balancer (upstream block)

Add an upstream block and change the site location / to proxy requests to the example upstream. Initially this will forward traffic, but backends will only see the load balancer IP unless we forward proxy headers. Example:

# Upstream configuration
upstream example {
    server node01:443;
    server node02:443;
}

server {
    listen 80;

    server_name example.com;
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl;

    server_name example.com;

    ssl_certificate /etc/ssl/certs/example.com.pem;
    ssl_certificate_key /etc/ssl/certs/example.com-key.pem;

    root /var/www/html;

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
    add_header X-Frame-Options "SAMEORIGIN";
    add_header Content-Security-Policy "default-src 'self'";
    add_header Referrer-Policy origin;

    index index.html index.htm index.nginx-debian.html;

    location / {
        proxy_pass https://example;
    }
}

Test and reload NGINX after editing.

4) Forward proxy headers so backends see original client info

To ensure Apache backends can log and act on the original client IP and protocol, set the appropriate proxy headers inside the location block. Update location /:

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_pass https://example;
}

Notes:

X-Real-IP sends the immediate client IP as seen by NGINX ($remote_addr).
X-Forwarded-For accumulates client IPs across hops; $proxy_add_x_forwarded_for appends the current hop.
X-Forwarded-Proto tells the backend whether the original request used http or https.
Always end directives with semicolons.

Test and reload:

root@nginx /etc/nginx/sites-available ➜ nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

root@nginx /etc/nginx/sites-available ➜ nginx -s reload

5) Inspect backend Apache logs and include proxy headers in log format

On the Apache backend nodes, check access logs:

root@node01 /var/log/apache2 ➜ ll
total 20
drwxr-x--- 2 root adm 4096 Feb 12 18:42 ./
drwxr-xr-x 1 root root 4096 Feb 12 18:42 ../
-rw-r----- 1 root adm 626 Feb 12 19:30 access.log
-rw-r----- 1 root adm 1411 Feb 12 19:16 error.log
-rw-r----- 1 root adm 101 Feb 12 18:43 other_vhosts_access.log

Tail the access log to observe incoming requests:

root@node01 /var/log/apache2 ➜ tail -f access.log
example.com:443 127.0.0.1 - - [12/Feb/2025:19:17:52 +0000] "GET / HTTP/1.1" 200 11223 "-" "curl/7.81.0"
example.com:443 192.231.70.4 - - [12/Feb/2025:19:30:42 +0000] "GET / HTTP/1.0" 200 3621 "https://k32e7jpvqa7xtxil.kk-lab-dev.kodekloud.com/" "Mozilla/5.0 (Macintosh; ...)"

To log the proxy headers forwarded by NGINX, add or update an Apache LogFormat (often in /etc/apache2/apache2.conf or an included conf-enabled file). Example LogFormat additions:

LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

# Extended format including proxy headers forwarded by NGINX
LogFormat "%v:%p \"%{X-Real-IP}i\" \"%{X-Forwarded-For}i\" \"%{X-Forwarded-Proto}i\" %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined

Test and restart Apache:

root@node01 /etc/apache2 ➜ apachectl -t
# Warnings about undefined config variables may appear; ensure your config is correct.
Syntax OK

root@node01 /etc/apache2 ➜ systemctl restart apache2

If you prefer the remote host (%h) to reflect the original client IP automatically, consider using Apache’s mod_remoteip which rewrites the client IP based on trusted proxy headers.

If you receive X-Forwarded-For from trusted proxies, enable Apache’s mod_remoteip (see the official docs) so %h and access control reflect the real client IP. Only enable this when you trust the upstream proxies.

Relevant links:

NGINX proxy headers and variables: https://nginx.org/en/docs/http/ngx_http_proxy_module.html
Apache mod_remoteip: https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html

6) Compare log output (before and after)

Before forwarding proxy headers, Apache access logs typically show the load balancer IP:

example.com:443 192.231.70.6 - - [12/Feb/2025:19:37:22 +0000] "GET /images/logo.svg HTTP/1.0" 200 3223 "https://443-port-k32e7jpvqa7txtil.kk-lab-dev.kodekloud.com/" "Mozilla/5.0 (...)"

After adding proxy_set_header and an extended LogFormat, log lines can include the forwarded IPs and protocol, improving traceability:

example.com:443 "192.231.70.4" "174.0.252.84, 34.117.152.159, 169.254.169.126, 192.168.1.144, 192.231.70.4" "https" 192.231.70.4 - - [12/Feb/2025:19:37:22 +0000] "GET / HTTP/1.0" 200 3621 "https://k32e7jpvqa7xtxil.kk-lab-dev.kodekloud.com/" "Mozilla/5.0 (...)"

Field meanings:

First quoted field: X-Real-IP (immediate client IP seen by NGINX).
Long comma-separated list: X-Forwarded-For (client IP chain across proxies).
Next quoted field: X-Forwarded-Proto (original request scheme, e.g., https).

This makes it much easier to trace request origin and diagnose issues across multiple proxy layers.

7) Recap and next steps

Inspected default response headers and added security headers in the NGINX TLS server block.
Implemented an upstream with two Apache backend nodes and proxied TLS traffic.
Added proxy_set_header directives (X-Real-IP, X-Forwarded-For, Host, X-Forwarded-Proto) so backends can see the original client context.
Updated Apache LogFormat to include forwarded headers or considered mod_remoteip to rewrite %h.

Introduction

Install & Config

Intermediate Config

Security

Performance

Conclusion

1) Initial checks — inspect current headers

2) Add security headers in NGINX (TLS server block)

3) Configure NGINX as a load balancer (upstream block)

4) Forward proxy headers so backends see original client info

5) Inspect backend Apache logs and include proxy headers in log format

6) Compare log output (before and after)

7) Recap and next steps

Watch Video

Practice Lab

​1) Initial checks — inspect current headers

​2) Add security headers in NGINX (TLS server block)

​3) Configure NGINX as a load balancer (upstream block)

​4) Forward proxy headers so backends see original client info

​5) Inspect backend Apache logs and include proxy headers in log format

​6) Compare log output (before and after)

​7) Recap and next steps

Watch Video

Practice Lab

1) Initial checks — inspect current headers

2) Add security headers in NGINX (TLS server block)

3) Configure NGINX as a load balancer (upstream block)

4) Forward proxy headers so backends see original client info

5) Inspect backend Apache logs and include proxy headers in log format

6) Compare log output (before and after)

7) Recap and next steps