关键是要让调试环境共享宿主机网络栈，常用方式是--network host启动netshoot容器执行ss、iptables、ip route等命令；高级场景可挂载/proc/1/ns/net并用nsenter调用宿主机网络接口；结合双向tcpdump抓包对比分析nat与转发路径。
要通过 Docker 网络命名空间特性调试宿主机网络，关键不是“进入容器看宿主机”，而是**让调试环境共享宿主机的网络栈**，从而复现、观察和验证宿主机层面的网络行为（如端口监听、iptables 规则、路由转发、防火墙拦截等）。这本质上是利用 --network host 模式或 netns 工具桥接隔离视图。
用 host 模式启动调试容器
这是最直接、最常用的方式。容器不创建独立网络命名空间，而是直接复用宿主机的 /proc/net/、iptables、ip route 和所有监听套接字。
- 运行轻量调试镜像：
docker run -it --network host --rm nicolaka/netshoot sh - 在其中执行：
ss -tuln查看真实监听端口（含被 Docker 映射隐藏的 80/443）、iptables -L -n -v检查 NAT/FORWARD 链、ip route get 8.8.8.8验证路由路径 - 注意：此时
curl http://localhost:8080就是访问宿主机上真正运行在 8080 的服务（而非某个容器），适合排查端口冲突或代理配置问题
手动挂载宿主机 netns 进容器（高级场景）
当需要保留容器其他环境（如特定工具链、证书、配置），又想临时获得宿主机网络视角时，可将宿主机的网络命名空间绑定进容器：
- 宿主机 netns 路径通常是
/proc/1/ns/net（init 进程的网络命名空间） - 启动容器并挂载：
docker run -it --rm -v /proc/1/ns/net:/host-net:ro ubuntu sh - 在容器内执行：
nsenter -n -t 1 ip a或nsenter -n -t 1 ss -tuln—— 直接调用宿主机内核接口 - 此法绕过
--network host的权限限制（如某些安全策略禁止 host 模式），但需容器有cap_sys_admin权限
对比容器 netns 与宿主机 netns 的差异
定位“为什么容器能通而宿主机不通”或“为什么宿主机能通而容器不通”这类问题，必须并行观察两个命名空间：
- 查容器 IP 和路由：
docker exec -it myapp ip a && ip route - 查宿主机对应信息：
ip a && ip route（注意 docker0 网桥、默认路由、FORWARD 策略） - 重点比对：
– 容器是否在正确网段（如 172.17.0.0/16）且网关可达
– 宿主机iptables -L FORWARD是否 DROP 了容器流量
–sysctl net.ipv4.ip_forward是否为 1（bridge 模式必需）
结合 netshoot + tcpdump 抓包分析路径
单纯看配置不够，要验证实际数据包走向：
- 在宿主机网络上下文中抓包：
docker run -it --network host --cap-add=NET_RAW --cap-add=NET_ADMIN nicolaka/netshoot tcpdump -i any port 8080 -w /tmp/host.pcap - 在容器 netns 中抓包（需先获取其 netns）：
pid=$(docker inspect -f '{{.State.Pid}}' myapp) && nsenter -n -t $pid tcpdump -i eth0 port 80 - 对比两份 pcap：确认请求是否到达宿主机、是否被 DNAT、是否从 docker0 转发、是否被 SNAT 回包 —— 这是诊断 NAT 和连接跟踪问题的核心手段
