docker compose 不支持原生单容器带宽限制，需通过 tc 工具在容器网络命名空间或宿主机 veth 设备上手动配置限速、延迟等流量整形规则，或使用代理容器间接实现。

在 Docker Compose 中，无法直接通过 docker-compose.yml 文件原生配置单容器的网络带宽限制或流量整形（如限速、延迟、丢包等）。Docker 本身支持通过 --network-mode=bridge 下的 docker run 参数（如 --limit-bps）实现部分限速，但这些参数 不被 Compose v2+ 原生支持。要实现精准的单容器网卡带宽控制与流量整形，需结合底层 Linux 工具（主要是 tc）和容器网络命名空间操作。

使用 docker-compose 启动容器后手动注入 tc 规则

这是最常用且可控的方式：先让 Compose 创建容器，再进入其网络命名空间，用 tc（traffic control）配置 egress（出向）限速或更复杂的 qdisc（如 netem 模拟延迟/丢包）。

• 确认容器已运行并获取其 PID：
  docker inspect -f '{{.State.Pid}}' <container_name></container_name>
• 进入容器网络命名空间执行 tc 命令（需 root 权限）：
  nsenter -n -t <pid> tc qdisc add dev eth0 root tbf rate 2mbit burst 32kbit latency 400ms</pid>
  → 此例将容器 eth0 出向带宽限制为 2Mbps，使用令牌桶过滤器（tbf）
• 查看规则：
  nsenter -n -t <pid> tc qdisc show dev eth0</pid>
• 清除规则：
  nsenter -n -t <pid> tc qdisc del dev eth0 root</pid>

通过自定义 network 和 host 网络命名空间预设 tc 规则

若需自动化或复用，可将限速逻辑封装进启动脚本，配合 network_mode: "container:<other>"</other> 或 network_mode: "host" 模式，在宿主机上提前对对应网络接口或 veth peer 施加规则。

• Docker 容器 bridge 模式下，每个容器对应一个 veth pair（如 vethabc123 在宿主机，eth0 在容器内），可通过查找 /sys/class/net/veth*/name 或 ip link 匹配容器 IP 定位宿主机端口
• 对宿主机上的 veth 设备直接限速（影响该容器出向）：
  tc qdisc add dev vethabc123 root tbf rate 1mbit burst 20kbit latency 200ms
• 注意：veth 名称随容器重启变化，建议配合 docker network inspect + ip link 脚本自动识别

使用支持 QoS 的 CNI 插件（适用于 Kubernetes 场景，非纯 Compose）

标准 Docker Compose 不集成 CNI，但如果运行在 Kubernetes 上并用 Helm 或 Kustomize 部署（而非 docker-compose），可选用支持带宽限制的 CNI 插件，例如：

• Bandwidth CNI plugin：通过 bandwidth 字段设置 ingressRate / ingressBurst 和 egressRate / egressBurst
• 需配合 multus-cni 多网络或默认 CNI 配置启用，属于集群级方案，不适用于本地 Compose 开发环境

替代方案：用轻量代理容器做流量网关（推荐开发/测试场景）

对单容器做透明限速较复杂时，可在应用容器前加一层限速代理（如 traefik、envoy 或专用工具 wondershaper 容器），通过端口映射+iptables+tc 组合实现逻辑隔离。

• 示例结构：
  应用容器暴露 8080 → 代理容器监听 8080 并限速 → 主机映射代理 8080 到外部
• 代理容器内运行 tc 限制其自身 eth0 出向，即间接限制下游应用出向流量
• 优势：无需操作宿主机网络栈，规则随容器启停，适合 CI/测试环境复现网络条件