2. Docker 网络基础与鉴权流量路径
在 Docker 部署环境中，中间件鉴权拦截的故障排查高度依赖对底层网络模型的理解。鉴权请求从外部客户端到达容器内的中间件服务，再转发至后端应用，其流量路径由 Docker 网络模式决定。本章将系统梳理三种核心网络模式、容器间通信原理，并绘制鉴权请求的完整流量路径图。
2.1 Docker 网络模式对比
Docker 提供多种网络驱动，生产环境中最常用的是 bridge、host 和 overlay 三种模式。它们在隔离性、性能、跨主机通信能力上存在显著差异，直接影响鉴权拦截器的部署位置和流量可见性。
| 特性 | Bridge（默认） | Host | Overlay |
|---|---|---|---|
| 网络隔离 | 容器拥有独立网络命名空间 | 容器共享宿主机网络栈 | 跨主机虚拟网络，容器独立命名空间 |
| 端口映射 | 需 -p 显式映射 | 直接暴露宿主机端口 | 通过 ingress 或 LB 暴露 |
| 性能损耗 | 低（NAT 转换） | 无（零损耗） | 中（VXLAN 封装） |
| 跨主机通信 | 不支持（需额外方案） | 不支持（依赖宿主机网络） | 原生支持 |
| 鉴权拦截影响 | 流量经过 docker-proxy 和 iptables | 流量直通，无中间层 | 流量经过 VXLAN 隧道和负载均衡 |
故障排查提示： 在 bridge 模式下，如果鉴权拦截器返回 403 但客户端 IP 显示为 docker-proxy 的 IP（172.17.0.1），说明需要配置
proxy_protocol 或 X-Forwarded-For 头传递真实客户端地址。host 模式下则无此问题。
2.2 容器间通信原理
容器间通信是鉴权流量路径的核心环节。无论使用哪种网络模式，容器间通信都遵循以下基本原则：
- 同网络桥接通信： 同一 bridge 网络下的容器通过 Docker DNS（127.0.0.11）解析容器名，直接通过 IP 通信，不经过宿主机端口映射。
- 跨网络通信： 不同 bridge 网络下的容器必须通过宿主机 IP + 映射端口或加入同一 overlay 网络才能通信。
- overlay 网络通信： 容器通过 VXLAN 隧道封装数据包，由分布式 KV 存储（如 etcd）维护路由表。
鉴权拦截关键点： 在微服务架构中，鉴权中间件（如 OAuth2 Proxy、Envoy 外部授权）通常部署在 ingress 网关之后。容器间通信时，鉴权请求的源 IP 可能是上游代理的容器 IP，而非真实客户端 IP。此时需要中间件支持
X-Forwarded-For 或 Forwarded 头解析。
2.3 鉴权请求的完整流量路径图
下图展示了在 Docker bridge 网络模式下，一个典型的鉴权请求从外部客户端到后端服务的完整流量路径。图中标注了每个网络跳转点可能出现的故障位置。
2.4 Overlay 模式下的鉴权流量路径
在 Swarm 或 Kubernetes 等编排环境中，overlay 网络是跨主机通信的标准方案。下图展示了 overlay 模式下鉴权请求的流量路径，重点标注了 VXLAN 封装/解封装和分布式负载均衡环节。
2.5 鉴权流量路径关键检查清单
在排查鉴权拦截故障时，建议按以下清单逐层检查网络路径：
- 外部可达性： 确认宿主机端口是否监听（
ss -tlnp | grep :port），iptables 规则是否允许入站流量。 - docker-proxy 状态： 检查 docker-proxy 进程是否运行，端口映射是否生效（
docker port <container>）。 - 容器内网络： 进入容器验证本地端口监听（
docker exec <container> netstat -tlnp），确认鉴权中间件绑定在 0.0.0.0 而非 127.0.0.1。 - DNS 解析： 测试容器间通过容器名通信是否正常（
docker exec <container> ping <other_container_name>）。 - overlay 隧道： 检查 VXLAN 接口状态（
ip -d link show <vxlan_iface>），确认 MTU 一致性。 - 客户端 IP 传递： 在鉴权中间件日志中检查
X-Forwarded-For头是否包含真实客户端 IP，而非代理 IP。
常见陷阱： 在 bridge 模式下，如果容器内鉴权中间件配置了
--proxy-protocol 但前端 nginx 未启用 proxy_protocol，会导致连接被重置。反之亦然。务必确保两端协议配置一致。