API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · レッスン

ヘッダーの転送とクライアントIP

プロキシ時にNginxがリクエストヘッダーを書き換える仕組みと、元のクライアント情報をアップストリームのアプリケーションに引き継ぐ方法を学びます。

「ヘッダーの転送とクライアントIP」はCoddyKit上の無料API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)レッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAPI Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)コースには全4レッスンが含まれています。

このレッスンの一部はまだ翻訳されておらず、英語で表示されています。

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_addr holds 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/headers

Quick 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:

Host preserves the requested domain
X-Real-IP and X-Forwarded-For carry the client IP
X-Forwarded-Proto reports the original scheme
Use real_ip and trusted ranges to avoid spoofing

These headers are the foundation of a transparent, secure reverse proxy.

よくある質問

「ヘッダーの転送とクライアントIP」レッスンは無料ですか？

はい。「ヘッダーの転送とクライアントIP」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)コースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)コースには全4レッスンが含まれています。

「ヘッダーの転送とクライアントIP」で何を学びますか？

プロキシ時にNginxがリクエストヘッダーを書き換える仕組みと、元のクライアント情報をアップストリームのアプリケーションに引き継ぐ方法を学びます。ブラウザで直接実行するハンズオンコードでAPI Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)を演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)を始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAPI Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)は初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「ヘッダーの転送とクライアントIP」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAPI Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)レッスンでコードを書いて実行できますか？

はい。すべてのAPI Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)レッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)に戻る