排查思路很实用，尤其是先看完整报错和 inspect 配置，而不是直接上 privileged。补充一点：做最小化对照测试时，最好固定镜像版本、启动参数和宿主机环境，每次只调整一个变量，否则容易误判。生产环境可以把 CapAdd、设备映射和 SecurityOpt 纳入配置审查，并注明授权用途。遇到 CAP_SYS_ADMIN 这类范围过大的能力，优先考虑把初始化操作放到宿主机或独立工具容器中完成...

补充一个容易忽略的点：修改 daemon.json 后，不仅要校验配置和重启 Docker，还要确认业务容器确实已经重新创建，否则旧容器仍会沿用原来的日志策略。实际排查时可以先记录大日志对应的容器、增长速度和错误类型，再处理文件，避免清理后丢失根因线索。

另外，Compose 项目最好在模板里统一声明 logging 配置，并把磁盘剩余空间和日志增长率同时纳入告警。单看磁盘使用...

这篇整理得很实用，尤其是强调了“容器运行不等于应用可用”。实际排查时，我通常先看 docker inspect 里的健康检查输出，再进容器执行同一条命令，这样很快就能区分是应用故障，还是缺少 curl、端口写错、权限不足等探测问题。补充一点：健康接口最好区分存活与就绪，存活检查只验证核心进程能否响应，就绪检查再判断数据库等必要依赖，避免外部服务短暂抖动导致误报。另...

实际项目里最容易忽略的确实是“最终镜像到底带进了什么”。除了控制复制范围，我通常还会在 CI 中检查镜像历史、以容器方式列出关键目录，并配合漏洞扫描，避免仅凭体积判断是否安全。另一个经验是不要盲目使用 scratch，证书、时区和排障工具缺失会增加运维成本。先保证运行依赖完整，再逐步精简，同时固定基础镜像摘要、使用非 root 用户，整体会更稳妥。

这种故障确实很容易被误判成 DNS 或应用超时。补充一点：如果业务短期内不能重建 Docker 网络，可以先在宿主机上通过 TCP MSS Clamping 做临时验证，观察 HTTPS、文件上传是否恢复，但不建议把它当作最终方案。正式调整 MTU 前，最好分别记录宿主机和容器的测试结果，并保留抓包作为变更依据。生产环境还要特别注意：修改 daemon.json 后，仅重启 Docker 不...

写得很实用，尤其是按“容器内、宿主机本地、宿主机网卡、远程客户端”逐层测试，比一上来折腾防火墙高效得多。我补充一个容易忽略的点：排查时可以同时用 tcpdump 抓取目标网卡和 docker0 上的 8080、80 端口流量，确认数据包到底在哪一层消失。若规则看似正确但访问仍异常，还应核对 Docker 使用的网络驱动、容器 IP 是否变化，以及系统实际采用的是 ...

排查重启循环时，先执行 docker update --restart no 容器名 很关键，既能避免日志被快速刷掉，也方便保留故障现场。实际维护中，我还会结合 docker inspect 查看退出码、OOMKilled 和 RestartCount，再按时间顺序核对应用日志。 另外，建议为服务补充健康检查和启动依赖检测。容器...

写得很实用，尤其是强调要查看真实业务进程的限制，而不能只看宿主机终端的 ulimit。实际排障时，我一般还会记录一段时间内的 fd 数量，例如定时统计 `/proc/PID/fd`，这样更容易区分瞬时并发高峰和持续泄漏。若发现 Socket 占比高，可以结合连接状态、连接池指标排查；若出现大量 deleted 文件，则优先检查日志轮转。临时提高 nofile 后也要持续观察使用率和回落情况，并把 ...

讲得很实用，尤其是先用 8080 验证链路，再定位低端口权限，这个思路能避免在容器配置上反复绕圈。我补充一点：执行 setcap 前最好用 systemctl --user cat docker 或查看进程启动参数，确认服务实际调用的 rootlesskit 路径，防止改错同名文件。升级 Docker 后也要重新执行 getcap 检查能力是否保留。生产环境我也更...

之前遇到过类似问题，最后发现不只是应用没回收子进程，入口脚本也多包了一层 shell。改成 Exec 形式并在脚本末尾使用 exec 后，docker stop 的退出速度明显正常了。对于会频繁调用转码器、浏览器或外部命令的服务，建议先用 ps 按 PPID 追到真正的父进程，再连续观察僵尸数量，而不是看到 Z 状态就直接重启。启用 init 确实能快速兜底，但应用里的 wait、超时取消和 SI...