Reverse Proxy and Upstream

## Why the app loses all this information A reverse proxy terminates the client's connection and opens a new one to the backend. From the backend's point of view the peer is nginx: its remote address is nginx's address, the connection is whatever nginx used (usually plain HTTP on a private network), and the Host header is whatever nginx chose to send. Everything about the original client is gone unless nginx re-attaches it as request headers. Nginx's built-in defaults for proxied requests are minimal: ```nginx proxy_set_header Host $proxy_host; proxy_set_header Connection close; ``` `$proxy_host` is the name and port from the `proxy_pass` value — for `proxy_pass http://backend;` that is literally `backend`. That is why an application behind an unconfigured proxy reports a Host nobody has ever heard of, and why virtual-host selection, absolute-URL generation and cookie domains all misbehave. ## The three headers that matter ```nginx 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; } ``` **Host.** `$host` is the host from the request line, or the Host header, or the matching `server_name`, lowercased and with the port stripped. `$http_host` is the raw header including any port. Use `$host` unless the backend genuinely needs the port back. **X-Forwarded-For.** Nginx adds no forwarded header on its own. `$proxy_add_x_forwarded_for` expands to the client's incoming X-Forwarded-For with `$remote_addr` appended, or just `$remote_addr` when the client sent none. `$remote_addr` alone is a useful alternative and is discussed below. **X-Forwarded-Proto.** `$scheme` is `http` or `https` for the connection the client made to nginx. Frameworks use it to decide whether to emit `https://` links, whether to set the Secure cookie flag, and whether to issue an HTTP-to-HTTPS redirect — which is how a missing X-Forwarded-Proto turns into an infinite redirect loop: the app sees http, redirects to https, nginx terminates TLS and proxies as http again. `X-Real-IP` is not standard; it is an nginx convention carrying a single address, convenient because it needs no parsing. ## Nginx setting them is only half the job These are ordinary request headers. The application must be told to trust them, and nearly every framework and app server has an explicit switch for that with a list of trusted proxy addresses. Until that switch is on, the app keeps using the socket peer address. This is the most common reason "I added the headers and nothing changed". ## The inheritance trap `proxy_set_header` directives are inherited from an outer configuration level **only when no `proxy_set_header` directive is defined at the current level**. Adding one header inside a `location` therefore discards every header set in the enclosing `server` or `http` block: ```nginx server { proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; location /api/ { proxy_set_header X-Api-Key $api_key; # Host and X-Forwarded-Proto are now gone here proxy_pass http://backend; } } ``` The robust pattern is to put the common set in a separate file and `include` it in each location that proxies, so the full set is always re-declared. ## Related mechanics worth knowing Setting a header to the empty string removes it from the proxied request: `proxy_set_header Accept-Encoding "";` is the standard way to stop backends compressing responses you want nginx to post-process. And `proxy_pass_request_headers off;` stops the client's headers being forwarded at all, leaving only what you set explicitly. ## What a good answer sounds like Name the three headers, say what each one unblocks in the application, state that nginx's Host default is `$proxy_host` and that no forwarded header is added automatically, and finish by pointing out that the backend must be configured to trust the headers. That is the complete loop; stopping at "copy these three lines" is the shallow version.