一、 核心故障复盘与根因分析

故障现象

表象排查

根本原因

根治原则

1. 容器循环重启 / 闪退


Address in use (bind: 80)

容器刚进就退，日志报端口无法绑定

容器错误使用了 --net=host 或外部配置冲突，与宿主机已有的 Nginx（PID 1300/1306）端口争抢

隔离原则：容器化服务优先使用默认 Bridge 网络，用宿主机空闲端口（如 83、8088）映射容器 80。

2. 构建构建中断 (exit code 2)


HTTP 403 / rm 报错

清华源返回 403，后续清理命令执行报错

国内镜像节点临时不可用；RUN 指令中 rm -rf /var/cache/ rm -f ... 存在语法断句错误

构建原子性：基础镜像换用高可用镜像源（如 aliyun）；安装依赖配合 --no-cache 避免手写冗余清理指令。

3. 脚本雪崩连锁报错


registry: not in allowlist

构建失败后，继续盲目执行容器 rm 和 run

build.sh 缺少失败熔断，本地没生成新镜像却尝试去公网 Docker Hub 拉取私有命名的镜像

自动化鲁棒性：Shell 脚本顶部声明 set -e，保障“前步失败即刻终止”，避免雪崩调用。

4. 网页请求 502 Bad Gateway


HTTP ERROR 502

浏览器直接访问域名无法到达页面

宿主机 80 端口原有 Nginx 的反代配置未对齐后端容器实际暴露的端口

链路拆解：遇到 502 先在宿主机本地 curl 127.0.0.1:端口 测后端，确认后端健康后再调前端反代。

5. 网页请求 403 Forbidden


curl 返回 403

网络通了但 Nginx 拒绝访问静态页面

解压包自带同名外层目录导致文件层级嵌套，且 Nginx 未显式配置 index

解压前验：打包/解压前先用 tar -tf 预览结构；写 Nginx 配置必配 index index.html 指令。

二、 技术思维维度的经验总结

  1. 坚持分层验证，杜绝凭空猜测

    • 排查网络与服务链路，必须遵循：容器进程运行状态 (docker ps) -> 容器内部监听 (ss -tulpn) -> 宿主机端口映射连通 (curl -I 127.0.0.1:端口) -> 宿主机外层反代 (proxy_pass) -> 本地解析 (hosts)。

    • 当看到 403 时，说明前面的网络打通已经成功了 90%，排查重心应立即从“网络层”切回“文件系统与权限层”。

  2. Docker 构建中的上下文与路径意识

    • ADD 指令虽然方便，但会自动解压，极易因为压缩包内部的目录结构引发路径二次嵌套问题。

    • 在制作镜像前，养成在宿主机使用 tar -tf xxx.tar.gz | head 预览包内相对路径的习惯，或者在打包阶段就统一使用 tar -zcf ... -C dir . 去除多余根目录。

  3. 宿主机业务与容器业务的边界感

    • 宿主机如果已经承担了特定网络角色（如已运行宿主机 Nginx 占用了 80/81 端口），新容器就不能再无脑占用标准端口。

    • 优雅的架构应该是：宿主机 Nginx 作为顶层统一流量入口，根据域名（Server Name）反向代理转发给内层不同容器映射出来的私有端口。