Caddy 配了 trusted_proxies，remote_ip 仍是 Cloudflare：看 client_ip 字段

Caddy 放在 Cloudflare 或其他反向代理后面，已经配置 trusted_proxies，访问日志却仍把代理地址写在 remote_ip。如果同一条请求的 client_ip 已是访客地址，先确认读取的是哪一个字段，不要因为 remote_ip 没变就扩大信任范围。

Caddy 的可信代理配置用于判断能否从请求头提取客户端地址。连接端看到的远端地址与解析出的客户端地址可以同时保留；代理确实在与 Caddy 建立连接时，日志中出现它的地址有实际意义。本文针对 Caddy 2 的普通 HTTP 代理链；使用 PROXY protocol 的部署，还要核对该协议提供的地址及独立信任边界。

同一条日志里比较两个字段

以下只是用于解释字段的示例，地址使用文档保留网段：

{
  "request": {
    "remote_ip": "192.0.2.10",
    "client_ip": "198.51.100.20"
  }
}

在这里，192.0.2.10 是请求进入 Caddy 的代理连接地址，198.51.100.20 是通过可信代理规则得到的客户端地址。日志分析或访问规则需要访客地址时，应选择对应的 client_ip，而不是要求 remote_ip 被覆盖。

如果两项都显示代理地址，才继续检查信任规则、请求头及实际链路。不要只在自己浏览器里看到公网 IP，就认定日志中的其他地址错误；还要核对请求是否经过了预期代理、Docker 网络转发或隧道入口。

信任的是实际代理连接，不能只信任一个头的名字

Caddy 默认不信任任何代理。配置后，仅当请求来自受信任的代理地址时，才按指定的头解析客户端地址；未受信任请求的客户端地址采用连接端地址，或已配置的 PROXY protocol 地址。

下面是结构示例，假设只有受控代理 192.0.2.10 会向 Caddy 转发 HTTP 请求，并使用 X-Forwarded-For：

{
    servers {
        trusted_proxies static 192.0.2.10/32
        trusted_proxies_strict
        client_ip_headers X-Forwarded-For
    }
}

这个地址必须替换成部署中的真实可信代理，不能直接用于 Cloudflare。Cloudflare 回源应维护它实际使用的官方地址范围，包括适用的 IPv4、IPv6；中间还有另一层代理或隧道时，则先确认 Caddy 真正收到连接的入口和该入口如何清理、传递头字段。

private_ranges 会信任整组私有网段，不等于“只信任我自己的一个 Docker 容器”。共享网络或其他可接入者可能进入这些范围，不能为了让显示变正确就信任所有私有地址，更不能改成信任所有公网地址。

client_ip_headers 多个候选按顺序取第一个非空字段。使用 Cloudflare 提供的访客地址头时，应先确认只有可信回源入口能传递它，并按实际部署核对字段；简单把更多头名加入列表，并不会让结果更可信。

X-Forwarded-For 链要按可信边界解析

某些代理向 X-Forwarded-For 右侧追加连接地址，左侧内容可能原本就由访客提交。Caddy 2.8 起支持 trusted_proxies_strict，从右向左解析这类地址链，找到第一个不在可信代理范围中的地址。默认的兼容行为仍是从左向右。

启用前确认使用的 Caddy 版本、各层代理的行为和信任范围。不能因为选了 strict，就省去对入口的验证；它也不会修复上游已经丢失或错误覆盖的地址头。

访问规则也应选对匹配器：按提取出的访客地址判断时使用 client_ip，按直接远端地址判断时使用 remote_ip。把一个需要校验代理入口的规则全部替换成访客地址规则，可能改变原有访问限制，应逐条说明规则目的后再改。

应用里的地址字段需要另行核对

Caddy 日志已有正确 client_ip，不代表 PHP 的 REMOTE_ADDR 或其他应用框架会自动采用同一个值。先看当前 Caddy 版本和 FastCGI、HTTP 代理实际传给应用的内容，再按框架支持的可信代理配置处理。

不要在应用里无条件把 X-Forwarded-For 第一项或 CF-Connecting-IP 当作用户身份。绕过代理直接访问应用的请求，可能自行构造这些头；地址恢复也不应替代认证。

修改前保存 Caddyfile、应用代理配置和原访问规则，校验后按正常方式加载。验收至少覆盖一条经过预期代理的请求，以及一条不受信任入口携带伪造地址头的受控检查：前者得到预期访客地址，后者不能通过头字段改变可信身份。还要检查原有访问限制和日志分析。

出现异常时恢复原配置和规则，保留两类地址及必要日志供比较。不要为了统一字段外观删除连接地址，它还能帮助定位流量究竟从哪一层进入。