查容器内进程在宿主机上的真实pid，应先用docker inspect获取容器init进程宿主机pid，再用nsenter -t -n ps查看；docker top显示的是容器内pid而非宿主机pid。
容器内进程在宿主机上的PID怎么查
直接看 /proc/[container_pid]/status 里的 NSpid 字段不靠谱——它只反映 PID namespace 内的层级，不是宿主机真实 PID。真正要定位物理 PID，得从容器 runtime 的视角反查：Docker 把容器进程作为子进程托管在 dockerd 或 containerd-shim 下，但实际工作进程（比如你 docker exec -it xxx /bin/sh 启的 shell）是独立的 Linux 进程，有自己在 init namespace 中的真实 PID。
最稳的方式是进容器先拿到目标进程的 PID（比如 ps aux | grep nginx 得到 123），再在宿主机上用 nsenter 切入该容器的 PID namespace 查映射：
nsenter -t <container_pid> -n ps -eo pid,comm --sort=-pid | head -10</container_pid>
其中 <container_pid></container_pid> 是容器 init 进程在宿主机的 PID，可用 docker inspect -f '{{.State.Pid}}' <container_name_or_id></container_name_or_id> 拿到。注意：这个 nsenter 命令输出的第一列就是该进程在宿主机上的真实 PID（因为 -n 进入的是容器的 PID namespace，而 ps 默认显示当前 namespace 视角下的 PID，和宿主机一致）。
为什么 docker top 显示的 PID 不是宿主机物理 PID
docker top 实际调用的是 containerd 的 ListProcesses API，返回的是容器 PID namespace 内的 PID（即相对于容器 init 的 PID），不是全局 PID。比如容器里看到的 1 是 nginx 主进程，宿主机上它可能是 8942 ——docker top 绝对不会告诉你 8942。
- 它不穿透 PID namespace，只做容器内部视图聚合
- 在使用
--pid=host启动的容器里，docker top输出才可能和宿主机 PID 一致，但这属于特例，不能作为排查依据 - 遇到容器逃逸线索（如异常进程监听 0.0.0.0:6666），必须确认该进程是否真以宿主机 PID 身份运行，否则会误判为“只是容器内行为”
用 pgrep 和 ps 直接扫宿主机风险高吗
不高，但容易漏。直接在宿主机跑 pgrep -f 'malware' 或 ps aux | grep 'python -c.*exec' 能发现脱离容器约束的进程，前提是攻击者没刻意隐藏或重命名进程名。但更隐蔽的逃逸方式（如利用 /proc/sys/kernel/modules_disabled 加载恶意内核模块、或通过 ptrace 劫持其他进程）不会体现为独立进程，这时候光看 PID 没用。
关键判断点在于：该进程是否在容器 cgroup 路径下。检查方法：
ls -l /proc/<pid>/cgroup</pid>
如果输出里包含 docker/ 或 kubepods/ 路径，说明仍在容器资源约束中；如果只有 init.scope 或空路径，就极可能已逃逸到宿主机。
排查时最容易忽略的两个点
一是容器 init 进程崩溃后残留的子进程：Docker 可能已标记容器为 Exited，但它的子进程（比如后台 curl 或 nc）仍以孤儿进程身份活在宿主机 PID namespace 中，docker ps 看不见，ps aux 却能扫到。
二是 docker run --privileged 容器里启动的进程，即使 PID 在容器 namespace 内，也可能通过 /dev/kmsg、/sys/module 等路径完成提权，此时它的 PID 是合法的，但行为已越界——不能只盯 PID，得同步检查 /proc/<pid>/status</pid> 的 CapEff: 字段和 /proc/<pid>/attr/current</pid> 是否含 unconfined。
