Azure Linux应用服务Docker容器内运行.NET Core控制台应用的启动问题

针对纯控制台常驻程序无HTTP服务、无法满足默认80端口HTTP探活要求的场景，可通过以下3种无侵入的方式解决启动失败问题：

• 在控制台程序中内置极轻量探活响应
  不需要重构业务逻辑，仅在现有程序启动流程中并行增加一个不占用主流程的HTTP监听任务，仅对探活请求返回200状态即可，完全不干扰原有循环延时的常驻执行逻辑。示例代码：

  static async Task Main(string[] args)
  {
      // 并行启动探活监听任务，独立线程运行
      _ = Task.Run(async () =>
      {
          var listener = new HttpListener();
          listener.Prefixes.Add("http://+:80/");
          listener.Start();
          while (true)
          {
              // 接收探活请求，直接返回200 OK
              var ctx = await listener.GetContextAsync();
              ctx.Response.StatusCode = 200;
              ctx.Response.Close();
          }
      });
  
      // 保留原有全部常驻业务逻辑，无任何修改
      await RunInfiniteLoopWithDelay();
  }
  

  这个轻量监听的内存占用不到10MB，每30秒一次的探活请求不会对业务运行产生任何影响。

• 通过Docker镜像内置健康检查覆盖默认探活规则
  Linux App Service 的探活逻辑存在优先级：如果检测到Docker镜像配置了HEALTHCHECK指令，会自动跳过默认的80端口HTTP ping校验，转而读取容器自身的健康检查结果。你只需要在现有Dockerfile末尾增加对应配置即可，不需要修改业务代码：

  # 配置健康检查：仅校验主控制台进程是否正常运行
  HEALTHCHECK --interval=30s --timeout=3s \
  CMD pgrep -f "your-console-app-name" || exit 1
  

  pgrep是Linux基础镜像自带的进程查询命令，不需要额外安装依赖。配置完成后，App Service 的启动校验逻辑会匹配容器健康检查的返回值，只要主业务进程持续运行，就不会触发启动超时、终止站点的逻辑。

• 通过应用设置关闭默认HTTP探活校验
  如果不想在代码或Docker配置中做任何调整，可在App Service的应用配置页新增以下环境变量，直接禁用默认的80端口HTTP探活检测：

  • 配置项键：WEBSITE_SKIP_CONTAINER_HEALTHCHECK
  • 配置项值：true
    保存配置后站点会自动重启，启动过程中不再主动向容器80端口发起HTTP探活，只要容器主进程持续运行，就会判定启动成功。

注意：上述方案任选其一即可，不需要叠加使用。原报错中提到的230秒超时、80端口无响应问题，本质是App Service 默认探活逻辑和非Web类容器的运行形态不匹配，适配任意一种校验规则后即可解决。

内容的提问来源于stack exchange，提问作者Andrew