Docker容器Win11正常运行但Ubuntu Server启动后立即退出排查

• 基于VS 2022创建.NET 6版本模板化托管Blazor WASM应用，使用VS默认生成的Dockerfile添加Docker支持，未做自定义修改
• 本地构建完成的镜像推送至Docker Hub
• 测试前清空环境中所有缓存镜像、容器，执行docker images -a、docker ps -a均无返回结果
• 分别在Win11开发机、Ubuntu服务器执行docker pull拉取同一镜像
• 两个环境使用完全相同的启动命令：docker run -dit -p 5000:80 username/imagename

运行结果差异 #

• Win11环境：容器后台正常运行，状态为UP，可通过localhost:5000正常访问应用
• Ubuntu环境：容器启动后约3秒随即退出，状态为Exited (0)
  • 执行docker logs containername无任何日志返回
  • 执行docker inspect查看核心配置："Architecture": "amd64", "Os": "linux", "Entrypoint": [ "dotnet", "App.Server.dll" ]，配置无明显异常

问题涉及的Dockerfile #

FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build
WORKDIR /src
COPY ["TestApp/Server/TestApp.Server.csproj", "TestApp/Server/"]
COPY ["TestApp/Shared/TestApp.Shared.csproj", "TestApp/Shared/"]
COPY ["TestApp/Client/TestApp.Client.csproj", "TestApp/Client/"]
RUN dotnet restore "TestApp/Server/TestApp.Server.csproj"
COPY . .
WORKDIR "/src/TestApp/Server"
RUN dotnet build "TestApp.Server.csproj" -c Release -o /app/build

FROM build AS publish
RUN dotnet publish "TestApp.Server.csproj" -c Release -o 
/app/publish

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "TestApp.Server.dll"]

容器退出码为0代表主进程（即dotnet App.Server.dll）为主动正常退出，而非崩溃、被系统强制杀死，排查核心是拿到dotnet进程的实际运行输出，按以下顺序操作即可定位问题：

• 查看容器状态元数据
  退出的容器未被删除时，执行docker inspect 容器名 | grep -A 15 "State"，查看Error字段内容，部分启动错误会直接记录在该字段中，无需重新启动容器即可获取信息。
• 前台启动容器获取实时输出
  去掉后台启动参数，直接执行docker run --rm -p 5000:80 username/imagename，不要加-d（后台运行）、-t（分配伪终端）参数，dotnet进程的所有启动日志、报错信息会直接打印在当前控制台，绝大多数场景下这一步就能直接看到明确的错误原因，比如文件缺失、配置错误、权限不足等。
• 进入容器内部手动复现启动流程
  如果前台启动依然无输出直接退出，执行docker run --rm -it --entrypoint sh username/imagename覆盖默认入口点，进入容器shell后依次操作：
  • 执行ls查看工作目录下的文件列表，确认入口点配置的dll文件是否存在、文件名完全匹配
  • 手动执行入口命令dotnet 对应dll文件名，完整复现启动流程，查看所有输出

结合跨环境运行的常见问题，该问题绝大多数是文件名大小写不匹配导致：

• Windows文件系统不区分大小写，Win11环境下运行时，即使ENTRYPOINT配置的dll文件名和实际发布出的dll文件名大小写不一致，dotnet也能正常找到文件完成启动
• Linux文件系统严格区分大小写，如果ENTRYPOINT里的dll文件名和实际文件的大小写存在差异，会导致dotnet无法找到入口文件。正常该场景会打印报错并返回非0退出码，如果镜像在构建时存在发布产物路径错误、或者使用VS调试模式构建的非标准镜像被推送到Docker Hub，可能出现无日志直接退出的情况。

另外贴出的Dockerfile中，publish阶段的RUN dotnet publish命令里-o参数后存在不必要的换行，如果实际构建使用的Dockerfile确实存在该换行，会导致发布产物没有被正确拷贝到最终镜像的工作目录，也会引发启动异常，但该问题会在镜像构建阶段就报错，不会成功推送至Docker Hub。

补充说明：Win11的Docker Desktop会自动为ASP.NET Core容器注入ASPNETCORE_URLS=http://+:80环境变量，Ubuntu原生Docker不会自动注入该变量，该问题只会导致应用默认绑定到容器内部的5000端口、外部无法访问，不会引发容器直接退出，可在启动时添加-e ASPNETCORE_URLS=http://+:80参数排除该影响。

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