根本原因是docker desktop在macos/windows上通过linux虚拟机运行容器，宿主机请求经虚拟机网关nat转发，导致容器看到的$remote_addr是虚拟机地址而非真实客户端ip。
容器内部拿不到真实客户端 ip，根本原因不在镜像，而在网络模式和流量路径。镜像是静态模板，不决定运行时网络行为；真正起作用的是容器启动时选用的网络模式，以及代理链中每一层是否正确传递和解析转发头。
关键在 Docker Desktop 的虚拟机网络层
Docker Desktop（macOS/Windows）不是直接跑在宿主机内核上，而是通过轻量 Linux 虚拟机（如 WSL2 或 Hyper-V VM）运行容器。所有来自宿主机或本机浏览器的请求，先进入虚拟机，再经其内部网桥转发到容器。这个过程中，原始源 IP 已被替换为虚拟机网关地址（如 192.168.49.1 或 172.17.0.1），容器看到的 $remote_addr 就是这个地址，不是你本地电脑的真实 IP。
这不是 Nginx 配置漏写 header 就能解决的问题——因为源头就已经丢失了。
三种实用解决路径
1. 改用 host 网络模式（开发调试最快）
启动容器时不走 bridge，直接共享宿主机网络栈：
- 命令示例：
docker run --net=host -p 80:80 nginx - 此时容器内
$remote_addr就是你本机真实 IP（如 192.168.1.100） - 注意：host 模式下端口冲突需自行规避，且不适用于生产环境多容器并存场景
2. 在 Docker Desktop 设置中启用“Use the WSL2 based engine”并配置端口转发（Windows）
确保 WSL2 发行版已更新，Docker Desktop 设置里勾选 WSL2 引擎，并在 WSL2 中执行：
echo -e "[wsl2]\nlocalhostForwarding=true" | sudo tee /etc/wsl.conf- 重启 WSL：
wsl --shutdown，再重开 Docker Desktop - 这样可让宿主机发起的请求更“透明”地抵达容器，配合 Nginx 的
proxy_set_header X-Real-IP $remote_addr;才有实际意义
3. Nginx + 后端双层信任链（推荐用于类生产调试）
即使用了 bridge 模式，也能靠可信头传递还原真实 IP：
- Nginx 配置必须包含：
set_real_ip_from 172.17.0.0/16;<br> set_real_ip_from 192.168.0.0/16;<br> real_ip_header X-Real-IP;<br> real_ip_recursive on;
- 后端应用（如 Node.js）不能只读
X-Forwarded-For最左字段，要结合real_ip_from白名单，只信任来自 Docker 网段的头信息 - 否则容易被伪造，比如前端加个
X-Real-IP: 8.8.8.8就能骗过没校验的后端
别再只盯着镜像和容器日志
很多人反复检查镜像里 Nginx 版本、容器里 netstat -tlnp 输出、甚至重装 Docker Desktop，却忽略了一个事实：问题出在“谁发起了连接”和“连接经过了几层 NAT”。
你可以用这个小验证快速定位：
- 在容器里执行：
curl -v http://host.docker.internal（Docker Desktop 内置 DNS） - 看响应头或服务日志里记录的来源 IP 是什么
- 如果是 192.168.x.x 或 127.0.0.1，说明请求被虚拟机层劫持了；如果是你本机真实 IP，说明网络通路已打通
不复杂但容易忽略
