docker默认bridge网络允许容器访问宿主机127.0.0.1，存在安全风险；需通过--network none、netns操作禁用lo、iptables拦截或macvlan隔离等多层手段阻断。
Docker 默认的 bridge 网络不会切断容器对宿主机 127.0.0.1 的访问——这是个常被忽略的安全盲区。容器内执行 curl http://127.0.0.1:8080，若宿主机本地服务监听在 0.0.0.0，该请求可能成功穿透，因为流量未经过 docker0 网桥，而是走 host 网络栈的 loopback 路径。
要真正阻断容器访问宿主机本地回环，需从两个层面入手：网络命名空间隔离 + 内核路由控制，而非仅依赖 Docker 原生参数。
容器启动时禁用 host-loopback 访问（推荐）
Docker 本身不提供 --disable-host-loopback 这类直接开关，但可通过以下组合实现等效效果：
- 使用
--network none启动容器，再手动注入受限网络栈 - 或使用
--cap-drop=NET_ADMIN --read-only配合自定义 entrypoint 屏蔽 loopback 路由
更实用的是：
docker run -d \ --network none \ --cap-drop=ALL \ --read-only \ --tmpfs /run --tmpfs /tmp \ -v /dev/null:/etc/hosts \ nginx
此时容器无任何网络接口，包括 lo（除非显式启用）。若需基础网络但排除 127.0.0.1 访问，继续看下一项。
通过 network namespace 操作移除或重置 lo 接口
容器启动后进入其 netns，可主动删除或禁用 lo 的默认行为：
# 获取容器 PID
PID=$(docker inspect -f '{{.State.Pid}}' <container_name>)
# 进入该容器的网络命名空间并关闭 lo 的回环转发
nsenter -t $PID -n ip link set dev lo down
# 或更彻底：删除 lo 接口（部分内核版本支持）
nsenter -t $PID -n ip link delete lo</container_name>
⚠️ 注意：lo 被删后，容器内 localhost 解析会失败，ping 127.0.0.1 报 Network is unreachable，但 ip addr show 将不再显示 lo。
阻断容器发往宿主机 127.0.0.1 的流量（iptables 方案）
即使容器有 lo，也可在宿主机 FORWARD/OUTPUT 链中拦截其发向 127.0.0.1 的包：
# 匹配从 docker0 出去、目标为 127.0.0.1 的流量（实际不走 FORWARD，走 OUTPUT） iptables -t filter -I OUTPUT -s 172.17.0.0/16 -d 127.0.0.1 -j DROP # 同时限制容器通过 NAT 后发往宿主机 loopback（极少见但存在） iptables -t nat -I PREROUTING -s 172.17.0.0/16 -d 127.0.0.1 -j DROP
✅ 验证方式：
docker exec <container> sh -c "echo 'GET /' | nc 127.0.0.1 8080" # 应超时或返回 Connection refused（非 Connection refused 表示未生效）</container>
替代方案：用 macvlan 或 ipvlan 隔离物理层
若宿主机有闲置网卡或子接口，可创建 macvlan 网络使容器脱离宿主机协议栈：
docker network create -d macvlan \ --subnet=192.168.1.0/24 \ --gateway=192.168.1.1 \ -o parent=eth0 \ isolated-macvlan
容器获得独立 IP，完全不共享宿主机的 127.0.0.1 上下文，天然无法访问宿主机本地服务——除非你显式在物理网络上开放。
不复杂但容易忽略
