在 Docker 中部署元数据代理（如 EC2 IAM 角色代理）时，若代理自身也运行于容器内，默认 bridge 网络会导致原始请求的源 IP 被替换为 docker0 网桥地址；启用 --net=host 可使代理直接复用宿主机网络栈，从而准确识别调用容器的真实 IP。
在 docker 中部署元数据代理（如 ec2 iam 角色代理）时，若代理自身也运行于容器内，默认 bridge 网络会导致原始请求的源 ip 被替换为 docker0 网桥地址；启用 `--net=host` 可使代理直接复用宿主机网络栈，从而准确识别调用容器的真实 ip。
在基于 AWS EC2 的容器化架构中，常需为不同应用容器分配独立 IAM 角色。由于原生 EC2 实例元数据服务（http://169.254.169.254）仅返回实例级凭证，无法区分容器身份，因此社区常用方案是部署一个反向代理（如 docker-ec2-metadata），通过 iptables 重定向元数据请求，并依据调用方容器 IP 动态返回对应角色凭证。
然而，当该代理本身也以普通 Docker 容器方式运行（例如 docker run -p 18000:18000 ...）时，会遭遇关键网络限制：所有经 docker0 桥接转发的流量，在抵达代理容器时，其 TCP 连接的远端地址（RemoteAddr）均被 NAT 为 docker0 接口 IP（如 172.17.0.1），而非原始发起容器的真实 IP（如 172.17.0.7）。这导致代理无法通过 IP 查找容器元数据（如 IAM_ROLE 环境变量），身份路由逻辑完全失效。
根本原因在于 Docker 默认的 bridge 网络模式会在容器与宿主机之间插入一层网络地址转换（NAT），隐藏了原始客户端 IP。而 --net=host 模式可彻底绕过该层——它让容器直接共享宿主机的网络命名空间，不创建独立网络栈，iptables 规则所捕获的连接将保留原始源 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 意味着容器内监听的端口（如 :18000）即宿主机端口，不可与其他进程冲突；
- 容器内 localhost 指向宿主机，/proc/net/、ip addr 等均反映宿主机状态；
- 需确保容器具备访问 Docker Socket 的权限（生产环境建议使用更安全的 socket 访问控制或专用用户）；
- 若宿主机启用了防火墙（如 firewalld 或 ufw），需放行目标端口（如 18000/tcp）并确认 iptables PREROUTING 规则优先级未被覆盖；
- 在 Kubernetes 或其他编排平台中，hostNetwork: true 提供等效能力，但需配合 Pod 安全策略（PSP）或 Pod Security Admission 控制权限。
? 补充验证方法：
可在代理容器内运行以下命令，确认是否看到真实容器 IP：
# 启动一个测试容器发起请求
docker run --rm curlimages/curl curl -s -o /dev/null -w "%{remote_ip}\n" http://169.254.169.254/latest/meta-data/iam/security-credentials/同时在代理日志或调试端点中打印 http.Request.RemoteAddr，应输出类似 172.17.0.7:52341 而非 172.17.0.1:xxx。
综上，--net=host 并非“权宜之计”，而是解决此类透明代理场景下源 IP 透传问题的标准且可靠方案。它平衡了容器化部署的便利性与网络可见性的刚性需求，是构建多租户、细粒度权限控制容器基础设施的关键一环。
