Pass the IP of the client?

Help
1

1. The problem I’m having:

I want to pass the actual IP address of the client accessing the web server through a reverse proxy. For example, I have software running at 192.168.2.3, and I am trying to access it from 10.1.10.21. The web server is seeing the IP of the Caddy server (10.1.10.252) instead of 10.1.10.21.

2. Error messages and/or full log output:

N/A

3. Caddy version:

2.8.4 h1

4. How I installed and ran Caddy:

Fresh install of Ubuntu 24.04. Caddy installed using apt.

a. System environment:

Ubuntu 24.04 on AMD64 CPU

b. Command:

I feel like I have googled and tried so many things, but none seem to work, or in some cases, the caddy service won’t start.

c. Service/unit/compose file:

N/A

d. My complete Caddy config:

{
        email swittwer@xxxxxxxxxxxxl.com
}

#log file procedure
(logging) {
        log {
                output file /var/log/caddy/{args[0]}.log {
                        roll_size 5MiB # Set max size 5 MB
                        roll_keep 2 # Keep at most 2 log files
                        roll_keep_for 96h # Keep log files for 4 days
                }
        }
}
catalina.xxxxxxxxxxxx.com {
        import logging catalina
        reverse_proxy 192.168.2.3:443 {
        transport http {
                tls
                tls_insecure_skip_verify
        }
    }
}

5. Links to relevant resources:

2

Caddy sets X-Forwarded-For by default. Your upstream software needs to take this into account.

https://caddyserver.com/docs/caddyfile/directives/reverse_proxy#defaults

1 Like
3

Sorry, I don’t have a clue what that means.

4

The X-Forwarded-For header is what passes the IP address of the client.

The docs I linked earlier have a further link to a pretty good resource to read more about it: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Forwarded-For

Your software running at 192.168.2.3 already has access to this information as Caddy sets this header without you having to configure anything. You might have to consult the documentation for your software to determine whether and how it can properly use it.

5

Look at the example

Reverse proxy

    reverse_proxy URL(http:// https:// domain and specyfi port) {
            header_up Host {host}
            header_up X-Real-IP {remote_host}
            header_up X-Forwarded-For {remote_host}
            header_up X-Forwarded-Port {server_port}

            transport http {
                    versions 2
                    keepalive 65s
            }
    }

.

6

header_up Host {host}

Redundant, remove this.

header_up X-Real-IP {remote_host}

Not likely to be relevant. Your upstream software may specifically require it - check said software’s documentation - otherwise, it’s a waste of bytes.

header_up X-Forwarded-For {remote_host}

Redundant, remove this.

header_up X-Forwarded-Port {server_port}

Probably not relevant either - once again, unless your upstream software specifically needs it. The vast vast majority will not, making this another waste of bytes in most cases.

            transport http {
                    versions 2
                    keepalive 65s
            }

Not relevant to the topic of passing the client IP.

1 Like
7

I spoke with our developer, and the concern is it can be faked, but he does have access to the header. but we need to think through this.

8

From here

By default, Caddy passes through incoming headers—including Host—to the backend without modifications, with three exceptions:

For these X-Forwarded-* headers, by default, the proxy will ignore their values from incoming requests, to prevent spoofing.

1 Like