这种故障确实很容易被误判成 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...

这套思路很实用，尤其是提醒了扩容并不等于滚动替换，生产环境直接依赖 `--scale` 确实容易误判。我们实践中更倾向蓝绿部署，并给新环境设置一段预热观察期：先检查健康状态，再通过代理发送少量真实请求，确认数据库连接、缓存和核心接口正常后才切换全部流量。 另外建议发布脚本加入锁机制，避免多人重复执行；同时记录当前项目名、镜像摘要和代理配置，回滚时可直接恢复。健康检查最好区分存活与就绪状态，实例退...

之前遇到过容器每次停止都卡满 10 秒，最后发现启动脚本没有用 exec，Java 进程并不是 PID 1，导致 SIGTERM 没有正常传递。修改后再配合应用的关闭钩子，停止速度和日志完整性都改善了。

补充一个实践建议：在编排环境中，还要把容器的停止宽限期与应用内部超时协调好，并预留连接池关闭、日志刷新所需的时间。测试时可持续发送慢请求再执行停止，确认新流量已被摘除、存量请求能完成...

实际部署中，最容易踩坑的确是把宿主机端口和容器端口混用，或者在容器里写 localhost。分成 frontend、backend 后，服务依赖关系会直观很多，也能避免数据库无意暴露。跨项目共享网络时，我更倾向给服务设置带项目前缀的别名，能减少重名导致的解析混乱。排障顺序也很实用：先看网络连接，再查 DNS，然后测试端口和进程监听地址，通常比一开始就翻应用日志更快定位问题。

这套排查顺序很实用，尤其是强调比较数字 UID/GID，比只看用户名可靠得多。我补充一个小技巧：可以在容器内直接执行 namei -l /app/data，逐级查看路径中每个目录的所有者和权限，定位父目录缺少执行权限的问题会更快。

另外，修改权限前建议先用临时文件验证创建、改写和删除是否都正常，因为“能写入”不代表“能删除”。团队开发时更推荐...