How to convert the map and custom log configuration in Nginx to the corresponding configuration in Caddy?

1. The problem I’m having:

How to convert the map and custom log configuration in the following Nginx HTTP configuration block to the corresponding configuration of Caddy and add it to my configuration?

    map $http_x_forwarded_for $clientRealIp {
        "" $remote_addr;
        "~*(?P<firstAddr>([0-9a-f]{0,4}:){1,7}[0-9a-f]{1,4}|([0-9]{1,3}\.){3}[0-9]{1,3})$" $firstAddr;
    }

    log_format main '$clientRealIp $remote_addr $remote_user [$time_local] "$request" '
                    '$status $body_bytes_sent "$http_referer" '
                    '"$http_user_agent" $http_x_forwarded_for '
                    '"$upstream_addr" "$upstream_status" "$upstream_response_time" "$request_time" ';

2. Error messages and/or full log output:

None.

3. Caddy version:

Caddy v2.8.4

4. How I installed and ran Caddy:

a. System environment:

Not relevant.

b. Command:

None.

c. Service/unit/compose file:

Not relevant.

d. My complete Caddy config:

{
	admin off
	log {
		output file /var/log/caddy/access.log
		level ERROR
	}
}

:443, xx.yy {
	tls {
		ciphers TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
		curves x25519 secp521r1 secp384r1 secp256r1
	}

	@host {
		host xx.yy
	}
	route @host {
		header {
			Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
		}
		file_server {
			root /var/www/html
		}
	}
}

5. Links to relevant resources:

Omitted.

You shouldn’t need that map. If you configure trusted_proxies, then client_ip is available in your logs.

Are you sure Caddy’s JSON logs are not sufficient? For custom log formatting, use this plugin: GitHub - caddyserver/transform-encoder: Log encoder module for custom log formats.

I strongly recommend removing all this. Caddy’s defaults are modern and secure. You don’t need to touch cipher and curve config at all.

1 Like

thanks for the reply. I know that Caddy uses trusted_proxies configuration to achieve the map configuration of Nginx, but I still want to get your help: Caddy uses the map configuration to implement the map configuration of Nginx. The reasons are as follows:

  1. The map configuration of the Nginx above is very convenient. There is no need to consider the IP range of the credible proxy server and the possible manual configuration.
  2. Nginx also has the http_realip_module module similar to trusted_proxies, which does not affect the use of the map configuration to implement the http_realip_module function.
  3. Compared tests, choose according to the test.
    The following is an example of unsuccessful map configuration (there is no self -defined log):
{
	admin off
	log {
		output file /var/log/caddy/access.log
		level ERROR
	}
}

:443, xx.yy {
	map {http.request.header.X-Forwarded-For} $clientRealIp {
		"" {remote_host}
		~*(?P<firstAddr>([0-9a-f]{0,4}:){1,7}[0-9a-f]{1,4}|([0-9]{1,3}\.){3}[0-9]{1,3})$ $firstAddr
	}

	@host {
		host xx.yy
	}
	route @host {
		header {
			Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
		}
		file_server {
			root /var/www/html
		}
	}
}

Please guide how to modify the needs, thank you!

Just totally forget about map, it doesn’t apply for what you’re trying to do. It’s not a transferable concept for this.

All you need to do like I said is configure trusted_proxies (see the docs I linked), then Caddy automatically parses X-Forwarded-For and makes it available in your access logs as client_ip.

Remember that you need to use the log directive inside your site for access logs to be enabled. The log global option does not enable access logs, it configures Caddy’s runtime logs.

1 Like

Thanks for the reply again, but I am so disappointed! Finally, let me ask: Even if Caddy uses JSON to configure map, it cannot implement the map configuration of Nginx as above?

Caddy does have the map directive, but what I’m trying to say is there’s no reason for you to try to port that nginx config to Caddy because Caddy has a different mechanism (trusted_proxies) to do the same thing (i.e. parsing X-Forwarded-For), in a much better, properly-integrated way.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.