.NET 项目 Docker 化 + Nginx 反向代理，一篇讲透

关注

原创最新推荐文章于 2026-11-08 23:07:35 发布 379 阅读 AI 写同款· GEO 优化 ›

Docker与Nginx核心原理与实战：从容器隔离到反向代理架构容器化部署已成为现代后端服务的标配，而Docker与Nginx的组合更是运维工程师必须掌握的核心技能。理解容器如何通过Namespace实现可见性隔离、通过Cgroups限制资源使用，是摆脱“命令搬运工”的关键。反向代理则解决了流量分发问题，Nginx基于事件驱动的异步非阻塞模型支撑高并发，其localtion匹配规则、proxy_pass转发细节及负载均衡策略，决定了生产环境的稳定性。从静态站点托管到HTTPS终止，从容器网络打通到配置继承逻辑，这套架构贯穿了中小型公司的典型部署场景。掌握Docker镜像阅读详情

大家好，我是码农刚子。前几天帮朋友排查一个 .NET 项目的部署问题，他说「我本地跑得好好的，一上服务器就崩」。

翻了一下他的 Dockerfile，问题挺典型的——单阶段构建、镜像 800MB、端口没映射对、Nginx 配置抄了份三年前的老模板。

今天把这一套从头到尾理一遍，从 Dockerfile 到 Compose 再到 Nginx 反向代理，每一步讲清楚「为什么这么写」，而不是只给一段能跑的代码。

1. 先搞懂：你到底需要几层构建

很多人写 .NET 的 Dockerfile，上来就 FROM mcr.microsoft.com/dotnet/sdk:8.0，然后 build + run 全在一个镜像里。

结果镜像动不动七八百 MB，部署拉取慢得要死。

正确的做法是多阶段构建——用 SDK 镜像编译，用 ASP.NET Core 运行时镜像跑。

打个比方，你盖房子的时候需要起重机（SDK），但住进去的时候不需要把起重机也留在家里。

核心思路： 构建阶段用 SDK 镜像（大而全），运行阶段用运行时镜像（小而精），最终只保留运行时那一层。

来看一份标准的 ASP.NET Core Dockerfile：

# 第一阶段：构建（publish）
FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src

# 先拷贝 .csproj，利用 Docker 缓存
COPY *.csproj .
RUN dotnet restore

# 再拷贝全部源码
COPY . .
RUN dotnet publish -c Release -o /app/publish

# 第二阶段：运行（runtime）
FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime
WORKDIR /app
COPY --from=build /app/publish .

EXPOSE 8080
ENTRYPOINT ["dotnet", "YourApp.dll"]

这里有两个细节很多人踩坑。

第一个，为什么先拷贝 .csproj 再拷贝全部代码？

因为 Docker 是分层缓存的。如果每次改一行代码就要重新 restore 一次 NuGet 包，那构建速度会慢到怀疑人生。

先拷贝 .csproj → restore → 再拷贝源码 → publish，这样只要 .csproj 没变，restore 那一层就能直接用缓存。

第二个，端口到底是 80 还是 8080？

这是个经典坑。.NET 8 开始，官方 ASP.NET Core 镜像的默认端口从 80 改成了 8080。

如果你还照着老教程写 EXPOSE 80，容器跑起来之后你会发现怎么都访问不到——不是服务没启动，是端口不对。

2. Docker Compose：把多服务串起来

如果你的项目只有一个 Web 应用，docker run 一下就够了。

但现实场景里，通常不止一个服务——Web 应用 + 数据库 + Redis + Nginx，四五个容器是常态。

这时候 Docker Compose 就是标配。

来看一份典型的 docker-compose.yml：

version: '3.8'

services:
  webapp:
    build:
      context: ./YourApp
      dockerfile: Dockerfile
    ports:
      - "5000:8080"
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ConnectionStrings__Default=Host=db;Database=appdb;Username=postgres;Password=secret
    depends_on:
      - db
      - redis
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      - POSTGRES_DB=appdb
      - POSTGRES_PASSWORD=secret
    volumes:
      - postgres_data:/var/lib/postgresql/data
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    volumes:
      - redis_data:/data
    restart: unless-stopped

volumes:
  postgres_data:
  redis_data:

说几个容易忽略的点。

depends_on 只保证启动顺序，不保证服务就绪。

