bridge网络仅提供基础连通性，不支持服务网格的精细化流量控制；真正实现该能力的是sidecar代理（如envoy）与控制平面协同，通过iptables或容器网络共享将流量重定向至sidecar，使其接管所有服务间通信。
Bridge 网络本身不支持服务网格所需的精细化流量控制，它只是 Docker 默认的单机网络模式，负责容器与宿主机之间的基础连通。真正实现精细化流量控制的是服务网格（如 Istio）的数据平面（Sidecar 代理）和控制平面协同工作，而 Bridge 网络仅作为底层通信通道之一——它不参与路由决策、策略执行或协议解析。
要让 Bridge 网络“配合”服务网格发挥作用，关键在于：不让 Bridge 网络直接承载服务间通信，而是通过 Sidecar 拦截并接管所有进出容器的流量。这样，即使容器运行在 Bridge 网络上，实际的服务治理逻辑仍由 Envoy 等代理完成。
流量必须经过 Sidecar
在 Kubernetes 或 Docker Compose 环境中部署服务网格时，需确保每个业务容器都伴随一个 Sidecar 容器（如 Envoy）。通过iptables规则或--net=container:方式，将容器的入站/出站流量重定向至 Sidecar 的监听端口（如 15001/15006），从而绕过 Bridge 网络的原始转发路径。Bridge 网络只负责“可达”，不负责“可控”
Bridge 模式下，容器可通过docker0网桥互相 ping 通，但这只是 L3 连通性；服务网格的灰度发布、mTLS 认证、超时重试等能力，全部依赖 Sidecar 对 HTTP/gRPC 流量的深度解析与干预，与 Bridge 无关。Bridge 不适合跨主机场景，需配合其他网络层
若服务分布在多台物理机上，仅靠 Bridge 网络无法互通。此时需叠加 Kubernetes CNI 插件（如 Calico、Cilium）或使用 overlay 网络（如 Flannel VXLAN），再在其上部署服务网格。服务网格不感知底层是 Bridge 还是 Overlay，只要网络层能保证 Pod/IP 可达，Sidecar 就能正常工作。调试时注意 Bridge 的干扰项
本地开发用 Docker + Bridge 搭建简易 Mesh 环境时，容易误以为“容器能 curl 通就代表服务网格生效”。其实，若未正确注入 iptables 规则或 Sidecar 未启动，请求会直连目标容器，跳过所有治理逻辑。验证方式是：检查 Envoy admin 页面（curl localhost:15000/config_dump）是否包含对应路由规则，而非仅看网络连通性。
不复杂但容易忽略
