当 Docker 代理服务（如 EC2 元数据代理）需识别真实调用容器的 IP 地址时，因默认 bridge 网络导致源 IP 被替换为 docker0 网关地址；解决方案是启用 --net=host 模式，使容器直接复用宿主机网络命名空间，从而完整保留原始 TCP 连接的源 IP。
当 docker 代理服务（如 ec2 元数据代理）需识别真实调用容器的 ip 地址时，因默认 bridge 网络导致源 ip 被替换为 docker0 网关地址；解决方案是启用 `--net=host` 模式，使容器直接复用宿主机网络命名空间，从而完整保留原始 tcp 连接的源 ip。
在基于 Docker 的多租户 IAM 角色隔离场景中（例如 AWS EC2 上运行多个应用容器，每个需绑定不同 IAM 角色），常通过自建元数据代理（如 docker-ec2-metadata）拦截对 169.254.169.254 的请求，并根据调用者身份动态返回对应角色凭证。该机制高度依赖准确识别发起请求的容器真实 IP 地址——因为代理需通过该 IP 查询 Docker Engine，进而获取容器启动时注入的 IAM_ROLE 环境变量。
然而，在默认 bridge 网络模式下部署代理容器时，会出现关键问题：所有来自业务容器的请求经 iptables DNAT 重定向至代理端口后，再经 Docker 内置的 NAT 层转发到容器内，此时代理进程 accept() 到的 socket 远端地址不再是原始容器 IP（如 172.17.0.7），而是 Docker 网桥接口 docker0 的网关地址（通常是 172.17.0.1 或 172.17.42.1）。这导致代理无法区分 containerA 与 containerB，丧失角色路由能力。
根本原因在于：Docker 的 bridge 网络本质是通过 iptables + netfilter 实现的二层隔离+三层 NAT，它在转发入站流量时执行了 SNAT（Source NAT）或连接跟踪伪装，隐藏了原始源 IP。
✅ 正确解法：使用 --net=host 启动代理容器
该模式使容器跳过 Docker 网络栈，直接共享宿主机的网络命名空间。此时：
- 容器内进程监听 0.0.0.0:18000 即等同于宿主机监听；
- iptables DNAT 规则重定向后的连接，其 SOCKADDR_IN.sin_addr 将真实反映发起容器的 IP（如 172.17.0.7）；
- 代理可直接调用 Docker API（通过挂载的 /var/run/docker.sock）反查该 IP 对应的容器元数据。
示例启动命令：
docker run -d \ --name ec2-metadata-proxy \ --net=host \ -v /var/run/docker.sock:/var/run/docker.sock \ -e PROXY_PORT=18000 \ dump247/docker-ec2-metadata
⚠️ 注意事项：
- --net=host 意味着容器不拥有独立网络栈，端口绑定直接作用于宿主机，需确保 PROXY_PORT（如 18000）未被其他进程占用；
- 容器内 localhost 指向宿主机，/etc/hosts 不包含自动注入的容器别名，需避免硬编码 localhost 作内部通信；
- 该模式削弱了网络隔离性，仅推荐用于可信、基础设施级系统组件（如元数据代理、监控采集器），切勿用于业务应用容器；
- 在 CoreOS 或其他容器化 OS 上，需确认 docker0 接口已启用且 iptables 规则由宿主机环境（而非容器）加载（即规则需在 host 网络上下文中生效）。
? 补充建议：若因安全策略限制无法使用 host 网络，可考虑替代方案——改用 macvlan 或 ipvlan 网络驱动，为代理容器分配与业务容器同网段的真实 IP，再配合 --ip 和精细 iptables 规则实现源 IP 透传，但复杂度显著升高，运维成本增加。
综上，--net=host 是解决 Docker 容器内服务需精确感知调用方原始 IP 这一经典问题的最简、最可靠方案，其核心价值在于绕过 Docker 默认网络抽象层，回归 Linux 原生网络语义，让 getpeername() 返回真实源地址。
