Feature Request : Enable X-Forwarded Headers by Default with an Option to Disable per Application #14

New Issue

adam · 2025-12-29T09:21:40+01:00

adam commented

2025-12-29 09:21:40 +01:00

Originally created by @arevindh on GitHub (Sep 30, 2024).

Currently, go-proxy only adds X-Forwarded-* headers (e.g., X-Forwarded-For, X-Forwarded-Proto, X-Forwarded-Host) when explicitly enabled via Docker labels. These headers are crucial for many applications running behind a reverse proxy to correctly identify the original client IP, protocol, and host, especially when used in combination with Docker.

Request:

Enable the inclusion of X-Forwarded-* headers by default.

Reasoning:

The X-Forwarded-* headers are essential in reverse proxy setups for several reasons:

Client IP Identification:
Applications often use the X-Forwarded-For header to obtain the real client's IP address, rather than the internal IP address of the reverse proxy. This is particularly important for features such as:
- Logging and audit trails
- Rate limiting
- Geolocation services
- Authentication mechanisms based on the user's IP address
Correct URL and Protocol Handling:
Many web applications rely on the X-Forwarded-Proto and X-Forwarded-Host headers to determine the original protocol (http vs. https) and host requested by the client, allowing them to:
- Construct correct absolute URLs for redirects
- Handle SSL termination properly
- Display proper canonical URLs to users

Popular Proxies:

It is worth noting that other widely used reverse proxies, such as Traefik, Caddy, and NGINX Proxy Manager, enable X-Forwarded-* headers by default.

Traefik: Automatically adds these headers when proxying HTTP requests.
Traefik documentation on forwarded headers
Caddy: The reverse proxy feature adds X-Forwarded-* headers by default.
Caddy documentation on reverse proxy defaults

This is a widely adopted practice in the proxy world as it provides transparency about the client's real information to the application being proxied.

Example Usage:

For instance, web frameworks such as Flask, Express, or Django often utilize middleware or configuration to parse these headers to find the real user's IP behind a proxy.

Flask: Uses X-Forwarded-For with a configuration setting called ProxyFix.
Django: Uses the X-Forwarded-For header to obtain the client IP behind proxies when configured.
Express (Node.js): It uses X-Forwarded-For to obtain the correct IP if the app is behind a proxy.

Proposal:

Change the default behavior of go-proxy to automatically include X-Forwarded-* headers unless explicitly disabled.
Provide a label option to disable these headers on a per-application basis, allowing users flexibility if they have different requirements.

Please consider this enhancement for a future release as it would provide a more seamless experience for users running applications behind a reverse proxy.

Thank you!

Originally created by @arevindh on GitHub (Sep 30, 2024). Currently, `go-proxy` only adds `X-Forwarded-*` headers (e.g., `X-Forwarded-For`, `X-Forwarded-Proto`, `X-Forwarded-Host`) when explicitly enabled via Docker labels. These headers are crucial for many applications running behind a reverse proxy to correctly identify the original client IP, protocol, and host, especially when used in combination with Docker. ### Request: **Enable the inclusion of `X-Forwarded-*` headers by default.** ### Reasoning: The `X-Forwarded-*` headers are essential in reverse proxy setups for several reasons: 1. **Client IP Identification:** Applications often use the `X-Forwarded-For` header to obtain the real client's IP address, rather than the internal IP address of the reverse proxy. This is particularly important for features such as: - Logging and audit trails - Rate limiting - Geolocation services - Authentication mechanisms based on the user's IP address 2. **Correct URL and Protocol Handling:** Many web applications rely on the `X-Forwarded-Proto` and `X-Forwarded-Host` headers to determine the original protocol (`http` vs. `https`) and host requested by the client, allowing them to: - Construct correct absolute URLs for redirects - Handle SSL termination properly - Display proper canonical URLs to users ### Popular Proxies: It is worth noting that other widely used reverse proxies, such as **Traefik**, **Caddy**, and **NGINX Proxy Manager**, enable `X-Forwarded-*` headers by default. - **Traefik:** Automatically adds these headers when proxying HTTP requests. [Traefik documentation on forwarded headers](https://doc.traefik.io/traefik/getting-started/faq/#what-are-the-forwarded-headers-when-proxying-http-requests) - **Caddy:** The reverse proxy feature adds `X-Forwarded-*` headers by default. [Caddy documentation on reverse proxy defaults](https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults) This is a widely adopted practice in the proxy world as it provides transparency about the client's real information to the application being proxied. ### Example Usage: For instance, web frameworks such as Flask, Express, or Django often utilize middleware or configuration to parse these headers to find the real user's IP behind a proxy. - **Flask:** Uses `X-Forwarded-For` with a configuration setting called `ProxyFix`. - **Django:** Uses the `X-Forwarded-For` header to obtain the client IP behind proxies when configured. - **Express (Node.js):** It uses `X-Forwarded-For` to obtain the correct IP if the app is behind a proxy. ### Proposal: - **Change the default behavior** of `go-proxy` to **automatically include `X-Forwarded-*` headers** unless explicitly disabled. - Provide a **label option to disable** these headers on a per-application basis, allowing users flexibility if they have different requirements. --- Please consider this enhancement for a future release as it would provide a more seamless experience for users running applications behind a reverse proxy. Thank you!

adam closed this issue

2025-12-29 09:21:40 +01:00

adam commented

2025-12-29 09:21:40 +01:00

@yusing commented on GitHub (Sep 30, 2024):

ebedbc931f

@yusing commented on GitHub (Sep 30, 2024): ebedbc931f69992453279b4625a35fbad81895e0

Sign in to join this conversation.