如何配置Azure上的容器化Django应用以避免崩溃？

delayed connect error: 111 本质是TCP连接被拒绝，说明Azure的反向代理组件（如App Service前端、AKS Ingress）无法正常连接到你的Django容器实例。以下是针对性的排查步骤：

• 核对端口配置一致性
  确保Django服务监听的端口、容器暴露的端口、Azure平台配置的目标端口三者完全匹配：

  • Django启动命令需绑定0.0.0.0（而非127.0.0.1），比如python manage.py runserver 0.0.0.0:8000
  • Dockerfile中需通过EXPOSE 8000声明端口
  • Azure端（App Service容器设置/AKS Service配置）的目标端口要设为对应数值

• 配置健康检查避免提前连接
  Azure代理可能在Django服务完全就绪前发起连接，导致连接拒绝：

  • 给Django添加一个简单的健康检查端点（如/health，返回200状态码）
  • 在Azure配置中设置就绪探针，指向该端点，并调整启动延迟时间，给Django足够的初始化时间（比如数据库连接、静态文件收集）

• 排查资源耗尽导致的服务崩溃
  容器资源不足会直接终止Django进程：

  • 在Azure门户查看容器的CPU/内存使用率，确认是否触发了资源上限
  • 调整容器的资源配额，同时优化Django内存占用（如关闭冗余中间件、优化数据库查询、使用缓存）

• 检查网络访问规则

  • 若使用AKS，确认Ingress控制器与Pod之间的网络策略没有拦截目标端口的流量
  • 若使用App Service，排查VNet防火墙、NSG规则是否阻止了代理到容器的内部通信

• 通过容器日志定位崩溃根源
  直接查看Django进程的崩溃日志：

  • App Service：使用门户的「日志流」或az webapp log tail命令实时查看
  • AKS：执行kubectl logs <pod-name>获取Pod日志，重点关注数据库连接失败、依赖缺失、代码报错等导致服务退出的信息

• 排查Azure平台临时异常
  偶尔出现的崩溃可能和平台调度有关：

  • 查看容器的重启历史，确认是否存在频繁重启的情况
  • 若使用AKS，检查节点状态是否正常，有无节点驱逐、平台维护事件

内容的提问来源于stack exchange，提问作者Jean Paul Ruiz