先执行ps aux --sort=-%mem | head -10确认docker-proxy是否进入前五，若仅排第七八位且%MEM仅1.2%则无需深查；再用docker ps -q | xargs docker inspect等命令统计端口映射数，超80行即表明docker-proxy实例激增；最后通过pgrep、/proc//cmdline等定位高RSS进程并反查对应容器行为。
确认 docker-proxy 进程是否真正在占用高内存
先在宿主机执行 ps aux --sort=-%mem | head -10，观察 docker-proxy 进程的 %MEM 是否排进前五。若它只是排在第七八位、占用 1.2%，就不用往下查——【docker-proxy 本身极轻量，单实例通常只占几 MB，超过 100MB 就异常】。
接着运行 docker ps -q | xargs -r docker inspect --format '{{.Id}} {{.HostConfig.PortBindings}}' 2>/dev/null | grep -v "null"，快速统计当前有多少端口映射在运行。如果输出行数超过 80 行，说明大量容器开启了 -p 映射，这正是 docker-proxy 实例激增的直接原因。
定位具体是哪个 docker-proxy 占内存高
执行 pgrep -f "docker-proxy" | xargs -r ps -o pid,ppid,vsz,rss,comm -p，列出所有 docker-proxy 进程的 PID、父进程 PID、虚拟内存（VSZ）和物理内存（RSS）。
重点看 RSS 列：挑出 RSS > 50000（即约 50MB）的进程，记下其 PID。
对这个 PID 执行 cat /proc/<pid>/cmdline | tr '<p>对这个 PID 执行 <code>cat /proc/<pid>/cmdline | tr '\0' '\n'</pid>，你会看到类似 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8080 -container-ip 172.17.0.3 -container-port 80 的输出——【最后两个参数就是它代理的容器 IP 和端口，立刻反查对应容器】。
/usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8080 -container-ip 172.17.0.3 -container-port 80 的输出——【最后两个参数就是它代理的容器 IP 和端口，立刻反查对应容器】。
查清背后容器的真实行为
第一步：用上一步拿到的 container-ip（如 172.17.0.3）反查容器名：docker network inspect bridge | jq -r '.Containers[] | select(.IPv4Address | startswith("172.17.0.3/")) | .Name'
第二步：进入该容器，运行 netstat -tuln | grep :80（把 80 换成你查到的 container-port），确认应用确实在监听该端口。如果没监听，说明端口映射冗余，应删掉。
第三步：检查该容器是否启用了健康检查且探针失败后疯狂重试：docker inspect | jq '.Healthcheck'。若存在且 Interval ≤ 5s 且 Retries ≥ 5，就可能让 docker-proxy 长时间维持连接状态，间接推高内存——这不是 docker-proxy 的 bug，而是它在忠实转发失败探针时累积了 socket 状态。
立即释放资源的两种操作
方法一：停掉问题容器并清理其端口映射docker stop && docker rm 。这会自动销毁关联的 docker-proxy 进程，内存立刻归零。
方法二：不重启容器，仅关闭其暴露端口docker update --publish-all=false ，再手动删掉宿主机上残留的 iptables 规则：iptables -t nat -L DOCKER --line-numbers | grep <host-port> | awk '{print $1}' | xargs -r -I{} iptables -t nat -D DOCKER {}</host-port>。执行完后，对应 docker-proxy 进程会在 30 秒内自动退出。
