Seccomp通过禁用socket、bind、connect、listen、accept4、sendto、recvfrom等底层系统调用实现网络限制，推荐采用defaultAction: SCMP_ACT_ALLOW配合SCMP_ACT_ERRNO拒绝策略，并确保规则文件路径正确、权限可读。
Seccomp 本身不直接识别“网络”或“Socket”这类语义概念，它只按系统调用名称（syscall name）和参数做过滤。所谓“禁止网络 Socket 系统调用”，实际是指禁用
socket
、
bind
、
connect
、
listen
、
accept4
、
sendto
、
recvfrom
等与网络通信强相关的底层 syscall。但需注意：盲目全禁会导致容器无法启动（如 Go 程序初始化时会尝试读取 /proc/sys/net/ 目录，触发 socket 相关探测），因此必须结合应用行为精准控制。
明确要禁用的核心 Socket 相关系统调用
以下是最常被用于主动建立或管理网络连接的系统调用，属于高风险拦截目标：
socket
：创建套接字，是所有网络通信起点
bind
：绑定地址端口，常用于服务监听
connect
：发起客户端连接，攻击者常用其外连 C2
listen
和
accept4
：服务端接受连接，暴露监听面
sendto
/
recvfrom
：UDP 通信主调用，也用于某些原始套接字操作
编写可落地的 Seccomp JSON 规则片段
推荐采用“默认允许 + 显式拒绝”策略（defaultAction: SCMP_ACT_ALLOW），避免白名单遗漏导致容器崩溃。以下规则将阻止任意进程调用 socket 类系统调用，并返回 EPERM 错误：
说明：
• 使用
SCMP_ACT_ERRNO
而非
SCMP_ACT_KILL
，避免因日志采集、健康检查等短暂调用直接杀死进程；
• 若需更严格防护（如无任何网络需求的离线计算容器），可改用
SCMP_ACT_KILL
，内核将立即终止违规进程；
• 不建议对
getsockopt
、
setsockopt
盲目禁用——它们常被 glibc 或运行时用于查询本地 socket 状态，禁用易致 panic。
Docker Sandbox
创建并管理 Docker 沙箱虚拟机环境以安全执行代理。适用于运行不受信任代码、探索包或隔离代理工作负载。支持 Claude、Codex、Copilot、Gemini 和 Kiro 代理，并提供网络代理控制。
下载
验证规则是否生效并定位失败调用
禁用后若容器异常退出或功能失效，需快速确认是否为 Seccomp 拦截所致：
在宿主机上运行：
dmesg -T | grep "SECCOMP"
，查看内核日志中是否有类似
"seccomp killed process"
的记录
进入正在运行的容器，执行：
strace -f -e trace=socket,connect,bind 2>&1 | head -20
，观察哪些调用被阻断及返回值（EPERM 即被 Seccomp 拦截）
使用
dockerinspect
检查
是否正确挂载了 seccomp 配置路径
部署注意事项：路径、权限与兼容性
规则文件必须被 Docker daemon 正确加载，否则配置无效：
文件须存放在 daemon 可读路径，例如
/etc/docker/seccomp-no-network.json
，不能用
或
确保 root 用户（daemon 运行身份）有读权限：
sudo chmod 644 /etc/docker/seccomp-no-network.json
启动容器时显式指定：
docker run --security-opt seccomp=/etc/docker/seccomp-no-network.json ...
Kubernetes 用户需通过
字段挂载，且 profile 必须预置于节点
下
{
"defaultAction": "SCMP_ACT_ALLOW",
"syscalls": [
{
"names": ["socket", "bind", "connect", "listen", "accept4", "sendto", "recvfrom"],
"action": "SCMP_ACT_ERRNO"
}
]
}HostConfig.SecurityOpt./~/securityContext.seccompProfile/var/lib/kubelet/seccomp/