Invalid auth shows wrong IP address

Configuration
1

When I get “Login attempt or request with invalid authentication” nothifications, the IP address displayed is of my tunnel containers docker network IP (172.22.0.11), despite my docker network being listed in trusted_proxies.

ssh tunnel (container) → caddy (container) → HA (container, network_mode: host)

From the caddy log (“ipv6 address” is what should be displayed):

{
    "request": {
        "remote_ip": "172.22.0.11",
        "client_ip": "172.22.0.11",
        "host": "home.mydomain.com",
        "uri": "/auth/login_flow/7b2138901b4e8b463abdc78bce48d869",
        "headers": {
            "Cf-Connecting-Ip": [
                "<ipv6 address>"
            ],
            "Origin": [
                "https://home.mydomain.com"
            ],
            "X-Forwarded-For": [
                "<ipv6 address>"
            ]
        }
    }
}
Full Caddy log entry 
{
    "level": "info",
    "ts": 1774620546.8215609,
    "logger": "http.log.access",
    "msg": "handled request",
    "request": {
        "remote_ip": "172.22.0.11",
        "remote_port": "37642",
        "client_ip": "172.22.0.11",
        "proto": "HTTP/1.1",
        "method": "POST",
        "host": "home.mydomain.com",
        "uri": "/auth/login_flow/7b2138901b4e8b463abdc78bce48d869",
        "headers": {
            "Cdn-Loop": [
                "cloudflare; loops=1"
            ],
            "Cf-Connecting-Ip": [
                "<ipv6 address>"
            ],
            "Origin": [
                "https://home.mydomain.com"
            ],
            "X-Forwarded-For": [
                "<ipv6 address>"
            ],
            "Accept-Encoding": [
                "gzip, br"
            ],
            "Cf-Ipcountry": [
                "redacted"
            ],
            "Sec-Fetch-Mode": [
                "cors"
            ],
            "Cf-Visitor": [
                "{\"scheme\":\"https\"}"
            ],
            "Accept-Language": [
                "en;q=0.9"
            ],
            "Priority": [
                "u=0"
            ],
            "Sec-Fetch-Dest": [
                "empty"
            ],
            "Sec-Fetch-Site": [
                "same-origin"
            ],
            "Sec-Gpc": [
                "1"
            ],
            "Content-Length": [
                "73"
            ],
            "X-Forwarded-Host": [
                "home.mydomain.com"
            ],
            "Accept": [
                "*/*"
            ],
            "X-Forwarded-Proto": [
                "https"
            ],
            "Cf-Ray": [
                "redacted"
            ],
            "Content-Type": [
                "text/plain;charset=UTF-8"
            ],
            "User-Agent": [
                "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0"
            ]
        }
    },
    "bytes_read": 73,
    "user_id": "",
    "duration": 0.50569145,
    "size": 223,
    "status": 200,
    "resp_headers": {
        "Content-Type": [
            "application/json"
        ],
        "Referrer-Policy": [
            "no-referrer"
        ],
        "Server": [
            ""
        ],
        "Content-Length": [
            "223"
        ],
        "Date": [
            "Fri, 27 Mar 2026 14:09:06 GMT"
        ],
        "X-Content-Type-Options": [
            "nosniff"
        ],
        "Via": [
            "1.1 Caddy"
        ],
        "X-Frame-Options": [
            "SAMEORIGIN"
        ],
        "Content-Encoding": [
            "gzip"
        ]
    }
}

And my http config:

http:
  use_x_forwarded_for: true
  trusted_proxies:
    - 172.22.0.0/16
    - 127.0.0.1
    - ::1
  ip_ban_enabled: true
  login_attempts_threshold: 10

I thought the trusted_proxies would mean that Caddy’s X-Forwared-For header was “trusted”. Is my configuration wrong or does HA not used the forwarded for header?

2

The logs will probably register the IP address the login attempt is coming from, ie. The Caddy Docker container.
The X-forward header is to proxy relaying the information about the remote connection, which is not used in the log entry.

Your entry probably is working, but the logs report other information than what you expected. It is not wrong, just different.

3

You’re right, it does look like it just uses the remote and not the forwarded-for