docker compose 中守护进程网络策略核心是“服务归属网络+显式多网接入”：定义 backend、monitoring、internal_db 等语义化网络，禁用默认网络；agent 类服务仅接入 monitoring，需主动访问业务时才显式双接入，并配合 dns 隔离、healthcheck 与端口绑定加固。
在 docker-compose.yml 中配置守护进程（如监控 Agent、日志采集器等）的网络策略，核心不是写防火墙规则，而是通过 **服务归属网络 + 显式多网接入** 实现“默认拒绝、按需放行”的访问控制。它天然阻断未声明的跨网通信，比 iptables 更轻量、更可靠。
定义职责清晰的专用网络
先在 networks 区块中创建语义明确的网络，每个网络代表一个安全边界：
- backend：业务服务间调用网络（如 user-service、order-service）
- monitoring：仅给 Prometheus、Grafana、Telegraf 等守护进程使用
- internal_db：数据库专属网络，不暴露给任何前端或外部组件
- 禁用默认网络（不写
default或不引用bridge），避免隐式互通
让守护进程只连它该连的网络
Agent 类服务（如 Telegraf、Fluentd、Node Exporter）通常只需单向采集，不需要主动调用业务 API。因此它的 networks 列表应严格限定：
- 只加入
monitoring—— 用于上报指标到 Prometheus - 如需读取容器元数据（例如挂载
/var/run/docker.sock），仍走 host 网络或保持隔离，不加 backend - 绝对不要让它同时出现在
backend和monitoring—— 这等于开了后门，业务服务可能反向调用 Agent 接口
需要跨网通信时，必须显式双接入
只有当守护进程确实要主动访问某个业务服务（比如 Agent 调用健康检查端点），才允许它加入两个网络，并且必须在服务定义中明确写出：
agent:
image: telegraf:latest
networks:
- monitoring
- backend # ← 关键：显式声明，否则无法访问 backend 内任何服务
environment:
- AGENT_MODE=service
此时 agent 才能通过服务名（如 web:8080）访问 backend 网络中的服务；但 backend 中其他服务仍无法反向访问 agent，因为它们没加入 monitoring 网络。
配合 DNS 隔离与健康检查加固边界
自定义网络自带 DNS 隐式隔离 —— 容器只能解析同网络内的服务名。再叠加以下配置可进一步收紧：
- 为 agent 设置
healthcheck，防止假死导致误判通信状态 - 用
depends_on控制启动顺序，但注意它不保证依赖服务“就绪”，需配合应用层重试 - 避免在 agent 中暴露管理接口（如
/debug/pprof），如有必要，用ports仅绑定到127.0.0.1宿主机地址