很多人以为加了 depends_on，Web 就会等数据库准备好再启动。其实不是，它只等容器启动，不等服务就绪。

PostgreSQL 容器起来了，但数据库初始化还没完成，这时候 Web 去连就会报错。

解决办法有两种：一是在程序里加重试逻辑（推荐用 Polly），二是用 healthcheck + condition。

# 在 db 服务里加健康检查
healthcheck:
  test: ["CMD-SHELL", "pg_isready -U postgres"]
  interval: 5s
  timeout: 5s
  retries: 5

# 在 webapp 的 depends_on 里指定条件
depends_on:
  db:
    condition: service_healthy
  redis:
    condition: service_started

数据一定要挂 volume。

数据库的数据、Redis 的持久化文件、用户上传的文件，这些都不能放在容器里。

容器一删数据就没了，到时候哭都来不及。

3. Nginx 反向代理：为什么需要它

有人会问，Kestrel 本身就是 Web 服务器，直接暴露端口不行吗，为什么还要在前面加一层 Nginx？

这个问题问得好。

Kestrel 确实是个不错的服务器，但它的设计目标是处理动态请求。静态文件、负载均衡、SSL 终止、限速、压缩这些事，交给 Nginx 效率高得多。

可以这么理解——Kestrel 是做菜的厨师，Nginx 是前厅的服务员。厨师也能端菜，但专业的事交给专业的人来做，整体效率更高。

来看一份完整的 Nginx 反向代理配置：

# /etc/nginx/conf.d/your-app.conf

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    # 静态文件直接由 Nginx 处理
    location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff2?)$ {
        root /var/www/your-app/wwwroot;
        expires 30d;
        access_log off;
    }

    # 动态请求转发给 Kestrel
    location / {
        proxy_pass http://webapp:8080;
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection keep-alive;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_buffering off;
        proxy_read_timeout 100s;
    }
}

这段配置看起来长，但核心就两件事：静态文件自己处理，动态请求转发给后端。

重点说几个 header 的作用，很多人抄了配置但不知道为什么要加。

X-Forwarded-For 和 X-Forwarded-Proto——告诉后端用户的真实 IP 和请求协议（http 还是 https）。没有这两个头，你的 .NET 程序拿到的 IP 永远是 Nginx 容器的 IP，而且会以为所有请求都是 http 的。

Host——保留原始域名。不然重定向的时候会跳转到内部地址，用户就懵了。

Upgrade 和 Connection keep-alive——支持 WebSocket 和长连接。如果你的应用用了 SignalR，这两行必须有。

光配置 Nginx 还不够，.NET 这边也要配合一下。在 Program.cs 里加上转发头中间件：

// Program.cs 里，在 builder.Build() 之前加
builder.Services.Configure<ForwardedHeadersOptions>(options =>
{
    options.ForwardedHeaders =
        ForwardedHeaders.XForwardedFor |
        ForwardedHeaders.XForwardedProto;
    options.KnownNetworks.Clear();
    options.KnownProxies.Clear();
});

// 在 app.UseHttpsRedirection() 之前加
app.UseForwardedHeaders();

KnownNetworks 和 KnownProxies 清空是因为 Docker 环境里代理 IP 不固定，不清除的话转发头会被忽略——这个坑我踩过两次。

4. 把 Nginx 也放进 Compose 里

既然所有服务都容器化了，Nginx 当然也不应该单独装在宿主机上。

把 Nginx 加到 docker-compose.yml 里，整个部署就完整了：

services:
  webapp:
    build: ./YourApp
    expose:
      - "8080"
    # 注意：这里用 expose 而不是 ports
    # 因为只需要被 Nginx 访问，不需要暴露到宿主机
    restart: unless-stopped

  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/conf.d:/etc/nginx/conf.d
      - ./nginx/ssl:/etc/nginx/ssl
      - ./nginx/logs:/var/log/nginx
    depends_on:
      - webapp
    restart: unless-stopped

这里有个细节：webapp 用 expose，不用 ports。

expose 只是声明容器内部用哪个端口，不会映射到宿主机。所有外部请求都走 Nginx，webapp 不直接对外——安全上更干净。

而且在同一个 Compose 网络里，服务之间可以直接用服务名通信，所以 Nginx 配置里 proxy_pass http://webapp:8080 直接就能通，不需要查 IP。