reverseproxy: fix X-Forwarded-* headers for Unix socket requests

[XYenon]

This is a follow-up improvement to #7265, which added trusted_proxies_unix support at the server layer.

Problem

While #7265 correctly determines trust status for Unix domain socket connections in determineTrustedProxy, the reverse_proxy module's addForwardedHeaders function does not account for this case. When RemoteAddr is "@" (Unix socket), net.SplitHostPort fails, causing all X-Forwarded-For, X-Forwarded-Proto, and X-Forwarded-Host headers to be unconditionally stripped — even when the connection is trusted via trusted_proxies_unix.

This means upstream applications behind a reverse_proxy directive never receive forwarded headers when Caddy itself listens on a Unix socket.

Fix

Check for Unix socket connections (RemoteAddr == "@") before attempting SplitHostPort:

• If the connection is trusted (already determined by the server layer via trusted_proxies_unix), preserve existing X-Forwarded-* headers from trusted proxies.
• If the connection is not trusted, strip the headers as before for security.

Tests

Added three test cases in headers_test.go:

• TestAddForwardedHeaders_UnixSocketTrusted — trusted Unix socket with existing headers are preserved
• TestAddForwardedHeaders_UnixSocketUntrusted — untrusted Unix socket has headers stripped
• TestAddForwardedHeaders_UnixSocketTrustedNoExistingHeaders — trusted Unix socket with no prior headers falls back to defaults

Assistance Disclosure

Amp (Claude) identified the bug, generated the fix and tests. I reviewed and verified the code is correct.

[francislavoie]

FYI @cseufert

[cseufert]

Yer, this looks good. I wonder how i missed this, although I think fast-cgi/php uses the client ip not the XFF header

LGTM

[mholt]

Thank you for the patch!